# Hashing Não É Anonimização

> Uma lista de clientes com hash parece segura de compartilhar. Os reguladores europeus – e a aritmética – discordam. O que o SHA-256 protege e o que não protege.

- Source: https://www.8apps.co/pt/blog/hashing-nao-e-anonimizacao
- Markdown: https://www.8apps.co/pt/blog/hashing-nao-e-anonimizacao.md
- Published: 2026-09-02
- Author: Equipe 8apps
- Language: pt

---
## 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](/pt/google-workspace/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](https://gdpr-info.eu/recitals/no-26/) – lido em 02/09/2026
- [Diretrizes 01/2025 do EDPB sobre Pseudonimização](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en) – lido em 02/09/2026
- [Serpro – Anonimização e pseudonimização são o suficiente?](https://www.serpro.gov.br/lgpd/noticias/2019/anonimizacao-pseudonimizacao-dados-suficientes-adequar-lgpd) – lido em 03/09/2026