Estrategias de salida y portabilidad al contratar IA en la administración pública

Por qué planificar la salida desde el inicio

Los proyectos de IA para entidades públicas suelen implicar datos sensibles, dependencias técnicas y obligaciones legales (ENS, RGPD, Ley 9/2017 y requisitos del EU AI Act para sistemas de alto riesgo). Si no se incorpora una estrategia de salida en la contratación y en la arquitectura, el riesgo de vendor lock-in puede traducirse en pérdida de control sobre datos, interrupciones del servicio y costes elevados al cambiar proveedor.

Planificar la salida no es una opción: es una práctica de gestión de riesgo. A continuación, se propone un conjunto de medidas contractuales, técnicas y operativas que las administraciones pueden exigir y validar antes y durante la contratación.

Cláusulas contractuales imprescindibles

• Entrega y portabilidad de datos: obligación del proveedor de exportar datos en formatos abiertos y documentados (CSV/NDJSON para registros, formatos normalizados para metadatos y trazas). Plazos y coste de exportación deben definirse.
• Entrega de artefactos de IA: especificar qué se entrega en caso de terminación—pesos de modelos (ONNX, PyTorch/TF exportados), código de inferencia, contenedores Docker, scripts de reentrenamiento y especificaciones de infraestructura.
• Escrow técnico y de código: depósito en custodia de código, modelos y claves para liberación bajo condiciones predefinidas (quiebra, incumplimiento, fin de contrato).
• SLA de transición: horas de soporte, conocimientos y formación para la entidad durante el periodo de transferencia; precios y tiempos máximos.
• Pruebas de salida periódicas: derecho a auditorías y ejercicios de migración parciales (p. ej. anuales) sin coste adicional.
• Derechos de propiedad intelectual y licencias: clarificar licencias de modelos y componentes; evitar cláusulas que impidan reproducir o desplegar internamente.
• Confidencialidad limitada: asegurar que cláusulas de NDA no impidan el acceso de la administración a información necesaria para la continuidad operativa.
• Penalizaciones por bloqueo: cláusulas económicas si el proveedor dificulta la portabilidad o la transferencia técnica.

Estas cláusulas pueden incorporarse en pliegos y contratos conforme a la Ley 9/2017 de Contratos del Sector Público; es recomendable coordinar con el área jurídica desde la fase de especificación.

Requisitos técnicos para facilitar la migración

• Interfaces abiertas y APIs versionadas: evitar protocolos propietarios. Documentación pública de API y esquemas de datos.
• Exportadores nativos: el sistema debe permitir exportar conjuntos de datos, logs, métricas y metadatos de entrenamiento en formatos estándar.
• Contenedores y IaC: empaquetado reproducible (Docker/OCI) e infraestructura como código (Terraform, Ansible) para recrear entornos.
• Model cards y data sheets: documentación técnica de modelos (arquitectura, datasets, hyperparámetros, performance) que facilite reentrenamiento y evaluación.
• Reproducibilidad de pipelines: definición clara de pipelines ETL y ML (p. ej. con MLflow, Airflow) y capacidad de exportar definiciones.
• Acceso a registros y trazabilidad: logs de inferencia y decisiones, retención que permita auditorías y comprobación de continuidad.
• Dependencias abiertas o gestionables: lista de dependencias y versiones; evitar componentes con licencias restrictivas que impidan migración.

Pruebas y verificación: no asumir, demostrar

• Ejercicio de migración piloto (dry run): contrato que incluya una migración de prueba completa a un entorno de staging, con criterios de aceptación definidos.
• Checklists de verificación: datos completos, integridad, latencias, resultados de inferencia comparables y documentación de despliegue.
• Validación funcional y legal: pruebas de consentimiento y tratamiento de datos conforme RGPD; verificación de continuidad frente a requisitos ENS.
• Auditorías externas periódicas: inclusión de auditoría anual por tercero para verificar que los mecanismos de portabilidad son efectivos.

Gobernanza y transferencia de conocimiento

• Plan de transferencia de conocimiento (KT): formación para equipos internos, documentación de runbooks, playbooks de incidentes y contactos de escalado.
• Equipo mixto en la fase de salida: técnicos de la administración y del proveedor que trabajen conjuntamente los primeros ciclos operativos.
• Reserva presupuestaria para transición: incluir en la planificación fondos para contratación temporal de integradores o para soporte post-terminación.

Checklist rápida de "Plan de salida" (crono sugerido)

1. Antes del contrato: incluir cláusulas de portabilidad, escrow y pruebas de migración.
2. Durante el contrato (cada 12 meses): exportación de copia completa y ejercicio parcial de migración.
3. 90 días antes de terminación/renuncia: ejecutar migración completa a entorno de staging y validar.
4. 30 días: transferencia de datos final, handover de modelos, formación y apagado ordenado.
5. Post-migración (30–90 días): soporte del proveedor según SLA de transición y verificación de KPIs.

Cumplimiento normativo a tener en cuenta

• RGPD: garantizar derechos de accesibilidad y portabilidad de datos personales; procedimientos para supresión ordenada si aplica.
• ENS (RD 311/2022): requisitos de seguridad que deben mantenerse en la nueva plataforma; documentar medidas equivalentes.
• Ley 9/2017: respetar marcos de contratación pública y justificar cláusulas técnicas y económicas en el expediente.
• EU AI Act: para sistemas de alto riesgo, conservar documentación técnica y registros necesarios para el cumplimiento tras la transición.

Conclusión y siguiente paso recomendado

La salida planificada combina tres elementos: cláusulas contractuales concretas, requisitos técnicos verificables y ejercicios periódicos de migración. Acción inmediata: incorporar en el próximo pliego una cláusula de "migration dry run" y programar una exportación anual de datos y artefactos. Si desea, OptimTech puede compartir un checklist técnico y contractual adaptable a su expediente de contratación y a la evaluación ENS del proyecto.

Takeaway: no firme un contrato de IA sin un plan de salida probado — incluya portabilidad técnica, escrow y pruebas de migración en el pliego y verifíquelas periódicamente.