La IA debía dar ventaja a las empresas. También puede crear una nueva dependencia
Hace unos años la conversación sobre vendor lock-in versaba principalmente sobre la nube, sistemas ERP, bases de datos o plataformas tecnológicas clave.
Las empresas se preguntaban: ¿Podemos migrar la aplicación a otro proveedor de nube?; ¿Podemos cambiar la base de datos?; ¿Podemos dejar de usar un sistema concreto?
Hoy a esa lista se suma un nuevo elemento: la inteligencia artificial.
Las organizaciones construyen cada vez más sistemas que usan modelos de lenguaje, IA generativa, soluciones RAG, automatización de procesos y agentes de IA. Los modelos se integran en aplicaciones, procesos de ventas, atención al cliente, análisis de documentos, sistemas de decisión y el trabajo diario de los equipos.
En la práctica, esto significa que una empresa puede volverse dependiente no sólo de un software concreto, sino también del proveedor de la inteligencia que alimenta sus sistemas.
Y aquí surge el problema. Porque usar un servicio de IA es una cosa y depender de él, otra muy distinta.
Esa es precisamente la diferencia entre una dependencia tecnológica consciente y el vendor lock-in.
¿Qué es exactamente el AI Vendor Lock-in?
Vendor lock-in significa una situación en la que una organización está tan fuertemente ligada a un proveedor de tecnología que pasar a una solución competidora resulta difícil, costoso, lento o arriesgado.
En el mundo de la IA puede adoptar muchas más formas que la clásica dependencia de una API.
Una compañía puede depender de:
- un modelo de IA concreto,
- un proveedor de API específico,
- un formato de comunicación determinado,
- funciones disponibles exclusivamente en un proveedor,
- un sistema de agentes,
- infraestructura cloud,
- la forma de almacenar datos,
- un mecanismo de embeddings concreto,
- un sistema RAG específico,
- la manera en que los agentes invocan herramientas,
- prompts optimizados para un modelo concreto,
- competencias del equipo ligadas a un único ecosistema.
Por eso la pregunta: "¿Usamos OpenAI?"
es demasiado simple.
Mejor preguntar: "¿Qué tan difícil sería para nosotros cambiar de proveedor de IA si tuviéramos que hacerlo en seis meses?"
Si la respuesta es: "No lo sabemos." — puede ser la primera señal de alarma.
OpenAI, Anthropic, Google — ¿importa la elección del proveedor?
Hoy existen varios ecosistemas fuertes de modelos y servicios de IA, entre ellos soluciones ofrecidas por OpenAI, Anthropic y Google.
Cada uno desarrolla sus modelos, APIs, herramientas y servicios adicionales.
El problema no es que alguno sea "malo". Al contrario.
Usar modelos listos y de alta calidad suele ser la mejor decisión de negocio. No todas las empresas deben entrenar su propio modelo; no todas necesitan infraestructura GPU propia; no todas deben construir todo el stack de IA desde cero.
Apoyarse en un proveedor externo permite salir al mercado más rápido, reducir costes iniciales y aprovechar tecnología que sería inalcanzable para la mayoría.
El problema surge cuando la empresa deja de ver al proveedor como un componente intercambiable y diseña todo el producto como si ese proveedor existiera sin cambios durante los próximos 10 años.
Y eso no se puede garantizar...
Los modelos se actualizan, las versiones antiguas se retiran, los precios cambian, los límites cambian, las APIs cambian, aparecen nuevos modelos, cambian las condiciones de licencia, cambian las capacidades de la competencia.
Es parte normal del mercado tecnológico.
Por eso la arquitectura de IA debe contemplar no sólo: "¿Qué modelo es el mejor hoy?"
sino también: "¿Qué coste pagaremos si dentro de un año queremos usar otro?"
La mayor trampa: "pero cambiaremos la API"
A primera vista la migración puede parecer trivial.
Tenemos una aplicación. La aplicación hace una solicitud al modelo. El modelo responde. Cambiamos de proveedor. Listo...
En realidad la situación puede ser muy distinta.
Imagina una aplicación desarrollada durante dos años alrededor de un único modelo.
En ese tiempo el equipo ha:
- creado cientos de prompts,
- optimizado su contenido,
- ajustado el formato de respuesta,
- construido un sistema RAG,
- configurado tool calling,
- creado agentes,
- diseñado flujos de trabajo,
- preparado tests,
- capacitado a usuarios para trabajar con el sistema.
Tras dos años resulta que el modelo deja de estar disponible tal como lo conocíamos.
O su precio sube, o un modelo competidor es claramente mejor, o la empresa quiere mover parte de los datos a otro entorno.
En teoría basta con cambiar la API; en la práctica puede que haya que volver a testear toda la lógica del sistema.
¿Por qué?
Porque los modelos no son idénticos:
- Difieren en cómo interpretan instrucciones.
- Difieren en la calidad de las respuestas.
- Difieren en su comportamiento con contexto largo.
- Difieren en el uso de herramientas.
- Difieren en el manejo de structured output.
- Difieren en capacidad multimodal.
- Difieren en velocidad.
- Difieren en precio.
- Difieren también en comportamiento en casos límite.
Por eso migrar entre modelos puede parecer más una migración de un componente de negocio que un simple cambio de URL.
Cinco niveles de AI Vendor Lock-in
Vale la pena ver el vendor lock-in con más amplitud.
1. Lock-in de modelo
El nivel más simple.
La aplicación está optimizada para un modelo concreto.
Un prompt funciona muy bien con un modelo y peor con otro.
El sistema se apoya en capacidades específicas de ese modelo.
Cambiar exige volver a afinar.
2. Lock-in de API
El sistema usa directamente funciones específicas del proveedor.
Cuantas más funciones específicas usemos, más difícil puede ser la migración.
No se trata solo de generar texto.
También importan:
- structured outputs,
- function calling,
- tool calling,
- multimodalidad,
- gestión del contexto,
- mecanismos de seguridad,
- sistemas de agentes.
3. Lock-in de datos
Los datos pueden almacenarse de forma fuertemente ligada a un ecosistema.
Esto incluye:
- embeddings,
- índices vectoriales,
- metadatos,
- historial de interacciones,
- configuración RAG.
Migrar puede requerir no solo mover datos, sino reprocesarlos.
4. Lock-in de arquitectura
Un nivel mucho más serio.
Toda la aplicación fue diseñada alrededor de un proveedor.
Sus mecanismos aparecen en muchos puntos del sistema.
No se reemplaza un componente; se reconstruye parte de la arquitectura.
5. Lock-in organizacional
A menudo el problema menos valorado.
El equipo conoce un solo ecosistema.
Todas las competencias están centradas en una solución concreta.
La documentación, procedimientos, tests y know‑how están ligados a un proveedor.
Aunque técnicamente se pueda cambiar el modelo, la organización no tiene gente capaz de hacerlo.
Entonces el vendor lock-in deja de ser solo un problema técnico y se convierte en un problema de negocio.
¿Resuelve el Multi-Model el problema?
La respuesta natural es: "Si un proveedor es un riesgo, usemos varios."
Pero no siempre es la mejor estrategia.
La arquitectura multi-model tiene sus costes.
Hay que gestionar:
- múltiples APIs,
- diferentes límites,
- distintos modelos de precios,
- niveles de calidad diversos,
- formatos de respuesta distintos,
- tests,
- monitoring,
- seguridad.
El sistema se vuelve más complejo.
Por eso el objetivo no debe ser: "Debemos usar cinco proveedores."
El objetivo debe ser: "Debemos poder cambiar de proveedor si el negocio lo requiere."
Esa es la diferencia clave.
No toda empresa necesita Multi-Model.
Pero toda empresa debería saber cómo sería la migración a otro modelo.
AI Gateway y Model Gateway: la capa que separa la aplicación del proveedor
Una forma de reducir la dependencia es usar una capa intermedia.
Puede desempeñar la función de AI Gateway o Model Gateway.
Simplificando, la arquitectura podría ser:
Aplicación de negocio
↓
Capa de abstracción de IA
↓
Routing de modelos
↓
Adaptador del proveedor
↓
OpenAI / Anthropic / Google / modelo open-weight / modelo local
Así la lógica de negocio no necesita conocer los detalles de cada proveedor.
Podemos tener una capa responsable de:
- elección de modelo,
- routing,
- fallback,
- control de costes,
- monitoring,
- registro,
- políticas de seguridad,
- gestión de límites.
En caso de fallo de un proveedor, el sistema puede intentar usar otro modelo.
Si suben los precios, cambiamos el routing.
Si aparece un mejor modelo, podemos probarlo y decidir la migración.
No significa que el cambio sea siempre indoloro; sí significa que se ha diseñado como una posibilidad real.
Model Router: la IA no siempre debe elegir el mismo modelo
Una idea aún más interesante es el routing por modelos.
Imagina un sistema que recibe tareas variadas.
Tarea simple: "Resume este texto."
Puede enviarse a un modelo rápido y económico.
Tarea compleja: "Analiza este documento y prepara una recomendación detallada."
Puede asignarse a un modelo más potente.
Una tarea que requiera análisis de imágenes puede enviarse a un modelo multimodal.
El sistema puede elegir dinámicamente el modelo según la tarea.
Esto permite optimizar:
- costes,
- calidad,
- tiempo de respuesta,
- disponibilidad.
Así el proveedor deja de ser parte integral de la lógica de negocio y se convierte en un elemento más de la infraestructura.
Eso es un cambio arquitectónico importante.
Abstraer no significa que todos los modelos sean iguales
Aquí hay que cuidar una trampa.
Puedes implementar una función propia: generateText() y pensar que el problema está resuelto.
No lo está.
Los modelos no son piezas LEGO intercambiables.
Si la aplicación usa capacidades específicas de un modelo, una abstracción simple puede ocultar el problema.
Una buena arquitectura debe abstraer del proveedor pero gestionar conscientemente las diferencias entre modelos.
En la práctica la capa de IA debe saber que los modelos pueden tener distintas:
- capacidades,
- límites,
- costes,
- niveles de calidad,
- funciones,
- contextos,
- parámetros.
Ser "provider-agnostic" no significa fingir que todos los modelos son iguales; significa que el sistema sabe aprovechar conscientemente sus diferencias.
Evals: sin ellos migrar la IA es conjetura
Un elemento crucial de una arquitectura resistente al cambio son los evals, es decir, pruebas sistemáticas de calidad de los modelos.
Supongamos que tenemos 1000 casos reales de uso. Los ejecutamos en el modelo actual. Luego los ejecutamos en el nuevo. Comparamos resultados.
Verificamos:
- calidad,
- corrección,
- completitud,
- alucinaciones,
- conformidad con requisitos,
- tiempo de respuesta,
- coste.
Solo entonces podemos decir: "El nuevo modelo es suficientemente bueno."
Sin evals la migración es un experimento; con evals es un proceso de ingeniería.
Por eso una empresa que usa IA debe construir sus propios conjuntos de pruebas. No sólo probar la API, sino probar su caso de negocio. Esa es la diferencia clave.
El prompt también puede ser una fuente de vendor lock-in
Tratar los prompts como simples textos es un error. En la práctica pueden convertirse en parte de la lógica de negocio.
Si durante meses el equipo optimiza instrucciones para un modelo específico, el prompt puede actuar como fragmento de código.
Por eso debe:
- versionarse,
- probarse,
- documentarse,
- monitorizarse.
También conviene saber qué prompts son críticos. Si cambiar de modelo reduce su eficacia, hay que saber dónde buscar el problema.
En sistemas maduros el prompt engineering debe tratarse cada vez más como parte de la ingeniería de software.
Open-weight y modelos propios — ¿fuga del vendor lock-in?
Los modelos open-weight y la posibilidad de ejecutar modelos en infraestructura propia aumentan el control tecnológico.
Pero no implican automáticamente independencia total.
Si movemos un modelo a nuestra infraestructura seguiremos necesitando:
- GPU,
- infraestructura,
- MLOps,
- monitoring,
- seguridad,
- actualizaciones,
- competencias.
Podemos reducir la dependencia del proveedor del modelo pero aumentar la dependencia del proveedor de infraestructura. También podemos ejecutar modelos open-weight en la nube, lo que traslada el problema a otro nivel. Por ello la independencia tecnológica debe contemplarse de forma más amplia.
No existe un sistema completamente libre de dependencias.
Existe, en cambio, un sistema en el que las dependencias son:
- conocidas,
- controladas,
- medibles,
- reemplazables.
El vendor lock-in más peligroso puede estar en la cabeza del equipo
Imagina una empresa que usa un solo proveedor de IA.
Técnicamente podría cambiar de modelo. Pero nadie sabe cómo hacerlo.
El equipo no conoce alternativas.
No hay benchmarks.
No hay evals.
No hay tests.
No hay experiencia con otros modelos.
Todo se construyó alrededor de un ecosistema.
Eso es lock-in organizacional.
Por eso la resistencia al vendor lock-in requiere invertir también en competencias.
El equipo debe entender:
- cómo funcionan los modelos,
- cuáles son las diferencias entre proveedores,
- cómo diseñar una capa de abstracción,
- cómo evaluar modelos,
- cómo medir calidad,
- cómo gestionar costes,
- cómo llevar a cabo una migración.
No se trata de que cada desarrollador conozca todas las APIs, sino de que la organización no sea tecnológicamente ciega fuera de un ecosistema.
¿Cuándo puede ser aceptable el vendor lock-in?
El vendor lock-in no siempre es malo.
A veces una dependencia consciente es una decisión de negocio razonable.
Si:
- el proveedor ofrece una funcionalidad excepcional,
- la solución reduce notablemente el tiempo de implementación,
- el coste de migración es conocido,
- el riesgo es aceptable,
- las alternativas son peores,
- el negocio necesita velocidad,
una mayor vinculación puede estar justificada.
El problema no es el lock-in en sí, sino el lock-in inconsciente.
La empresa debe saber:
- de qué depende,
- por qué depende,
- cuánto costaría cambiar,
- cuánto duraría la migración,
- qué alternativas existen.
Solo entonces se puede hablar de una decisión arquitectónica consciente.
¿Cómo evaluar el AI Vendor Lock-in en tu empresa?
Conviene hacer una auditoría sencilla.
Pregúntate:
¿Podemos cambiar de modelo sin rehacer toda la aplicación?
¿La lógica de negocio es independiente del proveedor de IA?
¿Los prompts están versionados?
¿Tenemos nuestros propios evals?
¿Contamos con tests de regresión para los casos más importantes?
¿Podemos exportar y trasladar nuestros datos?
¿Podemos cambiar el proveedor de embeddings sin perder datos?
¿Los agentes usan una capa de orquestación o están atados a un ecosistema?
¿Tenemos la opción de usar un modelo alternativo?
¿Tenemos fallback?
¿Sabemos cuánto costaría la migración?
¿Sabemos cuánto tardaría la migración?
¿Tenemos gente que pueda llevarla a cabo?
Cuantas más respuestas "no", mayor es la dependencia.
También puedes crear tu propio AI Portability Score. Por ejemplo, evaluar la organización en cinco áreas:
Arquitectura - ¿es el proveedor intercambiable?
Datos - ¿podemos migrarlos?
Modelos - ¿tenemos alternativas?
Evaluación - ¿podemos comparar modelos?
Competencias - ¿el equipo puede realizar la migración?
Ese resultado no tiene que ser un estándar formal, pero puede ser una buena herramienta de gestión.
Porque a veces el mayor problema no es el vendor lock-in, sino que la empresa ni siquiera sabe que lo tiene.
¿Cómo diseñar una arquitectura de IA resistente al cambio?
No existe una arquitectura universal. Pero sí varias reglas prácticas.
Regla 1 - separa la lógica de negocio del proveedor de IA
No construyas todo el sistema directamente alrededor de una sola API.
Regla 2 - aplica una capa de abstracción cuando tenga sentido
Un AI Gateway o Model Gateway puede reducir la dependencia de la aplicación respecto a un proveedor concreto.
Regla 3 - versiona los prompts
Trátalos como elementos del sistema, no como textos sueltos.
Regla 4 - construye evals
No des por hecho que "el nuevo modelo funciona". Compruébalo.
Regla 5 - prueba alternativas
No tienes que usarlas en producción, pero conviene saber cómo responden a tus casos de uso.
Regla 6 - controla los datos
No permitas que tus datos de negocio se conviertan en rehén de una plataforma.
Regla 7 - documenta las dependencias
Saber dónde el sistema está ligado a un proveedor es parte de la documentación arquitectónica.
Regla 8 - no abstraigas a la fuerza
No ocultes las diferencias entre modelos solo para aparentar portabilidad.
Regla 9 - mide el coste de la migración
No basta con decir: "Algún día podremos cambiar de proveedor."
Tienes que saber: "Necesitamos tres meses y cinco personas."
O: "No podemos hacerlo sin reconstruir el sistema."
Regla 10 - toma decisiones de forma consciente
A veces lo mejor es atarse a un proveedor. Pero debe ser un riesgo consciente.
No un accidente.
La pregunta que todo CTO debe hacerse
Imagina que mañana el proveedor de IA:
- duplica precios,
- retira el modelo que usamos,
- cambia límites,
- limita una función de la que depende nuestro producto,
- deja de cumplir nuestros requisitos de compliance.
¿Qué hacemos?
Si la respuesta es: "Cambiaremos de proveedor."
la siguiente pregunta debe ser: "¿Cuánto tiempo nos tomaría?"
Un día?
Una semana?
Un mes?
Medio año?
¿O quizás no lo sabemos?
Esa es la medida de nuestra resistencia tecnológica.
Resumen — no se trata de no tener proveedores
Construir un sistema completamente independiente de proveedores externos de IA puede ser costoso, innecesario o incluso imposible.
No se trata de eso.
El objetivo no es la ausencia de dependencias. El objetivo es la gestión consciente de las dependencias.
Podemos usar OpenAI. Podemos usar Anthropic. Podemos usar Google. Podemos usar modelos open-weight. Podemos combinar soluciones.
Lo importante es saber dónde está el límite entre: "usamos la tecnología" y "dependemos de ella".
En el mundo de la IA esa línea puede ser difícil de ver porque el vendor lock-in no surge de un día para otro. Surge gradualmente. Primero integramos una API. Luego añadimos una función. Luego RAG. Luego agentes. Luego automatizamos procesos. Luego todo el equipo comienza a trabajar según ese sistema. Y de repente cambiar de modelo deja de ser un cambio técnico y se convierte en cambiar parte de la organización.
Por eso la arquitectura de IA debe diseñarse pensando no sólo en qué funciona hoy, sino también en qué ocurrirá cuando el mundo tecnológico cambie mañana.
No necesitas construir un sistema que funcione sin OpenAI, Anthropic o Google. Pero sí deberías construir un sistema que pueda seguir funcionando si alguno de ellos falta.
Esa es la diferencia entre usar IA y diseñar conscientemente tecnología de IA.
