Durante años, la dependencia de proveedores de IA se discutió como un problema de ingenieros: APIs difíciles de migrar, formatos propietarios, contratos con cláusulas incómodas. En 2026 esa conversación se quedó corta. El riesgo ya no está solo en la tecnología que usamos, sino en cómo esa tecnología empieza a pensar por nosotros.
Mi postura es directa: la mayoría de las empresas e instituciones públicas están firmando contratos que protegen sus datos, pero no su forma de decidir. Y esa es la parte que más cuesta recuperar.
Contexto: de la dependencia técnica a la dependencia cognitiva
La IA dejó de ser un piloto aislado. Hoy opera dentro de procesos centrales: atención a clientes, revisión de documentos, análisis de riesgos, redacción de dictámenes, soporte a la toma de decisiones. Los agentes ya no solo responden preguntas; ejecutan tareas de principio a fin.
Boston Consulting Group lo planteó con claridad este año: el lock-in tecnológico está evolucionando hacia un lock-in cognitivo. Es decir, una organización puede volverse dependiente no solo de una plataforma, sino de los procesos de razonamiento de un modelo que ya moldean cómo opera y cómo piensa.
Ya vivimos algo parecido con los ERP y el SaaS: adaptamos procesos a las restricciones del software. La diferencia es que antes el sistema dictaba cómo se hacía el trabajo. Ahora influye en qué se decide.
Por qué la dependencia de proveedores de IA importa ahora
Tres fuerzas convergen en este momento.
- Los grandes proveedores quieren ser la capa operativa. Ya no venden solo acceso a un modelo; ofrecen agentes, orquestación, memoria, conectores y espacios de trabajo completos. Cuanto más cómodo es el paquete, más difícil es salir.
- El conocimiento institucional se está codificando en prompts, flujos y agentes. Reglas de negocio, criterios de aprobación y experiencia acumulada terminan viviendo dentro de configuraciones que no siempre son portables.
- Los modelos cambian cada pocos meses. Un modelo nuevo puede comportarse distinto con las mismas instrucciones. Si su operación depende de un comportamiento específico, cada actualización es un riesgo que usted no controla.
Lo más delicado: esta dependencia no requiere mala fe de nadie. Surge de decisiones perfectamente racionales de ambas partes. El proveedor mejora su producto; la organización lo adopta porque funciona. Y un día descubre que cambiar sería demasiado arriesgado.
Cómo se ve en empresas y en gobierno
En una empresa, la señal suele ser silenciosa. Los equipos ya no saben explicar por qué un análisis llegó a cierta conclusión, solo que «el sistema lo recomendó». Las reglas comerciales existen en los agentes, pero no en un documento que alguien gobierne.
En el sector público el problema es más serio. Cuando un gobierno automatiza la atención ciudadana, la clasificación de trámites o el análisis de solicitudes, está delegando criterio administrativo. Si ese criterio solo puede ejecutarse dentro de la plataforma de un proveedor, la soberanía tecnológica deja de ser un discurso y se vuelve una vulnerabilidad concreta: presupuestaria, jurídica y política.
Desde mi experiencia dirigiendo recursos tecnológicos, la pregunta que casi nadie hace en la mesa de compras es: «si mañana este proveedor sube precios, cambia condiciones o desaparece, ¿qué conocimiento perdemos?». No qué datos. Qué conocimiento.
Riesgos y errores comunes
- Confundir privacidad contractual con independencia. Que el proveedor no entrene con sus datos no significa que usted pueda llevarse su lógica de decisión a otro lado.
- Construir directamente sobre la plataforma del proveedor. Sin una capa propia intermedia, cada agente queda amarrado a un ecosistema.
- Estandarizar por comodidad. Elegir un único modelo «para simplificar» suele ser la decisión más cara a mediano plazo.
- No documentar las reglas de negocio fuera del sistema. Si el único lugar donde existe el criterio es un prompt, ese criterio no le pertenece del todo.
- Ignorar la dependencia de habilidades. Equipos que dejan de razonar sin el asistente también son una forma de lock-in, aunque no aparezca en ningún contrato.
Recomendaciones prácticas
No propongo desconfiar de la IA ni frenar su adopción. Propongo adoptarla con arquitectura y con criterio directivo.
1. Defina su «núcleo de conocimiento»
Identifique qué reglas, criterios, ontologías de datos y experiencia hacen distinta a su organización. BCG lo llama la «corteza empresarial». Ese núcleo debe vivir en una capa que usted gobierne, no dentro de la herramienta de un tercero.
2. Adopte una estrategia multimodelo desde el diseño
Use una capa de enrutamiento y evaluación propia que permita cambiar de modelo sin reescribir procesos. No se trata de usar muchos modelos por moda, sino de poder hacerlo cuando convenga.
3. Haga pruebas de salida, no solo de entrada
Antes de escalar un agente, pregunte: ¿cuánto costaría migrarlo? Si la respuesta es «no sabemos», todavía no está listo para producción.
4. Negocie portabilidad, no solo precio
Incluya en contratos la exportación de configuraciones, historiales, evaluaciones y flujos en formatos utilizables. En gobierno, esto debería ser requisito de licitación.
5. Mantenga el razonamiento humano entrenado
Exija que las decisiones importantes puedan explicarse sin el sistema. Si nadie en el equipo puede reconstruir el porqué, la dependencia ya es cognitiva.
Conclusión
La dependencia de proveedores de IA es el nuevo riesgo estratégico de esta década, y se parece menos a un problema de TI que a un problema de identidad institucional. Las organizaciones que ganen no serán las que usen el modelo más potente, sino las que sigan siendo dueñas de su forma de pensar mientras usan los mejores modelos disponibles.
La IA debe amplificar el criterio de una empresa o de un gobierno, no sustituirlo por el de un proveedor. Esa línea se decide hoy, en la arquitectura y en los contratos, no cuando ya sea demasiado caro cambiar.
Preguntas frecuentes
¿Qué es la dependencia cognitiva en inteligencia artificial?
Es la situación en la que una organización depende no solo de la infraestructura de un proveedor, sino de la forma en que su modelo razona y estructura decisiones, al grado de que cambiarlo pone en riesgo la operación.
¿Cómo evitar el vendor lock-in en IA?
Con una capa propia que concentre reglas de negocio, datos y evaluación; una estrategia multimodelo; contratos con cláusulas de portabilidad; y pruebas periódicas de migración antes de escalar.
¿Por qué es especialmente relevante para gobiernos?
Porque automatizar servicios públicos implica delegar criterio administrativo. Si ese criterio queda atado a un proveedor, la institución pierde control sobre costos, continuidad del servicio y rendición de cuentas.
¿Significa esto que hay que desarrollar modelos propios?
No necesariamente. Lo esencial es ser dueño del conocimiento y de la lógica de decisión. Los modelos pueden ser de terceros, siempre que puedan sustituirse sin perder lo que hace única a la organización.
Deja una respuesta