La forma más segura de reducir el lock-in no es prohibir toda tecnología propietaria. Exija antes de contratar una salida ejecutable: inventario de dependencias, derechos claros sobre datos y artefactos, formatos utilizables, documentación, costos previsibles y una prueba de transición. El proveedor puede usar servicios propietarios cuando crean valor, pero debe demostrar que el comprador conserva opciones reales.
Trate la portabilidad como requisito de arquitectura y operación, no como cláusula genérica al final del contrato. NIST AI RMF pide políticas para riesgos de terceros y contingencias cuando fallan datos o sistemas externos. El Sourcing Playbook británico conecta la salida del proveedor con la movilización del sucesor o la internalización. En IA, incluya modelos, prompts, evaluaciones, datos derivados, herramientas, observabilidad y conocimiento operativo.
AI Exit Readiness Proof-8: matriz de 32 puntos
Califique cada dimensión de cero a cuatro. Cero es ausencia; uno, promesa comercial; dos, mecanismo descrito; tres, artefacto verificable; cuatro, mecanismo probado en su contexto. Exija al menos 24 de 32 puntos, ningún cero y aprobación de los cinco filtros obligatorios. Cierre los pesos antes de recibir propuestas.
- Mapa de dependencias — modelos, nubes, bases vectoriales, herramientas, APIs, identidades, licencias y subcontratistas.
- Portabilidad de datos — entradas, salidas, metadatos, embeddings, logs, evaluaciones, historial y retención.
- Portabilidad de aplicación — código, prompts, configuración, workflows, esquemas, infraestructura como código y pruebas.
- Derechos y acceso — propiedad, licencias, secretos, repositorios, cuentas, claves, documentación y administración.
- Equivalencia funcional — resultados que deben preservarse cuando cambian los componentes.
- Economía de salida — egress, migración, reconstrucción, licencias, soporte, doble operación y capacidad interna.
- Transición operativa — responsables, hitos, continuidad, incidentes, capacitación, repetición de pruebas y comunicación.
- Evidencia y actualización — ensayos, inventario versionado, informe de brechas y disparadores de revisión.
Cinco filtros obligatorios
Descarte o solicite aclaración si la propuesta no permite recuperar datos y artefactos esenciales en formato útil; mantiene repositorios y cuentas críticas solo bajo control del proveedor; no identifica dependencias y subcontratistas; deja costos de salida sin fórmula y límite verificables; o rechaza un ensayo proporcional al riesgo. Un buen promedio no compensa estas brechas.
El lock-in no es binario. Puede ser técnico, económico, contractual, operativo o de conocimiento. Un modelo puede sustituirse mientras prompts, evaluaciones y feedback permanecen sin documentación. Una arquitectura puede ser modular, pero solo dos personas del proveedor saben operarla. Califique cada dependencia por separado e identifique quién acepta el riesgo residual.
Qué debe contener el mapa de dependencias
Solicite un registro que conecte cada función de negocio con su componente: modelo, endpoint, recuperación, base de datos, herramienta, cola, política, biblioteca y ambiente. Registre propietario, región, versión, datos procesados, permisos, SLA, costo, alternativa e impacto de sustitución. Actualícelo con cada cambio relevante.
NIST señala que el riesgo puede surgir tanto del componente externo como de su uso. Una alternativa no necesita código idéntico, sino preservar decisiones y controles esenciales. Defina resultados observables: calidad mínima, latencia, costo, auditoría, permisos, recuperación e intervención humana.
Datos exportables no equivalen a un sistema portátil
Solicite muestras reales de exportación durante la selección. CSV o JSON puede llevar registros sin relaciones, contexto, versiones de prompt, procedencia, políticas o juicios humanos. Exija diccionario, esquema, identificadores estables, timestamps, fuente y transformaciones. Verifique cómo se eliminarán o conservarán datos personales, secretos y contenido licenciado.
La Comisión Europea explica que el Data Act exige interfaces abiertas y exportaciones comunes y legibles por máquina para ciertos servicios de procesamiento. Es una referencia útil fuera de Europa, pero no sustituye asesoría jurídica local ni garantiza portabilidad de todo el sistema. El comprador debe convertir el principio en artefactos y criterios específicos.
Compare el costo total de la dependencia
El menor precio inicial puede ocultar el mayor costo de cambio. Modele tres escenarios: sustituir un modelo, cambiar una plataforma central y terminar la relación con el proveedor. Incluya egress, ingeniería, revalidación, observabilidad, licencias simultáneas, capacitación, indisponibilidad y apoyo posterior. Separe tarifas controladas por el proveedor de precios de nube y plataformas.
Solicite tarifas unitarias, supuestos de volumen y un límite para asistencia de salida. Documente qué artefactos ya están incluidos en la entrega normal. El objetivo no es migración gratuita, sino evitar que documentación básica, acceso operativo o datos del comprador se conviertan en presión al terminar la relación.
Realice un ensayo pagado de salida
Antes de un contrato amplio, financie un ejercicio de dos semanas con una parte no crítica. Exporte datos y configuración, recree el flujo en una cuenta controlada por el cliente, sustituya un componente, ejecute pruebas y produzca un runbook. Registre tiempo, fallas, pasos manuales, costos y diferencias. No solicite una migración completa sin pago.
Use el mismo ejercicio con finalistas. Califique integridad de artefactos, tiempo de recuperación, equivalencia funcional, claridad sobre limitaciones e independencia del equipo interno. Un proveedor maduro no promete portabilidad perfecta: distingue lo transferible, lo que debe reconstruirse y qué dependencia genera suficiente valor para justificar su costo.
Haga explícitos los trade-offs
- Servicio gestionado versus autonomía: menor esfuerzo actual versus dependencia de personas y procesos externos.
- Plataforma integrada versus arquitectura modular: velocidad y consistencia versus sustitución granular.
- Modelo propietario versus abierto: capacidad y soporte versus control y opciones de hosting.
- Estandarización versus diferenciación: formatos comunes facilitan cambio; personalización profunda puede crear ventaja y costo.
- Cuenta del proveedor versus cuenta del cliente: inicio rápido versus menor control de historial, límites, logs y acceso.
Convierta la salida en una práctica continua
El contrato debe identificar entregables, formatos, frecuencia, responsables, plazos de acceso, eliminación de datos, asistencia, costos y equivalencia. Revise el plan cuando aparezca un nuevo modelo, plataforma, integración, subcontratista o categoría de datos. El modelo británico de Exit Management refuerza la preparación continua para sostener el servicio al finalizar.
Para convertir estas evidencias en obligaciones, consulte https://makinai.co/insights/es/que-incluir-contrato-sow-servicios-ia. Para operación continua, vea https://makinai.co/insights/es/como-elegir-proveedor-servicios-gestionados-ia y, para dependencias empresariales, https://makinai.co/insights/es/como-elegir-empresa-integracion-ia-sistemas-empresariales.
Cuándo involucrar a MAKINAI
MAKINAI puede ayudar a mapear dependencias, estructurar la matriz y ejecutar un ensayo técnico-comercial de salida antes de una contratación mayor. El objetivo no es eliminar toda dependencia, sino elegir conscientemente dónde crea valor y preservar alternativas donde aumenta el riesgo.