Cuando el innovar rápido se convierte en dependencia estratégica

En noviembre 2025, Builder.ai, una plataforma de desarrollo de aplicaciones impulsada por IA, colapsó. La compañía que había obtenido respaldo de Microsoft y otros gigantes tecnológicos, repentinamente cerró operaciones. Miles de empresas que usaban la plataforma para construir y desplegar aplicaciones empresariales críticas se encontraron bloqueadas. No podían acceder a código fuente. No podían extraer datos. No podían migrar aplicaciones a otra plataforma. Simplemente perdieron acceso.

Esto no es una anomalía; es una advertencia. En la prisa por adoptar IA rápidamente y escalar soluciones "listas para usar," muchas empresas han creado dependencia de vendedor único (single-vendor) que, técnicamente, financieramente, y legalmente, es casi imposible de desactivar sin sufrir daño operacional masivo.

¿Qué es Vendor Lock-in en IA?

El Vendor lock-in tradicional ocurre cuando una organización se vuelve tan dependiente de un proveedor de cloud o servicio (AWS, Azure, Google Cloud) que el cambiar de proveedor requeriría una reingeniería completa, reentrenamiento masivo e interrupciones operacionales. Pero vendor lock-in en IA es algo diferente y mucho más profundo.

Aplicado a la IA, lock-in incluye:

1. Dificultad de determinar propiedad intelectual: En muchos contratos de IA no especifican claramente quién es dueño del código del modelo, pesos del modelo, o los datos de entrenamiento utilizados. Un cliente puede creer que "compró" un modelo personalizado cuando, legalmente, simplemente tiene derecho a "usar" una versión que sigue siendo propiedad del proveedor.
2. Portabilidad de datos limitada: Mientras que GDPR exige "derecho a portabilidad," muchos proveedores de IA ofrecen exportación limitada en formatos no estándar que requieren re-procesamiento extensivo antes de ser útiles en otro sistema.
3. APIs propietarias y ecosistemas cerrados: Un sistema de IA construido con APIs propietarias de OpenAI, Anthropic, o un cloud provider específico crea fricción técnica masiva al momento que uno desee realizar una migración. Cambiar de OpenAI a Claude o a un modelo open-source requeriría reingeniería de prompts, revalidación de salidas, y potencialmente re-entrenamiento de usuarios y de modelos.
4. Cláusulas de sub-procesadores poco claras: La documentación sobre dónde se procesan datos, quiénes son los sub-procesadores de datos, y qué derechos tiene el cliente sobre locación de datos suele ser deficiente, lo cual crea exposición regulatoria (especialmente bajo GDPR para empresas latinoamericanas operando en Europa).
5. Ausencia de términos de fallback/escrow: Si el proveedor quiebra o decide descontinuar un servicio, ¿qué sucede con su acceso a código y datos? Pocas empresas negocian términos de custodio (escrow) de código de fuente o acuerdos de acceso de suplencia (fallback).

Incidentes recientes que ilustran el riesgo

Caso 1: Builder.ai (Noviembre 2025)
Miles de clientes globales quedaron sin acceso a aplicaciones que habían desarrollado usando la plataforma. El impacto financiero fue considerable; empresas con aplicaciones críticas en producción tuvieron que pausar operaciones mientras buscaban alternativas. Lecciones: documentación insuficiente de dependencias, ausencia de estrategia de salida, y contratos que no especificaban derechos de acceso post-terminación.

Caso 2: UK Cabinet Office Alert sobre AWS (2024)
El gobierno del Reino Unido advirtió que dependencia excesiva de AWS podría costar a instituciones públicas £894 millones en costos de migración si alguna vez decidían cambiar de proveedor. Este alerta se amplifica en contexto de IA, donde modelos customizados entrenados en infraestructura AWS pueden no ser fácilmente portables.

Caso 3: Aumento de Precios y "Lock-Out" de VMware
VMware implementó cambios de precios que multiplicaron costos 10 veces para clientes existentes, aprovechando que la migración era prohibitivamente cara. Aunque esto ocurrió pre-IA masiva, el patrón es instructivo: una vez que eres cautivo, el proveedor tiene poder de pricing desproporcionado.

¿Por qué auditoría interna debe auditar la dependencia de proveedores de IA?

Bajo el marco de auditoría interna del IIA y la guía de gestión de terceros, los auditores internos tienen la responsabilidad de validar riesgos de concentración de proveedores y asegurar que contratos protejan intereses corporativos. Para sistemas de IA, esto incluye:

1. Evaluación de criticidad de sistema: ¿Cuán crítico es este sistema para operaciones comerciales? Si Builder.ai hubiera sido identificado como "crítico," ese nivel de criticidad debe haber disparado requerimientos contractuales más estrictos.
2. Revisión de cláusulas de contrato de terceros: Específicamente, validar presencia de:
   1. Cláusulas de propiedad de IP que especifiquen quién es dueño de código, modelos, datos usados por las plataformas IA
   1. Derechos de exportación/portabilidad en formatos estándar abiertos
   1. Cláusulas de custodio (escrow) de código de fuente para garantizar acceso si el proveedor se vuelve insolvente
   1. Términos de sub-procesadores y locación de datos
   1. Derechos de auditoría para validar cumplimiento normativo
3. Análisis de dependencia técnica: Se deben mapear qué aplicaciones críticas dependen de IA de terceros; asimismo, evaluar esfuerzo de migración si el proveedor desaparece o discontinúa servicio.
4. Planificación de suplencia (fallback) y recuperación ante desastre: ¿Tiene su organización un plan de continuidad de negocio si un proveedor crítico de IA se vuelve no disponible?

Las cinco cláusulas que no puede ignorar

Según investigación realizada por el CCSD Council (octubre 2025), todo contrato de proveedor debería IA debe incluir mínimamente:

1. Uso de datos: Quién puede acceder a datos, para qué propósitos, y cómo se protege
2. Aislamiento: Garantías de que datos de su organización están aislados de otros clientes
3. Transparencia: Acceso a documentación de capacidades del modelo, limitaciones, y cambios post-puesta en producción
4. Portabilidad: Derecho a exportar datos en formatos estándar abiertos; derecho a auditar proveedores de terceros
5. Sub-procesadores: Lista clara de sub-procesadores, ubicación de datos, y notificación si ocurren cambios

Recomendaciones principales

1. Auditar la dependencia de proveedores de IA en sistemas críticos: En los próximos 90 días, sugiero crear el inventario de qué sistemas empresariales dependen de IA de terceros (OpenAI, Google Vertex, AWS SageMaker, etc.); clasificar por criticidad y evaluar esfuerzo de migración.
2. Revisar y mejorar cláusulas de contrato de terceros: Proponer que todos los contratos nuevos de proveedores de IA incluyan las "cinco cláusulas" mínimas anteriormente presentadas; para contratos existentes, ver la posibilidad de negociar enmiendas o crear plan de transición a proveedores con términos más favorables.
3. Desarrollar una matriz de riesgo relacionada al vendor lock-in: Documente la dependencia técnica, exposición financiera de terminar la relación con el proveedor del modelo, y costo estimado de migración; priorizar reducción de dependencia en casos de riesgo alto.