LGPD e dados de teste: guia completo pra devs brasileiros

A Lei nº 13.709/2018 (Lei Geral de Proteção de Dados) não distingue entre ambiente de produção, staging ou teste. Usar CPF real, email ou endereço de um cliente em sua máquina de desenvolvimento, em um servidor de teste ou em uma pipeline de CI/CD pode gerar uma multa de até R$50 milhões. Sério mesmo. A solução aceita pela Autoridade Nacional de Proteção de Dados (ANPD) é usar dados sintéticos — números gerados do zero que nunca foram pessoais — sem risco de re-identificação. Este guia mostra o quê, quando e como fazer isso de forma prática.

TL;DR — Resumo de decisão rápida

O que a LGPD diz sobre ambientes de teste

Vamos aos artigos:

• Art. 6º (Princípios): LGPD se aplica a qualquer operação de dados pessoais, em qualquer contexto. Não há exceção para "ambiente interno" ou "servidor de teste".
• Art. 12, § 2º (Anonimização): dados são anonimizados quando "não for possível associar o dado a um indivíduo por meio de esforço técnico viável na atividade ordinária" — ou seja, tecnicamente inviável re-identificar. Dados sintéticos atendem esse critério por definição.
• Art. 7º, IX (Consentimento): você pode processar dados pessoais sem consentimento quando necessário para "interesses legítimos do controlador". Mas "interesse legítimo" em teste não protege você de usar dados reais — a ANPD vai argumentar que poderia usar dados sintéticos.

O resumo: se você usa dados sintéticos (gerados do zero, sem qualquer vínculo com pessoas reais), nenhum artigo da LGPD se aplica. Se você copia dados de produção "mascara" campos, você ainda está operando com dados pessoais e continua sob LGPD — a pseudonimização é reversível e a lei considera isso um risco.

Anonimização vs Pseudonimização vs Dados Sintéticos

Essa diferença é crítica. Vejamos lado a lado:

A maioria dos times tenta pseudonimização ou anonimização fraca — e falha. Dados sintéticos é a abordagem que funciona sem margem pra erro.

Por que "copiar produção com mascaramento" não resolve

É a armadilha clássica. Seu DBA faz o seguinte:

-- Padrão comum (ERRADO)
CREATE TABLE staging_usuarios AS
SELECT
  id,
  CONCAT('User_', id) as name,  -- "mascarar"
  'fake@fake.com' as email,     -- "mascarar"
  SUBSTRING(cpf, 1, 3) || '.****.***-**' as cpf  -- "mascarar"
FROM production.usuarios;

-- Resultado:
-- id | name      | email           | cpf
-- 1  | User_1    | fake@fake.com   | 123.****.**-**
-- Seu DBA: "pronto, dados mascarados, seguro"
-- ANPD: "Você copiou dados reais de clientes. Risco alto."

O problema: você ainda tem o banco de produção inteiro acessível. Um de seus devs vê a coluna "name" original no backup, faz um linkage attack entre "User_1" e tabelas correlatas, e consegue re-identificar a pessoa. O CPF truncado? Também pode ser recuperado cruzando dados.

Casos reais: times brasileiros já tomaram multa por cópia de banco com "mascaramento" quando um auditor descobriu dados reais em backup de desenvolvimento.

Como implementar dados sintéticos no seu time

Passo 1: Escolher uma ferramenta LGPD-safe pra dados de desenvolvimento

As principais opções:

• FakeForge: brasileira, validação nativa CPF/CNPJ, PIX nos 4 formatos BACEN, CEP correlacionado. API ou SDK Python/Node. R$29/mês plano básico.
• Faker.py / Faker.js: open-source, localização Brasil, não tem validação algorítmica nativa — precisa configuração manual pra CPF correto.
• Mockaroo: internacional, sem suporte Brasil nativo, mas pode funcionar pra apps que não validam documentos.

Passo 2: Criar seed script pra popular banco local

Exemplo com FakeForge SDK (Node):

// seed.js - Popula banco de teste sem dados reais
import { FakeForge } from '@fakeforge/sdk';
import db from './db.js';

const forge = new FakeForge({ apiKey: process.env.FAKEFORGE_KEY });

async function seedDatabase() {
  console.log('Gerando 1000 usuários sintéticos...');

  const usuarios = await forge.generate('pessoa', {
    quantity: 1000,
    format: 'json'
  });

  console.log('Inserindo no banco de teste...');
  for (const usuario of usuarios.data) {
    await db.query(
      'INSERT INTO usuarios (cpf, name, email, telefone) VALUES ($1, $2, $3, $4)',
      [usuario.cpf, usuario.name, usuario.email, usuario.telefone]
    );
  }

  console.log('✓ 1000 usuários sintéticos criados. Zero risco LGPD.');
}

Passo 3: Integrar em CI/CD (GitHub Actions)

# .github/workflows/test.yml
name: Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm ci

      # Antes de rodar testes, popular banco com dados sintéticos
      - name: Seed test database
        run: |
          node scripts/seed.js
        env:
          FAKEFORGE_KEY: ${{ secrets.FAKEFORGE_KEY }}
          DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}

      - name: Run tests
        run: npm test

Resultado: a cada PR, seu banco de teste é populado com dados sintéticos válidos — CPF passa em checksum, CNPJ correlacionado por estado, sem qualquer vínculo com clientes reais.

Passo 4: Validar que dados sintéticos passam em regras de negócio

// Teste que confirma validação
test('CPF gerado passa em validador do backend', async () => {
  const forge = new FakeForge({ apiKey: process.env.FAKEFORGE_KEY });

  const { data } = await forge.generate('cpf', { quantity: 100 });

  for (const item of data) {
    // Simula validador do backend
    const isValid = validarCPF(item.cpf);
    expect(isValid).toBe(true);
  }
});

test('Endereço gerado tem CEP coerente com estado', async () => {
  const forge = new FakeForge();
  const { data } = await forge.generate('endereco', { quantity: 50, state: 'SP' });

  for (const item of data) {
    // CEP de SP começa com 0 ou 1
    expect(item.cep.substring(0, 1)).toMatch(/[01]/);
    expect(item.state).toBe('SP');
  }
});

Ferramentas LGPD-safe para dados de desenvolvimento

Aqui está a comparação das principais ferramentas:

Para times brasileiros que processam CPF/CNPJ, FakeForge economiza horas de configuração. Para times com data multinacional, Faker.js + validação manual de CPF é suficiente.

FAQ: Dúvidas comuns sobre LGPD em teste

Resumo: próximos passos

A conformidade LGPD em desenvolvimento não é palpite. Lei 13.709/2018 existe desde 2020 e a ANPD aumentou auditorias. Se seu time ainda copia banco de produção "mascarado", você tem um passivo de risco.

Dados sintéticos é a solução que funciona. Não é paliativo — é a abordagem que a ANPD recomenda (art. 12, § 2º) porque elimina o risco completamente. CPF gerado nunca foi pessoal. Email gerado nunca teve dono. CEP gerado é apenas número com coerência geográfica.

Sua próxima ação: escolha uma ferramenta (FakeForge pra pronto, Faker.py pra open-source), rode o seed script em seu pipeline de CI/CD, e documente: "Ambiente de teste usa dados sintéticos 100%". Pronto. Compliance confirmada.