Schrems II e pixels de rastreamento: o que o DPF significa para si em 2026

Em julho de 2020, o TJUE proferiu o Schrems II (C-311/18). O Privacy Shield, que era o mecanismo padrão para transferências de dados entre a UE e os EUA desde 2016, foi invalidado. Da noite para o dia, todas as equipas de marketing que utilizavam o Meta Pixel ou o Google Tag estavam a transferir dados sem um mecanismo jurídico válido, a lutar para celebrar Cláusulas Contratuais Padrão, ou a basear-se na esperança de que o RGPD de alguma forma não se aplicava a um fragmento de JavaScript no browser do utilizador.

Seguiram-se três anos de orientações sobre medidas suplementares, modelos de Avaliações de Impacto sobre Transferências e medidas de fiscalização por parte das autoridades de supervisão. Depois, em julho de 2023, a Comissão Europeia adotou a decisão de adequação do Quadro de Privacidade de Dados UE-EUA, restaurando a adequação para as empresas norte-americanas certificadas pelo DPF. Meta, Google, Salesforce e HubSpot constam da lista.

A questão para as equipas de marketing e conformidade em 2026 não é "o DPF existe" - existe. A questão é o que ele efetivamente abrange, onde reside o risco residual e como é, na prática, uma arquitetura de transferência que resiste a um potencial desafio ao DPF.

Resumo#

• O Privacy Shield (2016) foi invalidado pelo Schrems II em julho de 2020. As CCPs com medidas suplementares colmataram a lacuna entre 2020 e 2023.
• O Quadro de Privacidade de Dados UE-EUA (julho de 2023) é a decisão de adequação em vigor. As transferências para empresas certificadas pelo DPF beneficiam de adequação sem necessidade de CCPs ou de uma AIT.
• Os pixels do lado do cliente para fornecedores certificados pelo DPF são juridicamente defensáveis em 2026, desde que a entidade destinatária esteja certificada, os titulares dos dados tenham sido informados e o consentimento ao abrigo da Diretiva ePrivacidade esteja em vigor quando exigido.
• O DPF está sujeito a um desafio jurídico antecipado. O rastreamento de modo dual - do lado do cliente sob cobertura do DPF e encaminhamento do lado do servidor a partir de infraestrutura da UE como alternativa estrutural - é a arquitetura que sobrevive a um terceiro acórdão Schrems.

O que o Schrems II realmente disse#

Vale a pena ler o acórdão diretamente em vez de através de um resumo. O raciocínio operativo encontra-se nos parágrafos 180–202. A conclusão central não é que as transferências de dados para os EUA são per se ilegais. É que a legislação norte-americana de vigilância - especificamente a FISA 702 e a Ordem Executiva 12333 - dá às agências de informação dos EUA acesso a dados pessoais de cidadãos da UE de uma forma que não lhes proporciona uma tutela judicial efetiva ao abrigo dos Artigos 77–79 do RGPD.

O Artigo 44 do RGPD proíbe as transferências para países terceiros a menos que seja aplicável um dos mecanismos do Capítulo V. O Privacy Shield era uma decisão de adequação ao abrigo do Artigo 45. A conclusão do Tribunal de que o Privacy Shield era inválido retirou, portanto, a base de adequação de todas as transferências que nele se apoiavam.

As Cláusulas Contratuais Padrão não foram invalidadas - mas o Tribunal declarou, no mesmo acórdão, que as CCPs não são automaticamente suficientes para transferências para os EUA. O responsável pelo tratamento ou o subcontratante que utilize CCPs deve verificar, caso a caso, se o sistema jurídico do país de destino impediria o funcionamento das proteções previstas nas CCPs. Esse requisito é a Avaliação de Impacto sobre Transferências: uma avaliação documentada da lei norte-americana de vigilância e do seu efeito sobre os dados transferidos.

As Recomendações 01/2020 do CEPD sobre medidas suplementares operacionalizaram este requisito. Estabeleceram um processo de seis etapas e um catálogo de medidas suplementares - técnicas (encriptação, pseudonimização), contratuais e organizacionais - que os responsáveis pelo tratamento devem avaliar quando recorrem a CCPs para transferências para os EUA. Para os pixels de marketing habituais, a maioria dessas medidas técnicas era praticamente impossível: não é possível encriptar de forma significativa um payload cujo propósito é permitir que a Meta atribua uma conversão a uma impressão publicitária.

Esta é a arquitetura com que as equipas de marketing viveram entre julho de 2020 e julho de 2023. As CCPs foram assinadas. As AITs foram tentadas. As APD da Áustria, França e Itália concluíram que implementações específicas - sobretudo o Google Analytics - eram não conformes apesar das CCPs, porque as medidas suplementares eram insuficientes.

O que mudou com o Quadro de Privacidade de Dados#

O Quadro de Privacidade de Dados UE-EUA (Decisão da Comissão (UE) 2023/1795, com efeitos a partir de 10 de julho de 2023) é uma decisão de adequação ao abrigo do Artigo 45 do RGPD. A sua premissa jurídica é que o quadro jurídico norte-americano - alterado pela Ordem Executiva 14086 do Presidente Biden e pelas regras subsequentes que criaram o Tribunal de Revisão da Proteção de Dados - oferece um nível de proteção essencialmente equivalente ao garantido na UE.

Em termos práticos, o DPF significa o seguinte: as transferências para empresas norte-americanas certificadas pelo DPF beneficiam de adequação. Não são necessárias CCPs. Não é necessária uma AIT. É necessário verificar que a entidade destinatária consta da lista de participantes do DPF, que é pesquisável publicamente e atualizada quase em tempo real.

A Meta Platforms, Inc. está certificada pelo DPF. A Google LLC está certificada pelo DPF. A Salesforce, Inc. está certificada pelo DPF. A HubSpot, Inc. está certificada pelo DPF. Para estes fornecedores, as transferências de dados pessoais de cidadãos da UE no âmbito de publicidade e análise estão cobertas pela adequação desde julho de 2023, desde que recebam os dados na sua capacidade certificada pelo DPF.

Dois esclarecimentos são importantes. Em primeiro lugar, a certificação DPF é voluntária. Nem todas as empresas norte-americanas que tratam dados da UE se autocertificaram. A lista de participantes é a fonte de referência; não presuma a certificação. Em segundo lugar, a certificação DPF abrange atividades específicas. Uma empresa certificada pelo DPF pode tratar os seus dados de pixel ao abrigo do âmbito certificado ou de outra base jurídica, dependendo do tipo de dados e da finalidade. Para atribuição de marketing padrão via pixel, o âmbito do DPF abrange-a.

O que isso significa para os pixels de marketing na prática#

Com a cobertura do DPF em vigor, a posição jurídica para os pixels de marketing do lado do cliente junto de fornecedores certificados é a seguinte.

O Meta Pixel do lado do cliente, ao enviar dados para a Meta Platforms Inc. (certificada pelo DPF), constitui uma transferência para um destino adequado. O mecanismo de transferência é a decisão de adequação do DPF, não as CCPs. A entrada no seu Registo de Atividades de Tratamento ao abrigo do Artigo 30 para o Meta Pixel documenta a base de transferência como "decisão de adequação (DPF)" e não como "CCPs". A AIT que seria necessária na via das CCPs não é exigida.

A mesma análise se aplica ao Google Tag Manager e ao GA4 a enviar dados para a Google LLC, ao pixel de rastreamento do HubSpot a enviar dados para a HubSpot Inc., e aos eventos de atribuição do Salesforce Marketing Cloud a enviar dados para a Salesforce Inc.

No entanto, a adequação é apenas uma camada de um quadro de conformidade composto por múltiplas camadas. Três requisitos adicionais devem estar em vigor para que esta posição se sustente.

Consentimento ePrivacidade. A Diretiva ePrivacidade 2002/58/CE, Artigo 5(3), exige consentimento antes de qualquer armazenamento ou acesso não essencial no equipamento terminal do utilizador. Os pixels de marketing são não essenciais. Os banners de consentimento devem ser específicos para o pixel em causa, livremente prestados e revogáveis. O facto de o destino da transferência ser adequado ao abrigo do DPF não afeta o requisito de consentimento da ePrivacidade. Trata-se de instrumentos jurídicos distintos.

Transparência para os titulares dos dados. O Artigo 13 do RGPD exige que o responsável pelo tratamento informe os titulares dos dados, no momento da recolha, sobre os destinatários dos seus dados e quaisquer transferências para países terceiros. O DPF não altera esta obrigação de transparência. Se o seu aviso de privacidade menciona "utilizamos o Meta Pixel" e "as transferências para os EUA são cobertas por adequação", isso é suficiente. Se não mencionar de todo a transferência para os EUA, a decisão de adequação não supre a lacuna do Artigo 13.

DPA do Artigo 28 com o fornecedor. O fornecedor do pixel continua a ser um subcontratante ao abrigo do Artigo 28 do RGPD. O DPF abrange o mecanismo de transferência; não substitui o DPA. Os termos padrão de tratamento de dados da Meta, o adendo de tratamento de dados da Google e o DPA do HubSpot são os instrumentos do Artigo 28 para a relação com o pixel. Certifique-se de que estão celebrados.

Os riscos remanescentes#

O DPF não é um acordo permanente. É uma decisão de adequação que pode ser contestada perante o TJUE por qualquer tribunal de um Estado-Membro, pelo Parlamento Europeu ou por qualquer autoridade nacional de supervisão. Max Schrems e a NOYB sinalizaram publicamente a intenção de contestar o DPF - um potencial Schrems III. A teoria jurídica para esse desafio é semelhante à do Schrems II: que a OE 14086 e o Tribunal de Revisão da Proteção de Dados não proporcionam, na prática, recursos equivalentes aos disponíveis ao abrigo do direito da UE.

As autoridades de supervisão não aguardaram uma decisão do TJUE. A DSB austríaca decidiu sobre uma implementação do Google Analytics ainda em 2022 - antes de o DPF estar em vigor - que a transferência era ilícita porque as CCPs e medidas suplementares em vigor eram insuficientes. A CNIL francesa e o Garante italiano emitiram conclusões semelhantes. Estas decisões foram proferidas ao abrigo do regime anterior ao DPF, mas estabelecem um padrão de supervisão: as APD estão dispostas a examinar a mecânica técnica das transferências baseadas em pixels, e não apenas a documentação contratual. Uma decisão futura ao abrigo de um desafio pós-DPF examinaria provavelmente se a ordem jurídica estabelecida pela OE 14086 limita genuinamente o acesso da FISA 702 aos dados armazenados das empresas certificadas.

A preocupação específica com os pixels de rastreamento vai além do mecanismo jurídico. Um pixel do lado do cliente faz mais do que transferir dados para uma empresa certificada. Executa JavaScript no browser do utilizador, define cookies de primeira e terceira parte no contexto do domínio do pixel e envia dados diretamente a partir do browser. Os dados que saem do browser estão fora do seu controlo - não é possível aplicar hash aos identificadores antes de eles saírem, não é possível limitar os campos preenchidos e não é possível verificar o que o pixel realmente envia em tempo de execução sem uma inspeção de rede. A adequação do DPF abrange o destino; não aborda o que o pixel recolhe antes da transferência.

Esta combinação - potencial desafio jurídico ao DPF, escrutínio das autoridades de supervisão sobre a mecânica e não apenas sobre a documentação, e limitações estruturais sobre o que um responsável pelo tratamento pode verificar sobre o comportamento de um pixel do lado do cliente - é a razão pela qual uma estratégia exclusivamente de cliente continua a ser arquiteturalmente frágil.

A posição prática: rastreamento de modo dual#

A arquitetura que resiste tanto ao DPF como a uma eventual invalidação do DPF é o modo dual.

O primeiro modo são os pixels do lado do cliente para fornecedores certificados pelo DPF, operando sob adequação atual com consentimento ePrivacidade em vigor. Isso fornece o sinal de atribuição mais amplo enquanto o DPF se mantiver. Para a maioria das equipas de marketing, este é o modo que alimenta os seus dashboards de atribuição hoje.

O segundo modo é o encaminhamento de conversões do lado do servidor a partir de infraestrutura da UE. Quando um utilizador clica numa ligação, a edge da Elido na região da UE recebe o clique, regista-o no nosso armazenamento de análise na UE e encaminha o sinal de conversão de servidor para servidor para a API de conversões da plataforma de publicidade - Meta CAPI, GA4 Measurement Protocol ou equivalente. O browser do utilizador não contacta o endpoint norte-americano. Os dados que saem da infraestrutura da UE foram submetidos a hash (SHA-256 em endereços de e-mail e números de telefone, conforme exigido pelo Meta CAPI), e a transferência origina-se a partir de infraestrutura sob o seu controlo, e não de código a correr no browser do utilizador.

Se o DPF for invalidado, o pixel do lado do cliente torna-se um mecanismo de transferência não conforme até que um quadro substituto esteja em vigor. A via do lado do servidor, operando através de CCPs com medidas suplementares aplicadas - encriptada em trânsito, com identificadores com hash antes de sair, restrita ao sinal de atribuição - é a alternativa que a sua equipa jurídica pode defender com uma AIT coerente. Como a via do lado do servidor trata os dados na infraestrutura da UE em primeiro lugar, a transferência pode ser documentada como de responsável para subcontratante, em vez de uma transferência direta do browser para um endpoint nos EUA.

Sempre que disponível, prefira o endpoint europeu do fornecedor. O GA4 com data_collection_endpoint apontado para region1.google-analytics.com mantém mais processamento na infraestrutura europeia da Google, embora algum processamento ainda ocorra na infraestrutura norte-americana, de acordo com a própria documentação da Google. O Meta CAPI não oferece atualmente um endpoint com região na UE; a transferência de servidor para servidor é sempre para os EUA. A medida suplementar é o hash dos identificadores, não a geografia do endpoint.

Para a mecânica completa da via de encaminhamento do lado do servidor e a sua integração com a atribuição de cliques em ligações curtas, o artigo atribuição sem cookies explicada abrange a arquitetura técnica. Para o quadro mais alargado de residência de dados na UE - onde começa e termina o conceito de "alojado na UE" numa pilha de ferramentas de marketing - residência de dados da UE para marketing é o artigo complementar.

Consentimento de subcontratantes ao abrigo do DPF#

Cada fornecedor de pixels certificado pelo DPF continua a ser um subcontratante ao abrigo do Artigo 28 do RGPD. A decisão de adequação do DPF abrange o mecanismo de transferência; nada diz sobre as obrigações do subcontratante que se aplicam em paralelo.

Isso significa que o responsável pelo tratamento precisa de um Contrato de Tratamento de Dados celebrado com cada fornecedor de pixels, cobrindo as obrigações do Artigo 28(3)(a)-(h). Os termos padrão de dados publicitários da Meta, o adendo de tratamento de dados da Google e o DPA do HubSpot são os instrumentos aplicáveis. Estão pré-assinados e incorporados por referência quando aceita os termos de serviço do fornecedor; a questão é se documentou esse acordo nos seus registos de conformidade.

A lista de subcontratantes que o seu DPO irá solicitar abrange estes fornecedores. Cada fornecedor de pixels torna-se um subcontratante na cadeia de atribuição entre a sua plataforma de rastreamento de ligações e a plataforma de publicidade. A lista pública de subcontratantes da Elido nomeia os seus cinco fornecedores; os fornecedores de pixels são subcontratantes ao nível do responsável pelo tratamento, e não ao nível da Elido. O seu Registo de Atividades de Tratamento ao abrigo do Artigo 30 deve enumerá-los separadamente.

Uma nuance: o Artigo 28(2) do RGPD exige que o subcontratante obtenha autorização do responsável pelo tratamento antes de contratar subcontratantes. Para a relação com o pixel, é o responsável pelo tratamento a contratar a Meta ou a Google diretamente - trata-se de uma relação de responsável para subcontratante, e não de uma cadeia de sub-subcontratação através da Elido. O DPA do Artigo 28 é estabelecido entre si e o fornecedor do pixel. O percurso de encaminhamento do lado do servidor - onde a edge da Elido encaminha eventos para o Meta CAPI em seu nome - é uma relação de sub-subcontratante: a Elido é o subcontratante, o Meta CAPI é o sub-subcontratante, e a obrigação do DPA flui através do DPA padrão da Elido.

Esta distinção é relevante para o seu Registo de Atividades de Tratamento. Uma equipa de conformidade DPA que analise os seus registos quer ver duas entradas separadas: uma para a relação com o subcontratante Elido (cobrindo os eventos de clique ao nível da ligação) e uma para cada relação com um fornecedor de pixels (cobrindo os dados de atribuição do lado do browser). Confundi-las produz uma entrada no Registo de Atividades de Tratamento que não é precisa em nenhuma das direções.

Para as obrigações completas do subcontratante ao abrigo do RGPD ao nível do artigo, RGPD para encurtadores de URL é o artigo principal deste cluster.

A lista de verificação de aquisição do DPO para fornecedores de pixels#

Cinco perguntas a fazer a cada fornecedor de pixels de rastreamento na aquisição. Estão escritas para uma revisão na era do DPF; ajuste a questão do mecanismo de transferência se o estado do DPF tiver mudado quando estiver a ler isto.

1. A sua empresa consta atualmente da lista de participantes do DPF e quais as atividades abrangidas pela sua certificação?

A lista está em dataprivacyframework.gov. Peça o âmbito específico da certificação, não um simples "sim, estamos certificados". A certificação tem âmbito por atividade; um fornecedor pode ser certificado pelo DPF para dados de recursos humanos, mas não para dados de atribuição de cliques comerciais.

2. Onde são efetivamente armazenados os dados que envio através do pixel e existe algum endpoint com região na UE que eu possa utilizar?

O DPF abrange a transferência para um destinatário norte-americano certificado. Se estiver disponível um endpoint com região na UE, a sua utilização reduz a exposição à transferência e pode afetar a análise da AIT se o DPF for posteriormente contestado. Documente a resposta na sua entrada no Registo de Atividades de Tratamento.

3. Qual é o seu Contrato de Tratamento de Dados padrão e abrange explicitamente as obrigações do Artigo 28(3)(a)-(h)?

Os DPAs pré-assinados incorporados por referência nos termos de serviço são aceitáveis; precisa de saber que o DPA existe e onde encontrá-lo. O DPA rege a relação com o subcontratante independentemente do mecanismo de transferência.

4. Como trata os pedidos de direitos dos titulares dos dados - nomeadamente a eliminação ao abrigo do Artigo 17 - para dados recolhidos pelo pixel?

Para pixels do lado do cliente, a eliminação é geralmente tratada pelos controlos de privacidade da plataforma (Centro de Privacidade da Meta, O Meu Centro de Anúncios da Google). Documente o processo para poder responder a um pedido de um titular de dados sem improvisar.

5. Se o DPF for invalidado, que mecanismo de transferência alternativo irá oferecer e em que prazo?

Esta questão testa se o fornecedor tem um plano de contingência. Durante a transição do Privacy Shield para as CCPs (2020–2021), alguns fornecedores foram lentos a atualizar os seus acordos. Um fornecedor que já documentou as CCPs como alternativa de invalidação do DPF - com medidas suplementares especificadas - fez este trabalho. Um fornecedor que diz "atualizaremos o nosso DPA quando necessário" não o fez.

Para a implementação específica da Elido: o encaminhamento de conversões do lado do servidor está disponível hoje, com hash SHA-256 dos identificadores antes de quaisquer dados saírem da infraestrutura da UE. A configuração é por workspace e está documentada no DPA padrão em /legal/dpa. Se a sua tolerância ao risco do DPF for baixa, a via do lado do servidor está disponível como mecanismo de encaminhamento principal, e não apenas como alternativa.