Transferências de dados sob o GDPR são o único risco de conformidade que você consegue eliminar pela arquitetura

A maior parte do risco sob o GDPR é procedimental — um aviso que você pode reescrever, um prazo de retenção que você pode encurtar, um fluxo de consentimento que você pode corrigir. As transferências internacionais de dados são diferentes. Elas dependem de um instrumento jurídico que você não controla e não pode corrigir, e esse instrumento já foi derrubado duas vezes em uma década. A única solução duradoura é arquitetural: nunca transferir os dados em primeiro lugar.

O mecanismo de transferência vive ruindo

O Capítulo V do GDPR proíbe enviar dados pessoais para um país sem um nível adequado de proteção, a menos que você tenha um mecanismo de transferência válido. Para os fluxos UE-EUA, esse mecanismo tem um cemitério. O TJUE invalidou o Safe Harbour em 2015 (Schrems I) e o Privacy Shield em 2020 (Schrems II), ambos porque a legislação de vigilância dos EUA não dava aos cidadãos da UE nenhuma reparação real.

O instrumento atual é o Data Privacy Framework UE-EUA (DPF), adotado em 2023. Em 3 de setembro de 2025, o Tribunal Geral da UE rejeitou o primeiro questionamento a ele, no caso Latombe v. Commission (Processo T-553/23), confirmando a decisão de adequação da Comissão.

Essa não é a última palavra. Latombe interpôs recurso ao Tribunal de Justiça em 31 de outubro de 2025, e o noyb — a organização de Max Schrems — sinalizou que está preparando um questionamento mais amplo ao DPF com base nos mesmos fundamentos de vigilância que afundaram os dois últimos frameworks. O tribunal que matou o Safe Harbour e o Privacy Shield vai dar outra olhada.

Por que isso recai especificamente sobre analytics

A analytics é a forma mais comum de um pequeno site da UE acabar fazendo uma transferência para os EUA sem perceber. O navegador envia um evento; um provedor de analytics sediado nos EUA recebe o endereço IP do visitante e dados comportamentais em infraestrutura norte-americana. Isso é uma transferência de dados pessoais, e ela herda qualquer status jurídico que o DPF tenha em um dado dia.

Os reguladores já tratavam isso como ilegal antes mesmo de o DPF existir. Após as denúncias coordenadas do noyb, a DSB austríaca decidiu em 2022 que as transferências UE-EUA via Google Analytics violavam o Capítulo V, e as autoridades de proteção de dados da França, Itália, Dinamarca, Finlândia, Suécia e Noruega seguiram com o mesmo raciocínio. O endereço IP chegando aos servidores dos EUA já era suficiente.

Se o TJUE invalidar o DPF, essas decisões voltam a ser o modelo, da noite para o dia, para qualquer ferramenta que ainda roteie dados de visitantes da UE para os EUA.

Eliminando o risco pela arquitetura

Você não tem como tornar o DPF mais estável. O que você pode fazer é construir um fluxo de dados que não tenha exposição alguma ao Capítulo V desde o início. Duas propriedades resolvem isso:

Processar no edge, dentro da região. O Data Localization Suite da Cloudflare permite que um Worker confine o processamento e os logs a data centers da UE, de modo que a requisição nunca saia da região em que se originou. A decisão sobre onde os dados são tratados passa a ser configuração de infraestrutura, e não um instrumento jurídico que você torce para que sobreviva ao recurso.

Nunca persistir os insumos identificadores. O IP bruto e o User-Agent que tornam uma requisição "dados pessoais" existem apenas em memória pelo tempo suficiente para computar um hash diário de visitante, e então são descartados:

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

O que fica armazenado é o hash, não os insumos. Como o salt rotaciona diariamente e é secreto, o hash não pode ser revertido a um indivíduo nem cruzado entre dias. Não há perfil, e nada identificador jamais cruza uma fronteira porque nada identificador é jamais retido.

Você pode verificar a geografia do fluxo no próprio fio. Um beacon de pageview é uma única requisição a um endpoint próprio que você controla:

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

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

Se api.monoid.website resolver para nós de edge na UE e o Worker fixar seu armazenamento na UE, não há processador nos EUA no caminho, nenhuma decisão de adequação em que se apoiar e nenhuma transferência a declarar. O país do visitante continua chegando — derivado da própria geolocalização do edge, e não do envio do IP a um terceiro.

A postura de conformidade que isso produz

Uma transferência que você nunca faz é uma transferência que você nunca precisa defender. Não há DPF a citar no seu registro de operações de tratamento, nenhuma cláusula contratual-tipo a manter, nenhuma avaliação de impacto de transferência a refazer quando o fundamento jurídico mudar, e nenhum suboperador em um país terceiro a declarar sob as regras de transparência que os reguladores estão auditando em 2026.

Toda outra tarefa de conformidade em analytics é algo que você continua fazendo. Eliminar a transferência é algo que você faz uma vez, na arquitetura, e então para de pensar a respeito — independentemente de como o TJUE decidir o recurso.

Fontes

• Tribunal de Justiça da UE — Comunicado à imprensa: o Tribunal Geral rejeita a ação Latombe (Processo T-553/23)
• IAPP — Tribunal Geral europeu rejeita o questionamento de Latombe e confirma o Data Privacy Framework UE-EUA
• noyb — DSB austríaca: transferências de dados UE-EUA para o Google Analytics são ilegais
• noyb — Mais autoridades de proteção de dados da UE ordenam a suspensão do Google Analytics
• Cloudflare — Data Localization Suite