La ilusión de la soberanía de datos: por qué las "zonas locales" no son suficientes

La geografía de una mentira

En las elegantes salas de juntas con paredes de cristal de Frankfurt, París y Ámsterdam, ha echado raíces una ficción reconfortante. Es la ficción de la "Zona Local". Cuenta una historia sencilla y tranquilizadora tanto a los directores de sistemas de información (CIO) como a los ministros: si alojan sus datos en un centro de datos ubicado físicamente en suelo europeo (tal vez un almacén anodino en los suburbios de Dublín, o un búnker cerca de Frankfurt), están protegidos. Cumplen con la normativa. Son soberanos.

Esta historia la cuentan los mayores hiperescaladores (hyperscalers) del mundo: Amazon Web Services, Microsoft Azure, Google Cloud. La repiten los responsables de compras, la validan costosos consultores y la firman los equipos de cumplimiento desesperados por marcar una casilla. Es la base de miles de millones de euros en gasto de TI en toda la Unión Europea.

Es también, para ser francos, una ilusión peligrosa.

En 2025, la ubicación física es el factor menos importante en la soberanía de los datos. Es una reliquia de una época en la que los datos eran papel físico en un archivador. En la era digital, la unidad física donde descansan sus datos podría estar en un bastidor de servidores en Dublín, pero si el sistema de gestión de identidades que controla el acceso se ejecuta en Virginia, usted no es soberano. Si el equipo de soporte que repara el servidor responde ante un gerente en Seattle, usted no es soberano. Y si las claves de cifrado que bloquean sus datos son gestionables en última instancia por una entidad estadounidense sujeta a la CLOUD Act, definitivamente no es soberano.

Estamos construyendo nuestra infraestructura crítica (nuestras redes energéticas, nuestros sistemas sanitarios, nuestros libros de contabilidad bancarios, nuestra logística de defensa) sobre una base de arena. Hemos confundido "residencia" con "soberanía". Y en un mundo de creciente inestabilidad geopolítica, esa confusión podría costarnos nuestra independencia.

La anatomía de la nube: músculo frente a cerebro

Para entender por qué falla el modelo de "Zona Local", hay que mirar más allá de los folletos de marketing y comprender la arquitectura de la nube pública moderna. Tendemos a pensar en la nube como una colección de servidores (cómputo) y discos duros (almacenamiento). Pero estos son solo el músculo. El "cerebro" de la nube es el Plano de Control.

El Plano de Control es la capa de software centralizada que orquesta todo. Decide quién puede activar una máquina virtual. Decide quién puede acceder a una base de datos. Gestiona la facturación. Envía las actualizaciones de software. Posee las claves maestras. Y crucialmente, para los principales hiperescaladores estadounidenses, este Plano de Control es un sistema global y unificado. No está federado; está centralizado. Y está casi invariablemente controlado desde Estados Unidos.

Cuando un banco europeo despliega su sistema bancario central en una región "soberana" de un hiperescalador de EE. UU., está efectivamente alquilando una habitación en un hotel enorme. Pueden cerrar la puerta de su habitación, claro. Pueden traer sus propios muebles. Pero el propietario controla el sistema de seguridad del edificio, la electricidad, el agua, los ascensores y (crucialmente) la llave maestra que anula todas las demás.

Esta centralización crea dos riesgos distintos: el riesgo técnico y el riesgo legal.

El riesgo técnico: la dependencia de US-East-1

La vulnerabilidad técnica de esta arquitectura no es teórica; se ha demostrado una y otra vez. Los ingenieros de nube experimentados conocen el chiste: "Cuando US-East-1 estornuda, internet se resfría". US-East-1 (Norte de Virginia) es la región principal para muchos servicios de AWS y, a menudo, aloja el plano de control global para funciones específicas.

Hemos visto múltiples casos en los que interrupciones en Virginia han derribado servicios en EU-West (Irlanda) o EU-Central (Frankfurt). ¿Por qué? Porque la región local en Europa no podía autenticar usuarios, o no podía aprovisionar nuevos recursos, porque perdió el contacto con la "Nave Nodriza" en EE. UU. Si un corte de fibra, un error de software o un ciberataque en Virginia puede detener su negocio en Berlín, su negocio no es soberano. Está atado.

La verdadera soberanía requiere la "Prueba de desconexión de internet". Si se cortaran físicamente los cables de fibra óptica que conectan Europa con Estados Unidos, ¿seguiría funcionando su infraestructura digital? Para la mayoría de las empresas europeas que operan en nubes de EE. UU., la respuesta es un aterrador "No". Perderían la capacidad de iniciar sesión (la gestión de identidades y accesos suele llamar a casa), la capacidad de escalar (Plano de Control inalcanzable) y, potencialmente, la capacidad de descifrar datos (Servicio de Gestión de Claves inalcanzable).

El riesgo legal: el largo brazo de la ley estadounidense

La dimensión legal es aún más cruda que la técnica, y es donde el marketing de "Zona Local" se desmorona por completo. Estados Unidos tiene un marco legal que rechaza explícitamente la idea de soberanía de datos basada en la ubicación física.

La CLOUD Act

La CLOUD Act de EE. UU. (Clarifying Lawful Overseas Use of Data Act), aprobada en 2018, cambió las reglas del juego. Fue diseñada para resolver un problema específico para las fuerzas del orden de EE. UU.: querían datos en poder de Microsoft en Irlanda, y Microsoft se negó a entregarlos, argumentando que estaban bajo jurisdicción irlandesa. La CLOUD Act invalidó ese argumento.

Bajo la CLOUD Act, las fuerzas del orden de EE. UU. pueden obligar a cualquier empresa tecnológica con sede en EE. UU. (o cualquier empresa con un "nexo suficiente" con EE. UU.) a entregar los datos que controlan, independientemente de dónde se almacenen esos datos. No importa si el servidor está en París. No importa si la filial que posee los datos es una Sociedad de Responsabilidad Limitada irlandesa. Si la empresa matriz es estadounidense, los datos están al alcance de los tribunales de EE. UU.

Esto es extraterritorialidad codificada en ley. Trata a las empresas tecnológicas estadounidenses como extensiones del estado estadounidense, con el poder de llegar a jurisdicciones extranjeras y extraer información sin pasar por el proceso tradicional del Tratado de Asistencia Legal Mutua (MLAT).

FISA 702 y vigilancia upstream

Más allá de la aplicación de la ley estándar, existe el ámbito de la seguridad nacional. La Sección 702 de la Ley de Vigilancia de Inteligencia Extranjera (FISA) permite a las agencias de inteligencia de EE. UU. (como la NSA) obligar a los proveedores de servicios de comunicación electrónica de EE. UU. a ayudar en la vigilancia de personas no estadounidenses ubicadas fuera de Estados Unidos.

Esto no se trata de atrapar criminales; se trata de inteligencia extranjera. "Inteligencia extranjera" es un término amplio que puede abarcar desde terrorismo hasta negociaciones comerciales, estrategias diplomáticas y capacidades industriales. Bajo FISA 702, se puede ordenar a un proveedor de nube de EE. UU. que intercepte comunicaciones o datos. Crucialmente, a menudo se les prohíbe revelar que existe tal orden.

El Tribunal de Justicia de la Unión Europea (TJUE) es muy consciente de esto. En la histórica sentencia Schrems II en 2020, el TJUE invalidó el acuerdo de transferencia de datos "Privacy Shield" entre la UE y EE. UU. El razonamiento del tribunal fue explícito: las leyes de vigilancia de EE. UU. (FISA 702, EO 12333) son desproporcionadas y no otorgan a los ciudadanos europeos derechos accionables. Por lo tanto, EE. UU. no ofrece una "protección adecuada" para los datos personales como exige el RGPD (GDPR).

Así que tenemos una situación en la que las empresas europeas están utilizando nubes de EE. UU. para almacenar datos sensibles, fingiendo que se quedan en Europa para satisfacer el cumplimiento interno, mientras que el tribunal más alto de Europa ha dictaminado que el marco legal de EE. UU. hace que esos datos sean inseguros. Es una disonancia cognitiva de proporciones épicas. Es una bomba de tiempo de cumplimiento esperando explotar.

La puerta trasera de "Romper el cristal"

Los proveedores de nube no ignoran esto. Saben que es un obstáculo para las ventas. Así que contraatacan con ofertas de "Nube Soberana". Reclaman "Soberanía Operativa". Dicen: "Solo el personal de la UE tiene acceso a sus datos". Establecen estructuras legales que suenan impresionantes, fideicomisarios independientes y empresas fantasma.

Pero si indaga en los Acuerdos de Nivel de Servicio (SLA) y la letra pequeña de la documentación técnica, casi siempre encontrará una disposición de "Romper el cristal" (Break Glass). Esta es una cláusula que permite al equipo de soporte global (EE. UU.) acceder a la infraestructura local en caso de un "incidente crítico", "emergencia técnica" o "amenaza de seguridad" que el equipo local no pueda manejar.

Desde una perspectiva de ingeniería de seguridad, un mecanismo de "Romper el cristal" es una puerta trasera. Es una ruta de acceso privilegiada que elude los controles estándar. ¿Y quién decide cuándo romper el cristal? El proveedor. ¿Quién define qué constituye un "incidente crítico"? El proveedor.

En una crisis geopolítica (una guerra comercial, tal vez, o una disputa de sanciones), ese mecanismo de "Romper el cristal" se convierte en una vulnerabilidad estratégica. Un gobierno extranjero podría teóricamente obligar al proveedor a "romper el cristal" no para reparar un servidor, sino para exfiltrar datos, hacer cumplir sanciones o interrumpir operaciones.

Incluso sin malicia, el modelo de soporte "Follow the Sun" plantea un riesgo. Cuando ocurre un problema complejo de corrupción de base de datos a las 3 a. m. en Frankfurt, el equipo de soporte local podría no tener la experiencia profunda para solucionarlo. Lo escalan al equipo de ingeniería central. ¿Dónde se encuentra ese equipo? Generalmente en Seattle o Silicon Valley. Para solucionar el problema, el ingeniero de Seattle necesita registros, volcados de memoria y tal vez acceso al volumen de datos. En el momento en que se otorga ese acceso, se viola la soberanía.

Verdadera soberanía: la definición de Dweve

En Dweve, creemos que el término "soberanía" se ha diluido hasta el punto de perder su significado. Necesitamos recuperarlo. Necesitamos una definición de soberanía rigurosa y basada en la ingeniería, no una legalista.

Para nosotros, un sistema solo es soberano si cumple tres criterios estrictos. Estos no son elementos "deseables"; son pruebas binarias de pasa/no pasa.

1. Autonomía técnica (El estado desconectado)

El sistema debe ser capaz de funcionar plenamente sin ninguna conexión a un plano de control central y extranjero. Esto significa que el "cerebro" del sistema (el planificador, el proveedor de identidad, el gestor de claves) debe ser local al despliegue.

La mayoría de las pilas de nube pública fallan esta prueba inmediatamente. Requieren conectividad constante con el Plano de Control global para facturación, identidad y gestión. Dweve está diseñado de manera diferente. Nuestra arquitectura prioriza el borde (edge-first) y está descentralizada. Cada clúster de Dweve es un universo autónomo. Tiene su propio mecanismo de consenso local, su propio almacén de identidad local y su propia lógica de control local.

Puede ejecutar un clúster de Dweve en un submarino, un búnker seguro o una planta de fábrica desconectada de internet, y funcionará indefinidamente. Esencialmente, tratará la falta de internet como una partición de red y seguirá trabajando. Puede aprovisionar nuevos recursos, actualizar modelos y gestionar usuarios localmente. Cuando se restablece la conectividad, puede sincronizarse (si así lo desea), pero nunca lo necesita.

2. Inmunidad legal

La entidad que opera la infraestructura debe ser inmune a las solicitudes de datos extraterritoriales. Esto significa que no puede ser una filial de una empresa sujeta a la CLOUD Act o FISA 702. Debe ser una entidad europea, sujeta únicamente a la ley europea.

Por eso Dweve está domiciliada en la UE, sin empresa matriz en EE. UU. y sin inversores estadounidenses que posean participaciones de control. No somos antiestadounidenses; nos encanta la innovación estadounidense. Somos pro-soberanía. No podemos ser obligados por un tribunal extranjero a traicionar a nuestros clientes porque simplemente no estamos sujetos a su jurisdicción.

3. Control criptográfico (HYOK > BYOK)

El cifrado es tan bueno como la gestión de claves. El estándar de la industria "Traiga su propia clave" (BYOK) es un término engañoso. En un modelo BYOK, usted genera una clave y la carga en el Servicio de Gestión de Claves (KMS) del proveedor de la nube. El software del proveedor utiliza entonces esa clave para cifrar y descifrar sus datos.

Esto significa que el proveedor tiene la clave. Puede estar en memoria solo por un milisegundo, pero está ahí. Si el software del proveedor se ve comprometido, o si se ven obligados a modificar su software para capturar la clave, sus datos quedan expuestos. Está confiando en que el proveedor no mire.

La verdadera soberanía requiere "Mantenga su propia clave" (HYOK). En este modelo, las claves nunca salen de su Módulo de Seguridad de Hardware (HSM) que permanece en sus instalaciones. El proveedor de la nube nunca ve la clave. Las operaciones criptográficas ocurren dentro de un Entorno de Ejecución Confiable (TEE) o localmente.

La capa de almacenamiento de Dweve se basa en este principio. No guardamos sus claves. No queremos sus claves. Si recibimos una orden judicial, queremos poder decir honestamente: "No podemos ayudarles. Los datos son matemáticamente inaccesibles para nosotros".

El imperativo estratégico

Esta discusión a menudo se enmarca como una cuestión de cumplimiento: cómo evitar las multas del RGPD. Pero esa es una visión miope. Se trata de la supervivencia estratégica en el siglo XXI.

Estamos entrando en una era de "mercantilismo tecnológico". Las naciones están utilizando las pilas tecnológicas como palancas de poder geopolítico. Las cadenas de suministro se están convirtiendo en armas. Los semiconductores, los modelos de IA y la infraestructura en la nube son el nuevo petróleo, acero y rutas de navegación.

Europa aprendió una dolorosa lección sobre la dependencia con la energía después de la invasión rusa de Ucrania. Nos dimos cuenta demasiado tarde de que construir toda nuestra economía industrial sobre gas barato de un único proveedor potencialmente hostil fue un error estratégico catastrófico. Gastamos miles de millones y sufrimos un choque económico masivo para desacoplarnos.

Ahora estamos en peligro de repetir exactamente el mismo error con nuestra infraestructura digital. Estamos construyendo nuestra economía digital (nuestra IA, nuestros lagos de datos, nuestras ciudades inteligentes) sobre la infraestructura propietaria de una única potencia extranjera. Confiar en un Plano de Control extranjero para su infraestructura crítica es negligencia estratégica.

La "Zona Local" es una ilusión cómoda. Nos permite fingir que hemos resuelto el problema sin hacer el duro trabajo de construir una verdadera independencia. Pero las ilusiones, por muy reconfortantes que sean, acaban rompiéndose.

Es hora de construir una infraestructura que sea real. Una infraestructura que se sostenga por sí misma. Una infraestructura que sea verdadera, técnica y legalmente soberana. Esa es la misión de Dweve.

Dweve construye infraestructura de IA verdaderamente soberana para empresas europeas. Nuestra arquitectura pasa las tres pruebas de soberanía: autonomía técnica (operación desconectada), inmunidad legal (jurisdicción exclusiva de la UE) y control criptográfico (gestión de claves HYOK). Sin puertas traseras de "Romper el cristal". Sin planos de control extranjeros. Sin ilusiones. Soberanía real, diseñada desde cero.