Requisitos de soberanía de datos en la UE: lo que exige el GDPR frente a lo que realmente implica la soberanía

Si le preguntas a la mayoría de los equipos de cumplimiento qué exige la soberanía de los datos en la UE, te señalarán el GDPR. Si le preguntas a su asesor legal qué exige Schrems II, te hablarán de los Análisis de Impacto de Transferencia y las Cláusulas Contractuales Estándar. Si le preguntas a su CISO qué sucede cuando una citación del gobierno estadounidense llega a la sede de su proveedor de nube, la sala se queda en silencio.

La confusión es comprensible. «Residencia de datos«, «localización de datos» y «soberanía de datos» suelen usarse como sinónimos en las conversaciones empresariales, pero son conceptos distintos tanto legal como arquitectónicamente. Una organización puede cumplir en papel todas las obligaciones de residencia de datos del GDPR y, aun así, seguir expuesta estructuralmente al acceso de gobiernos extranjeros. Entender dónde terminan los requisitos del GDPR y dónde empieza la verdadera soberanía de los datos no es una cuestión académica. Es la brecha de cumplimiento que las Autoridades de Protección de Datos están haciendo cumplir activamente.

Resumen Ejecutivo

Idea principal: El GDPR establece requisitos de residencia y transferencia de datos para la información personal de la UE, pero cumplir con el GDPR y lograr soberanía de datos no es lo mismo. La residencia de datos indica dónde deben almacenarse los datos. La soberanía de datos determina quién controla el acceso y bajo qué jurisdicción legal. Para las organizaciones que usan infraestructura en la nube con sede en EE. UU., la residencia de datos conforme al GDPR en un centro de datos en Frankfurt proporciona cumplimiento geográfico, pero deja los datos legalmente accesibles a exigencias del gobierno estadounidense bajo el CLOUD Act, una exposición estructural que las Cláusulas Contractuales Estándar no pueden resolver. El cumplimiento real de la soberanía de los datos exige controles arquitectónicos: claves de cifrado controladas por el cliente, implementación europea de tenencia única y geoperimetraje aplicado por políticas, que hagan técnicamente imposible el acceso no autorizado, no solo prohibido contractualmente.

Por qué te debe importar: Las autoridades de protección de datos de Austria, Francia e Italia ya han dictaminado que ciertos acuerdos en la nube con EE. UU. violan el GDPR. Las multas del GDPR pueden alcanzar el 4% de los ingresos globales anuales. La Directiva NIS 2 añade responsabilidad penal para la gestión. El Informe de Riesgos de Cumplimiento y Seguridad de Datos de Kiteworks 2026 reveló que el 33% de las organizaciones experimentaron un incidente relacionado con la soberanía en los últimos 12 meses, a pesar de que el 44% se describen como bien informadas. Las organizaciones que confunden residencia con soberanía no cumplen: están expuestas.

Puntos clave

1. Residencia, localización y soberanía de datos son conceptos legales distintos. La residencia regula dónde se almacenan físicamente los datos. La localización exige que permanezcan en el país de recogida. La soberanía regula quién controla el acceso y bajo qué jurisdicción legal. Cumplir uno no significa cumplir los otros automáticamente.
2. El GDPR establece requisitos de residencia, pero no de soberanía plena. Los artículos 44–49 restringen las transferencias transfronterizas, pero el cumplimiento no impide que una exigencia del CLOUD Act de EE. UU. alcance datos almacenados por un proveedor con sede en EE. UU. en un centro de datos de la UE. La ubicación no equivale a jurisdicción.
3. Schrems II redefinió la residencia como insuficiente. Al exigir Análisis de Impacto de Transferencia e identificar el cifrado controlado por el cliente como la medida suplementaria requerida, el TJUE estableció que la ubicación geográfica no puede sustituir el control jurisdiccional.
4. La soberanía arquitectónica resuelve lo que los contratos no pueden. Las Cláusulas Contractuales Estándar vinculan a las partes, pero no pueden anular una exigencia legal del gobierno estadounidense. Las claves de cifrado controladas por el cliente y almacenadas fuera de la infraestructura del proveedor hacen que este sea técnicamente incapaz de entregar datos legibles, sin importar la exigencia legal que reciba.
5. NIS 2 y DORA amplían las obligaciones de soberanía más allá del GDPR. La Directiva NIS 2 y DORA imponen evaluaciones de soberanía en la cadena de suministro, notificación de incidentes y responsabilidad de la gestión, que se suman al GDPR. Las organizaciones en sectores regulados deben cumplir los tres marcos a la vez.

Definición de términos: qué significan realmente residencia, localización y soberanía

Residencia de datos se refiere a la ubicación geográfica física donde se almacenan y procesan los datos. Un requisito de residencia de datos significa: estos datos deben almacenarse en servidores dentro de esta jurisdicción. El GDPR crea requisitos de residencia de facto mediante sus restricciones de transferencia: al limitar a dónde puede fluir la información personal, obliga a las organizaciones a mantener los datos dentro de la UE. Pero la residencia es una cuestión de ubicación, no de control. Los datos pueden estar físicamente en Alemania y, al mismo tiempo, ser legalmente accesibles para un gobierno extranjero.

Localización de datos es una versión más estricta de la residencia: exige que los datos no solo se almacenen localmente, sino que permanezcan dentro del país donde se recogieron. Algunas normativas nacionales y reglas sectoriales dentro de la UE imponen requisitos de localización adicionales al GDPR, especialmente para datos sanitarios, transacciones financieras y registros del sector público.

Soberanía de datos es el concepto más amplio. Se refiere al principio de que los datos están gobernados por las leyes de la jurisdicción donde residen, y que la organización controladora tiene un control legal y técnico real sobre quién puede acceder a ellos. No basta con elegir un centro de datos en la UE para lograr soberanía. Un proveedor estadounidense que opera un centro de datos en Frankfurt no es una opción de infraestructura soberana europea; es una dirección europea con exposición legal estadounidense.

La consecuencia práctica: una organización puede cumplir todos los requisitos de residencia del GDPR —centros de datos en la UE, mecanismos de transferencia documentados, subprocesadores conformes— y aun así no lograr soberanía de datos si el proveedor tiene sede en EE. UU. y posee las claves de cifrado.

Qué exige realmente el GDPR para residencia y transferencias de datos

El GDPR no contiene un requisito general de que los datos personales de la UE deban almacenarse dentro de la UE. El Capítulo V (artículos 44–49) restringe cuándo se pueden transferir datos personales de la UE fuera de la UE/EEE, mediante decisiones de adecuación, Cláusulas Contractuales Estándar, Normas Corporativas Vinculantes u otros mecanismos aprobados. En la práctica, el Capítulo V genera una fuerte presión de residencia: si no existe un mecanismo de transferencia válido para un destino concreto, los datos deben permanecer en la UE.

Para la mayoría de las organizaciones que usan proveedores de nube estadounidenses, las SCC son el mecanismo principal, complementado desde Schrems II por Análisis de Impacto de Transferencia que evalúan si la legislación estadounidense socava la eficacia de esas SCC. El artículo 32 del GDPR exige «medidas técnicas y organizativas apropiadas», y tras Schrems II, las autoridades de protección de datos interpretan que esto requiere controles técnicos demostrables proporcionales al riesgo identificado. Las Recomendaciones 01/2020 del EDPB señalan el cifrado controlado por el cliente con claves almacenadas exclusivamente en el EEE como la medida técnica capaz de afrontar el acceso forzado por el CLOUD Act. Aquí es donde convergen los requisitos de residencia del GDPR y la arquitectura de soberanía: el cumplimiento genuino del artículo 32 para transferencias con proveedores estadounidenses exige la misma arquitectura de control de claves por parte del cliente que demanda la soberanía.

La brecha del CLOUD Act: por qué la residencia no es soberanía

El CLOUD Act de EE. UU. exige a las empresas estadounidenses entregar los datos que controlan tras recibir una solicitud válida del gobierno estadounidense, sin importar dónde estén almacenados físicamente esos datos. Un proveedor estadounidense que opera un centro de datos en Frankfurt no es una organización europea: es una organización estadounidense con presencia inmobiliaria en Europa. La solicitud no requiere orden judicial europea, no notifica al responsable ni al titular de los datos, y el proveedor debe cumplir independientemente de su contrato con el cliente europeo. Las Cláusulas Contractuales Estándar documentan lo que el proveedor pretende hacer; no pueden cambiar lo que la ley estadounidense le obliga a hacer.

El Marco de Privacidad de Datos UE-EE. UU. (2023) proporciona un mecanismo de transferencia, pero no deroga el CLOUD Act. Ajusta la supervisión sobre la vigilancia de inteligencia estadounidense, pero no impide que las solicitudes del CLOUD Act alcancen los datos controlados por el proveedor. Los defensores de la privacidad ya están presentando impugnaciones legales. Construir una infraestructura de cumplimiento permanente basándose en el DPF implica aceptar una incertidumbre legal continua.

El único control que cierra esta brecha es arquitectónico: cifrado gestionado por el cliente con claves almacenadas completamente fuera de la infraestructura del proveedor. Cuando el proveedor no puede acceder a las claves, una solicitud bajo el CLOUD Act solo obtiene texto cifrado: legalmente obtenido, pero ilegible. El proveedor se vuelve técnicamente incapaz de cumplir una exigencia de descifrado, sin importar la obligación legal. La arquitectura resuelve lo que los contratos no pueden evitar. Esto es exactamente lo que el EDPB define como «medida técnica suplementaria» suficiente para afrontar la exposición al CLOUD Act, y es el estándar que las autoridades europeas están aplicando en sus acciones de cumplimiento.

El marco más amplio de soberanía en la UE: NIS 2 y DORA

El GDPR es la base, pero para la mayoría de las organizaciones que operan en la UE, no es el único marco de soberanía bajo el que trabajan. Dos normativas adicionales de la UE imponen obligaciones de soberanía que se suman al GDPR, y en algunos aspectos van más allá.

La Directiva NIS 2, transpuesta por los Estados miembros de la UE en octubre de 2024, abarca sectores esenciales —energía, transporte, banca, sanidad, infraestructura digital— y sectores importantes como la manufactura y los servicios profesionales. Su dimensión de soberanía está en el mandato de seguridad de la cadena de suministro del artículo 21: las entidades cubiertas deben evaluar los riesgos de ciberseguridad en sus cadenas de suministro TIC, incluida la postura de soberanía de los proveedores de nube. Un proveedor con sede en EE. UU. sujeto al CLOUD Act es un riesgo de soberanía en la cadena de suministro que NIS 2 exige documentar y abordar. Los incumplimientos de NIS 2 pueden acarrear sanciones de hasta 10 millones de euros o el 2% de la facturación global anual, con responsabilidad personal directa para la alta dirección, una responsabilidad que el GDPR no impone a individuos.

Los requisitos de cumplimiento de DORA, exigibles desde enero de 2025 para entidades de servicios financieros de la UE, van más allá: el artículo 30 exige explícitamente que los contratos con proveedores TIC aborden la soberanía de los datos, la gestión de claves de cifrado y las estrategias de salida. Para las organizaciones de servicios financieros, el GDPR, DORA y las leyes nacionales de secreto bancario crean una triple obligación de soberanía que los programas de cumplimiento centrados solo en el GDPR no pueden satisfacer.

Qué exige en la práctica el cumplimiento genuino de la soberanía de datos en la UE

Claves de cifrado controladas por el cliente. El EDPB señala esto como la principal medida técnica suplementaria para transferencias con proveedores estadounidenses. Las claves en el propio HSM del cliente, fuera de la infraestructura del proveedor, hacen que una divulgación forzada por el CLOUD Act solo entregue texto cifrado. Este único control arquitectónico satisface el artículo 32 del GDPR, los requisitos de gestión de claves del artículo 30 de DORA y la evaluación de soberanía en la cadena de suministro de NIS 2, todo a la vez y en los tres marcos.

Implementación europea de tenencia única. Infraestructura dedicada en un centro de datos específico de la UE, bajo control operativo del cliente, proporciona residencia de datos documentada que cumple el Capítulo V del GDPR y el estándar probatorio que aplican las autoridades en las revisiones de Análisis de Impacto de Transferencia. La jurisdicción sigue al control, no a las coordenadas.

Geoperimetraje aplicado por políticas. Los controles de geoperimetraje que impiden técnicamente que los datos salgan de regiones geográficas designadas —aplicados a nivel de infraestructura, no solo en políticas— es lo que el EDPB clasifica como «medida técnica suplementaria» y no solo «medida contractual suplementaria». Solo la primera se considera suficiente para transferencias expuestas al CLOUD Act.

Registros de auditoría inmutables. El artículo 30 del GDPR, la notificación de incidentes de NIS 2 y la documentación de riesgos TIC de DORA exigen lo mismo: registros a prueba de manipulaciones de cada acceso, transferencia y actividad de procesamiento de datos, con el alcance geográfico documentado. Las evaluaciones de gestión de riesgos de terceros deben verificar que los proveedores puedan entregar esta evidencia bajo demanda, no solo afirmar que la mantienen.

Cómo Kiteworks ofrece soberanía arquitectónica para el cumplimiento en la UE

La diferencia entre los requisitos de residencia de datos del GDPR y la verdadera soberanía de datos en la UE es la diferencia entre dónde están tus datos y quién controla realmente el acceso. Una organización puede almacenar datos en Frankfurt, firmar Cláusulas Contractuales Estándar y mantener un Análisis de Impacto de Transferencia conforme, y aun así estar a una citación del CLOUD Act de entregar los datos de sus clientes europeos a investigadores estadounidenses sin notificación. Esa es la realidad estructural de usar infraestructura controlada por EE. UU. para datos europeos, y es lo que las autoridades europeas están haciendo cumplir.

La verdadera soberanía de datos en la UE requiere una arquitectura que resuelva lo que los contratos no pueden: claves de cifrado controladas por el cliente que hagan que los proveedores sean técnicamente incapaces de entregar datos legibles, implementación europea de tenencia única que sitúe los datos bajo jurisdicción europea y geoperimetraje aplicado por políticas que convierta la residencia en una realidad técnica y no solo en una declaración contractual. Kiteworks ofrece esa arquitectura. Tus datos, tu jurisdicción, tu control.

Kiteworks fue diseñado bajo un principio organizador: tus datos deben permanecer bajo tu control, en tu jurisdicción, cifrados con tus claves, inaccesibles para cualquiera que no hayas autorizado, incluido el propio Kiteworks. Eso es lo que significa la soberanía arquitectónica en la práctica.

La Red de Datos Privados de Kiteworks consolida todos los canales de comunicación de contenido confidencial —correo electrónico, uso compartido de archivos, MFT, formularios web y APIs— en una sola plataforma gobernada por controles de soberanía unificados. El cifrado gestionado por el cliente (BYOK/BYOE) con cifrado validado FIPS 140-3 Nivel 1 y AES-256 en reposo garantiza que Kiteworks no pueda descifrar los datos del cliente, no por promesa sino por arquitectura. Nunca tenemos las claves. Cuando llega una solicitud gubernamental a Kiteworks, solo se entrega texto cifrado. Esa es la medida suplementaria exigida por el EDPB, implementada a nivel de infraestructura.

Las opciones de implementación europea —en las instalaciones, nube privada con proveedor europeo o infraestructura de Kiteworks alojada en la UE— hacen cumplir la residencia de datos de forma técnica. El geoperimetraje aplicado por políticas bloquea el contenido dentro de las regiones designadas. Los controles de seguridad de confianza cero regulan el acceso y cada interacción queda registrada en un registro de auditoría inmutable y unificado visible a través del Panel del CISO. Los informes de cumplimiento preconfigurados para GDPR, NIS 2, DORA e ISO 27001 proporcionan evidencia para Análisis de Impacto de Transferencia, registros del artículo 30 y documentación de custodia de claves: soberanía que puedes demostrar ante un regulador, no solo afirmar ante un cliente.

Para ver cómo Kiteworks ayuda a cumplir la soberanía de datos a organizaciones que operan en la UE, solicita una demo personalizada hoy.

Recursos adicionales

• Artículo del Blog
  Soberanía de datos: ¿mejor práctica o requisito normativo?
• eBook 
  Soberanía de datos y GDPR
• Artículo del Blog 
  Evita estos errores comunes sobre soberanía de datos
• Artículo del Blog 
  Mejores prácticas de soberanía de datos
• Artículo del Blog 
  Soberanía de datos y GDPR [Entendiendo la seguridad de los datos]