Contrato cloud y salida de proveedor: qué prever en el acuerdo

¿Tienes razón?

Tres aspectos definen si tendrás una salida ordenada de un proveedor cloud:

1) Derechos sobre los datos y aplicaciones. Debe quedar por escrito que los datos te pertenecen y que el proveedor solo actúa como procesador. Define qué incluye "datos": bases, metadatos, logs, backups y derivaciones. Sin claridad, podrías perder control sobre copias o derivaciones del procesamiento.

2) Formato y portabilidad. El contrato debe especificar el formato en que recibirás los datos al salir (formatos legibles, exportables, interoperables) y si el proveedor asumirá el coste de la exportación o si será tu responsabilidad. También especifica SLA para la entrega y verificaciones de integridad.

3) Plan de salida y devolución. Incluye un plan que detalle plazos operativos para la migración, pruebas de integridad, borrado certificado de datos del proveedor y acceso temporal post-terminación para recuperación. Define quién paga qué y cómo se verificará la eliminación segura en el entorno del proveedor.

Si estos tres puntos están claros y documentados, tu salida será viable. Si faltan, la migración será compleja, cara o técnica y jurídicamente conflictiva.

Cómo se soluciona

1. Antes de firmar: exige cláusulas de propiedad y licencia. Establece que tú conservas la titularidad de los datos y de cualquier código propietario que subas, y que el proveedor solo tiene una licencia limitada para prestar el servicio. Pide garantías de no uso comercial de tus datos y de no entrenamiento de modelos sobre ellos sin permiso.

1. Define exportabilidad y formatos. Obliga al proveedor a entregar datos en formatos abiertos y estructurados, junto con documentación y scripts necesarios para la reimportación a otro entorno. Acuerda si la exportación se hace en lotes o en un único volcado.

1. Plan de transición y soporte. Incluye horas de soporte para la migración, personal técnico del proveedor dedicado, y un calendario operacional. Define pruebas de aceptación: checksum, recuento de registros y verificación funcional de las aplicaciones migradas.

1. Copias y backups. Establece la política sobre backups: quién los conserva, cuántas copias, dónde y el procedimiento para su recuperación. Asegura que los backups también serán entregados o destruidos según lo pactado.

1. Borrado y certificación. Pide certificación de eliminación segura de tus datos del ambiente del proveedor y de subprocesadores. Define qué pruebas acreditan la destrucción (logs, actas, certificados de destrucción).

1. Cláusulas económicas y sanciones. Acuerda costos por exportación y sanciones por incumplimiento de las obligaciones de entrega o borrado. Incluye derecho a auditoría técnica para verificar cumplimiento.

1. Prueba previa. Si es posible, pacta ejercicios de migración periódicos para comprobar la viabilidad del exit y ajustar procesos.

Qué debes hacer tú: mantener copias locales actuales, documentar dependencias y asegurar que tu arquitectura no quede atada a APIs propietarias que impidan la migración.

Qué puede pasar

1) Negociación y salida ordenada. Lo habitual cuando el contrato contempla el exit: el proveedor coopera y entrega datos y backups en los formatos pactados y se certifica la eliminación.

2) Acuerdo con coste. Si el contrato no prevé todo, la salida puede implicar negociación económica para que el proveedor realice la exportación y soporte técnico adicional.

3) Conflicto y ejecución contractual. Si hay negativa del proveedor, podrías reclamar por incumplimiento contractual y pedir la ejecución forzada de cláusulas de entrega o medidas cautelares. Si pierdes el pleito, podrías afrontar costas y la posibilidad de seguir dependiendo técnicamente del proveedor.

Y si ganas, ¿cobras? Una sentencia puede ordenar entregas y pagos, pero la recuperación efectiva depende de la capacidad técnica del proveedor para ejecutar y de su solvencia para pagar sanciones.

Errores que arruinan el caso

• No definir “datos” y “backups”: deja la puerta abierta a retenciones.
• Depender de APIs propietarias sin estrategia de reemplazo: impide la migración.
• No prever coste de exportación: puede convertirse en un gasto sorpresa elevado.
• No exigir certificación de borrado: los datos pueden quedar en copias y ser motivo de incumplimiento de privacidad.
• No probar la migración en un entorno de ensayo: descubrir fallas en plena salida encarece la operación.