Teoría — Soberanía: ser dueños del flujo

La escena de la pizarra — «¿qué hace exactamente Corvus por nosotros?» y una columna con dos líneas — es la más barata de reproducir de todo el curso, y probablemente la más rentable. Esta teoría te da el marco para hacerla con rigor: qué es el lock-in como fenómeno de ingeniería, cómo se mide el coste de salida, qué conviene poseer y qué alquilar, y el mapa real — con licencias exactas, que es donde se esconde el diablo — de los estándares, modelos y herramientas que hacen posible irse.

El lock-in es ingeniería, no mala suerte

Vendor lock-in (dependencia de proveedor) es la situación en la que cambiar de proveedor cuesta tanto que, en la práctica, no puedes — y la palabra importante es cuesta: el lock-in no es una emoción ni una cláusula, es un número. Es la suma de todo lo que tendrías que reescribir, reaprender, migrar y re-verificar para irte. Tomás lo conocía de su gremio (el autómata del fabricante X con la consola del fabricante X sobre el bus del fabricante X): es un patrón comercial viejísimo, y no es una conspiración — es la física del mercado: la retención del cliente vale dinero, así que los productos evolucionan hacia la integración profunda, que a la vez aporta valor real y teje dependencia. Corvus no era malvada; era opaca, acoplante y cara de abandonar, y con eso basta. La respuesta de ingeniería tampoco es nueva: es exactamente la misma que aplicamos dentro del código desde hace medio siglo. Acoplamiento bajo, interfaces explícitas, dependencias inyectadas y sustituibles — todo el canon de la modularidad existe porque las dependencias duras convierten el cambio en catástrofe. La soberanía tecnológica es la arquitectura de dependencias de siempre, aplicada un nivel más arriba: no entre tus módulos, sino entre tu empresa y sus proveedores.

De ahí el instrumento de medida: el coste de salida. Para cada dependencia de tu flujo de desarrollo, pregunta: si mañana este proveedor cuadruplicara el precio (o quebrara, o cambiara sus términos, o degradara el producto — el correo del sunset llega en muchos formatos), ¿cuánto costaría sustituirlo? Hazlo en serio: lista las dependencias en una pizarra, y para cada una escribe qué habría que tocar, cuánto tiempo llevaría y qué se perdería por el camino. Tres observaciones que salen siempre de ese ejercicio. Primera: el coste de salida no se paga al salir — se paga antes, en forma de posición negociadora («ese número, y no el precio del plan, dice quién manda en esta relación»). Segunda: el coste depende menos del proveedor que de cómo te integraste con él — dos empresas con el mismo contrato de Corvus tenían costes de salida radicalmente distintos, y esa diferencia era su propia obra. Tercera: la escena que hay que evitar es descubrir el número el día del correo.

El criterio: acoplamiento inspeccionable

De todo el discurso de Élia a Íker, la frase que conviene formalizar es esta: desconfía del acoplamiento que no puedes inspeccionar. Un acoplamiento inspeccionable es aquel del que sabes exactamente qué pasa por él — qué datos, qué llamadas, qué permisos — porque puedes leerlo: está en tu código, en tu configuración, en un protocolo documentado. Uno no inspeccionable es el que viene «tan bien atado que mirar dentro es de mala educación»: la integración mágica que se configura sola, toca todo y no muestra las costuras. El ejemplo canónico, en nuestro propio terreno: para automatizar el trabajo con issues y pull requests puedes (a) instalar una app todo-en-uno que se integra con tu repositorio entero mediante permisos amplios y lógica opaca en servidores ajenos, o (b) montar un flujo dentro de tu agente — Claude Code, Codex, el que sea — que use la CLI gh para leer issues, comentar y actualizar. La opción (b) parece más artesanal, y fíjate en lo que te da: cada llamada visible en el flujo, permisos que tú acotas token a token, y — la prueba del algodón — que sustituir el agente que lo ejecuta cuesta una tarde, porque el acoplamiento con GitHub es una herramienta de línea de comandos estándar que cualquier agente puede invocar. La regla general: si puedes supervisar el acoplamiento, controlas las piezas, y si controlas las piezas, puedes cambiarlas de proveedor. La inspeccionabilidad no es una preferencia estética de ingenieros desconfiados; es la condición técnica de la libertad de salida. (Nota de honestidad: la opción (a) a veces es la elección correcta — velocidad hoy contra opciones mañana es un trade-off legítimo. Lo ilegítimo es no saber que lo estás haciendo. Élia no se equivocó contratando a Corvus; se equivocó comprándola sin mirar.)

Qué poseer, qué alquilar

El inventario de la pizarra de Vega generaliza a una doctrina simple. Se alquila lo que es caro de hacer, barato de cambiar y ajeno a tu diferencia: los modelos (entrenar un modelo frontera cuesta cientos de millones; cambiar de API de modelo, si hiciste los deberes, una mañana — son el commodity perfecto, y la frase de Nadia lo clava: un enchufe caro, y a los enchufes se les exige ser estándar) y la infraestructura de cómputo. Se posee todo aquello cuya sustitución sería reconstruir tu conocimiento: los prompts (tu operativa destilada — en git), las evals (la definición ejecutable de qué significa «bien» en tu producto, la pieza que convierte cambiar de modelo de acto de fe en experimento medible: la suite de Vega «midió la degradación sin opiniones ni marketing»), el contexto (AGENTS.md, ADRs, documentos de diseño — la teoría escrita), y el arnés (permisos, sandbox, sentidos, flujo). Fíjate en el patrón: todo lo que se posee es conocimiento codificado — y ya sabes desde la sección 3 que el conocimiento es el activo. La lista de Nadia lo resumió una noche: lo que puedes entender, lo puedes sustituir. Su reverso también es doctrina: la soberanía no es autarquía. Nadie sensato se hace su modelo, como nadie sensato se hace su central eléctrica. Élia, más corto: alquila caballos, no vendas el mapa.

Los estándares que hacen posible irse

La portabilidad no se decreta: se apoya en interfaces estándar. El estado real del terreno, a fecha de este curso:

• AGENTS.md — el contexto operativo en formato abierto (sección 5), leído por Codex, OpenCode, goose, Aider y, vía @AGENTS.md, Claude Code. Tu conocimiento de la casa, legible por cualquier inquilino.
• MCP — el protocolo abierto entre agentes y herramientas (sección 4). Dato institucional relevante: Anthropic lo donó a finales de 2025, junto con otras piezas, a una fundación de IA agéntica bajo la Linux Foundation — gobernanza neutral con los grandes del sector dentro. Para tu arquitectura significa: tus servidores MCP (telemetría, incidencias, base de datos) sobreviven a cualquier cambio de agente o de modelo.
• APIs de modelo compatibles — de facto, el formato de API de chat de OpenAI funciona como lingua franca que casi todos los proveedores e inferidores locales implementan, y las API principales (OpenAI, Anthropic, Google) se parecen lo bastante como para que una capa fina de adaptación las cubra. Herramientas como LiteLLM (open source, MIT con matices en su parte enterprise) dan una interfaz única sobre decenas de proveedores; pasarelas comerciales como OpenRouter ofrecen lo mismo como servicio — útil, con el matiz que a estas alturas del curso detectarás solo: un agregador que te abstrae de todos los proveedores es, a su vez, otro intermediario con su propio coste de salida. La abstracción no elimina la dependencia; la mueve. Elige dónde la quieres, con los ojos abiertos.

El mapa de 2026: modelos abiertos y agentes abiertos, con la licencia en la mano

La opción de salida definitiva es que existan alternativas abiertas competentes, y en 2026 existen — pero este curso te debe el rigor de las licencias, porque «open source» se usa como confeti y las diferencias importan.

Modelos de pesos abiertos (open weights: puedes descargar los pesos y ejecutarlos donde quieras): la familia Mistral y los Qwen grandes se publican bajo Apache 2.0 — licencia abierta de verdad, uso comercial sin restricciones; DeepSeek publica sus modelos punteros bajo MIT; Llama, en cambio, usa la «Llama Community License» — restricciones de uso y umbrales por tamaño de empresa que hacen que no sea open source según la definición de la OSI, por mucho marketing que diga lo contrario. Para poner orden en esa niebla existe precisamente la OSAID (Open Source AI Definition, OSI, 2024), que exige las cuatro libertades clásicas más información sobre datos, código y parámetros. Moraleja operativa: antes de apoyar una decisión de arquitectura en un modelo «abierto», lee su licencia, no su nota de prensa. Y la lección práctica de Vega: un modelo abierto mediano, servido en una máquina alquilada, resultó suficiente para las tareas con datos sensibles de los regantes — el punto no es que lo abierto gane siempre, sino que su mera existencia como opción viable pone un techo al precio y a la arrogancia de todos los demás.

Agentes de código abiertos: Aider (Apache 2.0, el veterano del código en terminal), OpenCode (MIT), Cline (Apache 2.0), goose (Apache 2.0, de Block — donado a la misma fundación que MCP), y Crush (de Charm — ojo: licencia FSL-1.1-MIT, una licencia «fair source» que restringe la competencia durante dos años antes de convertirse en MIT; otra vez, leer la letra). Todos hablan con el modelo que tú configures. Su existencia cambia la conversación con cualquier proveedor de agentes cerrado exactamente igual que los modelos abiertos cambian la de los modelos.

La dimensión geopolítica, para cerrar el zoom: la misma lógica de la pizarra de Vega aplica a escala de continentes. El informe EuroStack (Bertelsmann Stiftung, 2025) la cuantifica para Europa: «más del 80% de las tecnologías e infraestructuras digitales de Europa son importadas», y en torno al 70% de los modelos de IA fundacionales usados globalmente se originan en Estados Unidos (traducción propia). Los estados se hacen la pregunta de Élia con billones en juego, y las respuestas — estándares abiertos, alternativas propias, poder de sustitución — son las mismas. Que la pizarra de una startup de nueve personas y la agenda digital de un continente converjan en el mismo criterio es una pista fuerte de que el criterio es sólido.

La estrategia de salida como requisito de diseño

Síntesis operativa. Lo que Vega descubrió con alivio — que todo lo construido desde marzo «era una estrategia de salida sin proponérselo» — tú puedes hacerlo a propósito: tratar la estrategia de salida como un requisito no funcional más, al nivel de la seguridad o la disponibilidad, presente desde el diseño. En la práctica: (1) para cada proveedor nuevo, documenta el coste de salida estimado antes de firmar — una página, en un ADR: qué habría que tocar para irse, cuánto costaría; (2) mantén las piezas de posesión en tus repositorios y en formatos estándar — prompts, evals, contexto, arnés; (3) verifica la salida de vez en cuando, como se verifica un backup: la prueba de Vega contra dos proveedores no fue teórica, fue una ejecución — una estrategia de salida no ensayada es una esperanza, no una estrategia; y (4) cuando elijas entre integración profunda y flujo inspeccionable, hazlo con el número delante, no con la demo del comercial. Nada de esto es hostilidad hacia los proveedores — es simetría: ellos optimizan tu retención, tú optimizas tu libertad, y del equilibrio salen mejores contratos y mejor ingeniería. La víspera del correo del sunset, nadie en Vega sabía que estaba listo. Esa serenidad retroactiva tiene un nombre técnico: arquitectura.

Para llevar

• El lock-in es un número: el coste de salida. Se mide dependencia a dependencia, se paga antes de salir (en poder de negociación) y depende más de cómo te integraste que del proveedor.
• Desconfía del acoplamiento que no puedes inspeccionar: si puedes supervisarlo, controlas las piezas; si controlas las piezas, puedes sustituirlas. La app todo-en-uno frente al flujo con gh CLI es el caso canónico.
• Posee el conocimiento codificado (prompts, evals, contexto, arnés); alquila el commodity (modelos, infra). Lo que puedes entender, lo puedes sustituir. Alquila caballos, no vendas el mapa.
• Las evals son la pieza que convierte el cambio de proveedor en experimento medible en vez de acto de fe.
• Estándares que dan portabilidad: AGENTS.md, MCP (hoy en fundación neutral), APIs compatibles. Un agregador de APIs es útil y es otro intermediario: la abstracción mueve la dependencia, no la elimina.
• Lee licencias, no notas de prensa: Apache/MIT (Mistral, Qwen, DeepSeek, Aider, goose, OpenCode, Cline) no es lo mismo que «community license» (Llama) ni que «fair source» (Crush). La OSAID existe para eso.
• La estrategia de salida es un requisito de diseño: documéntala antes de firmar, y ensáyala — una salida no ensayada es una esperanza.

Para profundizar

• Los 12-Factor Agents de Dex Horthy (github.com/humanlayer/12-factor-agents, contenido CC BY-SA) — «Own your prompts», «Own your context window»: la doctrina de posesión, factor a factor.
• La Open Source AI Definition (opensource.org/ai) — el instrumento para leer licencias de modelos sin marketing.
• modelcontextprotocol.io y agents.md — los dos estándares de portabilidad, con sus especificaciones y gobernanza.
• EuroStack (Bertelsmann Stiftung, 2025, libre) — la misma pregunta a escala continental, con números.
• Ejercicio (hazlo esta semana): la pizarra de Élia sobre tu propio flujo de desarrollo. Columnas: dependencia / qué hace por nosotros / coste de salida estimado / ¿inspeccionable? Enséñasela a tu equipo. La fila que os incomode es la sección 8 de vuestra empresa.