Dados sintéticos para testar chatbot sem expor clientes

Dados sintéticos para testar chatbot sem expor clientes

Para testar um chatbot sem expor clientes, crie cadastros e conversas fictícias que imitam a estrutura, os erros e os casos difíceis do atendimento real, mas não contêm nenhuma pessoa de verdade. O caminho é listar as situações que o agente enfrenta, gerar dados inventados com regras claras e marcar cada registro como sintético. Assim a equipe avalia e homologa o agente de forma repetível, e os dados reais ficam fora do ambiente de teste.

Principais pontos

• Dado sintético bom copia o formato e a dificuldade do atendimento real, não a identidade de ninguém.
• Comece pelo mapa de situações do processo (pedidos, dúvidas, reclamações, exceções) e só depois gere os registros.
• Cadastros fictícios precisam de regras de consistência: datas, status, valores e histórico que façam sentido entre si.
• Todo registro de teste deve ser identificável como fictício, para nunca ser confundido com cliente real nem receber mensagem de verdade.
• Antes de homologar, verifique se o conjunto não carrega dado real escondido, como trechos copiados de conversas antigas.

Por que não usar conversas reais de clientes nos testes?

O caminho mais rápido para montar um conjunto de avaliação é exportar o histórico do WhatsApp e usar como está. É também o mais arriscado. Uma conversa real traz nome, telefone, endereço, documento, foto de comprovante e, muitas vezes, informações sensíveis que o cliente mencionou sem perceber, como um problema de saúde que justifica um atraso.

Pela LGPD, esses dados foram coletados para uma finalidade, normalmente o atendimento. Reaproveitá-los para treinar, avaliar ou demonstrar um sistema é outro uso, e precisa de base legal e de transparência com o titular. Mesmo quando a empresa acredita ter essa base, o teste costuma envolver mais gente e mais ferramentas do que o atendimento original: desenvolvedores, fornecedores, plataformas de avaliação e, muitas vezes, um provedor de modelo de linguagem fora do Brasil. Vale ler como funciona a transferência internacional de dados com IA e o que a LGPD exige antes de enviar qualquer conversa real para um serviço externo.

Há ainda um motivo prático: dado real é ruim para teste. Ele é desbalanceado (muitas perguntas fáceis, poucos casos raros), difícil de reproduzir e muda toda vez que alguém atualiza a base. Dado sintético permite fabricar justamente os casos que quase não aparecem, mas que causam o maior estrago quando o agente erra.

O que um conjunto de dados sintéticos para chatbot precisa ter?

Um bom conjunto tem três camadas, e cada uma responde a uma pergunta diferente.

• Cadastros: quem é o cliente fictício, o que ele comprou, em que status está o pedido, o contrato ou o atendimento.
• Conversas: como esse cliente escreve, com abreviações, áudio transcrito, erros de digitação e mensagens picotadas.
• Gabaritos: o que o agente deveria fazer em cada caso (responder, perguntar, recusar ou transferir para uma pessoa) e quais informações são proibidas de aparecer.

A terceira camada é a que mais se esquece. Sem gabarito, você tem apenas um monte de texto bonito e nenhum jeito de dizer se o agente passou ou falhou. A documentação sobre avaliações da OpenAI (guia de evals) e o texto da Anthropic sobre como avaliar agentes de IA tratam exatamente dessa ideia: casos de teste com critérios de sucesso definidos de antemão, executados de forma repetida.

Como criar cadastros fictícios realistas, passo a passo?

O plano abaixo funciona para qualquer agente de atendimento, seja de pedidos, agendamento, pós-venda ou suporte. A ordem importa.

• Passo um: mapeie o processo. Liste os tipos de pedido que chegam, os sistemas consultados (ERP, CRM, agenda, planilha) e os campos que o agente lê ou altera.
• Passo dois: defina o esquema do cadastro. Use os mesmos campos e formatos do sistema real, incluindo os campos mal preenchidos que existem na vida real, como complemento vazio ou telefone sem DDD.
• Passo três: crie perfis de cliente, não pessoas. Por exemplo: cliente recorrente com histórico longo, cliente novo sem histórico, cliente com dois cadastros duplicados, cliente inadimplente, cliente que escreve em nome de outra pessoa.
• Passo quatro: gere os identificadores com regras seguras. Use e-mails em domínios reservados para exemplo, como example.com, e telefones de uma faixa que sua equipe controla ou de um número de sandbox do provedor, nunca números sorteados que possam pertencer a alguém.
• Passo cinco: trate CPF e CNPJ com cuidado. Documentos com dígitos verificadores válidos podem coincidir com os de pessoas reais. Quando o teste não depende da validação, prefira um padrão claramente fictício; quando depende, use um gerador de documentos de teste e registre que a lista é sintética.
• Passo seis: garanta consistência interna. Data de compra anterior à data de reclamação, valor do pedido coerente com os itens, status compatível com o histórico. Incoerência gratuita faz o agente falhar por motivos que não existem no mundo real.
• Passo sete: marque tudo como fictício. Um campo de origem, um prefixo no nome ou uma tag no cadastro basta, desde que qualquer pessoa ou sistema consiga distinguir teste de produção.
• Passo oito: separe os ambientes. O cadastro sintético vive em um ambiente de homologação com suas próprias credenciais, sem acesso à base real e sem canal de envio para clientes de verdade.

Um detalhe sobre nomes: evite combinar nome e sobrenome comuns com cidade e profissão específicas demais, porque o resultado pode, por acaso, descrever uma pessoa existente. Misture partes de forma deliberada e prefira perfis genéricos.

Como escrever conversas fictícias que se parecem com WhatsApp de verdade?

O erro mais comum é gerar diálogos educados e completos, em que o cliente explica tudo na primeira mensagem. Ninguém escreve assim. O conjunto de teste precisa refletir como o canal é usado de fato.

• Mensagens curtas e quebradas em várias partes, com a informação principal na terceira mensagem.
• Erros de digitação, abreviações e ausência de acento.
• Áudios transcritos, com hesitações e frases sem fim.
• Fotos e documentos descritos em texto quando o teste não precisa da imagem.
• Mudança de assunto no meio da conversa e perguntas em que o cliente já mudou de ideia.
• Pedidos fora do escopo, tentativas de obter dado de outro cliente e mensagens agressivas.

Uma forma eficiente de produzir esse volume é pedir a um modelo de linguagem que gere variações a partir de cenários que você escreveu, sempre sem fornecer conversas reais como exemplo. Revise uma amostra à mão: modelos tendem a produzir texto limpo demais e a repetir os mesmos nomes. Se precisar manter o processo todo dentro da empresa, um modelo local, como no caso do Ollama, pode gerar as variações sem enviar nada para fora.

Inclua, em proporção deliberada, os casos de borda: o cliente que pede o desconto que ninguém autorizou, o que tenta fazer o agente ignorar as regras, o que pede dado de terceiros. A lista de ataques de injeção de prompt do OWASP é uma boa fonte de ideias para esses cenários.

Cenário ilustrativo: homologar um agente de pós-venda

Imagine, como exemplo inventado, uma loja que vende eletrodomésticos e quer um agente no WhatsApp para informar status de entrega e abrir pedidos de troca. O agente consulta um sistema de pedidos e só pode abrir a troca quando o pedido está dentro do prazo da política.

A equipe define cinco perfis fictícios: comprador com entrega em andamento, comprador com entrega atrasada, comprador fora do prazo de troca, comprador que escreve em nome da mãe e comprador com dois pedidos misturados. Para cada perfil, cria o cadastro e o pedido no ambiente de homologação, com e-mail em domínio de exemplo e telefone de sandbox.

Depois escreve três ou quatro conversas por perfil, com mensagens picotadas e um caso de pressão (o cliente insiste em trocar fora do prazo). O gabarito diz: no caso fora do prazo, o agente não abre a troca e transfere para uma pessoa com o resumo; no caso de quem escreve em nome da mãe, o agente não revela dados do pedido sem confirmar a identidade.

O resultado do teste não é uma nota única. É uma lista de falhas por tipo: respondeu errado, agiu sem permissão, deixou de transferir, vazou campo. Essa lista orienta o ajuste do prompt, das regras e das proteções de entrada e saída do agente.

Como garantir que o conjunto sintético não contém dado real?

Dado sintético pode falhar de duas formas: ser irreal demais para ensinar algo, ou ser real demais e carregar uma pessoa de verdade. A segunda é a que causa problema jurídico. A LGPD considera dado anonimizado fora do seu alcance apenas quando a anonimização é de fato irreversível com meios razoáveis. Trocar o nome por um apelido e manter o resto não é anonimizar, é pseudonimizar, e o dado continua pessoal. Para orientação oficial, consulte a página da ANPD.

Use esta checklist antes de liberar o conjunto para a equipe e para fornecedores:

• Nenhum registro foi copiado de conversa, e-mail ou planilha de cliente, nem com edição parcial.
• Os exemplos usados para gerar variações também eram inventados.
• Telefones e e-mails não pertencem a pessoas reais e não enviam mensagem para fora.
• Documentos e endereços são fictícios ou de listas de teste identificadas.
• Fotos, comprovantes e PDFs de teste foram criados do zero, sem metadados de arquivos reais.
• Há um responsável que revisou uma amostra e registrou a data e o critério da revisão.
• O ambiente de homologação não tem credencial com acesso à base de produção.

Se, mesmo assim, algum caso só puder ser reproduzido com dado real, trate como exceção: o menor trecho possível, acesso restrito, finalidade registrada e descarte depois do teste. Quem monitora o uso de ferramentas de IA na equipe também deve cuidar para que isso não vire vigilância sobre pessoas, como discutimos em medir produtividade com IA sem virar vigilância.

Como o método mapear, limitar, pilotar e transferir se aplica?

Os dados sintéticos entram em cada etapa do método, sem exigir nada especial.

Mapear: o processo atual vira a lista de situações e o esquema de cadastro. Sem esse mapa, o conjunto de teste reflete o que a equipe imagina, não o que acontece.

Limitar: o agente de homologação recebe apenas dados fictícios e permissões mínimas. O que ele pode ler e fazer no teste é o que se pretende permitir na operação.

Pilotar: o conjunto sintético serve de base para avaliações repetidas antes e durante o piloto. Quando o piloto começa com um fluxo real, os registros e as métricas acordadas passam a ser acompanhados com logs. Para estruturar isso, veja como medir um piloto de automação com IA.

Transferir: na entrega, o conjunto de casos, os gabaritos e a regra para criar novos registros ficam com a equipe do cliente, para que ela consiga reavaliar o agente depois de cada mudança de regra, de produto ou de modelo. A decisão final é expandir, ajustar ou parar, com base nas falhas que os testes mostraram.

Perguntas frequentes

Dados sintéticos são tão bons quanto dados reais para testar um chatbot? Para a maior parte dos testes de comportamento, sim, desde que reproduzam o formato, a bagunça e os casos difíceis do atendimento. Eles são até melhores para casos raros, porque você os fabrica sob demanda. O que dado sintético não mostra é a distribuição real de perguntas, então vale complementar com a observação do piloto, com dados tratados conforme a LGPD.

Posso usar um modelo de linguagem para gerar as conversas fictícias? Pode, e é uma forma comum de ganhar volume. Forneça cenários e regras escritos por você, não conversas reais, e revise uma amostra para evitar texto limpo demais e nomes repetidos. Se a política da empresa restringe o envio de dados para fora, use um modelo local.

Um CPF ou telefone gerado aleatoriamente é seguro para usar? Nem sempre. Um número com formato válido pode pertencer a uma pessoa real, e um telefone sorteado pode receber mensagem de verdade. Prefira domínios de e-mail reservados para exemplo, números de sandbox e identificadores claramente fictícios, e só use documentos válidos quando o teste depender da validação.

Quando devo atualizar o conjunto de testes? Sempre que mudar uma regra de negócio, um produto, um fluxo de transferência ou o modelo usado pelo agente. Também vale incluir um novo caso a cada falha encontrada na operação, transformando o erro real em um cenário fictício equivalente, sem copiar a conversa original.

Fontes

• OpenAI: guia de evals
• Anthropic: Demystifying evals for AI agents
• OWASP Top 10 for LLM Applications
• ANPD: Autoridade Nacional de Proteção de Dados