Schrems II y píxeles de seguimiento: dónde te deja el DPF en 2026

En julio de 2020 el TJUE dictó Schrems II (C-311/18). Privacy Shield, que había sido el mecanismo predeterminado para transferencias de datos UE-EE. UU. desde 2016, fue invalidado. De la noche a la mañana, cada equipo de marketing que ejecutaba un Meta Pixel o una Google Tag o bien transfería datos sin un mecanismo legal válido, estaba luchando por ejecutar Cláusulas Contractuales Tipo, o se apoyaba en la interpretación esperanzadora de que el GDPR de alguna manera no alcanzaba a un fragmento de JavaScript en el navegador de un usuario.

Siguieron tres años de orientación sobre medidas suplementarias, plantillas de Evaluación de Impacto de Transferencia y acciones de aplicación de autoridades de supervisión. Luego, en julio de 2023, la Comisión Europea adoptó la decisión de adecuación del Marco de Privacidad de Datos UE-EE. UU., restaurando la adecuación para empresas estadounidenses certificadas por el DPF. Meta, Google, Salesforce y HubSpot están todos en la lista.

La pregunta para los equipos de marketing y cumplimiento en 2026 no es "¿existe el DPF?" - sí existe. La pregunta es qué cubre realmente, dónde se sienta el riesgo residual, y cómo se ve en la práctica una arquitectura de transferencia que aguanta bajo un potencial desafío al DPF.

TL;DR#

• Privacy Shield (2016) fue invalidado por Schrems II en julio de 2020. Las SCCs más medidas suplementarias cubrieron la brecha de 2020 a 2023.
• El Marco de Privacidad de Datos UE-EE. UU. (julio de 2023) es la decisión de adecuación actual. Las transferencias de empresas certificadas por el DPF se benefician de la adecuación sin requerir SCCs o una TIA.
• Los píxeles del lado del cliente a proveedores certificados por el DPF son legalmente defendibles en 2026, siempre que la entidad receptora esté certificada, el sujeto de los datos haya sido informado, y el consentimiento ePrivacy esté en su lugar donde se requiera.
• El DPF es objeto de desafío legal anticipado. El seguimiento de modo dual - del lado del cliente bajo cobertura DPF, reenvío del lado del servidor desde infraestructura UE como respaldo estructural - es la arquitectura que sobrevive a una tercera sentencia Schrems.

Lo que Schrems II realmente dijo#

Vale la pena leer la sentencia directamente en lugar de a través de un resumen. El razonamiento operativo está en los párrafos 180–202. El hallazgo central no es que las transferencias de datos a EE. UU. sean per se ilegales. Es que la ley de vigilancia de EE. UU. - específicamente FISA 702 y la Orden Ejecutiva 12333 - da a las agencias de inteligencia de EE. UU. acceso a datos personales de sujetos de la UE de una manera que no proporciona remedio efectivo a esos sujetos bajo los Artículos 77–79 del GDPR.

El Artículo 44 del GDPR prohíbe transferencias a terceros países a menos que aplique uno de los mecanismos del Capítulo V. Privacy Shield era una decisión de adecuación bajo el Artículo 45. El hallazgo del Tribunal de que Privacy Shield era inválido por lo tanto despojó la base de adecuación de cada transferencia que dependía de él.

Las Cláusulas Contractuales Tipo no fueron invalidadas - pero el Tribunal sostuvo en la misma sentencia que las SCCs no son automáticamente suficientes para transferencias a EE. UU. El controlador o procesador que usa SCCs debe verificar, caso por caso, si el sistema legal del país de destino impediría que las protecciones a nivel de SCC funcionaran en la práctica. Ese requisito es la Evaluación de Impacto de Transferencia: una evaluación documentada de la ley de vigilancia de EE. UU. y su efecto en los datos transferidos.

Las Recomendaciones 01/2020 de la EDPB sobre medidas suplementarias operacionalizaron este requisito. Establecieron un proceso de seis pasos y un catálogo de medidas suplementarias - técnicas (cifrado, seudonimización), contractuales y organizativas - que los controladores deberían evaluar al confiar en SCCs para transferencias a EE. UU. Para los píxeles de marketing estándar, la mayoría de esas medidas técnicas eran prácticamente imposibles: no puedes cifrar significativamente un payload cuyo propósito es permitir que Meta atribuya una conversión a una impresión de anuncio.

Esta es la arquitectura con la que los equipos de marketing vivieron desde julio de 2020 hasta julio de 2023. Se firmaron SCCs. Se intentaron TIAs. Las DPAs en Austria, Francia e Italia encontraron implementaciones específicas - Google Analytics entre las principales - como no conformes a pesar de las SCCs, porque las medidas suplementarias eran insuficientes.

Qué cambió con el Marco de Privacidad de Datos#

El Marco de Privacidad de Datos UE-EE. UU. (Decisión de la Comisión (UE) 2023/1795, efectiva el 10 de julio de 2023) es una decisión de adecuación bajo el Artículo 45 del GDPR. Su premisa legal es que el marco legal de EE. UU. - modificado por la Orden Ejecutiva 14086 del Presidente Biden y las reglas subsiguientes que establecen el Data Protection Review Court - proporciona un nivel de protección esencialmente equivalente al garantizado en la UE.

Para fines prácticos, el DPF significa esto: las transferencias a empresas estadounidenses certificadas por el DPF se benefician de la adecuación. No necesitas SCCs. No necesitas una TIA. Necesitas verificar que la entidad receptora esté en la lista de participantes del DPF, que es públicamente buscable y se actualiza casi en tiempo real.

Meta Platforms, Inc. está certificada por el DPF. Google LLC está certificada por el DPF. Salesforce, Inc. está certificada por el DPF. HubSpot, Inc. está certificada por el DPF. Para estos proveedores, las transferencias de datos personales de la UE en conexión con publicidad y analítica están cubiertas por la adecuación desde julio de 2023, siempre que estén recibiendo los datos en su capacidad certificada por el DPF.

Dos aclaraciones importan. Primero, la certificación DPF es voluntaria. No toda empresa de EE. UU. que procesa datos UE se ha autocertificado. La lista de participantes es la fuente autoritativa; no asumas la certificación. Segundo, la certificación DPF cubre actividades específicas. Una empresa que está certificada por el DPF puede procesar tus datos de píxel bajo el alcance certificado o bajo una base legal diferente dependiendo del tipo de datos y propósito. Para la atribución estándar de marketing vía píxel, el alcance del DPF lo cubre.

Qué significa esto para los píxeles de marketing en la práctica#

Con la cobertura DPF en su lugar, la postura legal para píxeles de marketing del lado del cliente a proveedores certificados se ve así.

El Meta Pixel del lado del cliente, cuando se dispara a Meta Platforms Inc. (certificada por el DPF), es una transferencia a un destino adecuado. El mecanismo de transferencia es la decisión de adecuación del DPF, no las SCCs. La entrada de RoPA del Artículo 30 para el Meta Pixel documenta la base de transferencia como "decisión de adecuación (DPF)" en lugar de "SCCs". La TIA que habría sido requerida bajo el camino de SCC no se requiere.

El mismo análisis aplica a Google Tag Manager y GA4 disparándose a Google LLC, el píxel de seguimiento de HubSpot disparándose a HubSpot Inc., y los eventos de atribución de Salesforce Marketing Cloud disparándose a Salesforce Inc.

Sin embargo, la adecuación es una capa de una imagen de cumplimiento multi-capa. Tres requisitos adicionales deben estar en su lugar antes de que esta postura se sostenga.

Consentimiento ePrivacy. La Directiva ePrivacy 2002/58/CE, Artículo 5(3), requiere consentimiento antes de cualquier almacenamiento o acceso no esencial en el equipo terminal del usuario. Los píxeles de marketing son no esenciales. Los banners de consentimiento deben ser específicos al píxel en cuestión, libremente dados y revocables. El hecho de que el destino de la transferencia sea DPF-adecuado no afecta el requisito de consentimiento ePrivacy. Estos son instrumentos legales separados.

Transparencia a los sujetos de datos. El Artículo 13 del GDPR requiere que el controlador informe a los sujetos de datos, en el momento de la recopilación, sobre los destinatarios de sus datos y cualquier transferencia a terceros países. El DPF no cambia esta obligación de transparencia. Si tu notificación de privacidad dice "usamos Meta Pixel" y "las transferencias a EE. UU. están cubiertas por adecuación", eso es suficiente. Si no menciona la transferencia a EE. UU. en absoluto, la decisión de adecuación no cura la brecha del Artículo 13.

DPA del Artículo 28 con el proveedor. El proveedor del píxel sigue siendo un procesador bajo el Artículo 28 del GDPR. El DPF cubre el mecanismo de transferencia; no sustituye al DPA. Los términos estándar de procesamiento de datos de Meta, Google y HubSpot son los instrumentos del Artículo 28 para la relación del píxel. Asegúrate de que estén ejecutados.

Los riesgos restantes#

El DPF no es un acuerdo permanente. Es una decisión de adecuación que puede ser impugnada ante el TJUE por cualquier tribunal de Estado miembro, el Parlamento Europeo o cualquier autoridad de supervisión nacional. Max Schrems y NOYB han señalado públicamente la intención de impugnar el DPF - un potencial Schrems III. La teoría legal para ese desafío es similar a Schrems II: que la EO 14086 y el Data Protection Review Court no, en sustancia, proporcionan remedios equivalentes a los disponibles bajo la ley de la UE.

Las autoridades de supervisión no han esperado a una sentencia del TJUE. La DSB austriaca dictaminó sobre una implementación de Google Analytics tan recientemente como 2022 - antes de que el DPF estuviera en vigor - que la transferencia era ilegal porque las SCCs y medidas suplementarias en su lugar eran insuficientes. La CNIL francesa y el Garante italiano emitieron hallazgos similares. Estas sentencias estaban bajo el régimen pre-DPF, pero establecen un patrón de supervisión: las DPAs están dispuestas a examinar la mecánica técnica de las transferencias basadas en píxeles, no solo el papeleo contractual. Una futura sentencia bajo un desafío post-DPF probablemente examinaría si la orden legal que la EO 14086 estableció limita genuinamente el acceso de FISA 702 a los datos almacenados de las empresas certificadas.

La preocupación específica con los píxeles de seguimiento va más allá del mecanismo legal. Un píxel del lado del cliente hace más que transferir datos a una empresa certificada. Ejecuta JavaScript en el navegador del usuario, establece cookies de primera parte y de terceros en el contexto del dominio del píxel, y envía datos directamente desde el navegador. Los datos que salen del navegador están fuera de tu control - no puedes aplicar hash de identificador antes de que salgan, no puedes limitar qué campos se pueblan, y no puedes verificar qué envía realmente el píxel en runtime sin una inspección de red. La adecuación del DPF cubre el destino; no aborda lo que el píxel recopila antes de la transferencia.

Esta combinación - potencial desafío legal al DPF, escrutinio de la autoridad de supervisión sobre la mecánica en lugar de solo el papeleo, y límites estructurales sobre lo que un controlador puede verificar sobre el comportamiento del píxel del lado del cliente - es por qué una estrategia de única pista del lado del cliente sigue siendo arquitectónicamente frágil.

La postura práctica: seguimiento de modo dual#

La arquitectura que se sostiene tanto bajo el DPF como una potencial invalidación del DPF es de modo dual.

El primer modo son los píxeles del lado del cliente a proveedores certificados por el DPF, operando bajo adecuación actual con consentimiento ePrivacy en su lugar. Esto proporciona la señal de atribución más amplia mientras se sostenga el DPF. Para la mayoría de equipos de marketing, este es el modo que llena tus paneles de atribución hoy.

El segundo modo es el reenvío de conversiones del lado del servidor desde infraestructura UE. Cuando un usuario hace clic en un enlace, el edge de la región de la UE de Elido recibe el clic, lo registra en infraestructura de analítica de la UE, y reenvía la señal de conversión servidor-a-servidor a la API de conversión de la plataforma de anuncios - Meta CAPI, GA4 Measurement Protocol o equivalente. El navegador del usuario no contacta con el endpoint de EE. UU. Los datos que salen de la infraestructura UE han sido hasheados (SHA-256 en direcciones de email y números de teléfono, como requiere Meta CAPI), y la transferencia se origina desde infraestructura bajo tu control en lugar de desde código ejecutándose en el navegador del usuario.

Si el DPF es invalidado, el píxel del lado del cliente se convierte en un mecanismo de transferencia no conforme hasta que un marco de reemplazo esté en su lugar. El camino del lado del servidor, ejecutándose vía SCCs con medidas suplementarias aplicadas - cifrado en tránsito, hash de identificador antes de la salida, alcance estrecho a la señal de atribución - es el respaldo que tu equipo legal puede defender con una TIA coherente. Como el camino del lado del servidor procesa datos en infraestructura UE primero, la transferencia puede documentarse como controlador-a-procesador en lugar de como una transferencia directa navegador-a-endpoint-EE.UU.

Donde esté disponible, prefiere el endpoint UE del proveedor. GA4 con data_collection_endpoint apuntado a region1.google-analytics.com mantiene más del procesamiento en la infraestructura UE de Google, aunque algún procesamiento aún ocurre en infraestructura de EE. UU. según la propia documentación de Google. Meta CAPI actualmente no ofrece un endpoint de región UE; la transferencia servidor-a-servidor es vinculada a EE. UU. independientemente. La medida suplementaria es el hash de identificador, no la geografía del endpoint.

Para la mecánica completa del camino de reenvío del lado del servidor y cómo se integra con la atribución de clic de enlace corto, atribución sin cookies explicada cubre la arquitectura técnica. Para la imagen más amplia de residencia UE - donde empieza y para "alojado en UE" en un stack de herramientas de marketing - residencia de datos UE para marketing es el artículo compañero.

Consentimiento de subprocesador bajo DPF#

Cada proveedor de píxel certificado por el DPF sigue siendo un procesador bajo el Artículo 28 del GDPR. La decisión de adecuación del DPF cubre el mecanismo de transferencia; no dice nada sobre las obligaciones del procesador que aplican en paralelo.

Esto significa que el controlador necesita un Acuerdo de Procesamiento de Datos en su lugar con cada proveedor de píxel, cubriendo las obligaciones del Artículo 28(3)(a)-(h). Los términos estándar de datos publicitarios de Meta, la adenda de procesamiento de datos de Google y el DPA de HubSpot son los instrumentos aquí. Están pre-firmados e incorporados por referencia cuando aceptas los términos de servicio del proveedor; la pregunta es si has documentado ese acuerdo en tus registros de cumplimiento.

La lista de subprocesadores que tu DPO preguntará cubre estos proveedores. Cada proveedor de píxel se convierte en un subprocesador en la cadena de atribución entre tu plataforma de seguimiento de enlaces y la plataforma de anuncios. La lista pública de subprocesadores de Elido nombra sus cinco proveedores; los proveedores de píxel son subprocesadores en la capa del controlador, no en la capa de Elido. Tu RoPA del Artículo 30 debería enumerarlos por separado.

Un matiz: el Artículo 28(2) del GDPR requiere que el procesador obtenga la autorización del controlador antes de contratar subprocesadores. Para la relación del píxel, tú eres el controlador contratando a Meta o Google directamente - esto es una relación controlador-a-procesador, no una relación de cadena-subprocesador a través de Elido. El DPA del Artículo 28 es entre tú y el proveedor del píxel. La pierna de reenvío del lado del servidor - donde el edge de Elido reenvía eventos a Meta CAPI en tu nombre - es una relación de subprocesador: Elido es el procesador, Meta CAPI es el subprocesador, y la obligación del DPA fluye a través del DPA estándar de Elido.

Esta distinción importa para tu RoPA. Un equipo de cumplimiento del DPA revisando tus registros quiere ver dos entradas separadas: una para la relación de procesador de Elido (cubriendo los eventos de clic en la capa de enlace), y una para cada relación de proveedor de píxel (cubriendo los datos de atribución del lado del navegador). Conflarlas produce una entrada de RoPA que es precisa en ninguna dirección.

Para las obligaciones de procesador del GDPR a nivel de artículo en su totalidad, GDPR para acortadores de URL es el artículo cornerstone en este cluster.

La lista de comprobación de adquisiciones del DPO para proveedores de píxeles#

Cinco preguntas para hacer a cada proveedor de píxel de seguimiento en adquisición. Estas están escritas para una revisión de la era DPF; ajusta la pregunta del mecanismo de transferencia si el estado del DPF ha cambiado para cuando estés leyendo esto.

1. ¿Su empresa está actualmente listada en la lista de participantes del DPF, y qué actividades cubre su certificación?

La lista está en dataprivacyframework.gov. Pide el alcance específico de certificación, no un "sí, estamos certificados" general. La certificación está delimitada por actividad; un proveedor puede estar certificado por el DPF para datos de recursos humanos pero no para datos comerciales de atribución de clic.

2. ¿Dónde se almacenan realmente los datos que envío vía el píxel, y hay un endpoint de región UE que puedo usar?

El DPF cubre la transferencia a un receptor de EE. UU. certificado. Si un endpoint de región UE está disponible, usarlo reduce la exposición de transferencia y puede afectar el análisis TIA si el DPF es desafiado más tarde. Documenta la respuesta en tu entrada de RoPA.

3. ¿Cuál es su Acuerdo de Procesamiento de Datos estándar, y cubre las obligaciones del Artículo 28(3)(a)-(h) explícitamente?

Los DPAs pre-firmados que se incorporan por referencia en los términos de servicio están bien; necesitas saber que el DPA existe y dónde encontrarlo. El DPA gobierna la relación de procesador independientemente del mecanismo de transferencia.

4. ¿Cómo manejan las solicitudes de derechos del sujeto de datos - específicamente la supresión bajo el Artículo 17 - para datos recopilados por el píxel?

Para píxeles del lado del cliente, la supresión suele ser manejada por los controles de privacidad de la plataforma (Privacy Centre de Meta, My Ad Centre de Google). Documenta el proceso para que puedas responder a una solicitud de sujeto de datos sin improvisar.

5. Si el DPF es invalidado, ¿qué mecanismo de transferencia de respaldo ofrecerán, y en qué cronograma?

Esta pregunta prueba si el proveedor tiene un plan de contingencia. Bajo la transición de Privacy Shield a SCCs (2020–2021), algunos proveedores fueron lentos en actualizar sus acuerdos. Un proveedor que ya ha documentado SCCs como el respaldo de invalidación del DPF - con medidas suplementarias especificadas - ha hecho este trabajo. Un proveedor que dice "actualizaremos nuestro DPA cuando sea necesario" no lo ha hecho.

Para la implementación específica de Elido: el reenvío de conversiones del lado del servidor está disponible hoy, con hash de identificador SHA-256 antes de que cualquier dato salga de la infraestructura UE. La configuración es por workspace y está documentada en el DPA estándar en /legal/dpa. Si tu tolerancia al riesgo del DPF es baja, el camino del lado del servidor está disponible como el mecanismo de reenvío principal, no solo el respaldo.