- Dados sintéticos não são mágica: se você copiar demais o real, pode reidentificar; se simplificar demais, seu teste fica inútil.
- O foco é manter padrões (formatos, distribuições e relações) sem carregar identidades.
- Use dados sintéticos para testes, homologação, simulações e exemplos; dados reais devem ficar em sandbox com controles e necessidade comprovada.
- Documente: objetivo, método, risco residual e quem aprovou (compliance/segurança).
1) Defina o cenário de teste (e o que a IA precisa aprender/validar)
Escreva em uma frase o que você quer testar: por exemplo, “classificar tickets”, “responder dúvidas a partir de uma base”, “extrair campos de um contrato”. A partir disso, liste quais campos são indispensáveis (ex.: tipo de solicitação, produto, canal, data, prioridade) e quais são supérfluos (nome completo, CPF, endereço). Quanto menos dado pessoal, menor o risco.
2) Mapeie campos e classifique risco (PII, sensível, interno)
Monte uma planilha com colunas: campo, tipo (texto, data, número), exemplo de formato, fonte (se existe em produção), e risco. Marque explicitamente dados pessoais (identificadores diretos como CPF/e-mail; indiretos como cargo+unidade; e dados sensíveis). Se você não precisa do campo para o teste, corte agora — é o ganho mais barato.
3) Escolha a estratégia de síntese (regras, amostragem ou modelo)
Para a maioria das PMEs, regras + amostragem controlada resolve. Regras: gerar datas plausíveis, CEPs fictícios válidos no formato, telefones com máscara, valores com faixas reais. Amostragem: usar listas genéricas (nomes comuns, bairros) sem vincular a pessoas reais. Modelos gerativos podem ajudar em textos longos (descrições), mas exigem cuidado para não “memorizar” exemplos reais se você usar dados de produção como base.
4) Preserve relações sem preservar identidades
O dado sintético precisa manter coerência. Exemplos: pedidos têm itens; tickets têm status em sequência; clientes têm histórico. Crie chaves internas artificiais (ID_Cliente_Sintetico) e regras de consistência (um mesmo ID reaparece em registros relacionados), mas nunca use chaves reais nem hashes reversíveis de identificadores reais.
5) Gere textos sintéticos com “guardrails” (para não vazar PII)
Se você vai gerar campos de texto (motivo do chamado, observações, resumo médico, descrição de caso), defina um template e proíba PII: “não inclua nomes, e-mails, documentos, endereços, números de cartão, placas”. Depois, rode uma checagem: procure padrões (regex) de CPF, e-mail, telefone e endereços. Se aparecer, descarte e regenere.
6) Valide utilidade (o teste fica de pé?)
Antes de comemorar, execute os testes que motivaram o dataset: sua automação consegue classificar? o chatbot consegue responder? o RAG consegue recuperar documentos? Se a performance cair porque o conjunto ficou artificial demais, ajuste regras (mais variedade de casos, mais ruído realista, mais exceções). O objetivo não é parecer perfeito — é estressar o sistema.
7) Avalie risco de reidentificação (o dataset ‘entrega’ alguém?)
Procure combinações raras: “cidade pequena + data específica + condição” pode identificar alguém mesmo sem nome. Se você começou de um recorte real, atenção dobrada. Quando tiver dúvida, generalize (faixas etárias em vez de data completa, região em vez de bairro, arredondamento de valores) e reduza granularidade.
8) Documente e controle acesso como se ainda fosse sensível
Dados sintéticos reduzem risco, mas não viram ‘terra sem lei’. Registre: finalidade, como foi gerado, quais campos foram excluídos, quais validações foram feitas, e quem aprovou. Guarde em repositório com acesso mínimo, versionamento e prazo de retenção.
Quando dados sintéticos fazem diferença (e quando não resolvem)
Eles brilham em: testes de prompts e fluxos, demonstrações para time interno, treinamento de operadores, validação de integrações (CRM/ERP/Helpdesk), e criação de massa para QA.
Eles não resolvem sozinhos quando você precisa de fidelidade estatística muito alta (por exemplo, modelagem preditiva com sinal fraco) ou quando o risco está no conteúdo da base (documentos reais com PII). Nesse caso, além de síntese, você precisa de governança, sandbox e controles de acesso.
- Bom uso: simular 500 tickets com categorias e exceções para calibrar uma triagem automática.
- Uso arriscado: gerar “casos clínicos” baseados em descrições reais sem remover detalhes únicos (pode reidentificar).
- Uso inútil: criar dados perfeitos, sem erros e sem casos raros — seu sistema passa no teste e quebra na vida real.
Checklist rápido do que NÃO colocar em dados sintéticos
Regra prática: se a informação ajuda a reconhecer uma pessoa (direta ou indiretamente) e não é essencial ao teste, ela deve sair.
| Categoria | Exemplos | Alternativa segura para teste |
|---|---|---|
| Identificadores diretos | CPF, RG, e-mail real, telefone real, nome completo | Gerar valores fictícios no formato (máscara/regex) e nomes genéricos não associados a pessoas reais |
| Localização detalhada | Endereço completo, apartamento, ponto de referência | Cidade/região, ou endereços inventados sem correspondência real |
| Dados sensíveis | Saúde, religião, biometria, filiação sindical, dados de crianças | Criar categorias amplas ou cenários genéricos; reduzir granularidade e evitar combinações raras |
| Chaves e IDs de sistemas | ID de cliente, número de pedido, matrícula | Criar IDs sintéticos sem relação com a sequência/ID real |
Modelo de especificação (mini-brief) para gerar um dataset sintético
Copie e cole este modelo no seu documento interno. Ele evita o erro comum de “gerar um monte de linhas” sem critério e depois descobrir que não serve para nada.
- Objetivo do teste: (ex.: validar triagem automática de chamados do WhatsApp para 5 filas).
- Campos mínimos: (ex.: canal, categoria, subcategoria, urgência, texto_curto, data_abertura, status).
- Restrições: (proibido PII; proibido dados sensíveis; sem nomes reais; sem endereços reais).
- Regras de realismo: (ex.: 60% dúvidas, 25% reclamações, 15% cancelamentos; status deve seguir ordem).
- Casos extremos: (ex.: mensagem agressiva, mensagem muito curta, mensagens duplicadas, horário fora do expediente).
- Validações: (regex de e-mail/CPF/telefone; busca por strings proibidas; revisão humana por amostra).
- Responsáveis e aprovação: (nome do dono do processo + compliance/segurança).
Perguntas frequentes
Dados sintéticos são a mesma coisa que dados anonimizados?
Se eu gerar dados sintéticos com IA, ainda posso vazar informação real?
Dá para usar dados sintéticos para testar um chatbot com base de conhecimento (RAG)?
O que eu preciso documentar para justificar o uso de dados sintéticos internamente?
Leia também
Como anonimizar dados para usar IA no negócio (sem tropeçar na LGPD)
Passo a passo para anonimizar e pseudonimizar dados antes de enviar para IA: o que remover, como mascarar, checklist de risco e exemplos práticos para usar no dia a dia com mais segurança.
Ler →
Como criar uma sandbox de IA na empresa (sem vazar dados): guia prático
Passo a passo para criar uma sandbox de IA: ambiente de testes com dados anonimizados, regras de acesso, logs, prompts seguros e critérios de aprovação antes de escalar para produção.
Ler →
Como auditar prompts e logs de IA (sem paranoia): reduza vazamento de dados e risco na LGPD
Guia prático para auditar prompts, históricos e logs de ferramentas de IA: o que revisar, como anonimizar, quem aprova, o que guardar e por quanto tempo — com checklist e FAQ.
Ler →
Como criar uma base de conhecimento para chatbot sem vazar dados (guia prático)
Aprenda a montar uma base de conhecimento para chatbot com controle de acesso, limpeza de arquivos, RAG, testes anti-alucinação e governança — sem expor dados sensíveis.
Ler →