Elegiste una herramienta de código con IA. Te registraste. En algún punto de ese flujo, o se quedó con tu cuenta de proveedor, o te entregó su propio modelo sin manera de cambiarlo. Fue cómodo durante una semana.
Luego el modelo del que dependías cambió. O se movió el precio. O necesitaste correr una tarea en un avión sin red. Y descubriste, por las malas, que el modelo no era un ajuste que pudieras editar. Estaba soldado al producto, y cambiarlo significaba cambiar de producto.
Traer tu propio modelo es la apuesta contraria. Tú pones la clave. Tú apuntas al motor. La herramienta trata el modelo como una pieza, no como su propio corazón. Suena a checkbox. En realidad es una decisión sobre cómo está construido todo lo demás, y hay que tomarla antes de la primera línea del producto, no atornillarla después.
Una clave que tienes tú no es lo mismo que una clave que tienen ellos
Empecemos por la fontanería aburrida, porque decide todo lo que viene encima.
Cuando una herramienta te pide entrar con su cuenta y luego llama al modelo por ti, la relación que tienes con el proveedor del modelo pasa por la herramienta. Tu consumo es su línea de gasto. Tus rate limits son los que ellos negociaron. Tu acuerdo de datos es el suyo, no el tuyo. Si cambian de plan, o los compran, o deciden que tu tramo ya no les sale a cuenta, ese es tu problema entrando por su puerta.
Cuando traes tu propia clave, la cuenta es tuya. Tienes la API key de Anthropic, de OpenAI, de quien sea. La factura va a tu tarjeta, bajo tus términos. Los rate limits son los que contrataste. El acuerdo de tratamiento de datos es el que leíste y aceptaste. La herramienta es un cliente apuntando a tus credenciales, y mañana puede apuntar a otro sitio.
Esto no es un matiz pequeño para quien maneja código que no es suyo para filtrarlo. Si trabajas bajo contrato con un cliente, o dentro de la UE, o con algo que no querrías que se reutilizara para entrenar, “de quién es la clave” es la primera pregunta, no la última. Una herramienta que te revende tokens a través de su propia cuenta se ha colado, sin hacer ruido, en una cadena que se supone que controlas tú.
También decide qué puedes hacer el día que cambian los términos. Cuando la clave es tuya, moverte a otro proveedor es una edición de ajustes que haces a tu ritmo. Cuando la clave pasa por la herramienta, esperas a que la herramienta soporte el proveedor que quieres, al precio que negoció, cuando le venga bien. Tener la credencial es lo que mantiene tuya la salida.
Los motores locales no son el plan B
La siguiente pieza es la que la gente archiva como “bonito para aficionados” y luego necesita de verdad seis meses después.
Deberías poder apuntar la misma herramienta a un modelo corriendo en tu propia máquina. Un modelo open source a través de Ollama, en tu portátil, sin red. Casi todas las herramientas tratan esto como una degradación, lo que usas cuando la API buena se cae. Ese marco está del revés.
Correr en local es el único modo en el que puedes prometer, de verdad, que no salió nada de casa. Para toda una clase de trabajo esa promesa es el requisito, no el extra. Código regulado. Un cliente que firmó algo concreto sobre dónde vive su fuente. Un prototipo que no estás listo para exponer a ningún tercero. En cuanto entra una tarea así, una herramienta que solo sabe llamar a una API en la nube no tiene nada que ofrecerte, y vuelves a copiar y pegar en un terminal del que te fías.
Una fábrica local de software pensada para traer tu propio modelo trata el motor local como un ciudadano de primera al lado de las APIs frontier. Misma interfaz de tarea. Mismo contrato alrededor. Lo único que cambia es qué motor recoge el trabajo, y eso es justo el objetivo.
La portabilidad se decide antes de que el producto exista, no después
Aquí es donde esto deja de ser una lista de features y se convierte en arquitectura.
Si un producto cablea las asunciones de un modelo en su núcleo, sus formatos de prompt, sus manías de tool-calling, su contabilidad de tokens, la forma de parsear la salida de ese modelo concreto, entonces añadir portabilidad después es imposible sin reescribir. El modelo se ha vuelto estructural. Puedes poner un desplegable en los ajustes, pero debajo hay un motor sujetando el edificio y los demás son decoración.
La portabilidad tiene que ser una forma que eliges al principio. El modelo vive detrás de un adapter. El producto habla con el adapter, nunca con el motor en crudo. El formato de Anthropic, el de OpenAI, el de un modelo local, cada uno es una capa de traducción, y la parte duradera del producto no sabe ni le importa cuál hay detrás. Añades un motor nuevo y escribes un adapter. Nada de lo de encima se mueve.
Esto me importa porque he visto la alternativa. Retiran un modelo, o lo restringen, o lo deprecan con un mes de aviso, y un producto atado a ese único motor se apaga con él. Los que sobreviven a esa semana son los que decidieron, de entrada, que ningún motor puede ser irreemplazable. Es el mismo argumento que hice sobre enrutar cada tarea al motor adecuado: enrutar por una flota solo funciona si la flota era portable desde el principio. Traer tu propio modelo es el suelo sobre el que se apoya el router.
Qué tiene que sobrevivir al cambio
El modelo es la parte que quieres hacer desechable. ¿Cuál es entonces la parte que no debe serlo?
Todo lo que sostiene el sentido de tu trabajo. El contrato de producto. Las especificaciones y los criterios de aceptación. Las decisiones que tomaste y por qué. El grafo de conocimiento del código. La evidencia de que una tarea pasó de verdad. Si eso vive dentro de una conversación con un solo modelo, cambiar el modelo lo tira a la basura, y la portabilidad es mentira.
intercambiable
- el modelo
debe sobrevivir
- contrato de producto
- specs y criterios
- decisiones
- grafo del código
- evidencia
Si vive fuera del modelo, en almacenamiento local que puedes inspeccionar, entonces el modelo es de verdad intercambiable. Cambias de motor y la memoria sigue ahí. Las decisiones de ayer siguen aplicando. Las specs siguen en pie. El motor nuevo lee el mismo contexto duradero que leía el viejo y retoma el trabajo donde estaba. Eso es lo que te compra la portabilidad. No la libertad de cambiar un desplegable. La libertad de cambiar el motor y no perder nada.
Por eso traer tu propio modelo y la memoria de producto duradera son el mismo diseño visto desde dos ángulos. Uno dice que el modelo es una pieza. El otro dice que lo importante vive fuera de la pieza. No puedes tener lo primero sin lo segundo.
Dónde encaja PaellaDoc
PaellaDoc está construido así a propósito. Tú traes tus claves API, o apuntas a un modelo local a través de Ollama, y trata a Claude, Codex, Gemini y motores locales como intercambiables bajo un mismo contrato. Tus claves, tu factura, tu acuerdo de datos. Nada se revende a través de la cuenta de otro.
Debajo, la parte que importa no se mueve cuando cambias. El contrato de producto, las historias y los criterios, el grafo del código y la evidencia viven en almacenamiento local en tu máquina. Cambia el motor y la memoria sobrevive al cambio. El modelo es la palanca. La fábrica de alrededor es lo que de verdad es tuyo.
¿Tienes tú tus claves, o las tiene tu herramienta por ti? Vale la pena comprobarlo antes del día en que necesites cambiar.
Preguntas frecuentes
¿Qué significa traer tu propio modelo?
Traer tu propio modelo significa que tú pones la clave API o apuntas la herramienta a un motor local, y la herramienta trata el modelo como una pieza intercambiable en vez de como su núcleo. Tienes tú la credencial; la herramienta es un cliente apuntando a ella. Suena a checkbox, pero es una decisión sobre cómo está construido el producto, y hay que tomarla antes de la primera línea de código, no atornillarla después.
¿Puedo usar mi propia clave API con una herramienta de código con IA?
Con una herramienta que trae tu propio modelo, sí, y la diferencia importa. Cuando la clave es tuya, la factura va a tu tarjeta bajo tus términos, los rate limits son los que contrataste y el acuerdo de datos es el que aceptaste. Moverte a otro proveedor pasa a ser una edición de ajustes a tu ritmo. Cuando la clave pasa por la herramienta, esperas a que soporte el proveedor que quieres, al precio que negoció.
¿Las herramientas de código con IA pueden correr modelos locales sin conexión?
Una herramienta pensada para traer tu propio modelo puede, a través de un motor como Ollama corriendo un modelo open source en tu máquina sin red. No es un plan B. Local es el único modo en el que puedes prometer, y cumplirlo, que no salió nada de casa: el requisito para código regulado, un contrato con un cliente sobre dónde vive la fuente, o un prototipo que no estás listo para exponer. Una buena fábrica trata el motor local como ciudadano de primera junto a las APIs frontier.
¿Qué pasa con mi trabajo si cambio de modelo?
Nada, si el trabajo vive fuera del modelo. El contrato de producto, las especificaciones, las decisiones, el grafo del código y la evidencia deben estar en almacenamiento local que puedes inspeccionar, no dentro de una conversación con un solo motor. Entonces cambias de modelo y la memoria sobrevive: las decisiones de ayer siguen aplicando, las specs siguen en pie, el motor nuevo lee el mismo contexto duradero. Si ese sentido vive dentro de un modelo, cambiarlo tira el trabajo a la basura y la portabilidad es mentira.