A crença confortável
Aplique hash nos e-mails, aplique hash nos telefones, e a lista está "anonimizada" – segura para enviar por e-mail, segura para entregar a uma agência, fora do alcance das regras de privacidade. Essa crença sustenta muita coisa em muitos times de marketing. E ela está errada, tanto na frente regulatória quanto na matemática.
O que os reguladores realmente dizem
O GDPR resolve isso no Considerando 26: "Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person." As Diretrizes 01/2025 sobre Pseudonimização do Comitê Europeu de Proteção de Dados (EDPB), adotadas em janeiro de 2025, partem exatamente desse ponto.
Hashing é pseudonimização – uma transformação que pode ser desfeita por quem tiver as informações adicionais certas. Nesse enquadramento, dados de clientes com hash continuam sendo dados pessoais. Não é uma zona cinzenta: a frase citada é o enquadramento.
E no Brasil, a LGPD
Se você trata dados de titulares no Brasil, é a LGPD que responde pela sua lista. Ela traça a mesma linha de fundo: dados efetivamente anonimizados não são considerados dados pessoais para os fins da lei. O que a LGPD não tem é uma frase equivalente ao Considerando 26 do GDPR sobre pseudonimização – então onde exatamente cai uma lista com hash é uma pergunta para o seu jurídico, não algo que este texto decida por você. O que não muda é a parte prática abaixo: o arquivo com hash continua sendo um arquivo de clientes, e a aritmética não pergunta sob qual lei você está.
O que a aritmética diz
Um hash criptográfico não pode ser revertido algebricamente – até aí a crença confortável está correta. Mas números de telefone não precisam ser revertidos; precisam ser adivinhados. Um plano nacional de numeração é um espaço pequeno para os padrões computacionais atuais: aplique hash em todos os números plausíveis, compare com a lista, pronto. Isso não é um ataque teórico; é uma tabela de consulta.
O mesmo raciocínio vale, com ainda mais força, para o CPF: o conjunto de números válidos é finito e enumerável, então uma coluna de CPFs com hash é um ataque de dicionário, não um segredo.
E-mails resistem um pouco mais – o espaço é maior e mais irregular –, mas endereços conhecidos são verificados na hora: qualquer pessoa que tenha jane@example.com pode aplicar hash e testar a presença dela no seu arquivo "anônimo". A falha silenciosa é a revelação de participação: a lista entrega quem está nela a qualquer um que já conheça as pessoas.
Por que você não pode simplesmente adicionar salt
O reforço padrão – salting, adicionar um valor secreto antes do hash – é exatamente o que a correspondência das plataformas de anúncios não tolera. A correspondência funciona porque os dois lados aplicam hash na mesma entrada da mesma forma; um salt que só você conhece produz digests que só você consegue produzir, e nada corresponde. O hashing para upload é sem salt por projeto, o que significa que ele carrega permanentemente as fraquezas acima. (A questão completa entre com e sem salt tem um guia próprio.)
Então trate uma lista com hash pelo que ela é
- Controle o acesso como faria com a lista bruta – mesmas permissões de pasta, mesmas regras de compartilhamento.
- Aplique o hash e destrua o rastro de trabalho: copie a coluna com hash, cole como valores, exclua a coluna bruta de qualquer arquivo que circule.
- Compartilhe o arquivo com hash deliberadamente, sob os mesmos acordos que o arquivo bruto exigiria – não casualmente porque "está com hash".
- Mantenha arquivos brutos e com hash separados – uma planilha com as duas colunas lado a lado é a tabela de consulta, já pronta.
Onde o Hash Data se encaixa
Nada disso é um argumento contra o hashing – as plataformas exigem, e manter PII bruta fora dos arquivos de upload é estritamente melhor que a alternativa. É um argumento para fazer isso de olhos abertos. O Hash Data aplica o hash dentro do Google Planilhas, então a transformação acontece na planilha que você já controla, e não em uma ferramenta web onde você cola dados de clientes.
Fontes
- GDPR Considerando 26 – Não aplicável a dados anônimos – lido em 02/09/2026
- Diretrizes 01/2025 do EDPB sobre Pseudonimização – lido em 02/09/2026
- Serpro – Anonimização e pseudonimização são o suficiente? – lido em 03/09/2026