Qué es el vendor lock-in en proveedores de IA y cómo evitarlo

El problema real detrás del vendor lock-in

El patrón se repite con variaciones menores. Una cadena de retail en Colombia llevaba tres años usando el mismo proveedor de nube para sus modelos de recomendación de producto. Cuando quisieron renegociar el precio, el proveedor subió la tarifa sin miedo a perder el contrato: sabía que mover el histórico de compras, las etiquetas de producto y la lógica de personalización a otro lado tomaría meses y un equipo que la empresa no tenía. No hubo negociación real. Hubo aceptación.

Un estudio de arquitectura pequeño en Perú vivió la otra cara del mismo problema. Contrató a un freelancer para automatizar la generación de propuestas comerciales con IA. Funcionó bien durante un año, hasta que el freelancer dejó de responder. Nadie en el estudio sabía qué prompts se usaban, en qué orden se llamaba a cada herramienta ni dónde vivían las plantillas. El sistema seguía corriendo, pero nadie podía tocarlo sin arriesgarse a romperlo.

En ambos casos el primer diagnóstico suele ser el equivocado: se piensa que el problema es el modelo, o que basta con firmar con otro proveedor de nube. El problema real aparece cuando alguien intenta salir y descubre todo lo que nunca se mapeó: dónde están los datos, quién entiende el sistema completo, y qué tan a medida quedaron las integraciones que sostienen la operación diaria.

Qué es el vendor lock-in en IA

En criterio de negocio, el vendor lock-in no es una etiqueta técnica que le interese solo al área de sistemas. Es una condición contractual y operativa que decide cuánto poder de negociación te queda después de la primera decisión que tomaste con un proveedor.

La palabra clave ahí es costaría. El lock-in no se activa el día que firmas el contrato: se activa el día que intentas irte y calculas cuánto te cuesta el cambio en tiempo, en dinero y en riesgo operativo. Si esa cuenta te asusta, ya estás atrapado, aunque el contrato diga que puedes cancelar cuando quieras.

La confusión más común es pensar que el lock-in vive solo en el modelo de IA que usas. En la práctica, el modelo suele ser la parte menos grave del problema. Lo que de verdad amarra a una empresa está en otro lado, y ahí es donde conviene mirar antes de firmar, no después.

El amarre más grave: los datos y su formato

El amarre más grave, en la mayoría de los casos que he revisado, es el de los datos. No es que el proveedor se quede con tu información: es que la deja en un formato, una estructura o un sistema que solo su herramienta sabe leer bien. El historial de conversaciones, el etiquetado de intención, las reglas de negocio que quedaron codificadas dentro de un flujo, todo eso puede existir sin estar realmente disponible para ti.

Una aseguradora mediana en Chile automatizó la clasificación de siniestros con un proveedor que también hostea el modelo, el almacenamiento y el flujo completo. Los datos, técnicamente, eran de la aseguradora. En la práctica, exportarlos en un formato usable por otra herramienta hubiera significado reconstruir el esquema desde cero, porque el proveedor nunca documentó cómo estaba organizado internamente.

Lo que casi nunca se advierte a tiempo es qué tanto de eso se puede llevar uno realmente al migrar y qué queda inservible. El historial de conversaciones suele exportarse como texto plano, pero pierde el etiquetado propio que le daba valor de negocio. Los embeddings que el proveedor generó no sirven en otro sistema: hay que recalcularlos desde cero, con el tiempo y el esfuerzo que eso implica. Y las reglas de negocio que quedaron escritas dentro de los prompts, en lugar de en un documento aparte, se rescatan a mano, prompt por prompt, porque nadie las dejó en un lugar distinto de la propia herramienta del proveedor.

Antes de firmar o de seguir operando con un proveedor, vale la pena verificar estos puntos con calma, sin esperar a que la relación se ponga tensa:

• En qué formato exacto se guardan tus datos y si ese formato lo puede leer cualquier otra herramienta del mercado, no solo la del proveedor.
• Si puedes exportar el histórico completo, no solo un resumen, sin depender de que el proveedor te lo entregue manualmente.
• Quién figura como dueño legal de los datos en el contrato firmado, no solo en la conversación comercial previa.
• Dónde vive la documentación del esquema de datos: si solo existe en la cabeza del equipo del proveedor, no existe para ti.
• Si el etiquetado y las reglas de negocio quedaron mezclados con la lógica interna del proveedor o están separados y son portables.

El amarre más caro: el proveedor que nadie más entiende

El segundo amarre, y el que más caro sale casi siempre, no es técnico. Es que solo una persona, un equipo interno o una agencia externa entiende cómo funciona tu sistema completo. Da igual qué tan bueno sea el modelo o qué tan estándar sea la nube que usas: si la única memoria del sistema vive en la cabeza de alguien de afuera, tu empresa no controla nada, solo alquila el control.

Es lo que le pasó al estudio de arquitectura en Perú. El sistema en sí no era complicado. Lo complicado fue que nadie adentro lo había aprendido mientras funcionaba, porque siempre hubo alguien externo que lo resolvía más rápido. Cuando esa persona dejó de responder, el conocimiento se fue con ella. La empresa no perdió una herramienta, perdió la capacidad de decidir sobre su propia operación.

Este amarre es el que menos se discute en las reuniones de compra de tecnología y el que más pesa cuando toca renegociar, escalar o simplemente entender por qué algo falló un martes a media tarde. Un proveedor que resuelve todo por ti sin dejarte entender nada no es un socio, es una dependencia con factura mensual.

El costo real de este amarre casi nunca se ve hasta que alguien intenta salir de verdad. Una cadena de clínicas mediana en Bolivia decidió cambiar de proveedor de IA para el triage de pacientes por chat, después de meses de fallas que el proveedor no resolvía. Pidió cotización a dos proveedores nuevos para migrar. Los dos coincidieron en algo: el trabajo más grande no era construir el sistema nuevo, sino primero entender qué hacía el sistema viejo, porque ni en la clínica ni en el proveedor saliente había una sola persona dispuesta a explicarlo con calma. La migración terminó tomando meses solo en descubrir el sistema, antes de escribir una sola línea del nuevo.

Integraciones a medida y el modelo: el amarre que sí se deshace

El tercer amarre son las integraciones a medida: conectores hechos específicamente para tu ERP, tu CRM o tu sistema de tickets, con reglas de negocio metidas a presión dentro del código de integración. Cuando esas integraciones no están documentadas ni versionadas de forma independiente del proveedor, cambiar de herramienta implica rehacer meses de trabajo invisible que nadie presupuestó la primera vez.

Una empresa de logística grande en Argentina construyó, a lo largo de dos años, decenas de integraciones a medida entre su sistema de despacho y su proveedor de IA para optimización de rutas. Ninguna de esas integraciones quedó documentada fuera del código fuente que solo mantenía el equipo del proveedor. Cuando la empresa quiso comparar resultados con otro modelo, no pudo: mover la lógica de negocio incrustada en cada conector hubiera tomado más tiempo y presupuesto que construir el sistema completo desde cero.

El cuarto amarre, y el que menos debería asustar, es el modelo de IA en sí. Acá está el error de percepción más extendido: se piensa que cambiar de modelo es lo más difícil, cuando en la práctica suele ser lo más fácil si la arquitectura quedó bien pensada desde el inicio. Un modelo se puede sustituir por otro con una capa de abstracción bien diseñada. Los datos mal formateados y el conocimiento concentrado en una sola persona, no.

Ya existe una comparación completa entre modelo open source y modelo propietario para decidir con cuál construir desde el principio, así que no la repito acá. Lo que sí conviene tener claro en este punto es que la decisión de modelo pesa menos en el lock-in de lo que la mayoría cree, y las integraciones a medida pesan más de lo que casi nadie mide a tiempo.

Cómo evitarlo sin volverte paranoico

Evitar el vendor lock-in no significa desconfiar de todos los proveedores ni construir todo internamente por las puras. Significa negociar desde el día uno, cuando todavía tienes poder de decisión, en lugar de esperar al día en que ya lo necesitas y descubres que no lo tienes.

• Exigir documentación técnica completa y acceso administrativo desde el arranque del proyecto, no como favor cuando ya quieres irte.
• Ser dueño explícito de tus datos y de tus prompts en el contrato, con cláusula de exportación en formato abierto, no como promesa verbal.
• Aislar la llamada al modelo detrás de una capa propia, para que cambiar de proveedor de modelo sea un ajuste de configuración y no una reconstrucción completa.
• Pactar las condiciones de salida, tiempos, formatos y costos, en el contrato mientras el proveedor todavía te está vendiendo, que es el único momento en que tienes palanca real.

Nada de esto exige tratar al proveedor como enemigo. Exige tratar la relación como lo que es: un contrato entre dos partes, no un matrimonio. Documentos como el detalle de qué exigir a un proveedor de IA o la definición de un SLA de IA ayudan a poner esto en papel antes de que se vuelva un problema, y el análisis de costo total de un proyecto de IA ayuda a ponerle número real a lo que cuesta quedarse versus lo que costaría salir.

Mi criterio

Cuándo preocuparte y cuándo no

No toda dependencia de un proveedor es un problema. La pregunta que importa es si esa dependencia te deja sin capacidad de negociar o de salir cuando la relación deja de convenirte.

Señales de que ya estás atrapado en un vendor lock-in

• No puedes decir con precisión en qué formato viven tus datos ni exportarlos sin ayuda directa del proveedor.
• Nadie dentro de la empresa puede explicar cómo funciona el sistema completo sin llamar primero al proveedor.
• El proveedor sube precios o cambia condiciones sin que exista una alternativa real sobre la mesa.
• Las integraciones con tus sistemas internos solo las entiende y las toca el equipo del proveedor.
• El contrato no dice nada sobre qué pasa el día que decides irte.

Señales de que tu operación está protegida

• Puedes exportar tus datos completos, en un formato abierto, sin pedirle permiso especial al proveedor.
• Al menos una persona dentro de la empresa entiende la arquitectura completa del sistema, no solo cómo usarlo.
• La llamada al modelo de IA está separada del resto del sistema, así que cambiarla no rompe nada más.
• El contrato incluye condiciones de salida claras: tiempos, formatos y costos, pactados antes de necesitarlos.
• Puedes nombrar al menos dos alternativas reales de proveedor si la relación actual se rompe mañana.

El orden que evita el lock-in

El orden que evita el vendor lock-in es el mismo que evita casi cualquier mal proyecto de IA: primero el dolor de la operación, después el proceso que hay que rediseñar, después el dato que ese proceso necesita, y solo al final la herramienta que lo ejecuta. Cuando una empresa empieza por la herramienta, y peor aún, cuando deja que el proveedor de esa herramienta diseñe también el proceso y decida qué hacer con el dato, el lock-in ya está sembrado antes de la primera factura.

El proveedor correcto no es el que promete que nunca vas a necesitar irte. Es el que te deja en condiciones de irte y, precisamente por eso, casi nunca te da una razón real para hacerlo.