Quando um Hash É Dado Pessoal? A Decisão SRB do TJUE e a Identidade em Analytics

A pergunta que todo fornecedor de analytics evita é simples de fazer e difícil de responder: o identificador no seu banco de dados é dado pessoal? Em 4 de setembro de 2025 o TJUE deu a resposta mais relevante dos últimos anos, e reformulou todo o teste em torno do contexto, e não do dado isolado.

O que o EDPS v SRB de fato decidiu

O caso — EDPS v SRB, C-413/23 P — surgiu da resolução do Banco Popular. O Single Resolution Board coletou comentários de acionistas, substituiu a identidade de cada autor por um código alfanumérico e enviou os comentários codificados à Deloitte como avaliadora independente. A Deloitte não tinha chave para reverter os códigos e nenhuma outra via até os autores.

O TJUE entendeu que dados pseudonimizados não são automaticamente dados pessoais para toda parte que os manipula. Se um conjunto de dados é pessoal se avalia em relação a quem o detém — a partir da posição do destinatário específico, considerando os meios técnicos, organizacionais e jurídicos realisticamente disponíveis a ele.

Este é o teste da identificabilidade relativa (ou contextual), e é a leitura operativa do "meios razoavelmente suscetíveis de serem utilizados" do Considerando 26. Um dado pessoal nas mãos do controlador pode ser não pessoal nas mãos de um destinatário que genuinamente não consegue reidentificar ninguém.

A tensão com o EDPB

O tribunal não deu carta branca aos fornecedores. As Diretrizes 01/2025 do EDPB sobre pseudonimização adotam uma linha deliberadamente mais rígida: dados pseudonimizados continuam sendo dados pessoais enquanto qualquer pessoa — o controlador ou algum terceiro — mantiver os meios de reidentificar. O relatório do EDPB de fevereiro de 2026 sobre anonimização e pseudonimização é a tentativa do conselho de resolver exatamente essa lacuna entre sua posição e a do tribunal.

Para quem desenvolve, a leitura prática é conservadora. Não presuma que um valor com hash está fora do escopo do GDPR só porque o seu serviço não consegue revertê-lo. A pergunta certa é se a reidentificação é razoavelmente provável para quem detém a informação adicional — e se essa informação adicional ainda existe.

Por que a maioria dos hashes de analytics falha no teste

Aplicar hash a um identificador não é anonimização. Um SHA-256 de um endereço de e-mail é determinístico: o mesmo e-mail sempre produz o mesmo digest. Quem tiver uma lista de e-mails candidatos pode aplicar hash neles e cruzar. O hash é uma chave estável e vinculável — pseudonimização, na melhor das hipóteses, e dado pessoal sob qualquer leitura, porque os meios de reidentificar estão trivialmente disponíveis.

A mesma armadilha pega um IP com hash, um ID de dispositivo com hash, ou qualquer digest de uma entrada vinda de um espaço pequeno e enumerável. Determinismo mais entrada adivinhável é igual a reidentificação. A função de hash muda os bytes, não a vinculabilidade.

O que torna um hash genuinamente defensável

Duas propriedades movem um hash de "dado pessoal pseudonimizado" para "não razoavelmente reidentificável": um salt secreto que nunca é armazenado junto com o dado, e uma entrada que não pode ser adivinhada exaustivamente e não persiste ao longo do tempo. O modelo de identidade do Monoid é construído exatamente sobre isso:

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

O IP e o User-Agent brutos vivem apenas na memória do Worker pelo tempo necessário para computar o digest; o D1 armazena o hash, nunca as entradas. O SALT_SECRET é mantido no servidor e nunca gravado ao lado do dado, então um ataque de rainbow table ou força bruta contra os hashes armazenados não tem âncora. E como a data é uma entrada, o digest do mesmo visitante rotaciona toda meia-noite UTC. Não há chave estável entre dias para correlacionar.

Passe essa construção pelos dois testes. Sob o padrão relativo do TJUE, nenhum destinatário dos hashes armazenados — inclusive o Monoid consultando seu próprio D1 — detém os meios razoavelmente suscetíveis de reidentificar, porque o salt está segregado e a entrada é não enumerável. Sob o padrão mais rígido do "qualquer pessoa" do EDPB, a informação adicional necessária (IP bruto mais UA mais o salt secreto daquela data específica) não é retida em lugar nenhum depois que a requisição termina. Os meios de reidentificar não são apenas restritos; eles deixam de existir.

Como auditar sua própria stack

A decisão dá um checklist concreto para aplicar a qualquer analytics em que você confia:

• A entrada com hash é enumerável? Um e-mail, um telefone ou um IP bruto podem ter hash aplicado e ser cruzados com uma lista de candidatos. Se o espaço de entrada é pequeno, o hash é reversível na prática.
• Há um salt secreto segregado do dado armazenado? Um hash sem salt, ou com salt no mesmo repositório, não oferece barreira real à reidentificação.
• O identificador persiste entre sessões? Uma chave estável que vincula a atividade de uma pessoa ao longo de semanas é dado pessoal sob qualquer leitura. Uma chave que rotaciona diariamente não consegue acumular um perfil.

O TJUE não declarou a pseudonimização um porto seguro, e o EDPB está garantindo que ninguém a leia assim. A posição durável é a que não precisa de nenhuma interpretação para vencer: um hash com salt, rotacionado diariamente, sobre uma entrada não enumerável não é razoavelmente reidentificável por ninguém, porque o material necessário para revertê-lo nunca foi guardado.

Fontes

• Acórdão do TJUE no Processo C-413/23 P, EDPS contra CUR (4 de setembro de 2025)
• Diretrizes 01/2025 do EDPB sobre Pseudonimização
• Relatório do EDPB sobre o evento com partes interessadas sobre anonimização e pseudonimização de 12 de dezembro de 2025
• Considerando 26 do RGPD — Não aplicável a dados anônimos