A medida que más organizaciones europeas migran cargas a la nube, reaparece un dilema jurídico que no es teórico: ¿qué ocurre cuando una norma de EE. UU. ordena acceder a datos alojados en Europa y el RGPD lo prohíbe? Ese tirón de jurisdicciones tiene nombre y apellidos: CLOUD Act frente a RGPD. Entender el alcance real del conflicto —y cómo gestionarlo— es clave para evitar sanciones, litigios y pérdida de confianza.

Qué es cada norma (y qué no)

CLOUD Act (EE. UU.)

El Clarifying Lawful Overseas Use of Data Act (2018) enmienda el Stored Communications Act y aclara que un proveedor sujeto a la jurisdicción de EE. UU. debe cumplir con una orden judicial válida (warrant/subpoena) aunque los datos estén almacenados fuera del país. Prevé:

• Impugnación por “comity” si el cumplimiento entra en conflicto material con una ley extranjera.
• Posibilidad de canalizar el acceso mediante acuerdos ejecutivos bilaterales y MLATs (asistencia judicial mutua).

No autoriza un acceso “a voluntad”: requiere orden judicial, pero su extraterritorialidad crea fricciones en Europa.

RGPD (UE)

Regula el tratamiento de datos personales en la UE (y el de entidades extracomunitarias que dirigen servicios a residentes). Puntos críticos:

• Principios (licitud, transparencia, minimización, limitación de conservación).
• Transferencias internacionales: solo si hay un mecanismo válido (decisión de adecuación, cláusulas contractuales tipo –SCC–, normas corporativas vinculantes –BCR–, etc.) y garantías equivalentes.
• Responsabilidad proactiva (DPIA, seguridad, privacidad desde el diseño).
• Régimen sancionador: multas de hasta 20 M€ o 4 % del volumen global.

Dónde chocan realmente

1. Extraterritorialidad vs. limitación de transferencias
   El CLOUD Act puede obligar a un proveedor con casa matriz en EE. UU. a entregar datos alojados en la UE; el RGPD exige que cualquier transferencia a un país tercero se base en un mecanismo válido y garantice un nivel esencialmente equivalente de protección.
2. Vigilancia gubernamental
   Tras Schrems II (TJUE, 2020) se invalidó Privacy Shield por la desproporción de la vigilancia estadounidense y la falta de recursos efectivos. En 2023 la Comisión aprobó el EU–US Data Privacy Framework (DPF), con nuevas salvaguardas. Aun así, el debate sobre accesos por seguridad nacional no está cerrado y varias autoridades recomiendan evaluaciones de impacto de transferencia (TIA).
3. Riesgo para el responsable europeo
   Si el proveedor entrega datos bajo CLOUD Act sin base de transferencia válida, el responsable (y en su caso el encargado) podría incumplir el RGPD, incluso si nunca “movió” los datos fuera del EEE.

El “puente” actual (y sus límites)

• EU–US Data Privacy Framework (DPF): permite transferencias a entidades certificadas en EE. UU. (sujetas a nuevas salvaguardas y redress mechanism). No cubre a todas las entidades ni todas las categorías de tratamiento; además, es objeto de escrutinio y posibles impugnaciones.
• SCC 2021 y TIA: las cláusulas tipo siguen siendo el mecanismo más usado. Exigen evaluar (caso por caso) riesgos derivados del acceso gubernamental y adoptar medidas complementarias (cifrado, seudonimización, partición).
• Comity bajo CLOUD Act: permite impugnar órdenes si entran en conflicto con la ley extranjera, pero la protección es casuística y no elimina la incertidumbre.

Implicaciones prácticas para empresas europeas

• Inseguridad jurídica: responsables atrapados entre una orden extranjera y el RGPD.
• Riesgo sancionador y reputacional: una entrega indebida puede desencadenar acciones de autoridades y reclamaciones de interesados.
• Cadenas complejas: subencargados repartidos por varios países y procesos híbridos (cloud + on-prem) complican la trazabilidad.

Además del RGPD, conviene cruzar con normativa sectorial:

• NIS2 (seguridad de redes y sistemas) y DORA (resiliencia operativa digital en finanzas) introducen obligaciones de ciberseguridad, gestión de terceros y localización/continuidad que afectan a la elección de proveedores.
• Esquemas de certificación en marcha (p. ej. EUCS) evalúan soberanía, ubicación de datos y control.

Estrategias de cumplimiento (en castellano llano)

1) Gobernanza y contrato

• Mapeo de datos y flujos: qué datos, dónde residen, quién accede, con qué finalidad.
• Cláusulas reforzadas con proveedores:
  • Residencia de datos (EEE) y subencargados preaprobados.
  • Notificación y desafío de solicitudes gubernamentales; uso de MLAT como canal preferente.
  • Transparencia (informes de solicitudes) y derechos de auditoría.
  • Compromiso de impugnar órdenes incompatibles (warrant canary y límites legales según jurisdicción).

2) Transferencias internacionales

• Verificar DPF (si aplica) o suscribir SCC (módulos 2021) y realizar TIA documentada.
• Medidas complementarias:
  • Cifrado fuerte end-to-end con claves bajo control exclusivo del cliente (BYOK/HYOK, key splitting con custodios europeos).
  • Seudonimización/anonimización antes de la transferencia; minimización estricta.
  • Partición de datos y procesamiento local cuando sea viable.

3) Seguridad y continuidad

• DPIA para tratamientos de alto riesgo; planes de respuesta y registro de accesos.
• Alineación con NIS2/DORA si afecta (gestión de TTP, continuidad, pruebas).
• Formación y simulacros: saber cómo actuar ante una orden extranjera.

4) Opciones arquitectónicas

• Proveedor europeo o cloud soberano cuando la criticidad lo requiera.
• Multicloud/híbrido: segregar tratamientos sensibles en entornos de control; usar gateways y confidencial computing para limitar exposición.
• Localización selectiva: procesar atributos identificadores en la UE y derivar atributos no identificables para procesamiento global.

Comparativa rápida

Lista de verificación (para el consejo y compliance)

• ¿Tenemos inventario de tratamientos y mapa de transferencias?
• ¿Nuestros contratos incluyen residencia, desafío de órdenes y transparencia?
• ¿Hemos realizado TIAs y, si procede, DPIAs documentadas?
• ¿Claves de cifrado bajo control exclusivo (no compartido con el proveedor)?
• ¿Planes y playbooks ante solicitudes gubernamentales?
• ¿Revisamos subencargados y ubicaciones de datos al menos anualmente?
• ¿Alineación con NIS2/DORA y políticas de continuidad?

Conclusión

El enfrentamiento CLOUD Act vs RGPD no es una batalla académica: afecta a cada contrato y a cada flujo que cruce fronteras, incluso cuando los datos no se mueven físicamente del EEE. La buena noticia es que existe una caja de herramientas jurídica y técnica para reducir riesgos: mecanismos de transferencia bien elegidos, medidas criptográficas con control de claves, cláusulas contractuales que exijan impugnar solicitudes incompatibles y, donde proceda, opciones de soberanía (localización, proveedores europeos, segmentación de cargas).

El reto para el responsable del tratamiento es documentar y demostrar que esas decisiones no solo existen, sino que funcionan. En un contexto de multas relevantes y litigios transatlánticos aún en evolución, la diligencia debida ya no es una ventaja competitiva: es la línea base.

Preguntas frecuentes

¿Puedo “curarme en salud” alojando todos mis datos en la UE?
Reduce riesgo, pero no lo elimina si el proveedor está sujeto a EE. UU. (matriz/filiales). La clave es quién controla el acceso (claves) y cómo se gestionan las órdenes.

¿Sirve con firmar SCC y ya?
No. Las SCC exigen evaluación de impacto de transferencia y, si es necesario, medidas complementarias (cifrado, seudonimización, segmentación). Sin eso, las SCC son insuficientes.

¿El DPF resuelve el problema de forma definitiva?
Aporta una base válida para transferencias a entidades certificadas, pero no es un salvoconducto universal y podría ser impugnado. Mantenga TIAs y medidas técnicas.

¿Qué hago si recibo (o mi proveedor recibe) una orden basada en CLOUD Act?
Active el playbook: notificación (si es legalmente posible), impugnación por comity, solicitar canal MLAT, registro de la diligencia y consulta con asesoría. El objetivo es minimizar el conflicto con el RGPD y demostrar actuación responsable.