Como montar massa de teste sem violar a LGPD

Toda equipe de QA já passou por isso: falta massa de dados realista para testar uma tela nova, o prazo é curto, e alguém sugere "pega um dump do banco de produção, tira uns CPFs de exemplo e usa lá no homologação". Funciona no imediato. E é, ao mesmo tempo, uma das formas mais diretas de gerar um incidente de proteção de dados sob a LGPD — porque o problema não é copiar um CPF, é copiar as combinações que permitem reidentificar uma pessoa real fora do ambiente controlado de produção.

O que a LGPD realmente diz sobre dados de teste

A Lei 13.709/2018 não tem um artigo específico chamado "ambiente de homologação", mas o conceito que resolve esse problema já existe nela: anonimização. O Art. 12 estabelece que um dado tratado por meios técnicos razoáveis, de forma que não possa mais ser associado a um indivíduo, deixa de ser considerado dado pessoal — e, portanto, deixa de estar sob o guarda-chuva da lei. O detalhe que costuma passar despercebido é a palavra "razoáveis": não basta apagar o nome se o CPF, a data de nascimento e o CEP juntos ainda permitem cruzar a informação com outra fonte e chegar à pessoa.

Isso é diferente de pseudonimização (Art. 13), onde o dado é substituído por um identificador reversível através de uma chave guardada à parte — útil para relatórios internos, mas que ainda é tratado como dado pessoal pela lei, porque a reversão é possível. Ambiente de teste que usa pseudonimização em vez de dados sintéticos continua exigindo as mesmas bases legais, controles de acesso e registro de tratamento que a produção.

Três erros que aparecem o tempo todo

1. Mascarar só o campo "óbvio". É comum ver scripts de sanitização que substituem o CPF por zeros e acham que resolveram o problema, mas deixam nome completo, data de nascimento e cidade intactos. Essa combinação de três campos, sozinha, já é suficiente para reidentificar a maioria das pessoas em uma base de clientes — é o mesmo princípio por trás de vários estudos de "reidentificação" que derrubaram bases de dados supostamente anônimas nos Estados Unidos e na Europa.

2. Copiar produção inteira para "ambiente interno". Ambiente de homologação não é ambiente de produção com outro nome. Se o time de infraestrutura não aplica os mesmos controles de acesso, criptografia e log de auditoria no banco de staging que aplica em produção, qualquer dado pessoal real que esteja lá é um incidente em potencial — mesmo que "só a equipe interna" tenha acesso.

3. Usar e-mails e telefones reais em teste de carga. Este é o mais silencioso: ao rodar um teste de carga ou um script de regressão contra um ambiente mal isolado, é possível disparar e-mails transacionais reais (confirmação de cadastro, recuperação de senha, cobrança) para endereços de clientes verdadeiros. Isso não é só um problema de LGPD — é um vazamento operacional que o cliente percebe.

Massa sintética: o que muda na prática

A alternativa que resolve os três problemas ao mesmo tempo é simples de enunciar e um pouco mais trabalhosa de aplicar: nunca usar dado de uma pessoa real no ambiente de teste, e sim gerar dados fictícios que sejam estruturalmente equivalentes — mesmo formato, mesmas regras de validação, mesma coerência entre campos — sem corresponder a ninguém.

Coerência entre campos é o ponto que mais gera retrabalho quando é ignorado. Um CPF gerado aleatoriamente, sem relação com o CEP ou o DDD escolhidos para a mesma ficha, pode passar na validação de dígito verificador e mesmo assim derrubar uma regra de negócio que cruza esses campos (por exemplo, uma verificação de risco que compara a Região Fiscal do CPF com o estado do endereço de entrega). O Gerador de Pessoas deste site resolve isso sincronizando CEP, DDD e Região Fiscal do CPF automaticamente ao escolher um estado — mas o princípio vale independente da ferramenta usada: dado sintético só é útil se for coerente o bastante para não gerar falso negativo.

Checklist rápido antes de montar sua próxima massa de teste

• Nenhum dado de cliente real (nem mascarado, nem "só para uso interno") sai do ambiente de produção.
• CPF, CNPJ e cartão de teste são gerados por algoritmo, não por amostragem de uma base real.
• Campos relacionados (endereço, DDD, documento) são coerentes entre si para não mascarar bugs reais atrás de uma rejeição por inconsistência regional.
• E-mails de teste usam um domínio que você controla (ex: @teste.suaempresa.com), nunca endereços reais.
• Se algum dado pseudonimizado precisar circular (ex: para depuração de um bug específico em produção), ele fica sob os mesmos controles de acesso e retenção que qualquer dado pessoal, com base legal registrada.

Nenhuma dessas práticas exige ferramenta paga ou processo complexo — exige, principalmente, tirar o hábito de "pegar emprestado" um pedaço de produção quando falta tempo. As calculadoras de CPF, CNPJ e cartão de teste deste site cobrem a parte de gerar números estruturalmente válidos; a parte de manter a disciplina de nunca usar dado real no ambiente errado é do time.