Prevén riesgos del CLOUD Act: protege datos europeos con arquitectura segura
Cómo evitar el acceso del gobierno de EE. UU. a datos europeos: un enfoque arquitectónico al problema del CLOUD Act
Las organizaciones europeas que procesan datos confidenciales a través de plataformas en la nube con sede en EE. UU. enfrentan un problema estructural de cumplimiento que ni el derecho contractual ni la residencia de datos pueden resolver.
La Ley de Clarificación del Uso Legal de Datos en el Extranjero de Estados Unidos (CLOUD Act) de 2018 exige que las empresas estadounidenses entreguen datos almacenados en cualquier parte del mundo si reciben una solicitud válida del gobierno de EE. UU., sin importar dónde residan esos datos o lo que digan los acuerdos de privacidad de datos.
Para las organizaciones sujetas a GDPR, NIS2 y DORA, esto crea un conflicto directo entre las plataformas en las que confían y las obligaciones legales que deben cumplir.
Resumen Ejecutivo
Idea principal: El CLOUD Act de EE. UU. crea un conflicto irreconciliable entre las obligaciones legales de los proveedores estadounidenses y la legislación europea sobre soberanía de datos. Soluciones como las cláusulas contractuales estándar, la implementación en centros de datos de la UE y otras no eliminan esta exposición porque el CLOUD Act sigue el control del proveedor, no la ubicación de los datos. Las claves de cifrado controladas por el cliente —en poder de la organización europea, no del proveedor— son la única medida arquitectónica que hace que las solicitudes del gobierno estadounidense sean técnicamente inexigibles frente al contenido real de los datos.
Por qué te debería importar: El artículo 48 del GDPR prohíbe transferir datos personales a autoridades fuera de la UE únicamente sobre la base de una orden judicial o administrativa extranjera. Una organización que procese datos a través de una plataforma estadounidense sujeta a la jurisdicción del CLOUD Act puede estar en incumplimiento estructural continuo, no por un incidente concreto, sino por la propia arquitectura. NIS2 y DORA añaden obligaciones de gestión de riesgos en la cadena de suministro TIC de terceros que agravan esta exposición para sectores críticos y servicios financieros.
5 puntos clave
- El CLOUD Act sigue el control del proveedor, no la ubicación de los datos. Almacenar datos en un centro de datos en Frankfurt o Ámsterdam operado por una empresa estadounidense no coloca esos datos bajo jurisdicción alemana u holandesa. Las autoridades estadounidenses pueden exigir al proveedor que los entregue sin importar la ubicación física del almacenamiento.
- Las Cláusulas Contractuales Estándar y los Acuerdos de Procesamiento de Datos no pueden anular la obligación legal de EE. UU. El CLOUD Act exige que los proveedores cumplan con solicitudes válidas del gobierno estadounidense incluso si hacerlo entra en conflicto con leyes extranjeras. Las SCC y los DPA son instrumentos contractuales sin fuerza legal frente a órdenes judiciales o administrativas estadounidenses dirigidas al proveedor.
- El Marco de Privacidad de Datos UE-EE. UU. no resuelve la exposición al CLOUD Act. El DPF aborda las reglas de transferencia de datos personales para empresas estadounidenses certificadas, pero no impide que las autoridades estadounidenses emitan solicitudes bajo el CLOUD Act. La Sección 702 de FISA, reautorizada con alcance ampliado en abril de 2024, sigue siendo una preocupación distinta y no resuelta bajo la legislación europea de protección de datos.
- Los Análisis de Impacto de Transferencia realizados con honestidad identificarán el riesgo del CLOUD Act como no minimizado sin medidas técnicas. Las recomendaciones Schrems II del EDPB identifican explícitamente las claves de cifrado controladas por el cliente y retenidas en el EEE como la principal medida técnica suplementaria capaz de abordar la exposición a la legislación de vigilancia estadounidense.
- El cifrado gestionado por el cliente hace que las solicitudes del CLOUD Act sean técnicamente inexigibles sobre el contenido de los datos. Cuando la organización europea —y no el proveedor estadounidense— tiene las claves de cifrado integradas en HSM bajo control jurisdiccional, el proveedor no puede entregar datos legibles aunque esté legalmente obligado. La arquitectura resuelve lo que los contratos no pueden.
Por qué el CLOUD Act crea un problema estructural para las organizaciones europeas
La distinción clave es entre ubicación y control de los datos. La mayoría de las organizaciones europeas que migraron a plataformas en la nube estadounidenses lo hicieron bajo la premisa de que «nuestros datos están en la UE» como medida de tranquilidad. Esa tranquilidad es, en gran parte, infundada.
Cómo opera el CLOUD Act y por qué los centros de datos de la UE no ofrecen protección
El CLOUD Act exige que las empresas estadounidenses conserven, respalden y revelen comunicaciones electrónicas y registros en su posesión, custodia o control cuando reciban una solicitud legal válida, sin importar la ubicación del almacenamiento. El criterio operativo es el control, no la geografía. Un proveedor estadounidense que opera un centro de datos en Frankfurt sigue siendo una empresa de EE. UU. con control sobre los datos allí almacenados. Cuando el Departamento de Justicia o el FBI emiten una solicitud, la ubicación en Frankfurt es legalmente irrelevante.
El problema se agrava porque las solicitudes del CLOUD Act suelen incluir órdenes de no divulgación: el proveedor estadounidense puede tener prohibido legalmente informar al cliente europeo cuyo dato está siendo accedido. Una organización puede estar en incumplimiento continuo del artículo 48 del GDPR, que prohíbe entregar datos personales a autoridades fuera de la UE sin un acuerdo internacional, sin saber nunca que se ha producido una solicitud. El CLOUD Act no es tal acuerdo.
Por qué las protecciones contractuales no cierran la brecha
El CLOUD Act establece explícitamente que los proveedores estadounidenses deben cumplir con solicitudes válidas incluso si hacerlo entra en conflicto con leyes extranjeras. El compromiso contractual del proveedor de impugnar una solicitud o notificar al cliente es secundario frente a sus obligaciones legales en EE. UU. Esto no es teórico. La sentencia Schrems II del TJUE invalidó el Privacy Shield UE-EE. UU. precisamente por esta razón: la legislación estadounidense permitía el acceso de las autoridades a datos personales de la UE de manera incompatible con el GDPR, y los ciudadanos de la UE carecían de recursos judiciales efectivos. El Tribunal confirmó que no se podía confiar en las cláusulas contractuales estándar cuando la ley estadounidense socavaba su eficacia y que se requerían medidas técnicas suplementarias.
Lista completa de cumplimiento GDPR
Leer ahora
Cómo el marco de transferencias del GDPR se cruza con la exposición al CLOUD Act
El Capítulo V del GDPR —artículos 44-49— regula las transferencias internacionales de datos personales. Para las organizaciones europeas que utilizan plataformas estadounidenses, comprender este marco no es opcional. Usar un proveedor en la nube estadounidense puede constituir una transferencia internacional continua y la base legal de ello tiene implicaciones directas para la exposición regulatoria bajo el cumplimiento GDPR.
Artículos 44-49, Schrems II y lo que deben cubrir los Análisis de Impacto de Transferencia
Las organizaciones que se basan en las SCC del artículo 46 deben, tras Schrems II, realizar Análisis de Impacto de Transferencia evaluando si la legislación estadounidense afecta la eficacia de las SCC para sus transferencias concretas. Las Recomendaciones 01/2020 del EDPB detallan este proceso. De forma crítica, el EDPB identificó el cifrado robusto previo a la transmisión —donde las claves de descifrado permanecen bajo control exclusivo del EEE— como la medida técnica suplementaria capaz de abordar la exposición a la legislación de vigilancia estadounidense. El cifrado estándar en la nube, donde el proveedor gestiona las claves como parte del servicio, no cumple este estándar: el proveedor mantiene acceso técnico a los datos en texto claro y sigue estando sujeto a solicitudes bajo el CLOUD Act.
Por qué el Marco de Privacidad de Datos UE-EE. UU. no resuelve el problema
El DPF, adoptado por la Comisión Europea en julio de 2023, permite que empresas estadounidenses certificadas reciban datos personales de la UE sin SCC adicionales. No impide que las autoridades estadounidenses emitan solicitudes bajo el CLOUD Act o la Sección 702 de FISA a empresas certificadas. La Sección 702 de FISA fue reautorizada en abril de 2024 con alcance ampliado. El Parlamento Europeo advirtió en mayo de 2023 que el DPF «no logra crear una equivalencia esencial». El informe de revisión del EDPB de noviembre de 2024 pidió una reevaluación en tres años. A principios de 2025, la administración Trump destituyó a tres de los cinco miembros de la Junta de Supervisión de Privacidad y Libertades Civiles de EE. UU. —el organismo que supervisa los compromisos de inteligencia del DPF— dejándola sin quórum. Los dos predecesores del DPF, Safe Harbour y Privacy Shield, fueron invalidados por el TJUE. Las organizaciones que tratan la certificación DPF como su principal mitigación ante el CLOUD Act están construyendo sobre cimientos demostrablemente frágiles.
NIS2 y DORA agravan la exposición
El GDPR no es el único marco que crea obligaciones relevantes para la exposición al CLOUD Act. Para organizaciones de infraestructuras críticas y servicios financieros, NIS2 y DORA añaden requisitos específicos de gestión de riesgos de terceros que la dependencia de proveedores estadounidenses implica directamente.
Seguridad en la cadena de suministro según NIS2 y riesgo TIC de terceros según DORA
NIS2, aplicable desde octubre de 2024, exige que las entidades esenciales e importantes evalúen la seguridad de la cadena de suministro TIC, incluyendo la exposición de sus proveedores a solicitudes de acceso de gobiernos fuera de la UE según el artículo 21. Una organización que no haya evaluado si la exposición de su proveedor estadounidense al CLOUD Act constituye un riesgo en la cadena de suministro puede estar incumpliendo las obligaciones de gestión de riesgos de NIS2, aunque no se haya producido ninguna solicitud. Las multas pueden alcanzar los 10 millones de euros o el 2% del volumen de negocios anual global para entidades esenciales.
DORA, aplicable desde enero de 2025, exige que las entidades financieras evalúen el riesgo de concentración asociado a la dependencia de proveedores TIC, revisen los compromisos de confidencialidad y mantengan estrategias de salida documentadas para relaciones TIC críticas. El CLOUD Act crea un riesgo de concentración específico que DORA exige evaluar y abordar. La Guía del BCE de julio de 2025 sobre externalización de servicios en la nube refuerza esto, enfatizando la evaluación basada en riesgos de la exposición legal de los proveedores de nube para bancos supervisados por el BCE.
La solución arquitectónica: cifrado gestionado por el cliente
La guía del EDPB define el requisito con precisión: el proveedor estadounidense nunca debe tener acceso ni a los datos sin cifrar ni a las claves de cifrado. Es un requisito arquitectónico, no contractual. Cumplirlo requiere implementar plataformas donde el cumplimiento de la soberanía de datos esté integrado en la propia capa de cifrado, con claves bajo control del cliente europeo, almacenadas en HSM dentro de la jurisdicción del cliente.
Cómo el cifrado gestionado por el cliente aborda la exposición al CLOUD Act
El cifrado gestionado por el cliente funciona bajo un principio sencillo: los datos se cifran antes de llegar a la infraestructura del proveedor estadounidense, usando claves que el cliente genera y almacena de forma independiente. Cuando una autoridad estadounidense presenta una solicitud bajo el CLOUD Act, el proveedor puede entregar los datos cifrados, pero no el contenido legible, porque no posee las claves. La solicitud es técnicamente inexigible sobre la información real. Para fines de GDPR, esta arquitectura cumple directamente el requisito de medida suplementaria del EDPB. El exportador de datos —la organización europea— mantiene el control exclusivo de las claves de descifrado dentro del EEE. El importador de datos —el proveedor estadounidense— solo procesa datos cifrados. Esta es la configuración específica que el EDPB identificó como capaz de abordar la exposición a la legislación de vigilancia estadounidense.
Implementación de claves específica por jurisdicción para operaciones multinacionales
Para organizaciones que operan en Alemania, Francia, Países Bajos y Reino Unido, el cifrado gestionado por el cliente permite una implementación de claves específica por jurisdicción. Las organizaciones alemanas implementan HSM en Alemania, cumpliendo el GDPR y las obligaciones de confidencialidad penal del §203 StGB. Las organizaciones francesas controlan las claves en Francia, manteniendo el secreto profesional bajo el Código de Salud Pública. Las organizaciones neerlandesas almacenan las claves en Países Bajos, cumpliendo las expectativas de la AP. Las organizaciones del Reino Unido implementan en Reino Unido, cumpliendo la guía del ICO sobre medidas suplementarias de transferencia. Esta arquitectura no exige abandonar las plataformas en la nube estadounidenses, sino asegurar que la capa de cifrado esté bajo control europeo antes de que los datos lleguen a la infraestructura estadounidense.
Construir el caso documental para los reguladores
Implementar la arquitectura adecuada es necesario, pero no suficiente. Las autoridades de protección de datos, los organismos supervisores de NIS2 y las autoridades competentes de DORA esperan pruebas documentadas. Para las organizaciones que han abordado la exposición al CLOUD Act mediante cifrado gestionado por el cliente, la documentación sigue una estructura clara.
Pruebas del Análisis de Impacto de Transferencia y cumplimiento continuo
Un Análisis de Impacto de Transferencia conforme a Schrems II para relaciones con proveedores estadounidenses debe documentar: las leyes estadounidenses relevantes (CLOUD Act, FISA 702); una evaluación de cómo afectan a las SCC; las medidas técnicas suplementarias adoptadas; la base para concluir que esas medidas logran una protección esencialmente equivalente; y un compromiso de monitoreo ante cambios en la decisión de adecuación del DPF. Las pruebas de soporte incluyen diagramas de arquitectura, procedimientos de gestión de claves, registros de implementación de HSM y registros de auditoría que demuestran que los controles de acceso están operativos. Para NIS2 y DORA, añade evaluaciones de riesgos en la cadena de suministro que aborden la exposición de los proveedores al CLOUD Act, evaluaciones de riesgo de concentración, estrategias de salida y matrices RBAC que muestren quién puede descifrar qué.
Cómo Kiteworks permite a las organizaciones europeas abordar la exposición al CLOUD Act desde la arquitectura
El problema del CLOUD Act es real, estructural y no puede resolverse solo con contratos. Las organizaciones europeas que procesan datos confidenciales a través de plataformas estadounidenses sin claves de cifrado gestionadas por el cliente mantienen una brecha de cumplimiento que los Análisis de Impacto de Transferencia honestos identificarán, sobre la que las autoridades supervisoras del GDPR están cada vez más dispuestas a actuar, y que los marcos de riesgos de terceros de NIS2 y DORA exigen abordar. La solución arquitectónica avalada por el EDPB ya está disponible. Solo requiere asegurar que la capa de cifrado esté donde debe: bajo control europeo, antes de que los datos lleguen a la infraestructura estadounidense.
Kiteworks ofrece a las organizaciones europeas una Red de Contenido Privado que aborda directamente la exposición al CLOUD Act mediante cifrado gestionado por el cliente. Las claves de cifrado permanecen bajo control exclusivo del cliente europeo, almacenadas en HSM implementados dentro de la jurisdicción del cliente. Cuando Kiteworks procesa datos, procesa solo datos cifrados, haciendo que el contenido en texto claro sea técnicamente inaccesible para solicitudes del gobierno estadounidense dirigidas a Kiteworks.
La plataforma permite implementaciones específicas por jurisdicción —las organizaciones alemanas controlan claves en Alemania, las francesas en Francia, las neerlandesas en Países Bajos, las del Reino Unido dentro de Reino Unido— cumpliendo los requisitos de medidas suplementarias de Schrems II del EDPB y proporcionando la base documental que exigen los Análisis de Impacto de Transferencia. Kiteworks integra correo electrónico seguro, uso compartido seguro de archivos, MFT segura y formularios de datos seguros de Kiteworks en una arquitectura unificada, lo que significa que el cifrado gestionado por el cliente se aplica de forma coherente en todos los canales de intercambio de datos.
Para descubrir cómo Kiteworks ayuda a las organizaciones europeas a abordar la exposición al CLOUD Act, agenda una demo personalizada hoy mismo.
Preguntas frecuentes
El CLOUD Act de EE. UU. se aplica en función del control del proveedor, no de la localización de los datos. Una empresa estadounidense que opera un centro de datos en la UE mantiene la posesión y el control de los datos que almacena allí. Cuando las autoridades estadounidenses emiten una solicitud bajo el CLOUD Act, el proveedor debe cumplirla sin importar la ubicación física del almacenamiento. La ubicación en un centro de datos de la UE no coloca los datos bajo jurisdicción de la UE si el operador es una empresa estadounidense sujeta a obligaciones legales de EE. UU.
Las cláusulas contractuales estándar son instrumentos entre el exportador e importador de datos. El CLOUD Act exige que los proveedores estadounidenses cumplan con solicitudes válidas del gobierno de EE. UU. incluso si hacerlo entra en conflicto con leyes extranjeras u obligaciones contractuales. El EDPB confirmó en sus recomendaciones de Schrems II que las medidas contractuales suplementarias por sí solas no pueden abordar la exposición a la legislación de vigilancia estadounidense: se requieren medidas técnicas, específicamente claves de cifrado controladas por el cliente y retenidas en el EEE.
No. El DPF regula las reglas de transferencia de datos personales para empresas estadounidenses certificadas, pero no impide que las autoridades estadounidenses emitan solicitudes bajo el CLOUD Act o la Sección 702 de FISA. La Sección 702 de FISA, identificada en Schrems II como el principal obstáculo para una protección esencialmente equivalente, fue reautorizada en abril de 2024. El DPF también enfrenta desafíos legales y una inestabilidad política continuos. Las organizaciones que confían únicamente en la certificación DPF para mitigar el CLOUD Act mantienen un riesgo de cumplimiento de datos sin resolver.
Un TIA conforme debe documentar las leyes estadounidenses relevantes (CLOUD Act, FISA 702), la evaluación de cómo afectan a las SCC, la medida técnica suplementaria adoptada (cifrado gestionado por el cliente con claves controladas en el EEE), pruebas de que el proveedor no puede acceder a los datos sin cifrar y un compromiso de monitoreo. Las pruebas técnicas de soporte incluyen diagramas de arquitectura, procedimientos de gestión de claves, registros de implementación de HSM y registros de auditoría que demuestren que los controles de acceso están operativos.
NIS2 exige que las entidades esenciales e importantes evalúen los riesgos de seguridad en la cadena de suministro TIC, incluyendo la exposición de los proveedores a solicitudes de acceso de gobiernos fuera de la UE. DORA exige que las entidades financieras evalúen el riesgo de concentración y los compromisos de confidencialidad para proveedores TIC críticos de terceros. Ambos requieren evaluaciones de riesgos documentadas que aborden la exposición al CLOUD Act. Usar un proveedor estadounidense sin controles técnicos puede constituir una brecha no minimizada en la gestión de riesgos de la cadena de suministro bajo el artículo 21 de NIS2 o un riesgo TIC de terceros no documentado bajo DORA.
Recursos adicionales
- Artículo del Blog
Soberanía de datos: ¿mejor práctica o requisito regulatorio? - eBook
Soberanía de datos y GDPR - Artículo del Blog
Evita estos errores en la 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]