Soberanía digital en Azure: qué controlas de verdad
· 8 min de lectura
By Juan Pedro Márquez
La soberanía digital no se resuelve sacando las cargas de trabajo de la nube pública. Se resuelve identificando cuál de los tres ejes —dato, operación o independencia tecnológica— te obliga de verdad, y aplicando el control que corresponde. En la mayoría de organizaciones españolas que veo, el eje es el dato, y la nube pública ya lo cubre.
El problema es que "soberanía digital" llega a TI desde la conversación política, no desde un requisito técnico. Alguien lo lee en prensa. Alguien lo traduce a "hay que repatriar todo". Y aparece un proyecto de infraestructura de tres años sin un solo artículo de normativa detrás.
¿Qué significa soberanía digital para una organización española?
Tres cosas distintas que casi nadie separa. La documentación de Microsoft sobre soberanía digital las distingue igual, y separarlas evita sobredimensionar el proyecto.
Soberanía del dato
Dónde se almacena y procesa la información, y qué ley la gobierna. Es lo que quiere decir casi todo el mundo, y lo que la nube pública europea ya resuelve mediante el EU Data Boundary y el almacenamiento en región. Si tu requisito se queda aquí, no necesitas salir. Lo detallé para tenants españoles en residencia de datos de Copilot en la UE.
Soberanía operativa
Quién puede tocar producción, con qué supervisión, y si puedes demostrarlo ante un auditor. Aquí han aparecido capacidades nuevas, y es donde más análisis desactualizados me encuentro.
Independencia tecnológica
Si puedes seguir operando aunque cambie la relación con el proveedor. Preocupación legítima de seguridad nacional e infraestructura crítica. Rara vez la de una empresa mediana, por mucho que se plantee en la reunión.
Mi norma en los talleres: antes de dibujar arquitectura, que alguien escriba la norma, el artículo y la expectativa del supervisor. Si nadie lo produce, lo que hay es soberanía del dato disfrazada.
¿Qué es la nube soberana de Microsoft y qué modelos ofrece?
La nube soberana de Microsoft es un conjunto de capacidades y modelos de despliegue para administraciones e industrias reguladas. No es un producto que se compra: son tres modelos de entrega y una serie de controles que se activan.
- Nube pública soberana: regiones hiperescalares existentes con controles añadidos de residencia, supervisión operativa y cifrado controlado por el cliente.
- Nube privada soberana: infraestructura que operas tú, sobre Azure Local, para entornos regulados o desconectados.
- Nubes de socios nacionales: entornos operados de forma independiente por un socio local bajo legislación nacional.
Esto sustituye a lo que antes se llamaba Microsoft Cloud for Sovereignty, y no fue solo un cambio de nombre: se añadieron controles que antes no existían como funcionalidad visible para el cliente.
¿Basta con la nube pública soberana?
Para la mayoría de empresas reguladas españolas y buena parte del sector público, sí. La nube pública soberana añade capacidades de soberanía sobre Azure y Microsoft 365 sin sacarte de la plataforma. Mantienes el ritmo de innovación, la inversión en seguridad y la resiliencia.
Protección de datos y supervisión europea
La capacidad que cambia las conclusiones de análisis antiguos es Data Guardian: el acceso remoto de personal de Microsoft a sistemas en regiones definidas como UE y EFTA queda supervisado en tiempo real por personal autorizado residente en Europa, y cada sesión se registra en un libro mayor a prueba de manipulaciones.
Si tu objeción histórica ha sido "un ingeniero fuera de la UE podría acceder a producción sin supervisión", esa objeción ya tiene respuesta documentada y auditable.
Distínguelo de Customer Lockbox, porque el auditor lo va a preguntar: Lockbox exige tu aprobación explícita antes de que un ingeniero acceda a contenido de cliente; Data Guardian supervisa y registra las intervenciones en producción. Los verás juntos en los controles operativos.
Barreras como código y evidencia para el ENS
La zona de aterrizaje soberana es una variante de la Azure Landing Zone con las barreras de soberanía codificadas como política, en Bicep y Terraform.
Úsala, y no porque las políticas sean mágicas. "Restringimos las regiones" es una afirmación; una asignación de política con su panel de cumplimiento es evidencia. En una auditoría del Esquema Nacional de Seguridad, esa diferencia es exactamente lo que te van a pedir.
¿Necesitas custodiar las claves fuera de Azure?
Aquí es donde discrepo de casi todas las propuestas de soberanía que reviso en España.
El equipo oye "soberanía" y salta directo a guardar las claves fuera de la infraestructura de Microsoft. Parece el control más fuerte posible. En la inmensa mayoría de casos es un mal negocio.
Azure Key Vault Managed HSM ya te da soberanía de claves: hardware validado FIPS 140-3 Nivel 3, aislamiento de inquilino único y un dominio de seguridad que controlas tú. Sin ese dominio, las claves no sirven. Eso es custodia real, con acuerdo de nivel de servicio detrás.
La administración de claves externas mantiene la clave de cifrado de claves en un HSM que operas fuera de Azure, delegando las operaciones a través de un proxy tuyo. La propia documentación de Microsoft dice dos cosas que conviene citar en el comité: que para la mayoría de organizaciones Managed HSM satisface incluso requisitos regulatorios estrictos, y que la gestión externa sacrifica disponibilidad, rendimiento y simplicidad operativa a cambio de control físico de la clave, siendo una opción de último recurso ante un mandato legal o contractual firme.
Es el fabricante diciéndote que no sobrecompres.
El modo de fallo es predecible: acabas operando un clúster HSM y un proxy en el camino crítico de todos los servicios cifrados. Tu disponibilidad queda limitada por el componente menos fiable que gestionas tú. El día que el proxy falla, se paran el almacenamiento y las bases de datos, y en la revisión del incidente alguien pregunta qué norma exigía esto.
Si tienes ese mandato por escrito, adelante. Si lo que tienes es una preferencia por el control, quédate con Managed HSM y dedica el presupuesto a corregir el exceso de permisos, que es donde se producen las fugas reales. Ese argumento lo desarrollé en Purview DSPM para IA.
¿Y si la IA no puede salir de mis instalaciones?
Entonces hablamos de nube privada soberana, que se apoya en Azure Local y admite cargas como máquinas virtuales o sobre clústeres de AKS habilitados para Arc. Encima se colocan Foundry Local para IA y Microsoft 365 Local para Exchange, SharePoint y Skype for Business Server.
Asume el intercambio con los ojos abiertos. La documentación de Microsoft dice que los entornos privados ofrecen los controles de soberanía más fuertes, con control total sobre hardware, software, datos, ubicación y gestión, y a continuación reconoce que no entregan todo el valor de la nube en coste, escalabilidad, velocidad de innovación, seguridad y fiabilidad.
Estás comprando control con velocidad de innovación. Para una carga desconectada de defensa es evidentemente correcto. Para la analítica de recursos humanos de un banco, no.
Si el bloqueo concreto es "la inferencia no puede salir", Foundry Local ejecuta modelos íntegramente dentro de tu entorno de Azure Local. Es un bloqueo más estrecho de lo que suele plantearse.
¿Y las nubes de socios nacionales?
Las nubes de socios nacionales son entornos operados de forma independiente que entregan Azure y Microsoft 365 bajo propiedad local, aislados física y lógicamente, gestionados por personal local bajo el marco normativo de cada país. Bleu en Francia —una joint venture de Orange y Capgemini construida para SecNumCloud— y Delos Cloud en Alemania —operada por una filial de SAP— son los ejemplos con nombre propio.
Existen para seguridad nacional, regulación del sector público y mitigación de riesgo geopolítico. Si no estás en una de esas categorías, este no es tu modelo.
La restricción práctica es la cobertura. La disponibilidad y el alcance del servicio varían por geografía y siguen marcos nacionales, lo que significa que las capacidades más recientes de Azure y Copilot no están ahí el primer día. Comprometer un programa de Copilot con una nube de socio nacional sin comprobar antes la lista de servicios disponibles es un error que prefiero que aprendas aquí, no en producción.
¿Qué cambia con las cargas de trabajo de IA?
Sube el listón de la clasificación e introduce activos que tu gobierno del dato probablemente no nombra. La guía de cargas de trabajo de IA y soberanía recomienda etiquetar antes de elegir modelo, y distinguir corpus de entrenamiento, incrustaciones, índices vectoriales, pesos del modelo y registros de inferencia como cosas separadas.
Las incrustaciones y los índices vectoriales son los que pillan a todo el mundo. Derivan de datos regulados, pueden filtrar información sobre ellos y acaban en un servicio que nadie metió en el alcance. Pregunta dónde vive tu índice vectorial. La pausa antes de la respuesta ya te dice bastante.
Usa claves gestionadas por el cliente para datos de entrenamiento, pesos y bases vectoriales, y rota las claves con los ciclos de versión del modelo. La parte que todos se saltan: revoca las claves sin uso al retirar un modelo. Los modelos se jubilan, sus artefactos se quedan en almacenamiento y las claves siguen vivas. Métela en el procedimiento de retirada o no ocurrirá.
Sobre la elección de plataforma, escribí la comparativa en Microsoft Foundry frente a Azure AI Foundry.
El orden correcto para decidir
- Nombra la obligación. Norma, artículo y responsable, por escrito. Sin cita no hay proyecto de soberanía.
- Clasifica el eje. Dato, operación o independencia tecnológica.
- Prueba primero la nube pública soberana. Documenta qué obligación concreta no cubre.
- Escala solo entonces. Privada para infraestructura propia o desconectada; socio nacional para seguridad nacional; claves externas solo con mandato firme por escrito.
- Comprueba la cobertura de servicio antes de comprometerte. Sobre todo para capacidades de IA y Copilot en los modelos privado y de socio nacional.
- Captura la evidencia sobre la marcha. Reconstruirla después cuesta varias veces más.
El paso 3 es el que se salta todo el mundo. Saltárselo convierte un requisito de residencia en un programa de infraestructura de tres años.
La soberanía digital en 2026 es sobre todo un problema de controles y evidencias, no de ubicación. La respuesta de ubicación era correcta en 2022. Revisa cuándo se escribió tu requisito.
Preguntas frecuentes
¿Es lo mismo soberanía digital que residencia de datos?
No. La residencia de datos es dónde se almacena y procesa la información. La soberanía digital incluye además quién puede operar el sistema, bajo qué supervisión, y si puedes seguir operando con independencia del proveedor.
¿La nube pública puede cumplir el Esquema Nacional de Seguridad?
Sí, y la vía práctica es la evidencia: asignaciones de política con panel de cumplimiento, registros de acceso supervisado y control documentado de claves. La zona de aterrizaje soberana existe precisamente para producir esa evidencia de forma sistemática en lugar de artesanal.
¿Qué diferencia hay entre nube soberana y nube privada?
La nube privada se define por quién posee y opera la infraestructura. La nube soberana se define por qué jurisdicción y qué supervisión se le aplican. La nube pública soberana es soberana sin ser privada.
¿Necesito claves externas para tener soberanía de claves?
Por lo general no. Managed HSM aporta soberanía de claves con hardware FIPS 140-3 Nivel 3, aislamiento de inquilino único y dominio de seguridad bajo tu control, y la guía de Microsoft indica que eso satisface requisitos estrictos en la mayoría de organizaciones.
¿Puedo ejecutar Copilot y cargas de IA en un entorno soberano?
Sí, con modelos distintos. En la nube pública soberana aplicas los controles de soberanía a lo largo del ciclo de vida de la IA con claves gestionadas por el cliente, computación confidencial y Data Guardian. Si el requisito es que no salga de tus instalaciones, Foundry Local en Azure Local ejecuta los modelos dentro de tu propio entorno. En nubes de socio nacional, comprueba antes la cobertura de servicio.
¿Dónde encajan los compromisos digitales europeos?
Son los compromisos de política que sustentan estos controles, y las políticas de la zona de aterrizaje soberana se alinean con ellos. Merece la pena revisar los compromisos digitales europeos antes de una conversación con el supervisor, porque es lo que él habrá leído.