# Anonimização ou pseudonimização na LGPD: qual usar e quando

> Anonimização ou pseudonimização? Veja quando o dado deixa de ser pessoal para a LGPD, onde cada técnica entra no sistema e como usar dados em testes e BI.

Fonte: https://pervian.tech/blog/anonimizacao-ou-pseudonimizacao · Pervian Tech · publicado em 2026-10-01

A conversa costuma começar com uma frase tranquilizadora: "pode ficar sossegado, os dados estão anonimizados". Quando alguém olha de perto, o CPF foi trocado por um código, o nome sumiu, mas existe uma tabela em algum lugar que liga cada código à pessoa. Isso não é anonimização. É pseudonimização, e para a LGPD a diferença muda tudo: um dado continua sendo pessoal, o outro deixa de ser.

Os dois termos aparecem em contratos e propostas como sinônimos, e não são. Escolher errado leva a dois problemas opostos: tratar como livre um dado que a lei ainda protege, ou destruir uma ligação que a empresa vai precisar mais tarde. Este texto mostra o que a lei diz e onde cada técnica entra no sistema.

**Resposta curta:** decida pelo uso que o dado ainda vai ter. Anonimize quando a empresa não precisa mais saber quem é a pessoa, como em estatística, BI agregado e bases de teste, e aceita perder essa ligação para sempre. Pseudonimize quando o dado precisa ser religado ao titular em algum momento, sabendo que ele continua sendo dado pessoal e continua sujeito a todas as regras da LGPD.

## O que a LGPD diz sobre dado anonimizado e pseudonimizado

A Lei 13.709/2018 (art. 5º) define dado anonimizado como aquele relativo a um titular que não pode ser identificado, considerando os meios técnicos razoáveis e disponíveis no momento do tratamento. E o art. 12 diz algo decisivo: dado anonimizado não é considerado dado pessoal, a menos que o processo seja revertido com meios próprios ou possa ser revertido com esforços razoáveis.

Dois pontos dessa definição merecem atenção:

- **"Meios razoáveis" não é um padrão fixo.** A lei leva em conta custo, tempo e tecnologia disponível. Uma base que era segura contra reidentificação há alguns anos pode deixar de ser quando surgem novas fontes de dados públicas para cruzar.
- **Reversível com esforço razoável significa dado pessoal.** Se alguém da própria empresa, ou um parceiro, consegue religar o registro à pessoa sem esforço extraordinário, a base nunca saiu do escopo da lei.
- **Perfil de comportamento também conta.** A lei avisa que dados usados para formar o perfil comportamental de uma pessoa identificada podem ser tratados como dados pessoais. Um "cliente 4821" com todo o histórico de compras, horários e preferências, que o CRM sabe quem é, não está anonimizado.

A pseudonimização aparece na LGPD de forma mais discreta, no art. 13, que trata de estudos em saúde pública, descrita como o tratamento em que o dado perde a possibilidade de associação, direta ou indireta, com o indivíduo, exceto pelo uso de uma informação adicional mantida separadamente pelo controlador, em ambiente controlado e seguro. A leitura prática é simples: existe uma chave. Quem tem a chave religa o dado à pessoa. Por isso o dado pseudonimizado continua sendo pessoal.

Isso não quer dizer que pseudonimizar seja inútil. É uma medida de segurança importante, que reduz o estrago de um vazamento e limita quem enxerga a identidade. Só não tira o dado do alcance da lei. Finalidade, base legal, direitos do titular e prazos de guarda continuam valendo. Para ver como esses deveres viram requisitos técnicos, veja [LGPD no software: o que o sistema precisa fazer](https://pervian.tech/blog/lgpd-no-desenvolvimento-de-sistemas).

A lei também dá ao titular o direito de pedir a anonimização de dados desnecessários ou excessivos (art. 18) e permite conservar, após o fim do tratamento, dados anonimizados para uso exclusivo do controlador (art. 16). E prevê que a ANPD defina padrões e técnicas de anonimização; vale acompanhar as orientações da autoridade e revisar as práticas quando elas mudarem.

## Anonimização: técnicas e o risco de reidentificação

Anonimizar não é apagar a coluna de nome. O risco real está nos chamados quase identificadores: campos que, sozinhos, não apontam ninguém, mas que combinados apontam. Data de nascimento, CEP e sexo juntos, por exemplo, podem reduzir um grupo a uma única pessoa em uma cidade pequena. Cargo e filial podem identificar o único gerente daquela unidade.

As técnicas mais usadas, em linguagem simples:

- **Supressão.** Remover campos que identificam direta ou indiretamente: nome, CPF, e-mail, telefone, endereço completo.
- **Generalização.** Trocar o valor exato por uma faixa: idade vira faixa etária, CEP vira região, data de nascimento vira ano, valor exato vira intervalo.
- **Agregação.** Publicar totais e médias em vez de linhas individuais, e não mostrar grupos pequenos demais (o total de uma categoria com dois clientes revela os dois).
- **Perturbação.** Adicionar ruído controlado aos números, mantendo o comportamento estatístico do conjunto.
- **Dados sintéticos.** Gerar registros fictícios que imitam a estrutura e a distribuição da base real, sem corresponder a nenhuma pessoa. Cuidado com geradores que copiam casos raros quase idênticos ao original: o cliente atípico continua reconhecível.

### O teste que importa

Antes de chamar uma base de anonimizada, pergunte: com o que mais existe dentro e fora da empresa, alguém consegue descobrir quem é esta linha? Se a resposta for "talvez", trate como dado pessoal. Dois erros são frequentes:

- **Hash simples de CPF ou e-mail.** Parece irreversível, mas o universo de CPFs é finito e conhecido. Quem tem tempo de processamento calcula o hash de todos e compara. Sem um segredo adicional, isso é, no máximo, uma pseudonimização fraca.
- **Texto livre esquecido.** O campo "observações" do atendimento cita o nome do cliente, o telefone do filho, o endereço da entrega. A coluna de nome foi removida, mas a pessoa continua ali.

A anonimização bem feita também é a saída para guardar dados depois que a finalidade original acabou, sem manter informação pessoal além do prazo. Esse caminho aparece em [retenção e descarte de dados pessoais](https://pervian.tech/blog/retencao-e-descarte-de-dados-pessoais), junto com a tabela de prazos e o cuidado com backups.

## Pseudonimização: tokens, chaves e quem pode religar

Na pseudonimização, o identificador real é substituído por outro valor, e a ligação entre os dois fica guardada em separado. As formas mais comuns:

- **Tokenização.** Cada pessoa recebe um código aleatório, e a correspondência fica num cofre de tokens isolado, com acesso restrito. O resto do sistema só conhece o token.
- **Hash com segredo.** Uma função de hash combinada com uma chave secreta. O mesmo CPF gera sempre o mesmo código, o que permite cruzar bases, mas sem a chave não dá para refazer o cálculo. A chave precisa ficar fora do código e do banco, como explicamos em [gestão de segredos](https://pervian.tech/blog/senhas-e-chaves-de-api-no-codigo).
- **Criptografia.** O dado é cifrado e pode ser decifrado por quem tem a chave. Serve quando alguns processos precisam do valor original de volta. Na variante determinística, o mesmo valor gera sempre o mesmo texto cifrado, o que permite busca e cruzamento, ao custo de revelar quando dois registros são iguais.

A pergunta central da pseudonimização não é técnica, é de governança: **quem pode religar, quando e com registro de quê.** Um desenho saudável tem estas características:

1. **Separação física e lógica.** O cofre de tokens ou a chave fica em outro ambiente, com credenciais diferentes das usadas pela aplicação e pelo time de dados.
2. **Religação como operação explícita.** Desfazer o pseudônimo é uma função específica, chamada por um processo autorizado, nunca uma consulta livre ao banco.
3. **Trilha de auditoria.** Cada religação fica registrada: quem, quando, qual registro e por qual motivo. Detalhamos esse controle em [perfis de acesso e trilha de auditoria](https://pervian.tech/blog/controle-de-acesso-e-trilha-de-auditoria).
4. **Rotação.** Se a chave vazar, é preciso trocá-la sem reescrever o sistema. Com hash com segredo, trocar a chave muda todos os pseudônimos; planeje desde o início como versionar a chave e recalcular os códigos nas bases que dependem deles.

Um caso em que a solução pronta é a melhor escolha: cartão de pagamento. Gateways costumam oferecer tokenização do cartão como parte do serviço. Usar esse recurso, em vez de guardar o número no próprio banco, tira muito risco e exigência de conformidade da empresa. Confirme com o fornecedor como o recurso funciona no seu contrato atual.

## Bases de teste e homologação com dados reais

Aqui mora um dos riscos mais comuns em empresas médias. Para reproduzir um erro, alguém copia o banco de produção para o ambiente de homologação. Esse ambiente costuma ter senhas mais fracas, mais gente com acesso, fornecedores externos e menos monitoramento. Uma cópia integral leva todos os dados pessoais para o lugar menos protegido da empresa.

O caminho recomendado depende do tipo de teste:

- **Teste funcional do dia a dia.** Dados sintéticos ou base anonimizada resolvem. Ninguém precisa do CPF verdadeiro para testar se a tela de pedido calcula o frete certo.
- **Reprodução de um problema específico.** Copie só o recorte necessário e aplique mascaramento: nome trocado, documento gerado com dígito válido mas falso, e-mail apontando para um domínio de teste. Assim nenhum e-mail ou SMS de homologação chega a um cliente real.
- **Teste de integração com bases que precisam cruzar.** Pseudonimização com hash com segredo mantém a consistência entre tabelas (o mesmo cliente tem o mesmo código em pedidos e em financeiro) sem expor a identidade.

O ideal é que a geração da base de teste seja um processo automatizado, não um script improvisado. Existem ferramentas de mercado para mascaramento e dados sintéticos, e alguns bancos e serviços de nuvem têm mascaramento nativo. Quando atendem ao seu cenário, usá-los é mais sensato do que construir do zero; confirme os recursos atuais com o fornecedor. A separação dos ambientes em si está em [ambiente de homologação e produção: por que separar](https://pervian.tech/blog/ambientes-de-homologacao-e-producao).

## BI, relatórios e compartilhamento com parceiros

No BI, a pergunta é se a análise precisa chegar ao indivíduo.

**Análise agregada.** Vendas por região, ticket médio por faixa etária, churn por plano. Aqui a anonimização costuma ser a escolha certa: generalize os campos, agregue, e o data warehouse deixa de concentrar dados pessoais sem necessidade, quase sem perder valor analítico.

**Análise que precisa voltar à pessoa.** Campanha de reativação, lista de cobrança, acompanhamento de paciente. Pseudonimize no ambiente analítico e religue só no sistema operacional, com quem tem permissão. O analista trabalha com o código; o relacionamento recebe a lista final com nome.

Na arquitetura, a carga do data warehouse já aplica a transformação no caminho: identificadores viram tokens ou somem, quase identificadores são generalizados. O tema da base analítica em si está em [data warehouse para empresa média: por onde começar](https://pervian.tech/blog/data-warehouse-para-empresas-medias).

**Compartilhamento com parceiros.** Para estudo ou estatística, envie dado anonimizado ou agregado. Para cruzar com a base do parceiro, use pseudonimização com segredo combinado em contrato, sabendo que os dois lados continuam tratando dado pessoal. Se o parceiro executa um serviço em nome da empresa, ele é operador e o contrato precisa refletir isso.

## Tabela comparativa: anonimização x pseudonimização x criptografia

A criptografia entra na comparação porque é frequentemente confundida com as outras duas. Ela protege o dado em repouso e em trânsito, mas quem acessa a aplicação vê o valor original.

| Critério | Anonimização | Pseudonimização | Criptografia |
|---|---|---|---|
| É reversível? | Não, por definição | Sim, com a informação adicional | Sim, com a chave |
| Continua sendo dado pessoal na LGPD? | Não, se a reidentificação não for razoável | Sim | Sim |
| Objetivo principal | Usar o dado sem identificar ninguém | Limitar quem enxerga a identidade | Proteger contra acesso indevido ao armazenamento ou à rede |
| Uso típico | BI agregado, estatística, base de teste, guarda após a finalidade | Ambiente analítico, integração entre bases, pesquisa com acompanhamento | Banco, backups, arquivos, comunicação entre sistemas |
| Permite voltar ao titular? | Não | Sim, por processo controlado | Sim, para quem tem a chave |
| Maior risco | Reidentificação por cruzamento | Vazamento da chave ou do cofre de tokens | Chave guardada junto com o dado |
| Atende pedido de exclusão do titular? | Em vários casos, sim: a lei permite conservar dado anonimizado para uso exclusivo do controlador | Não por si só | Não por si só |

As três não competem. Um sistema bem desenhado costuma usar criptografia em toda a base, pseudonimização no ambiente analítico e anonimização nos relatórios públicos, na base de teste e nos dados guardados após o prazo.

## Quando escolher cada uma

**Escolha anonimização quando:**

- A pergunta que o dado responde é sobre grupos, não sobre pessoas.
- A base vai para homologação, testes, treinamento de equipe ou demonstração comercial.
- O prazo de guarda do dado pessoal terminou, mas a série histórica ainda tem valor estatístico.
- O dado vai sair da empresa para estudo ou divulgação.

**Escolha pseudonimização quando:**

- O dado precisa ser religado ao titular depois: cobrança, campanha, atendimento, acompanhamento de saúde.
- Duas bases precisam ser cruzadas pelo mesmo indivíduo sem expor o documento.
- O time de dados precisa trabalhar no nível da linha, mas não precisa saber quem é cada um.
- O titular pode exercer direitos (acesso, correção, exclusão) e o sistema precisa localizar todos os registros dele.

**Prefira uma solução pronta quando:**

- O dado sensível é cartão de pagamento e o gateway oferece tokenização.
- O banco de dados ou a nuvem já tem mascaramento nativo que cobre o seu caso de teste.
- Uma ferramenta de mascaramento de mercado se conecta às suas bases sem adaptação pesada.

**Construa sob medida quando:**

- A regra de quem pode religar depende da estrutura da operação (filial, função, contrato).
- A carga do data warehouse precisa aplicar transformações diferentes por finalidade.
- Os dados vêm de sistemas legados ou integrações sem recurso nativo de mascaramento, e a transformação precisa acontecer no meio do caminho.

**Sinal de alerta:** se alguém diz "anonimizado" e existe uma tabela de correspondência guardada em algum lugar, trate como pseudonimizado até prova em contrário.

## Perguntas frequentes

### Dado anonimizado precisa seguir a LGPD?

Não, desde que a anonimização não possa ser revertida com esforços razoáveis. O art. 12 da LGPD diz que dado anonimizado não é considerado dado pessoal, salvo quando o processo é revertido com meios próprios ou pode ser revertido com esforço razoável. Se existe tabela de correspondência, o dado é pseudonimizado e a lei continua valendo.

### Criptografar o dado é o mesmo que anonimizar?

Não. Criptografia protege o dado armazenado e em trânsito contra acesso indevido, mas quem tem a chave recupera o valor original, então o dado continua pessoal para a LGPD. Anonimização remove de forma irreversível a possibilidade de identificar a pessoa. Um sistema bem desenhado costuma usar as duas técnicas, em pontos diferentes.

### Hash de CPF é anonimização?

Não. Como o universo de CPFs é finito e conhecido, quem tem tempo de processamento calcula o hash de todos e compara, revertendo o processo. Hash simples de CPF ou e-mail é, no máximo, pseudonimização fraca. Com uma chave secreta guardada fora do código e do banco, vira pseudonimização adequada, mas o dado continua pessoal.

### Anonimizar os dados atende ao pedido de exclusão do titular?

Em vários casos, sim. A LGPD permite conservar dado anonimizado para uso exclusivo do controlador depois do fim do tratamento, o que preserva séries históricas sem manter informação pessoal. Pseudonimização ou criptografia, por si só, não atendem ao pedido de exclusão. Situações específicas, como dados de saúde, devem ser validadas com o jurídico ou o encarregado.

## Como a Pervian Tech ajuda a decidir e a proteger os dados no sistema

Começamos mapeando onde os dados pessoais circulam: banco, integrações, ambiente de teste, data warehouse, exportações e parceiros. Para cada fluxo, definimos se o dado precisa voltar à pessoa, e daí sai a técnica certa. Esse desenho faz parte do nosso trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software).

O diagnóstico inicial é gratuito. Quando um recurso pronto resolve, como a tokenização do gateway ou o mascaramento nativo do banco, recomendamos e ajudamos a configurar. Quando a regra é específica da operação, construímos o cofre de tokens, a carga analítica com transformação e a geração automatizada de bases de teste dentro do sistema. O investimento é definido sob consulta, depois de entender o volume de dados e as integrações envolvidas.

Para outros temas de proteção de dados, veja os textos da categoria [segurança e LGPD](https://pervian.tech/blog/categoria/seguranca-e-lgpd). E se a sua homologação ainda roda com uma cópia do banco de produção, [fale com a gente](https://pervian.tech/#contato).