Nube soberana en Europa: la residencia no es lo mismo que la jurisdicción.

Esta página es la perspectiva de ingeniería. Si tu DPO, tu auditor o un filtro de compras está preguntando qué significa realmente "soberano" en 2026, esta es la versión que resiste el escrutinio.

Residencia frente a soberanía: la distinción que lo decide todo

La industria de la nube ha dedicado quince años a entrenar a los compradores para que hagan la pregunta equivocada. "¿Dónde se aloja el dato?" es una pregunta de residencia. La respuesta puede ser técnicamente correcta y legalmente irrelevante al mismo tiempo, porque la soberanía no tiene que ver con la geografía. Tiene que ver con qué tribunales pueden obligar a un proveedor a actuar.

Una región UE en un hyperscaler estadounidense, como AWS Frankfurt, Azure West Europe o GCP Belgium, mantiene los bits en la UE. No elimina a la empresa matriz de la jurisdicción estadounidense. Bajo la US CLOUD Act (2018), un proveedor con sede en EE. UU. puede ser obligado a revelar datos de clientes alojados en cualquier parte del mundo, incluidas las regiones UE. La FISA 702 impone la misma exposición en el ámbito de la vigilancia. El Comité Europeo de Protección de Datos ha señalado esto explícitamente como un problema de Schrems II.

"Soberano" significa entonces tres cosas concretas, todas a la vez:

1. La entidad legal que posee tus datos no tiene una matriz en un país tercero con leyes extraterritoriales de divulgación de datos.
2. Ningún subprocesador en la ruta de datos se encuentra tampoco en dicho país.
3. Tú, no el proveedor, controlas las claves de cifrado, o las claves residen en un custodio fuera del tercer país.

Si cumples las tres condiciones, tienes soberanía. Si fallas en una, tienes residencia. La terminología de tu DPA, tu política de privacidad y tus páginas orientadas al cliente deben reflejar cuál de las dos es realmente.

Por qué "subsidiaria de la UE" no es la respuesta

Una solución habitual que promueven los hyperscalers estadounidenses es la estructura de subsidiaria en la UE. Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd. El argumento es que la entidad europea es la contraparte contractual bajo la legislación de la UE.

Esto no resuelve el problema jurisdiccional. Según la CLOUD Act, la prueba no es qué subsidiaria firmó el contrato. Es si la empresa matriz tiene "posesión, custodia o control" de los datos. Una subsidiaria de la UE de propiedad total está, por diseño, controlada por la matriz. El análisis del TJUE y el EDPB en Schrems II trata la exposición de la matriz como la determinante.

Así que cuando un proveedor ofrece un plan "europeo" operado por una filial en la UE de un grupo estadounidense, la pregunta correcta es: "¿Puede obligarse a su empresa matriz estadounidense a ordenarle divulgar datos sin nuestro consentimiento ni conocimiento?" La respuesta honesta es sí.

El nivel intermedio pseudo-soberano

De 2024 a 2026 se produjo una ola de asociaciones "soberanas" anunciadas, típicamente un integrador de sistemas europeo que licencia el stack tecnológico de un hyperscaler estadounidense y lo opera bajo gestión europea. Ejemplos en el mercado actual:

• Ofertas soberanas licenciadas, construidas sobre tecnología de un hyperscaler estadounidense, operadas por una subsidiaria europea de Telekom.
• Bleu, una nube soberana francesa construida sobre la tecnología de Microsoft Azure, operada por Capgemini y Orange.
• S3NS, una joint venture de Thales y Google en Francia.

Estas ofertas pueden ser útiles para regímenes de cumplimiento específicos, pero no son lo que un equipo de ingeniería debería llamar soberano sin matices. La pila tecnológica, las actualizaciones de la plataforma, los parches de seguridad y, de forma crucial, el know-how operativo provienen del socio estadounidense. En el peor escenario de amenaza, en el que la parte estadounidense retira su cooperación o es obligada a hacerlo, el operador europeo hereda una pila que no puede mantener de forma independiente.

Para la mayoría de los compradores, la respuesta arquitectónica más limpia es construir sobre una infraestructura donde no exista dependencia de EE. UU. en la cadena de suministro en absoluto. Eso es lo que queremos decir cuando hablamos de un stack soberano en Binadit.

Cómo es en realidad un stack soberano de la UE

Aquí tiene una arquitectura de referencia concreta para una carga de trabajo SaaS del mercado medio o regulada que se ejecuta enteramente bajo jurisdicción de la UE. Ninguna de ellas es exótica; todas son de nivel producción.

• Compute y almacenamiento: compute gestionado de Binadit y hardware dedicado, sobre infraestructura de la UE bajo jurisdicción de la UE.
• Almacenamiento de objetos: Ceph o MinIO, compatibles con S3, operados por nosotros en la misma infraestructura.
• CDN: Bunny.net (SI), KeyCDN (CH), o gestionado de forma autónoma en el edge para un control total.
• DNS: PowerDNS o Knot, autoritativos y firmados con DNSSEC, o Bunny DNS donde se desee integrado con el CDN.
• Entrega de correo electrónico: Mailgun EU (con precaución, debido a la matriz estadounidense), u opciones totalmente de la UE como Postmark EU, Mailpace, Tuta business, o Postfix self-hosted en la misma infraestructura.
• Seguimiento de errores: GlitchTip o Sentry self-hosted, o el despliegue de Sentry en la región de la UE con las contrapartidas documentadas.
• Analytics: Plausible (alojado en la UE), Matomo (self-hosted o cloud de la UE), Pirsch.
• Observabilidad: Prometheus + Grafana + Loki autogestionados, o equivalentes gestionados en la UE (Grafana Cloud EU, Last9 con región UE).
• Gestión de claves: Hashicorp Vault sobre infraestructura de la UE, o proveedores de KMS gestionados en la UE; para escenarios de alta confianza, HSM on-premises con BYOK del lado de la nube.
• CI/CD: GitLab self-hosted, Forgejo, Gitea, o la instancia de GitLab.com en la UE. Nunca el github.com por defecto para código que involucre datos personales sin medidas complementarias.

El objetivo no es que uno solo de estos elementos sea "la" respuesta. El objetivo es que toda la pila pueda montarse con proveedores con sede en la UE, y que un socio de infraestructura gestionada pueda operarla de la misma manera que un socio nativo de AWS operaría AWS.

La prueba de las cuatro preguntas, en detalle

1. Residencia: dónde, exactamente

No "en la UE", sino en qué datacenter, en qué país, bajo qué jurisdicción. La UE no es un único régimen legal; el GDPR está armonizado, pero la autoridad de supervisión es local, y también lo es el recurso legal si un proveedor falla. Documenta el código de país para las ubicaciones primaria, secundaria y de backup en tu DPA.

2. Subprocesadores: cada uno de ellos

En nuestras auditorías de entornos del mercado medio, la cadena de subprocesadores sin mapear es el hallazgo más común. La aplicación está en infraestructura de la UE, lo cual es positivo. Pero la API de optimización de imágenes que llama está alojada en EE. UU. El correo transaccional se envía a través de un ESP estadounidense. El rastreador de errores es el predeterminado de EE. UU. El widget de soporte al cliente carga JavaScript desde una CDN de EE. UU. Cada uno es un flujo de datos independiente. Cada uno necesita una base legal si los datos cruzan a un tercer país.

Un stack soberano requiere una lista completa de subencargados, incluyendo las APIs de terceros que su aplicación utiliza y no solo los proveedores de infraestructura. La nuestra figura íntegramente en el acuerdo de tratamiento de datos, y se la enviaremos antes de que firme nada.

3. Jurisdicción: quién puede exigir la divulgación

La cuestión del proceso legal. Para cada entidad en tu ruta de datos, identifica la sede de la empresa matriz. Si alguna matriz está en EE. UU., China, Rusia u otro país con leyes extraterritoriales de acceso a datos, esa entidad está expuesta. El estatus de filial en la UE de una matriz estadounidense no resuelve el problema.

Aquí es donde el diagrama de arquitectura se convierte en un documento legal. Dibújalo una vez, revísalo trimestralmente.

4. Custodia de claves: quién puede leer técnicamente los datos

El cifrado en reposo es necesario pero no suficiente. La cuestión es quién tiene las claves. Las claves gestionadas por el proveedor no ofrecen protección alguna frente a que el proveedor sea obligado a descifrar. BYOK (Bring Your Own Key) ayuda al discurso de cumplimiento; el proveedor sigue teniendo una copia en tiempo de ejecución. HYOK (Hold Your Own Key) es el único modelo en el que el proveedor cloud físicamente no puede leer los datos sin una llamada activa a su custodio de claves. Elija el modelo que exija el modelo de amenazas.

La ruta de migración: de AWS Fráncfort a una pila soberana

El temor a abandonar un hyperscaler suele ser mayor que el proyecto real. Una migración típica de mercado medio se desarrolla en tres fases:

1. Inventario y auditoría (1-2 semanas). Mapee cada flujo de datos, identifique cada subprocesador, clasifique según exposición a EE. UU. Resultado: una lista de remediación ordenada por riesgo y complejidad de migración.
2. Eliminaciones rápidas (2-4 semanas). Sustituya primero las dependencias blandas: seguimiento de errores, analítica, CDN, DNS, correo electrónico. Estas se migran con poco o ningún cambio en la aplicación.
3. Migración del núcleo (4-8 semanas). Compute, almacenamiento, base de datos. Use replicación por streaming para migraciones de bases de datos sin downtime; use patrones blue-green o DNS-failover en la capa de aplicación. La parte difícil raramente es la tecnología. Es la coreografía.

Tiempo total transcurrido para que un equipo de ingeniería de 6 a 8 personas, con sus tareas diarias, lo complete: de diez a dieciséis semanas. Con un socio de infraestructura gestionada impulsando la migración, de cuatro a doce. La diferencia de costo entre ejecutar el stack soberano frente al hyperscaler es, en nuestra experiencia, neutra a negativa para cargas de trabajo predecibles, moderadamente mayor para cargas de trabajo con picos, y significativamente menor una vez que se consideran el egress y el ancho de banda.

¿Es más cara la nube soberana? La respuesta honesta

Para el 80% de las cargas de trabajo del mercado medio, el stack soberano es más económico a cinco años, principalmente porque los proveedores de la UE no cobran tarifas punitivas de egress y porque el precio de servidores dedicados y bare-metal es dramáticamente mejor que los tipos de instancia equivalentes de los hyperscalers. Los casos en los que el stack soberano resulta más costoso son: cargas de trabajo muy variables que se benefician del autoescalado en menos de un segundo, cargas de trabajo que dependen de un servicio gestionado específico (DynamoDB, BigQuery, Lambda) sin un equivalente limpio, y cargas de trabajo de entrenamiento de ML que requieren una generación específica de acelerador.

Una revisión técnica competente le dirá en una semana en qué categoría se encuentra. Si desea una, eso es a lo que nos dedicamos.

Impulso regulatorio: NIS2, DORA, EHDS y la AI Act

La dirección regulatoria entre 2025 y 2027 apunta hacia una mayor exigencia de responsabilidad en la cadena de suministro:

• NIS2 (Artículo 21): las entidades esenciales e importantes deben realizar evaluaciones de riesgo en la cadena de suministro y trasladar contractualmente las obligaciones de seguridad a los subprocesadores. Un subprocesador bajo jurisdicción estadounidense es difícil de defender en esta evaluación sin medidas complementarias.
• DORA (en vigor desde enero de 2025): las entidades financieras deben mantener un registro de proveedores externos de TIC y una estrategia de salida para proveedores críticos. El concepto de riesgo de concentración apunta explícitamente a la dependencia de proveedores dominantes no pertenecientes a la UE.
• European Health Data Space (EHDS): el uso secundario de datos de salud está restringido a entornos de procesamiento bajo jurisdicción de la UE.
• EU AI Act: los sistemas de IA de alto riesgo requieren una procedencia trazable de los datos de entrenamiento, lo cual es en la práctica muy difícil sobre una API de modelo fundacional estadounidense.

Ninguna de estas regulaciones prohíbe a los proveedores de EE. UU. Lo que hacen es elevar la carga de documentación y medidas suplementarias lo suficiente como para que, en la mayoría de los casos de uso, un stack soberano sea la opción de menor fricción.

Lo que no afirmamos

Para ser honestos: hay cargas de trabajo en las que un stack soberano de la UE resulta más difícil que con un hyperscaler. Multi-región activo-activo con latencia global por debajo de 50ms. Almacenes de análisis gestionados específicos. Inferencia de ML a hiperescala en los últimos aceleradores. Le informaremos cuando su carga de trabajo pertenezca a esa categoría. Para el 90% de las plataformas SaaS, e-commerce, B2B y cargas de trabajo reguladas que vemos, el stack soberano no solo cumple con la normativa. También es más rápido, más económico y más fácil de razonar.

Dónde encaja Binadit

Somos un procesador de datos según el Artículo 28, con sede en Rotterdam, Países Bajos. Nuestra huella de infraestructura es 100% con proveedores con sede en la UE. Nuestra lista de subprocesadores está nombrada en su totalidad en el acuerdo de procesamiento de datos y disponible a solicitud. No aceptamos proyectos que requieran un subprocesador bajo jurisdicción estadounidense en la ruta de datos predeterminada. Cuando una carga de trabajo realmente requiere uno (un SaaS de terceros en el que el cliente insiste), lo documentamos por escrito, incluimos las medidas suplementarias y presentamos el riesgo residual al DPO antes de firmar.

Si eso suena como el tipo de socio que ha estado buscando, el siguiente paso es una llamada de alcance de 30 minutos.