Anonimização vs Pseudonimização LGPD: guia prático para devs

A LGPD trata dado anonimizado e dado pseudonimizado de forma radicalmente diferente, e essa diferença determina se o seu sistema precisa de base legal para processar a informação ou não. Muitos times tratam os dois conceitos como sinônimos e acabam com compliance superficial que não resistiria a uma auditoria da ANPD.

---

O que a LGPD diz sobre dado anonimizado e dado pseudonimizado

Definição legal de dado anonimizado (LGPD Art. 5º, III)

O Art. 5º, III define dado anonimizado como "dado relativo a titular que não possa ser identificado, considerando a utilização de meios técnicos razoáveis e disponíveis na ocasião de seu tratamento". A consequência prática está no Art. 12: dado verdadeiramente anonimizado sai do escopo da lei e não exige base legal, consentimento nem DPO responsável por ele.

Definição legal de dado pseudonimizado (LGPD Art. 5º, XI)

O Art. 5º, XI define dado pseudonimizado como "tratamento por meio do qual um dado perde a possibilidade de associação, direta ou indireta, a um indivíduo, senão pelo uso de informação adicional mantida separadamente pelo controlador em ambiente controlado e seguro". O titular ainda existe, a re-identificação é possível com a chave certa.

Por que a distinção importa: dado anonimizado sai do escopo da lei, pseudonimizado não

Pseudonimização é uma medida de segurança, não uma saída do regime da LGPD. Um CPF tokenizado com HMAC ainda é dado pessoal porque o controlador detém o segredo. Isso significa base legal obrigatória, direitos do titular aplicáveis e prazo de retenção a justificar.

---

Critérios técnicos que a ANPD usa para avaliar anonimização

Irreversibilidade como requisito central

A ANPD, nas suas Orientações sobre Anonimização (2023), adota o critério de irreversibilidade técnica com meios razoavelmente disponíveis. "Razoavelmente disponíveis" é deliberadamente vago: o avaliador considera o estado da arte no momento da auditoria, não no momento do desenvolvimento.

Os três testes práticos: singling out, linkability, inference

A ANPD segue metodologia alinhada ao Art. 29 WP216 da autoridade europeia. Os três testes são:

• Singling out: é possível isolar um registro específico do dataset?
• Linkability: é possível correlacionar dois registros distintos referentes ao mesmo indivíduo?
• Inference: é possível deduzir atributos sensíveis de um titular a partir dos dados disponíveis?

Se qualquer um dos três passar, o dado não está devidamente anonimizado.

Quando a ANPD pode reclassificar um "dado anonimizado" como pessoal

A reclassificação ocorre quando o controlador detém dados auxiliares (outros datasets, chaves, logs) que, combinados, permitem re-identificação. Um CEP completo + data de nascimento + sexo identifica cerca de 87% das pessoas nos EUA segundo estudo de Latanya Sweeney (Carnegie Mellon, 2000); o cenário brasileiro é comparável dado o desequilíbrio populacional entre municípios.

---

Técnicas de anonimização aplicáveis em sistemas brasileiros

Generalização e supressão de atributos

Generalização reduz a precisão de um atributo. CEP 01310-100 vira 01310-000 (suprime os últimos três dígitos). Data de nascimento 1990-03-15 vira 1990 (só o ano). Supressão remove o atributo por completo quando a generalização ainda permite inferência.

Perturbação estatística

Adiciona ruído aleatório a valores numéricos dentro de um intervalo que preserva utilidade analítica. Renda de R$ 4.800 pode virar R$ 4.650 ou R$ 5.100, mas o quartil permanece o mesmo. Útil para analytics de BI onde a tendência importa mais que o valor exato.

Agregação

Substitui registros individuais por estatísticas de grupo. Em vez de linha por linha com CPF, o dataset exibe "1.240 transações PIX entre R$ 100 e R$ 500 na região Sudeste em março/2025". Nenhum titular é rastreável.

k-anonimato, l-diversity e t-closeness

---

Técnicas de pseudonimização e onde cada uma se encaixa

Tokenização determinística com HMAC-SHA256

Produz sempre o mesmo token para o mesmo dado com o mesmo segredo. Útil para joins cross-sistema sem expor o CPF original. O risco: dois sistemas com o mesmo segredo podem correlacionar tokens.

Tokenização com vault

Token aleatório (UUID v4) mapeado para o dado real em banco separado. Re-identificação exige acesso explícito ao vault. Mais seguro que HMAC determinístico, porém joins cross-sistema exigem chamada ao vault.

Cifragem com chave segregada (AES-256-GCM)

O dado original é cifrado e armazenado. A chave fica em HSM ou KMS separado (AWS KMS, Google Cloud KMS). Reversível com autorização, auditável, rotação de chave viável sem migrar dados.

Hashing com salt por registro vs salt global

Salt global é vulnerável a ataques de dicionário se o segredo vazar: o atacante computa hashes de todos os CPFs válidos (aproximadamente 230 milhões de combinações) e cruza com o dataset. Salt por registro elimina o ataque de dicionário mas torna joins impossíveis sem descriptografar primeiro.

AVISO: Nunca use MD5 ou SHA-1 sem salt para pseudonimizar CPF. As funções são rápidas demais: hardware comum computa bilhões de hashes por segundo, tornando força bruta trivial contra o espaço de CPFs válidos.

---

Implementação em TypeScript: pseudonimização de CPF e e-mail

Tokenização de CPF com HMAC-SHA256

import { createHmac } from "node:crypto";

const SECRET = process.env.PSEUDONYM_SECRET;
if (!SECRET) throw new Error("PSEUDONYM_SECRET não definido");

export function tokenizeCpf(cpf: string): string {
  const digits = cpf.replace(/\D/g, "");
  return createHmac("sha256", SECRET).update(digits).digest("hex");
}

// Uso:
// tokenizeCpf("123.456.789-09") → "a3f9c1..." (64 chars hex, determinístico)

O token tem 64 caracteres hexadecimais, não carrega estrutura de CPF e não permite reversão sem o segredo. Para validar se um CPF gerado ainda passa no algoritmo da Receita Federal, use o validador antes de tokenizar, não depois.

Mascaramento reversível de e-mail para logs de suporte

export function maskEmail(email: string): string {
  const [local, domain] = email.split("@");
  if (!local || !domain) return "***@***";
  const visible = local.slice(0, 2);
  return `${visible}${"*".repeat(Math.max(local.length - 2, 3))}@${domain}`;
}

// maskEmail("joao.silva@gmail.com") → "jo*********@gmail.com"

Esse mascaramento é suficiente para logs de suporte onde o agente precisa confirmar o domínio mas não o usuário completo. Não é reversível sem o dado original.

Estrutura de vault mínimo com PostgreSQL

CREATE TABLE tokens (
  token        VARCHAR(36)  PRIMARY KEY DEFAULT gen_random_uuid()::text,
  encrypted_value BYTEA     NOT NULL,
  key_id       VARCHAR(64)  NOT NULL,
  created_at   TIMESTAMPTZ  NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_tokens_created_at ON tokens (created_at);

encrypted_value armazena o dado cifrado com AES-256-GCM. key_id referencia a versão de chave no KMS, viabilizando rotação sem migrar linhas.

---

Implementação em TypeScript: anonimização de dataset de teste

Pipeline de anonimização para fixtures de banco

import { parse } from "csv-parse/sync";
import { stringify } from "csv-stringify/sync";
import { createHmac, randomBytes } from "node:crypto";
import { readFileSync, writeFileSync } from "node:fs";

const SECRET = randomBytes(32).toString("hex"); // efêmero por execução

function anonymizeRow(row: Record<string, string>) {
  return {
    ...row,
    cpf: createHmac("sha256", SECRET).update(row.cpf ?? "").digest("hex").slice(0, 11),
    email: row.email ? `user_${Math.floor(Math.random() * 1e6)}@example.com` : "",
    nome: `Usuário ${Math.floor(Math.random() * 1e5)}`,
    cep: row.cep ? row.cep.slice(0, 5) + "-000" : "",
  };
}

const input = parse(readFileSync("dump_prod.csv"), { columns: true });
const output = input.map(anonymizeRow);
writeFileSync("fixture_sanitized.csv", stringify(output, { header: true }));

Geração de dados fictícios como alternativa à anonimização

Para muitos cenários de teste, gerar dados estruturalmente válidos do zero é mais simples e mais seguro do que anonimizar um dump de produção. A API do FakeForge entrega datasets prontos:

const response = await fetch(
  "https://fakeforge.com.br/api/generate?type=pessoa&quantity=500&format=json"
);
const pessoas = await response.json();
// Cada objeto tem nome, CPF, e-mail, telefone, endereço — todos fictícios e válidos

Esse dataset de pessoas fictícias estruturalmente correto passa em validadores de CPF, tem DDDs válidos e CEPs coerentes com o estado gerado. Para CPFs gerados com dígitos verificadores corretos, o gerador usa o mesmo algoritmo mod-11 da Receita Federal.

Quando usar um gerador em vez de anonimizar produção

Use dados gerados quando o objetivo é testar lógica de negócio (validação, formatação, fluxos de pagamento). Use anonimização quando o objetivo é testar com a distribuição real dos seus dados (modelos de ML, análises de coorte, performance com volume real).

---

Ambientes de desenvolvimento e staging: o risco do dump de produção

Por que copiar produção para dev viola a LGPD mesmo internamente

O acesso de um dev ao banco de staging com dados reais configura tratamento de dado pessoal. Exige base legal (art. 7º), necessidade demonstrável e medidas de segurança proporcionais. A finalidade de desenvolvimento raramente é compatível com a finalidade original de coleta, conflitando com o princípio da finalidade do Art. 6º, I.

Fluxo seguro: pipeline de sanitização antes do restore

# Pipeline exemplo: dump → sanitiza → restore
pg_dump prod_db | python sanitize_pii.py | psql staging_db

O script sanitize_pii.py (ou equivalente TypeScript) executa o pipeline do exemplo anterior antes de qualquer byte chegar ao ambiente não-produtivo.

Dados gerados vs dados anonimizados: qual exige menos manutenção

Dados anonimizados exigem re-execução do pipeline a cada refresh do staging, auditorias periódicas para confirmar que novas colunas PII foram incluídas no processo e testes de re-identificação documentados. Dados gerados via API exigem apenas manter o script de seed atualizado com os tipos de dados necessários. Para volumes maiores em pipelines de CI/CD, o plano de API cobre chamadas em batch.

---

Casos de uso práticos e qual técnica aplicar

Logs de aplicação

Pseudonimize identificadores em logs de aplicação (CPF, e-mail, telefone). Onde o dado não é necessário para diagnóstico, anonimize ou não registre. Logs com dado pessoal bruto são o vetor mais comum de vazamento acidental.

Analytics e BI interno

Use agregação e generalização. O analista precisa de tendências, não de registros individuais. CEP de 5 dígitos + faixa etária de 10 anos é suficiente para análise demográfica e reduz drasticamente o risco de re-identificação.

Compartilhamento com terceiros (LGPD Art. 7º, IX)

O Art. 7º, IX exige legítimo interesse como base legal para compartilhamento. Antes de enviar qualquer dataset a parceiros, aplique k-anonimato (k >= 5) e documente no contrato de processamento quais atributos foram suprimidos ou generalizados.

Treinamento de modelos de ML

K-anonimato reduz utilidade para ML em datasets pequenos. Para volume acima de 100 mil registros, dados sintéticos gerados a partir da distribuição real (via CTGAN, por exemplo) preservam utilidade estatística sem expor nenhum titular.

---

Armadilhas comuns que transformam pseudonimização em dado identificável

Re-identificação por combinação de quasi-identificadores

CEP + data de nascimento + sexo combinados identificam indivíduos mesmo sem CPF. Esses atributos são quasi-identificadores: individualmente inócuos, combinados tornam o registro único no dataset.

Logs que gravam o dado original junto com o token

Um sistema que registra cpf_original=123.456.789-09 token=a3f9c1... no log de auditoria invalidou a pseudonimização. O token e o original estão no mesmo arquivo, acessível a qualquer pessoa com leitura de log.

DICA: Revise os campos logados em frameworks de observabilidade (Datadog, New Relic, OpenTelemetry). Muitos SDKs serializam o objeto de request completo por padrão. Configure blocklists explícitas para campos PII antes de ativar tracing automático.

Salt global compartilhado entre ambientes

Um salt idêntico em produção e staging permite que um atacante com acesso a staging derive tokens de produção. Segredos de pseudonimização devem ser únicos por ambiente e rotacionados quando qualquer pessoa com acesso ao ambiente for desligada.

---

Documentação e evidência para auditoria da ANPD

O que registrar no RIPD

O Relatório de Impacto à Proteção de Dados deve documentar: qual técnica foi aplicada, quais atributos foram tratados, qual o resultado dos três testes (singling out, linkability, inference) e quem é responsável pela chave de pseudonimização ou pelo processo de anonimização.

Testes de re-identificação como prova de eficácia

Execute tentativas de re-identificação com os dados auxiliares que o controlador possui (outros datasets, logs, registros de CRM) e documente o resultado. Se a re-identificação falhar mesmo com esses meios, registre o experimento como evidência de anonimização eficaz.

Retenção mínima de chaves de pseudonimização

Mantenha chaves pelo tempo necessário ao exercício de direitos do titular (retificação, exclusão, portabilidade). Após o término da finalidade de tratamento, destrua as chaves com procedimento auditável. Sem a chave, o dado pseudonimizado se torna anonimizado de fato.

---

Resumo

• Dado anonimizado sai do escopo da LGPD; dado pseudonimizado não. A distinção é técnica e avaliada pela ANPD com os testes de singling out, linkability e inference.
• HMAC-SHA256 com salt por ambiente é o ponto de partida para pseudonimização de CPF e e-mail em logs e bancos de dados. Salt global é vulnerável a ataques de dicionário.
• Nunca copie dump de produção para staging sem pipeline de sanitização. O acesso de dev a dados reais configura tratamento sem base legal compatível com a finalidade original.
• Para fixtures de teste e dados de desenvolvimento, dados gerados são mais seguros e de menor manutenção que dados anonimizados. O FakeForge gera datasets com CPFs, pessoas e endereços válidos prontos para CI/CD.
• Documente no RIPD a técnica usada, os atributos tratados e os resultados dos testes de re-identificação. Ausência de documentação é, sozinha, fundamento para sanção administrativa.
• Chaves de pseudonimização únicas por ambiente e rotação programada são requisitos mínimos. Compartilhar o mesmo segredo entre produção e staging invalida o isolamento.

---

Leitura complementar: documentação da API para integrar geração de dados no pipeline de CI, outros artigos sobre LGPD e boas práticas, e o guia oficial da ANPD sobre anonimização.