Qué pasa con tu analítica si cae el Marco de Privacidad de Datos UE-EE. UU.

Pregúntale a un equipo de marketing europeo qué base jurídica sostiene su stack de analítica y casi siempre te hablará del consentimiento. Pregúntale qué sostiene el flujo de esos datos hacia un proveedor de capital estadounidense y la sala se queda en silencio. En la mayoría de los casos la respuesta es el Marco de Privacidad de Datos UE-EE. UU., una decisión de adecuación de la Comisión sobre la que se apoya, discretamente, muchísimo herramental.

Conviene saber exactamente cómo de firme es ese suelo y qué pasa la mañana en que deje de serlo.

En qué punto está realmente el Marco

Tres cosas son ciertas a la vez, y confundirlas es donde se equivoca casi todo el análisis que se publica.

Está en vigor. El primer recurso de anulación, Latombe contra Comisión (T-553/23), fue desestimado por el Tribunal General de la UE el 3 de septiembre de 2025. El Marco sobrevivió. Quien te diga que ya ha sido invalidado se equivoca.

Está recurrido. El recurso de casación contra esa desestimación, asunto C-703/25 P, se interpuso el 31 de octubre de 2025 y está pendiente ante el Tribunal de Justicia de la UE. Este tipo de recursos llevan tiempo y el resultado se desconoce.

En 2026 se abrió un segundo frente. Tras una sentencia del Tribunal Supremo estadounidense de junio de 2026 sobre la protección frente al cese de los comisionados de la FTC — una sentencia que toca la independencia de los órganos de supervisión de EE. UU. —, noyb escribió a la Comisión Europea el 30 de junio de 2026 y anunció una nueva impugnación, bautizada popularmente como "Schrems III".

Nada de esto te dice cómo acabará ninguno de los dos frentes. El resultado de un litigio no es previsible y no vamos a fingir lo contrario. Lo que sí te dice es que el Marco es una cuestión jurídica abierta y no cerrada, y que un plan que necesita que sobreviva es un plan con una dependencia sin valorar.

Por qué importa el historial

El Marco de Privacidad de Datos es el tercer acuerdo de su especie. Primero llegó Safe Harbor y fue anulado. Privacy Shield lo sustituyó y también fue anulado. El Marco sustituyó a este último.

Dos invalidaciones no hacen inevitable una tercera: el Marco se negoció precisamente para corregir las deficiencias que el Tribunal había identificado, y ya ha ganado una vez en los tribunales. Pero el patrón explica por qué los delegados de protección de datos con experiencia tratan las arquitecturas dependientes de transferencias como un riesgo permanente. Cada caída anterior produjo la misma carrera contrarreloj: contratos reabiertos, evaluaciones rehechas y algún proveedor abandonado en silencio.

Qué implicaría de verdad rehacer la documentación

Si el Marco se invalidara, la decisión de adecuación dejaría de ser base lícita para las transferencias que se apoyan en ella. Los datos personales que fluyen hacia los proveedores estadounidenses afectados necesitarían otra vía del Capítulo V, lo que en la práctica significa cláusulas contractuales tipo más evaluación de impacto de las transferencias más medidas complementarias, evaluadas por proveedor, por categoría de datos y por finalidad del tratamiento.

Para un stack de marketing de tamaño medio eso no es un documento. Es un proyecto. Analítica, gestor de etiquetas, tests A/B, CDP, email, plataformas publicitarias, grabación de sesiones y ahora las funciones de IA acopladas a varias de ellas. Cada una con su papeleo, su cadena de subencargados y su gestor de cuenta al que perseguir.

Y una evaluación de impacto de las transferencias no es un trámite. Te obliga a valorar si la legislación del país de destino permite el acceso de las autoridades públicas de un modo que socava las garantías: exactamente la pregunta que el Tribunal ya ha respondido de forma desfavorable dos veces respecto a la legislación de vigilancia estadounidense. Por eso las rondas anteriores fueron tan dolorosas.

Qué configuraciones son estructuralmente inmunes

Esta es la parte que conviene interiorizar. El Capítulo V del RGPD regula las transferencias de datos personales a terceros países. Se activa cuando se cumplen dos condiciones: hay datos personales y van a algún sitio fuera de la UE o a una parte sometida a jurisdicción extranjera.

Rompe cualquiera de las dos y el capítulo no llega a aplicarse. No "se aplica pero se cumple": no se aplica.

La primera forma de romperlo es no recoger datos personales. Una analítica que nunca recoge IPs, cookies, huellas de dispositivo ni identificadores de visitante no tiene datos personales que transferir. La segunda es mantener el tratamiento en un encargado constituido en la UE que no tenga matriz estadounidense, de modo que ningún régimen extraterritorial lo alcance.

Haz las dos cosas y el litigio se convierte en un deporte de espectador. Ese es el diseño detrás de Seal AI: la inferencia se ejecuta en Scaleway Generative APIs, solo en París. Scaleway es una empresa francesa cuya matriz es el grupo Iliad, sin capital estadounidense, y declara explícitamente que sus servicios de IA no están sujetos a leyes extraterritoriales como la CLOUD Act estadounidense. Aparece en nuestra lista de subencargados como un simple encargado del tratamiento del artículo 28: Scaleway SAS, París, Francia, finalidad inferencia LLM, retención cero. En esa cadena no hay cláusulas contractuales tipo porque no hay nada que cubrir con ellas.

La trampa asociada es dar por hecho que una región europea lo resuelve. No lo hace: la CLOUD Act sigue a la matriz corporativa, no al centro de datos, que es la distinción que desmenuzamos en Residencia no es soberanía.

Qué revisar en tu stack este trimestre

Es un ejercicio de dos tardes, y merece la pena hacerlo antes de cualquier sentencia y no después.

1. Lista todos los proveedores que tocan datos de visitantes, incluidas las funciones de IA que aparecieron dentro de herramientas que ya tenías. Suelen llegar con un subencargado nuevo y sin revisión contractual.
2. Para cada uno, anota la base del Capítulo V. Adecuación por el Marco de Privacidad de Datos, cláusulas contractuales tipo, una excepción para situaciones específicas o "ninguna necesaria, no hay transferencia". Si nadie en la empresa sabe cuál es, ese es el hallazgo.
3. Marca todo lo que caiga en el primer grupo. Son los elementos que exigirían trabajo el día uno de una sentencia desfavorable. Ordénalos por cuánto tráfico o cuánta facturación dependen de ellos.
4. Revisa la capa de IA por separado. Pregunta dónde se ejecuta la inferencia, en exclusiva, y de quién es esa entidad. Un proveedor puede alojar su aplicación en la UE y estar llamando a un modelo en otro sitio.
5. Pregunta a cada proveedor marcado cuál es su plan. La calidad de esa respuesta ya es información. Algunos tienen una vía real de procesamiento en la UE lista; otros tienen un párrafo tranquilizador.

No se trata de arrancar tu stack de cuajo. Se trata de saber, por adelantado, exactamente cuántos elementos tiene la lista, para que si llega el día estés ejecutando un plan en lugar de descubriendo el alcance.

En resumen

Es perfectamente posible que el Marco de Privacidad de Datos sobreviva a las dos impugnaciones. No tenemos opinión sobre el fondo ni bola de cristal. Pero hay una diferencia importante entre una posición de cumplimiento que necesita que un tribunal falle en un sentido concreto y otra a la que le da igual.

La segunda no es mejor abogacía. Es una decisión de arquitectura tomada antes: no recojas nada personal, procesa dentro de la UE con un encargado al que ninguna ley extranjera pueda alcanzar y no habrá transferencia que defender. La jurisprudencia cambia. La arquitectura no.