Durante años hemos vendido la nube como una conversación casi binaria: o estás en cloud o estás on-premises. Para mí, ese debate ya se ha quedado corto.

La cuestión real ya no es “cloud sí” o “cloud no”. La cuestión relevante para gobiernos, banca, salud, industria, defensa o infraestructuras críticas es otra:

¿Qué nivel de control operativo, jurídico, técnico y de continuidad necesito sobre mis sistemas más sensibles?

Y aquí es donde empieza a ponerse interesante la conversación sobre cloud soberana, Azure Local, operaciones desconectadas, Microsoft 365 Local, Foundry Local y modelos de DevOps más controlados.

Mi tesis es sencilla: la soberanía digital no consiste en sacar todo de la nube pública. Consiste en diseñar una arquitectura capaz de demostrar control cuando las condiciones normales dejan de ser normales.

Microsoft ya presenta su estrategia de Sovereign Cloud en tres modelos: nube pública soberana, nube privada soberana y nubes nacionales operadas con socios locales. La propia documentación de Microsoft describe la Sovereign Public Cloud como Azure/Microsoft cloud con controles añadidos de residencia, claves gestionadas por cliente, transparencia operativa, Data Guardian, External Key Management y logs resistentes a manipulación; y define la Sovereign Private Cloud como un modelo ejecutado en datacenters controlados por el cliente o por socios, basado en Azure Local y Microsoft 365 Local, orientado a escenarios híbridos o desconectados.

Soberanía no es solo residencia de datos

Uno de los errores habituales es reducir la soberanía a “mis datos están en Europa” o “mis datos están en una región concreta”.

Eso es importante, pero no suficiente.

La soberanía real tiene varias capas:

Primero, soberanía del dato: dónde reside, quién lo cifra, quién puede acceder y bajo qué condiciones.

Segundo, soberanía operativa: quién administra la plataforma, qué accesos excepcionales existen, cómo se auditan y si puedo demostrar trazabilidad.

Tercero, soberanía tecnológica: si mis cargas críticas pueden seguir funcionando aunque pierda conectividad, aunque haya una crisis contractual, regulatoria, geopolítica o de proveedor.

Cuarto, soberanía del ciclo de vida del software: dónde vive el código, dónde se ejecutan los pipelines, dónde están los secretos, quién puede modificar la cadena de suministro y cómo se evidencia cada cambio.

Para mí, esta última parte se olvida demasiado. En empresas reguladas, el código fuente, los pipelines y los artefactos de despliegue son tan sensibles como los datos de producción. No tiene sentido proteger obsesivamente una base de datos si luego el camino que permite cambiar el software está débilmente gobernado.

Azure Local: la nube híbrida empieza a parecerse a una póliza de continuidad

Azure Local es especialmente relevante porque deja de plantear el datacenter como un “mundo antiguo” separado de la nube. Microsoft lo describe como una solución de infraestructura distribuida para ejecutar máquinas virtuales, contenedores y determinados servicios Azure en infraestructura propiedad del cliente; además, Azure Stack HCI forma ya parte de Azure Local.

La diferencia importante no es solo técnica. Es estratégica.

Azure Local puede convertirse en la base para una arquitectura donde ciertas cargas sigan beneficiándose del modelo cloud, pero con más control sobre ubicación, operación y continuidad. En la documentación de Sovereign Private Cloud, Microsoft posiciona Azure Local como la capa base de infraestructura para workloads soberanos, incluyendo cómputo, almacenamiento, red, lifecycle management, VMs y AKS habilitado por Arc.

Esto no significa que Azure Local sea “todo Azure dentro de tu CPD”. Esa lectura sería equivocada y peligrosa. Significa algo más concreto: una base local, gestionable con experiencia cloud, sobre la que construir escenarios regulados, híbridos, edge o desconectados.

Y aquí está el matiz que a mí me parece clave: Azure Local no debería venderse como nostalgia on-premises. Debería entenderse como resiliencia arquitectónica soberana.

Operaciones desconectadas: útil, pero no magia

Las operaciones desconectadas son probablemente una de las piezas más importantes para sectores regulados. La documentación pública indica que permiten desplegar y administrar instancias de Azure Local sin conexión a la nube pública de Azure, usando un plano de control local y una experiencia familiar de portal y CLI para máquinas virtuales y aplicaciones contenedorizadas mediante servicios seleccionados habilitados por Azure Arc.

Esto es muy potente, pero hay que aterrizarlo bien.

Desconectado no significa “sin gobierno”.
Desconectado no significa “sin parches”.
Desconectado no significa “sin identidad”.
Desconectado no significa “sin operación”.

De hecho, cuanto más aislado está un entorno, más disciplina necesita: gestión de versiones, procedimientos de actualización offline, control de identidades locales, backups, observabilidad, evidencias, runbooks, pruebas de conmutación, restauración y validación periódica.

La cloud soberana no elimina la complejidad. La mueve al terreno donde los arquitectos debemos estar cómodos: diseño de riesgos, controles y evidencias.

Microsoft 365 Local: útil, pero no confundamos el alcance

Microsoft 365 Local es otra pieza interesante, pero conviene explicarla con precisión. Según Microsoft Learn, Microsoft 365 Local permite ejecutar Exchange Server, SharePoint Server y Skype for Business Server sobre infraestructura Azure Local propiedad y gestionada por el cliente, con mayor control de residencia, acceso y cumplimiento. También se indica que soporta escenarios híbridos y completamente desconectados.

Esto es importante para sectores que necesitan productividad local o continuidad en escenarios de aislamiento.

Pero hay que evitar una confusión: Microsoft 365 Local no debe interpretarse automáticamente como “todo Microsoft 365 cloud funcionando localmente”.

No estamos hablando, al menos con la información pública actual, de replicar sin más toda la experiencia SaaS moderna de Microsoft 365, Teams, Copilot, Entra ID, Conditional Access y ecosistema cloud en un datacenter local. Es una solución con un alcance concreto, útil para determinados escenarios, pero que debe explicarse sin crear expectativas incorrectas.

En entornos regulados, vender mal el alcance de una plataforma es casi tan peligroso como diseñarla mal.

IA soberana: el dato no siempre puede ir al modelo

La IA introduce una nueva tensión. Antes nos preocupaba dónde estaba la base de datos. Ahora también debemos preguntarnos:

¿Dónde se ejecuta la inferencia?
¿Dónde se procesan los embeddings?
¿Dónde se guardan los prompts?
¿Dónde se evalúan los modelos?
¿Dónde quedan las trazas?
¿Qué datos pasan por una cadena RAG?
¿Qué agente puede actuar sobre qué sistema?

Microsoft ya documenta Foundry Local sobre Azure Local como una vía para acercar la IA al dato, desplegando y ejecutando modelos dentro del entorno Azure Local. La documentación pública indica que Foundry Local está en preview, que puede desplegarse sobre Kubernetes conectado a Azure Arc o Kubernetes directo, y que requiere acceso de preview para el despliegue.

Para mí, esto apunta a una idea importante: la IA empresarial no se va a decidir solo por el modelo más potente, sino por el modelo operativo más gobernable.

En banca, salud, administración pública o industria, muchas cargas de IA no podrán moverse alegremente a cualquier endpoint global. Necesitaremos arquitecturas donde los datos sensibles se queden cerca de su dominio de control, donde la inferencia tenga trazabilidad y donde los agentes no puedan actuar sin límites.

Aquí conecto con algo que llevo tiempo defendiendo: la IA empresarial no puede ser solo productividad individual. Tiene que evolucionar hacia un modelo gobernado de ciclo de vida: intención, especificación viva, controles, ADRs, guardrails, testing, despliegue y auditoría.

DevOps soberano: el código también es soberanía

Hay un punto que creo que va a ganar peso: la soberanía del software delivery.

GitHub Enterprise Server ya existe como versión self-hosted de GitHub. La documentación oficial de GitHub lo describe como una plataforma autohospedada que se ejecuta en infraestructura propia, con controles de acceso, seguridad, red, IAM, monitorización y VPN definidos por la empresa. También deja claro que el administrador es responsable de mantener la instancia actualizada.

Esto no es menor.

Si una organización necesita soberanía extrema, no basta con tener producción controlada. Tiene que controlar también:

  • repositorios;
  • pull requests;
  • secretos;
  • pipelines;
  • artefactos;
  • políticas de branch;
  • evidencias de revisión;
  • SBOMs;
  • firmas de artefactos;
  • trazabilidad de cambios;
  • dependencias de terceros.

Mi punto aquí es claro: GitHub Enterprise Server encaja muy bien conceptualmente en una estrategia de soberanía del software delivery. Pero en arquitectura no deberíamos vender intuiciones como certezas. Hasta que no exista documentación suficiente o una validación real en un entorno controlado, lo responsable es tratarlo como una opción prometedora, no como una capacidad cerrada y universalmente aplicable.

La nube soberana no es una tecnología: es una arquitectura de decisión

Para mí, el mayor error sería convertir esto en otro catálogo de productos.

Azure Local, Microsoft 365 Local, Foundry Local, Confidential Computing, External Key Management, Data Guardian, Sovereign Landing Zone o Regulated Environment Management son piezas. Algunas ya están disponibles, otras evolucionan, y todas requieren diseño.

La Sovereign Landing Zone, por ejemplo, se plantea como un enfoque de policy-as-code para aplicar controles de localización, cifrado, configuración y computación confidencial en entornos soberanos. Microsoft también documenta REM como una experiencia para configurar, desplegar y monitorizar workloads en soporte de operaciones soberanas, complementando EKM, Data Guardian y Confidential Computing.

Pero ninguna landing zone sustituye a una conversación seria sobre riesgo.

La pregunta correcta no es: “¿Qué producto compro?”
La pregunta correcta es: “¿Qué escenarios de pérdida de control debo resistir?”

Por ejemplo:

¿Qué pasa si pierdo conectividad durante días?
¿Qué pasa si un proveedor externo no puede operar mi entorno?
¿Qué pasa si una carga crítica debe moverse a ejecución local?
¿Qué pasa si necesito demostrar que ningún operador no autorizado accedió a datos sensibles?
¿Qué pasa si mi pipeline de software queda comprometido?
¿Qué pasa si un modelo de IA procesa información regulada fuera del perímetro aceptado?

Ahí es donde un arquitecto aporta valor. No dibujando cajas, sino convirtiendo incertidumbre en decisiones verificables.

Mi punto de vista

Mi lectura es que estamos entrando en una etapa donde la cloud híbrida deja de ser una solución de transición y pasa a ser una estrategia de resiliencia soberana.

Durante años, muchas organizaciones han visto lo híbrido como una deuda: “todavía no hemos migrado todo”. Creo que eso cambia. En los próximos años, lo híbrido bien diseñado puede convertirse en una ventaja competitiva para sectores regulados.

Pero tiene que ser híbrido de verdad, no un Frankenstein.

Tiene que tener identidad pensada.
Tiene que tener red pensada.
Tiene que tener observabilidad pensada.
Tiene que tener actualizaciones pensadas.
Tiene que tener DevSecOps pensado.
Tiene que tener IA pensada.
Tiene que tener pruebas reales de desconexión.
Tiene que tener evidencias.

La cloud soberana no debería ser una excusa para volver a modelos artesanales, opacos y difíciles de operar. Debería ser justo lo contrario: llevar la disciplina cloud, la automatización, el gobierno y la trazabilidad a los entornos donde el control local es obligatorio.

Conclusión

No creo que el futuro sea abandonar la nube pública. Tampoco creo que el futuro sea confiar ciegamente en ella para todo.

Creo que el futuro será más matizado:

  • cloud pública para innovación, elasticidad y servicios avanzados;
  • cloud soberana pública para cargas reguladas con controles reforzados;
  • Azure Local y modelos privados para continuidad, edge, defensa, industria y escenarios críticos;
  • IA local o híbrida cuando el dato, la latencia o la regulación lo exijan;
  • DevOps soberano cuando el código y la cadena de suministro sean activos críticos.

La soberanía digital no es un botón.
No es una región.
No es un contrato.
No es una landing zone.
No es un producto.

Es una arquitectura de control, continuidad y evidencia.

Y esa, sinceramente, es una conversación donde los arquitectos tenemos que estar mucho más presentes.