Mover un workload a una región puede cumplir un requisito de ubicación y dejar intactos la jurisdicción, el acceso privilegiado, las claves de cifrado, la cadena de software y las dependencias de recuperación. Empieza por el riesgo que debes controlar y diseña la operación en función de él.
El Cloud Sovereignty Framework de la Comisión Europea evalúa ocho objetivos de soberanía y combina niveles de garantía con una puntuación basada en 48 criterios. En abril de 2026, la Comisión adjudicó un contrato cloud a cuatro proveedores; la explicación y guía de implementación publicadas en junio describen el framework y lo aprendido en esa contratación. Es una herramienta de evaluación para compras públicas, no una certificación universal que resuelva automáticamente el riesgo jurídico o técnico de cada cliente.
La Comisión también propuso el Cloud and AI Development Act. La propuesta describe cuatro niveles de garantía para la soberanía cloud y de IA, pero sigue siendo una propuesta legislativa. Conviene seguir su tramitación sin tratar el borrador como una obligación ya vigente.
La residencia de datos responde dónde se almacenan o procesan determinados datos. La soberanía abarca más: quién gobierna y opera el servicio, qué leyes pueden aplicarse, quién puede acceder, quién controla las claves, cómo se suministran software y hardware, y si el cliente puede seguir operando o salir. Geopatriación significa trasladar workloads o dependencias a jurisdicciones elegidas por motivos estratégicos, regulatorios o de resiliencia. Es una estrategia de ubicación, no una propiedad de seguridad por sí sola.
| Riesgo | Control de arquitectura | Evidencia que conservar | Señal de fallo |
|---|---|---|---|
| Ubicación de datos | Clasifica cada almacén y proceso; limita región, réplica, backup, logs, telemetría y exportaciones de soporte. | Inventario de recursos, evaluación de políticas, mapa de flujo, ubicación de backups y responsable de excepciones. | Nuevo recurso fuera de la geografía aprobada o copia desconocida. |
| Jurisdicción y acceso | Revisa entidad contratante, propiedad/control, subencargados, soporte, divulgación y salvaguardas de transferencia con asesoría jurídica. | Versión contractual, lista de subencargados, compromisos de acceso, evaluación y fecha de revisión. | Cambio de control, soporte, términos legales o subcontratista. |
| Identidad y operación | Identidad federada, MFA resistente al phishing, roles limitados, elevación temporal, aprobación de soporte sensible y break-glass separado. | Permisos, sesiones, aprobaciones, revisión de acceso y ejercicio de emergencia. | Admin persistente del proveedor, cuenta compartida o sesión sin registro. |
| Cifrado y claves | Cifra en tránsito y reposo; elige control de claves según el threat model; prueba rotación, revocación, backup y comportamiento del servicio. | Propiedad de la clave, política, rotación, logs de acceso, recuperación y límites del proveedor. | Clave solo bajo control del proveedor cuando se exige independencia, o pérdida irrecuperable. |
| Portabilidad y salida | Prefiere APIs y formatos documentados; separa datos de negocio de lógica propietaria; ensaya exportación, restore y fin de contrato. | Inventario de exportación, tiempo/coste medidos, restore, dependencias y runbook de salida. | Dependencia propietaria sin probar, exportación inutilizable o recuperación superior al RTO. |
| Recuperación regional | Define RTO/RPO, replica solo datos permitidos, conserva credenciales y artefactos independientes y prueba identidad, DNS, secrets y observabilidad. | Línea temporal del ejercicio, pérdida de datos, aprobaciones, retorno y brechas abiertas. | La región secundaria depende del control plane afectado o no puede recibir los datos legalmente. |
Una segunda región no es automáticamente un sitio de recuperación seguro. La replicación puede cruzar una frontera de residencia; un tenant de identidad compartido puede dejar ambas regiones fuera de servicio; un gestor central de claves puede impedir la recuperación; y bases propietarias pueden hacer inviable la salida. Para cada servicio crítico, documenta geografía permitida, categorías que se pueden replicar, credenciales independientes, capacidad necesaria y quién puede activar el plan.
Registra por workload obligaciones legales, control operativo, protección técnica, resiliencia y portabilidad en campos distintos. Un proveedor puede destacar en una dimensión y quedarse corto en otra. No lo reduzcas a una casilla de “soberano”: comparte evidencias, supuestos y riesgos residuales con quien responde por el servicio.
Un catálogo de workloads vinculado con clasificación de datos y jurisdicciones; verificaciones de policy-as-code para regiones e identidad; recolector de evidencias de acceso; pruebas del ciclo de claves y recuperación; grafo de dependencias que incluya control planes y subencargados; paquete portable de exportación; y dashboard trimestral de ejercicios de recuperación y salida. Cada control tendría responsable, fuente de evidencia, vigencia, excepción y ruta de alerta.
Elige la ubicación cloud a partir del threat model y del plan de continuidad. Verifica con evidencia la ubicación, exposición jurídica, acceso operativo, control criptográfico, cadena de proveedores y salida. Reevalúa ante cambios de ley, contrato, adquisición, región, subencargado, soporte o dependencia crítica.
Nota legal: este texto es una discusión de ingeniería, no asesoría jurídica. Las transferencias, normas sectoriales, compras públicas y leyes nacionales dependen de los datos, la entidad, el servicio y la jurisdicción vigente.