Dados de Teste: Por Que Nunca Usar um CPF Real em Desenvolvimento

A cena é conhecida: o time precisa reproduzir um bug que só acontece "com dados de verdade", alguém restaura um backup de produção no ambiente de homologação e o problema é resolvido em vinte minutos. O custo dessa decisão só aparece meses depois — quando o banco de homologação, sem MFA, com senha compartilhada e acessível a todo mundo que já passou pelo time, vira a porta de entrada de um vazamento.

Este artigo é sobre por que essa prática é arriscada, o que a LGPD diz a respeito e o que fazer no lugar.

O que a LGPD exige (em três frases)

A Lei 13.709/2018 trata o CPF como dado pessoal: qualquer informação que identifique ou torne identificável uma pessoa natural. O tratamento desse dado — e "tratamento" inclui copiar, armazenar e usar em teste — precisa de base legal e de finalidade específica, além de respeitar os princípios de necessidade (o mínimo de dados para atingir o objetivo) e segurança.

Nada disso proíbe usar dados reais em desenvolvimento por decreto. O que acontece, na prática, é que é muito difícil justificar: a finalidade original do dado era executar um contrato com aquela pessoa, não popular a máquina de um desenvolvedor; e o princípio da necessidade derruba o argumento assim que existe uma alternativa que funciona igual — dados fictícios.

Por que homologação é o elo fraco

Ambientes que não são produção acumulam exatamente as características que um atacante procura:

• Controle de acesso frouxo. Senha única compartilhada, sem MFA, credencial no README, acesso mantido para quem já saiu do time.
• Menos monitoramento. Ninguém liga alerta de exfiltração em homologação.
• Cópias que se multiplicam. Dump no notebook para "investigar um bug", cópia no bucket para o time de dados, arquivo no chat da equipe.
• Integrações apontando para serviços de teste. E-mails de teste saindo para endereços reais, webhooks para sandboxes de terceiros.
• Logs verbosos. Ambientes não-produtivos costumam logar corpo de requisição inteiro — CPF incluído, agora também no seu agregador de logs e nos backups dele.

O dado é o mesmo de produção. A proteção, não.

"Mas a gente anonimiza"

Anonimizar de verdade é mais difícil do que parece, e três armadilhas aparecem sempre:

1. Mascarar não é anonimizar. Trocar 529.982.247-25 por 529.***.**7-25 mantém informação suficiente para reidentificar quando cruzado com outra base. A LGPD só considera anonimizado o dado que não pode ser revertido com esforço razoável.

2. O que identifica não é só o CPF. Nome + data de nascimento + CEP já identificam boa parte da população. Remover o campo "CPF" e manter o resto não resolve.

3. Anonimização quebra teste. Se você embaralha os dígitos, os CPFs param de passar na validação e o seu fluxo de cadastro falha — aí alguém desliga a validação em homologação e o teste deixa de testar justamente o que importa.

O caminho que evita as três é gerar dados fictícios que se comportam como reais: números que passam no dígito verificador, mas que não vieram de ninguém. É para isso que serve o Gerador de CPF e CNPJ.

Como montar uma massa de teste decente

Gere os documentos. CPFs e CNPJs válidos, em lote, com a máscara que o seu sistema espera. Se o seu produto separa clientes por região, gere CPFs de estados diferentes — o nono dígito indica a Região Fiscal do cadastro e dá realismo à distribuição.

Inclua o CNPJ alfanumérico. Desde julho de 2026 as inscrições novas podem ter letras. Se a sua massa de teste só tem CNPJ numérico, a primeira letra que chegar vai chegar em produção. Vale ler o que mudou no CNPJ alfanumérico antes de montar os casos.

Cubra os casos ruins de propósito. Documento com dígito errado, com caractere inválido, com tamanho errado, sequência repetida (111.111.111-11), campo vazio, número colado com espaços no começo e no fim. Um formulário que só foi testado com entrada perfeita não foi testado.

Use domínios reservados para e-mail. example.com, example.org e example.net existem exatamente para isso (RFC 2606) e nunca entregam mensagem a uma pessoa real.

Fixe uma semente. Se o gerador do seu time aceita seed, use-a: massa reproduzível transforma "falhou no CI e não consigo reproduzir" em um comando.

Versione a massa, não o dump. Um arquivo de fixtures no repositório é revisável, diffável e não contém dado de ninguém.

Quando o bug realmente só aparece com dados de produção

Acontece — e a resposta certa não é copiar o banco.

1. Reproduza o formato, não o conteúdo. Na maioria das vezes o que quebra é um caso de borda estrutural (nome com acento, endereço longo demais, CNPJ com letra, valor negativo). Escreva um fixture com essa característica.
2. Investigue em produção com acesso controlado. Consulta pontual, registrada em log, com a menor quantidade de dados possível, por quem tem autorização — é melhor do que uma cópia inteira em um ambiente frouxo.
3. Se copiar for inevitável, trate o ambiente como produção: mesmo controle de acesso, mesmo monitoramento, prazo de descarte definido e registro de quem autorizou. E reduza: copie a menor fatia que resolve.

Checklist rápido

• Nenhum dump de produção em máquina de desenvolvedor.
• Massa de teste gerada, versionada e com casos inválidos.
• CNPJ alfanumérico incluído nos casos.
• E-mails em example.com; telefones fictícios.
• Logs de ambientes não-produtivos sem corpo de requisição com dado pessoal.
• Acesso a homologação revisado quando alguém sai do time.

Nada disso é caro. O que é caro é descobrir, em uma notificação da ANPD ou em um post no fórum errado, que o CPF dos seus clientes estava em um banco de homologação que ninguém achava que importava.

Fontes

• Lei nº 13.709/2018 (LGPD) — art. 5º (dado pessoal e anonimizado), art. 6º (princípios de finalidade, necessidade e segurança) e art. 7º (bases legais).
• RFC 2606 — domínios reservados para documentação e teste (example.com e afins).
• Receita Federal — folheto de educação fiscal sobre o CPF (composição do número e Região Fiscal).