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

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.

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, 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.
• 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.
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.

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.

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.

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.

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. E se a sua homologação ainda roda com uma cópia do banco de produção, fale com a gente.