¿Puedo usar un proveedor de nube con sede en EE. UU. si mis datos deben permanecer dentro de la UE?
La respuesta corta es: depende. Un proveedor de nube con sede en EE. UU. y centros de datos en la UE no queda automáticamente descalificado para alojar datos de residentes europeos, pero el uso conforme requiere mucho más que elegir una región de servidor en Frankfurt o Dublín. La mayoría de las organizaciones que creen haber resuelto esta cuestión mediante la selección geográfica, en realidad no lo han hecho. Han cambiado la dirección de sus datos sin modificar su exposición legal.
Esta publicación responde a tres preguntas: si se pueden usar proveedores estadounidenses, qué categorías de datos tienen las restricciones más estrictas de soberanía y qué medidas de protección se requieren para que cualquier acuerdo sea realmente conforme.
Resumen Ejecutivo
Idea principal: Los proveedores de nube estadounidenses solo pueden alojar datos de residentes de la UE legalmente cuando existen medidas técnicas y legales específicas, que van más allá de la selección de servidores en la UE para abordar el problema estructural de que la legislación estadounidense se aplica a las empresas estadounidenses sin importar dónde estén sus servidores. El CLOUD Act de EE. UU. y la Sección 702 de FISA generan una exposición al acceso gubernamental que ni el Marco de Privacidad de Datos UE-EE. UU. elimina ni las Cláusulas Contractuales Tipo pueden resolver por sí solas. La solución necesaria es arquitectónica: cifrado controlado por el cliente con llaves fuera de la infraestructura del proveedor, de modo que el proveedor sea técnicamente incapaz de entregar datos legibles de la UE, incluso bajo obligación legal.
Por qué te debe importar: Las autoridades de protección de datos de la UE han emitido decisiones de cumplimiento que dictaminan que ciertos acuerdos con proveedores de nube estadounidenses violan el GDPR, sin importar la ubicación de los servidores. La Directiva NIS 2, DORA y leyes nacionales sectoriales imponen obligaciones adicionales de soberanía con sanciones que pueden alcanzar el 4% de los ingresos globales. Las organizaciones que no han revisado sus acuerdos con proveedores estadounidenses bajo los estándares posteriores a Schrems II están expuestas a acciones de cumplimiento.
Puntos Clave
- La ubicación del servidor en la UE no equivale a jurisdicción de la UE. El centro de datos de Frankfurt de un proveedor estadounidense sigue sujeto a exigencias legales de EE. UU. por la estructura corporativa del proveedor. La geografía cambia dónde se almacenan los datos, pero no qué gobierno puede exigir acceso a ellos.
- El Marco de Privacidad de Datos UE-EE. UU. no deroga el CLOUD Act. El DPF proporciona un mecanismo de transferencia para datos personales bajo el GDPR, pero no elimina las obligaciones de las leyes de vigilancia estadounidenses para los proveedores de EE. UU. Las exigencias del CLOUD Act siguen siendo válidas, participen o no en el DPF.
- Algunas categorías de datos tienen restricciones que prácticamente prohíben el uso de proveedores estadounidenses sin controles de soberanía arquitectónicos. Los datos de salud bajo leyes nacionales, los datos financieros bajo DORA, los datos gubernamentales clasificados y ciertas categorías de datos personales identificadas como de alto riesgo en el Artículo 9 del GDPR, tienen restricciones que los acuerdos genéricos de SCC con proveedores estadounidenses no pueden abordar adecuadamente.
- El uso conforme de un proveedor estadounidense requiere medidas técnicas específicas, no solo documentación legal. Tras Schrems II, el EDPB ha identificado el cifrado controlado por el cliente con llaves fuera de la infraestructura del proveedor como la medida técnica suplementaria requerida. Los compromisos contractuales no son suficientes cuando la ley estadounidense exige el cumplimiento del proveedor, sin importar los términos del contrato.
- La alternativa arquitectónica es una implementación europea de tenencia única con cifrado gestionado por el cliente. Esto resuelve el problema del CLOUD Act de forma estructural: el proveedor no puede entregar datos legibles porque nunca tuvo las llaves, haciendo posible cumplir simultáneamente con las obligaciones legales de EE. UU. y los requisitos de protección de datos de la UE desde el punto de vista técnico.
Lista de verificación integral de cumplimiento GDPR
Leer ahora
El problema central: la jurisdicción sigue a la empresa, no al servidor
La suposición detrás de la mayoría de los acuerdos de «centro de datos de la UE» es que la ubicación física determina la jurisdicción legal. No es así. El CLOUD Act de EE. UU. (2018) exige a las empresas estadounidenses entregar los datos que controlan ante solicitudes gubernamentales válidas, sin importar dónde estén almacenados. Una solicitud dirigida a la sede de un proveedor estadounidense obliga a entregar datos de sus servidores en la UE. La dirección del servidor es irrelevante; la nacionalidad corporativa es lo que activa el alcance legal de EE. UU. La Sección 702 de FISA amplía esto a los datos de comunicaciones bajo autoridades de seguridad nacional. Ninguno de estos instrumentos requiere supervisión judicial compatible con la UE ni notificación al cliente.
No se trata de un riesgo teórico. Las autoridades de protección de datos de Austria, Francia e Italia han emitido decisiones de cumplimiento concluyendo que ciertos acuerdos con proveedores estadounidenses violan el GDPR, precisamente porque la exposición al CLOUD Act no fue abordada adecuadamente por las medidas de protección aplicadas.
Lo que el Marco de Privacidad de Datos UE-EE. UU. resuelve — y lo que no
Muchas organizaciones asumen que el Marco de Privacidad de Datos UE-EE. UU., adoptado en 2023, resolvió el problema de Schrems II. No es así. El DPF proporciona un mecanismo de adecuación de transferencia bajo el Artículo 45 del GDPR, es decir, una base legal para transferir datos personales de la UE a empresas estadounidenses certificadas. Lo que no hace es derogar el CLOUD Act de EE. UU. Los proveedores estadounidenses certificados bajo el DPF siguen obligados legalmente a cumplir con solicitudes válidas bajo el CLOUD Act. El DPF responde si existe una base legal para la transferencia; no responde si una solicitud del gobierno estadounidense podría obligar al proveedor a entregar datos de la UE.
El DPF también enfrenta impugnaciones legales activas por parte de NOYB, la organización que anuló el Privacy Shield en 2020. Las organizaciones cuya postura de cumplimiento depende únicamente de la certificación DPF asumen el mismo riesgo de invalidación que eliminó los acuerdos de Privacy Shield. El cifrado controlado por el cliente brinda protección que sobrevive a cualquier mecanismo de transferencia, ya que los datos nunca son accesibles al proveedor, sin importar el marco legal que rija la transferencia.
Qué tipos de datos enfrentan las restricciones de soberanía más estrictas
No todos los datos implican el mismo riesgo de soberanía. Cinco categorías activan los requisitos más restrictivos bajo los marcos de la UE y nacionales.
Datos personales de categoría especial (Artículo 9 del GDPR). Los datos de salud, biométricos, genéticos y otras categorías sensibles requieren una base legal específica más allá de las bases estándar del GDPR, y las transferencias deben cumplir tanto el Capítulo V como el Artículo 9 simultáneamente, un doble requisito que los acuerdos genéricos de SCC suelen no resolver.
Datos de salud y de pacientes. Las leyes nacionales de datos de salud imponen restricciones adicionales al GDPR. Francia exige que los datos de salud se procesen en infraestructuras bajo soberanía francesa. Alemania impone protecciones equivalentes para los datos de pacientes. Varios marcos nacionales prohíben en la práctica a proveedores estadounidenses para datos de salud sin controles de soberanía a nivel de infraestructura, sin importar los acuerdos SCC.
Datos de servicios financieros. DORA (operativo desde enero de 2025) exige que las entidades financieras y sus proveedores TIC incluyan cláusulas contractuales sobre localización de datos, gestión de llaves y estrategias de salida. Las directrices de externalización de la EBA requieren evaluaciones documentadas de soberanía. Las entidades financieras de la UE que usan proveedores estadounidenses sin una gestión de llaves adecuada actualmente no cumplen con la normativa.
Datos gubernamentales y relacionados con defensa. Los datos clasificados, los datos de contratistas de defensa y los datos sujetos a políticas nacionales de nube del sector público, con frecuencia no pueden procesarse legalmente en infraestructuras bajo control estadounidense bajo ningún mecanismo de transferencia. La mayoría de los estados miembros de la UE tienen restricciones explícitas sobre el procesamiento de datos gubernamentales a través de proveedores no europeos.
Datos operativos de infraestructuras críticas. El Artículo 21 de NIS 2 exige que los operadores de servicios esenciales —energía, transporte, salud, agua, infraestructura financiera y digital— evalúen la postura de soberanía de los proveedores de nube como parte de las obligaciones obligatorias de seguridad en la cadena de suministro. El umbral aceptable de exposición al CLOUD Act en estos contextos es mucho más bajo que para datos comerciales generales.
Medidas técnicas y legales requeridas
Para las organizaciones que determinan que un acuerdo con un proveedor estadounidense puede ser conforme, se requieren cuatro medidas de protección.
Análisis de impacto de transferencia con evaluación honesta del CLOUD Act. Un TIA cuya conclusión se base en controles técnicos, no compromisos contractuales. Un TIA que reconoce el riesgo del CLOUD Act pero confía en procedimientos de notificación como mitigación no cumple con el estándar posterior a Schrems II: la evaluación debe concluir que una solicitud válida no resultaría en la entrega de datos legibles de la UE, y esa conclusión debe estar fundamentada arquitectónicamente.
Cifrado controlado por el cliente con llaves fuera de la infraestructura del proveedor. Las Recomendaciones 01/2020 del EDPB identifican esto como la medida técnica suplementaria requerida: llaves generadas por el cliente y almacenadas en HSM bajo el control exclusivo del cliente de la UE, nunca en poder del proveedor estadounidense. Sin esto, cualquier TIA que reconozca la exposición al CLOUD Act no puede concluir válidamente que la transferencia está suficientemente protegida.
Aplicación de residencia de datos a nivel de infraestructura. Las cláusulas contractuales de localización de datos son medidas contractuales suplementarias. El geofencing aplicado por políticas, que impide que los datos salgan de regiones designadas de la UE sin importar la configuración, es una medida técnica. Tras Schrems II, la distinción es clave para la evaluación de cumplimiento por parte de las autoridades.
Registros de auditoría inmutables y documentación continua de rendición de cuentas. El principio de responsabilidad del GDPR exige demostrar el cumplimiento de forma continua. Los registros de auditoría inmutables, los registros de gestión de llaves y los TIA revisados regularmente son el estándar mínimo. Para DORA y NIS 2, esta documentación debe estar disponible para los reguladores bajo solicitud.
Cómo Kiteworks garantiza la soberanía de datos conforme en la UE
La Red de Datos Privados de Kiteworks resuelve el problema estructural de raíz. La implementación de tenencia única en la ubicación elegida por el cliente de la UE —en las instalaciones, nube privada europea o infraestructura de Kiteworks alojada en la UE— sitúa los datos bajo jurisdicción europea y no bajo control corporativo estadounidense. El cifrado gestionado por el cliente (BYOK/BYOE) con cifrado validado FIPS 140-3 Nivel 1 significa que Kiteworks nunca posee las llaves del cliente: una solicitud bajo el CLOUD Act solo obtiene datos cifrados. La conclusión del TIA está fundamentada arquitectónicamente: Kiteworks es técnicamente incapaz de entregar datos legibles, no solo comprometido contractualmente a protegerlos. El geofencing aplicado por políticas implementa la residencia de datos a nivel de infraestructura en todos los canales: correo electrónico, uso compartido de archivos, MFT, formularios web y APIs. El panel CISO proporciona registros de auditoría inmutables de cada movimiento de datos. Los informes de cumplimiento preconfigurados para GDPR, NIS 2, DORA e ISO 27001 facilitan la rendición de cuentas continua y la respuesta a consultas regulatorias en las categorías de datos con los requisitos de soberanía más estrictos.
Para hablar sobre los requisitos específicos de soberanía de datos de tu organización y cómo Kiteworks los resuelve, agenda una demo personalizada hoy.
Preguntas frecuentes
No. Seleccionar una región de centro de datos en la UE cambia dónde se almacenan físicamente los datos, pero no qué gobierno puede exigir legalmente acceso a ellos. El CLOUD Act de EE. UU. se aplica a proveedores con sede en EE. UU., sin importar la ubicación del servidor: una solicitud válida obliga a entregar datos de servidores en la UE a través de la estructura corporativa del proveedor. Cumplir los requisitos de soberanía de datos de la UE en acuerdos con proveedores estadounidenses requiere cifrado controlado por el cliente con llaves fuera de la infraestructura del proveedor, no solo elegir una región en la UE.
No. El DPF proporciona un mecanismo de adecuación de transferencia bajo el Artículo 45 del GDPR, es decir, una base legal para transferir datos personales de la UE a empresas estadounidenses certificadas. No deroga ni limita el CLOUD Act de EE. UU. Los proveedores estadounidenses certificados bajo el DPF siguen obligados legalmente a cumplir con solicitudes válidas bajo el CLOUD Act. El DPF responde a la cuestión del mecanismo de transferencia, pero no a si una solicitud del gobierno estadounidense podría obligar al proveedor a entregar datos de la UE. Además, el DPF enfrenta impugnaciones legales activas y podría ser invalidado, como ocurrió con Privacy Shield en 2020, por lo que los controles de soberanía arquitectónicos son una protección más duradera que depender solo del DPF.
Cinco categorías tienen los requisitos más restrictivos: datos personales de categoría especial según el Artículo 9 del GDPR; datos de pacientes y de salud bajo marcos nacionales (Francia, Alemania y otros); datos de servicios financieros bajo DORA y directrices de externalización de la EBA; datos gubernamentales y relacionados con defensa bajo políticas nacionales de nube del sector público; y datos operativos de infraestructuras críticas bajo los requisitos de seguridad de la cadena de suministro de NIS 2. Para datos gubernamentales y de salud, el uso de proveedores estadounidenses puede estar prácticamente prohibido sin controles de soberanía a nivel de infraestructura, sin importar el mecanismo de transferencia o acuerdo contractual.
Tras Schrems II, las medidas mínimas requeridas son: un Análisis de Impacto de Transferencia que evalúe honestamente la exposición al CLOUD Act y FISA 702 con una conclusión basada en controles técnicos; cifrado controlado por el cliente con llaves gestionadas exclusivamente fuera de la infraestructura del proveedor (la medida técnica suplementaria exigida por el EDPB); aplicación de residencia de datos a nivel de infraestructura en vez de compromisos contractuales de localización; y registros de auditoría inmutables que respalden las obligaciones continuas de responsabilidad bajo el GDPR. Las organizaciones que solo cuentan con medidas contractuales —cláusulas contractuales tipo, acuerdos de procesamiento de datos, compromisos de notificación— sin la capa arquitectónica, no cumplen con el estándar posterior a Schrems II, sin importar la documentación.
Para ciertas categorías de datos y perfiles organizativos, sí. Los datos gubernamentales sujetos a políticas nacionales de soberanía, los datos de salud bajo marcos nacionales estrictos y los datos clasificados bajo legislación de seguridad pueden requerir en la práctica infraestructura controlada por Europa, sin importar las medidas técnicas que ofrezca un proveedor estadounidense. Para estas organizaciones, la implementación de tenencia única en infraestructura europea —a través de un proveedor europeo, en las instalaciones o mediante una plataforma como Kiteworks desplegada en infraestructura controlada por la UE— es la solución adecuada. Los controles arquitectónicos que ofrece Kiteworks (cifrado gestionado por el cliente, tenencia única, geofencing aplicado por políticas) están disponibles en todos los modelos de implementación, incluidos los completamente europeos que eliminan el control corporativo estadounidense.
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]