"É só copiar o banco de produção para o ambiente de testes." A frase é tentadora, porque dados reais têm todos os casos estranhos que um sistema encontra na vida real. Mas ela transforma o ambiente de desenvolvimento, normalmente menos protegido, num segundo lugar onde dados pessoais de clientes ficam guardados. Este guia explica por que isso é um problema, o que a LGPD tem a dizer e quais alternativas funcionam bem no dia a dia.
Este texto é material técnico de apoio e não substitui a orientação de um profissional de direito ou do encarregado de proteção de dados da sua empresa.
Por que dados de produção em testes são arriscados
- Superfície de ataque maior: ambientes de teste costumam ter senhas fracas, acessos compartilhados, backups soltos e menos monitoramento que a produção.
- Vazamento por acidente: dumps enviados por e-mail ou chat, notebooks de desenvolvedores, capturas de tela em tickets e logs com dados reais espalham informação para lugares que ninguém controla.
- Efeitos colaterais reais: um teste que dispara e-mail, SMS ou cobrança usando contatos verdadeiros afeta pessoas de verdade.
- Acesso além do necessário: quem só precisava testar uma tela passa a enxergar dados de milhares de clientes.
O que a LGPD tem a ver com isso
A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) define dado pessoal como a informação relacionada a uma pessoa natural identificada ou identificável (art. 5º, I). CPF, nome, e-mail, endereço e telefone entram nessa definição. Alguns pontos da lei ajudam a pensar no tema:
- Finalidade e necessidade (art. 6º): o tratamento deve ter propósito legítimo e se limitar ao mínimo necessário. Para testar um formulário, raramente é necessário usar os dados de clientes reais.
- Segurança (art. 6º e art. 46): quem trata dados deve adotar medidas técnicas e administrativas para protegê-los, inclusive contra acessos não autorizados. Isso vale para qualquer ambiente onde os dados estejam, não só para a produção.
- Anonimização (art. 12): dados efetivamente anonimizados deixam de ser considerados dados pessoais, a menos que o processo possa ser revertido com esforços razoáveis. Por isso, "mascarar" só com uma troca simples e reversível não resolve.
As alternativas, da mais simples à mais robusta
1. Dados sintéticos gerados por algoritmo
Em vez de reaproveitar registros, gere registros novos que respeitem o formato: nomes fictícios, CPFs e CNPJs com dígito verificador correto, endereços e telefones plausíveis. Para formulários e validações isso é suficiente. O gerador de pessoas monta um cadastro completo, e o gerador de dataset em massa entrega centenas de linhas em CSV, JSON ou SQL para popular um banco de testes. Quem precisa gerar dados direto do código pode usar a API.
2. Mascaramento e anonimização de uma cópia
Quando é indispensável manter a forma dos dados reais (volumes, distribuições, relacionamentos), copie o banco e substitua os campos sensíveis antes de a cópia sair do ambiente de produção. Troque nomes, documentos e contatos por valores fictícios coerentes, mantendo as chaves de relacionamento. Pseudonimizar (trocar por um código que ainda pode ser ligado de volta à pessoa) é diferente de anonimizar; se a ligação existir em algum lugar, os dados continuam sendo pessoais.
3. Ambientes de sandbox de terceiros
Para pagamentos, e-mail e outras integrações, use os ambientes de teste oferecidos pelos próprios provedores, com números de cartão e contas de teste documentados por eles. Nunca use o número de um cartão real para testar. Para cartões de teste que passam na validação de formato, veja o gerador de cartão de crédito de teste e o guia Algoritmo de Luhn passo a passo.
Um cuidado que muita gente esquece
Um CPF gerado por algoritmo é apenas um número que passa na conta do dígito verificador. Como o espaço de números possíveis é limitado (um bilhão de combinações de nove dígitos de base) e uma fração grande dele já foi emitida, um CPF gerado ao acaso pode, por coincidência, pertencer a uma pessoa real. Por isso, números gerados servem para testar validações e telas, mas nunca para enviar mensagens, abrir cadastros em sistemas de terceiros, fazer consultas em órgãos ou qualquer coisa que alcance o mundo real. Para entender por que "válido" não significa "existente", leia Dígito verificador: o que é e o que ele não prova.
Checklist rápido para o seu time
- Separe ambientes: produção, homologação e desenvolvimento não compartilham banco nem credenciais.
- Proíba dumps de produção fora da produção sem tratamento prévio.
- Use dados sintéticos por padrão e mascare somente quando houver motivo claro.
- Desative envios reais (e-mail, SMS, webhooks) nos ambientes de teste ou aponte-os para caixas de captura.
- Não registre dados pessoais em logs; se for inevitável, mascare-os na origem.
- Limite quem acessa o quê e revise os acessos periodicamente.
- Documente onde os dados de teste vêm e por quanto tempo ficam guardados.