A IA escreveu o raciocínio dela dentro do campo de CNPJ. O que aprendi com um agente de WhatsApp em produção.

Por Fernando Sugiyama · 6 de outubro de 2026· 6 min de leitura

Num teste do meu agente de atendimento, o campo de CNPJ do CRM veio assim: uma frase em que o modelo conversava consigo mesmo sobre como montar um esquema de dados para uma empresa fictícia.

Não era CNPJ. Era o raciocínio interno dele, escrito num campo que alguém do comercial ia ler.

Foi aí que entendi o que eu estava construindo. Não era um chat. Era uma fonte de dados que escreve no sistema da empresa. E fonte de dados, eu não deixo escrever sem conferir.

Este texto conta o que aprendi colocando em produção um agente de WhatsApp que qualifica lead para uma das minhas empresas, a Hutz, e-commerce de iluminação e neon. Vale para qualquer empresa que vai ligar IA a um sistema.

O que o agente faz

O lead chega de uma página de anúncio e manda mensagem no WhatsApp. O agente conversa, descobre o que a pessoa quer (descrição, quantidade, prazo, tamanho, cor) e, na hora certa, passa o lead para um humano com um briefing pronto. Também lê a imagem que o cliente manda, como uma arte ou um logo, e cruza com a conversa.

Ele só responde quem veio de uma página de anúncio. Quem chega por outro caminho não é tocado.

A memória já existia

A primeira versão estava “completamente burra”, palavras minhas. O cliente dizia que queria para dez lojas de uma rede. Dois turnos depois o agente perguntava quantas unidades e de qual logo.

A causa era simples. Cada mensagem era uma chamada isolada, sem histórico. A única coisa estável que o modelo via eram os campos do cadastro do cliente, e ali estava um pedido antigo, de fevereiro do ano anterior. Toda vez que a mensagem nova não repetia a demanda, ele voltava para o pedido velho.

Minha primeira ideia foi criar uma tabela de memória. Antes de fazer, olhei onde o sistema já gravava cada turno. Gravava numa tabela de log, só para observabilidade. Aquela tabela já era a transcrição da conversa.

Bastou uma função que devolve os turnos anteriores daquele telefone e o agente passou a receber a conversa inteira. Sem tabela nova, sem infraestrutura de estado.

Um detalhe de segurança: o log guarda o conteúdo completo das mensagens, com telefone e dados cadastrais. Por isso não abri leitura geral da tabela. A função só devolve os turnos do telefone consultado.

Também separei duas coisas que o modelo misturava. O cadastro (documento, e-mail, endereço) é fato permanente. O pedido anterior é histórico, e no prompt está marcado como “isto não é o que ele quer agora”. Foi essa separação que parou de confirmar pedido velho no meio de uma demanda nova.

Se você vai construir um agente de atendimento, procure primeiro onde as conversas já estão sendo guardadas.

A saída do modelo é entrada não confiável

Voltando ao CNPJ. Nos testes apareceram dois vazamentos, os dois indo para o CRM.

O primeiro foi o raciocínio dentro do campo de documento. O segundo foi o marcador de rastreio, que eu uso para saber de qual anúncio o lead veio. Como o histórico é lido cru, o marcador entrou na conversa e o modelo o gravou como se fosse dado do pedido, no campo de especificidades.

Prompt reduz a frequência desse tipo de erro. Não impede. Quem impede é código na fronteira, antes de gravar no sistema:

• Todo campo tem teto de tamanho. Valor acima do teto é descartado, não cortado. Um texto cortado continua errado, só que com cara de certo.
• Só passam as chaves que eu listei. Campo que o modelo inventar não entra.
• O marcador de rastreio é removido da mensagem antes de o modelo vê-la, no turno atual e no histórico.
• O campo de CNPJ saiu do esquema. O agente não precisa pedir documento, então não precisa de um lugar para escrevê-lo.

Escrevi checagens automáticas para isso, 21 no total, incluindo o caso real do vazamento. É a regra que eu aplicaria a qualquer integração: o que o modelo devolve é tratado como o que um usuário digitou num formulário público. Você validaria um formulário público antes de gravar? Então valide isto.

Quando o modelo menor não deu

Comecei com o Haiku 4.5, um modelo menor e mais barato. Ele chegou no teto dessa tarefa. Devolveu uma linha de raciocínio no lugar da mensagem para o cliente e inventou um valor para o campo de especificidades.

Troquei para o Sonnet 5 e os dois problemas sumiram. O custo ficou em centavos por lead: cerca de US$ 0,03 numa conversa de cinco turnos com imagem. Contra um custo de aquisição de lead de uns R$ 200, a diferença para o modelo menor é irrelevante.

Modelo barato só é economia quando a saída é usável. Se você precisa de revisão humana ou de retrabalho para consertar o que ele escreve, o barato saiu caro. Meça na tarefa real, com a conta real ao lado, e não pelo preço da tabela.

O que vai direto para uma pessoa

Algumas coisas eu nunca deixo o agente tentar resolver.

• Áudio, vídeo e documento. O modelo não recebe áudio. Um agente que finge ter ouvido é pior do que nenhum, porque o cliente acredita que foi entendido. Esses casos vão direto para um humano.
• Falha do próprio agente. Se o modelo cai ou devolve resposta vazia, o lead é transferido. Ele nunca fica no vácuo.
• Falha de envio. Houve um caso em que a plataforma de atendimento recusou a mensagem e o log dizia que o agente tinha respondido. O cliente não recebeu nada. É o pior formato de bug, porque parece funcionando. Agora, se nenhuma parte da resposta foi entregue, o log diz erro e o lead vai para um humano.

A regra por trás disso é a mesma do campo de CNPJ: o sistema decide pelo que conseguiu verificar, não pelo que o modelo disse que fez.

O que eu levaria para a sua empresa

Três perguntas antes de ligar uma IA a qualquer sistema seu.

1. Onde isso já está registrado? Antes de criar memória, banco ou fila, olhe os logs que você já tem.
2. O que acontece se ela escrever bobagem neste campo? Se a resposta é “vai para o CRM, para a nota fiscal ou para o cadastro do cliente”, precisa existir uma validação em código entre o modelo e o sistema.
3. Quem recebe o que a IA não consegue tratar? Áudio, documento, falha. O caminho para a pessoa tem que existir antes do primeiro cliente.

Quem tem esse desenho na mão consegue testar com segurança e trocar de modelo depois sem medo.

Se você está avaliando colocar IA no atendimento ou em qualquer sistema da sua operação, e quer fazer isso do jeito que aguenta produção, veja como trabalho em /contratar/.

Fernando Sugiyama é empresário desde 2010 (Leox e Hutz) e desenvolve soluções com IA em produção para empresas: agentes de atendimento, automação com aprovação humana e software sob medida. Tudo o que escreve aqui roda primeiro nas próprias empresas.