Las transferencias de datos del RGPD son el único riesgo de cumplimiento que puedes eliminar mediante la arquitectura

La mayor parte del riesgo del RGPD es procedimental: un aviso que puedes reescribir, un plazo de conservación que puedes acortar, un flujo de consentimiento que puedes corregir. Las transferencias internacionales de datos son distintas. Dependen de un instrumento jurídico que no controlas y no puedes parchear, y ese instrumento ha sido anulado dos veces en una década. La única solución duradera es arquitectónica: no transferir los datos en primer lugar.

El mecanismo de transferencia no deja de derrumbarse

El Capítulo V del RGPD prohíbe enviar datos personales a un país sin un nivel adecuado de protección, a menos que dispongas de un mecanismo de transferencia válido. Para los flujos UE-EE. UU., ese mecanismo tiene un cementerio. El TJUE invalidó el Safe Harbour en 2015 (Schrems I) y el Privacy Shield en 2020 (Schrems II), ambos porque la legislación de vigilancia estadounidense no daba a los ciudadanos de la UE ninguna reparación real.

El instrumento actual es el Marco de Privacidad de Datos UE-EE. UU. (DPF), adoptado en 2023. El 3 de septiembre de 2025, el Tribunal General de la UE desestimó el primer recurso contra él, en el asunto Latombe c. Comisión (Asunto T-553/23), confirmando la decisión de adecuación de la Comisión.

Ese no es el final de la historia. Latombe interpuso un recurso ante el Tribunal de Justicia el 31 de octubre de 2025, y noyb —la organización de Max Schrems— ha señalado que prepara un recurso más amplio contra el DPF sobre los mismos fundamentos de vigilancia que hundieron los dos marcos anteriores. El tribunal que liquidó el Safe Harbour y el Privacy Shield volverá a examinarlo.

Por qué esto recae específicamente sobre la analítica

La analítica es la forma más habitual en que un pequeño sitio de la UE acaba realizando una transferencia a EE. UU. sin darse cuenta. El navegador envía un evento; un proveedor de analítica con sede en EE. UU. recibe la dirección IP del visitante y datos de comportamiento en infraestructura estadounidense. Eso es una transferencia de datos personales, y hereda el estatus jurídico que tenga el DPF en cualquier día dado.

Los reguladores ya trataban esto como ilegal antes incluso de que existiera el DPF. Tras las denuncias coordinadas de noyb, la DSB austriaca dictaminó en 2022 que las transferencias UE-EE. UU. a través de Google Analytics vulneraban el Capítulo V, y las autoridades de protección de datos de Francia, Italia, Dinamarca, Finlandia, Suecia y Noruega siguieron con el mismo razonamiento. Que la dirección IP llegara a servidores de EE. UU. ya era suficiente.

Si el TJUE invalida el DPF, esas resoluciones vuelven a ser la plantilla, de la noche a la mañana, para toda herramienta que siga enrutando datos de visitantes de la UE hacia EE. UU.

Eliminar el riesgo mediante la arquitectura

No puedes hacer que el DPF sea más estable. Lo que sí puedes hacer es construir un flujo de datos que no tenga exposición alguna al Capítulo V desde el principio. Dos propiedades lo logran:

Procesar en el edge, dentro de la región. El Data Localization Suite de Cloudflare permite que un Worker confine el procesamiento y los registros a centros de datos de la UE, de modo que la solicitud nunca abandona la región en la que se originó. La decisión sobre dónde se tratan los datos pasa a ser configuración de infraestructura, y no un instrumento jurídico que esperas que sobreviva a la apelación.

Nunca persistir los insumos identificativos. La IP en bruto y el User-Agent que convierten una solicitud en "datos personales" existen solo en memoria el tiempo justo para calcular un hash diario de visitante, y luego se descartan:

visitor_hash = SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

Lo que se almacena es el hash, no los insumos. Como el salt rota a diario y es secreto, el hash no puede revertirse a una persona ni cruzarse entre días. No hay perfil, y nada identificativo cruza jamás una frontera porque nada identificativo se conserva jamás.

Puedes verificar la geografía del flujo en el propio cable. Un beacon de página vista es una única solicitud a un endpoint propio que tú controlas:

POST /collect HTTP/2
Host: api.monoid.website
Content-Type: application/json

{"site_id":"...","path":"/pricing","referrer":"..."}

Si api.monoid.website resuelve a nodos de edge en la UE y el Worker fija su almacenamiento en la UE, no hay ningún encargado estadounidense en el camino, ninguna decisión de adecuación en la que apoyarse y ninguna transferencia que declarar. El país del visitante sigue llegando, derivado de la propia geolocalización del edge y no de enviar la IP a un tercero.

La postura de cumplimiento que esto produce

Una transferencia que nunca realizas es una transferencia que nunca tienes que defender. No hay DPF que citar en tu registro de actividades de tratamiento, ninguna cláusula contractual tipo que mantener, ninguna evaluación de impacto de la transferencia que rehacer cuando cambie la base jurídica, y ningún subencargado en un tercer país que declarar bajo las normas de transparencia que los reguladores están auditando en 2026.

Cualquier otra tarea de cumplimiento en analítica es algo que sigues haciendo. Eliminar la transferencia es algo que haces una vez, en la arquitectura, y luego dejas de pensar en ello, sin importar cómo resuelva el TJUE la apelación.

Fuentes

• Tribunal de Justicia de la UE — Comunicado de prensa: el Tribunal General desestima la acción Latombe (Asunto T-553/23)
• IAPP — El Tribunal General europeo desestima el recurso de Latombe y confirma el Marco de Privacidad de Datos UE-EE. UU.
• noyb — DSB austriaca: las transferencias de datos UE-EE. UU. a Google Analytics son ilegales
• noyb — Más autoridades de protección de datos de la UE ordenan detener Google Analytics
• Cloudflare — Data Localization Suite