Resumen

  • AWS respalda su European Sovereign Cloud con compromisos operativos, jurídicos y arquitectónicos poco habituales; deben verificarse como un mapa de control, no aceptarse como una etiqueta geográfica.
  • Una decisión sólida examina seis vías: operaciones privilegiadas, identidad y claves, soporte, cadena de software, gobierno y autoridad de cambio de emergencia.

Una carga regulada puede mantener todos sus datos en Brandeburgo y aun dejar sin respuesta su decisión extraordinaria más importante: ¿quién autoriza un cambio urgente cuando la cadena de mando habitual no está disponible? La pregunta no presupone un fallo. Separa la residencia —dónde reposan los datos— de la soberanía operativa —las personas, credenciales, entidades jurídicas y proveedores capaces de cambiar lo que ocurre después—.

La propuesta de AWS va más allá de un distintivo regional. AWS European Sovereign Cloud está disponible desde el 14 de enero de 2026, con una primera región en Brandeburgo y tres zonas de disponibilidad. AWS afirma que está separada física y lógicamente de sus demás regiones; usa sistemas dedicados de identidad, facturación y DNS; mantiene en la UE el contenido y los metadatos creados por clientes; y está diseñada para operar si se corta la conexión con el resto del mundo.

El trabajo diario queda en manos de personal residente en la UE, con una transición progresiva hacia ciudadanos de la UE. Entidades jurídicas alemanas dedicadas y un consejo asesor de ciudadanos europeos añaden un límite de gobierno.

Son controles relevantes, pero siguen siendo declaraciones y compromisos del proveedor. No demuestran que cada arquitectura del cliente herede el mismo resultado. La federación de identidad, el soporte, la observabilidad, las claves, el despliegue o el software de terceros pueden reintroducir dependencias. La soberanía empieza por inventariarlas.

La primera vía son las operaciones privilegiadas: todos los roles que pueden cambiar producción, su jurisdicción y empleador, la aprobación exigida y el acceso de emergencia. La segunda es la identidad y la autoridad criptográfica: dónde se controlan credenciales raíz, firmas y claves, y si una identidad externa sigue en el camino crítico. La tercera es el soporte: una recepción local no basta si un incidente complejo necesita equipos o diagnóstico fuera del límite.

La cuarta vía es el suministro de software. Una nube europea puede depender de repositorios, compilación, claves de firma, inteligencia de vulnerabilidades o autoridades de lanzamiento situadas fuera. AWS afirma que no tiene dependencias críticas de infraestructura no europea; el comprador debe convertirlo en una lista de componentes, pruebas de fallo y evidencias.

La quinta es el gobierno: qué entidad contrata, emplea, subcontrata y puede ser obligada a actuar. El Addendum contiene compromisos sobre personal, gobierno, subcontratistas, continuidad y aviso, incluido un mínimo de doce meses para ciertos cambios materiales o una discontinuación prevista, con excepciones definidas.

La sexta vía es la autoridad de emergencia. Conviene ensayar conflicto jurídico, falta de personal, un canal de actualización comprometido y una vulnerabilidad grave que requiera un parche inmediato. Para cada escenario: quién decide, quién ejecuta, qué sistema autoriza, qué dependencia externa se activa y qué prueba queda después.

La propuesta europea de Cloud and AI Development Act ofrece una escala compatible. El primer nivel exige ubicación de datos en la UE. Los niveles superiores añaden independencia del derecho de terceros países, transparencia del suministro de software, propiedad y control europeos y, al final, dominio integral de la cadena de software sin interferencia exterior. La propuesta puede cambiar, pero su estructura acierta: la ubicación abre el argumento, no lo cierra.

El expediente de aceptación debería incluir un mapa del plano de control, registro de roles y jurisdicciones, custodia de claves, rutas de soporte y subcontratación, procedencia de compilaciones y firmas, compromisos de gobierno y resultados de ejercicios de aislamiento y cambio urgente. Las fuentes públicas no prueban esos hechos para una carga concreta; el comprador debe obtenerlos y ponerlos a prueba.

AWS ha elevado la precisión del debate. La respuesta justa no es aceptar ni sospechar por reflejo. Un servicio es soberano para una carga solo si sus dependencias decisivas permanecen dentro del límite acordado y auditable cuando dejan de darse las condiciones normales.

Fuentes