O dia em que o nosso agente inventou um preço

A correção não foi escrever a instrução com mais ênfase. Foi tirar a decisão do modelo.

Numa quarta-feira de março, um cliente perguntou pelo WhatsApp quanto custava um e-CNPJ de três anos. O agente respondeu com um valor que não existia na nossa tabela. Era plausível, estava na faixa certa, e estava errado em quarenta reais.

Ninguém percebeu na hora. A gente descobriu dois dias depois, quando o cliente chegou para a emissão com um print da conversa.

A primeira correção, que não funcionou

A reação óbvia foi mexer no texto que orienta o agente. A instrução já dizia para usar só os valores da tabela. Então a gente reescreveu com mais ênfase, listou o que não fazer, colocou em maiúsculas o que importava.

Funcionou, no sentido de que o erro ficou mais raro. Em cerca de duzentas conversas de teste, ele reapareceu duas vezes. Uma taxa de erro de 1% parece pequena até você multiplicar por um volume de atendimento real e perceber que é um preço errado por dia.

E havia um problema pior que a taxa: a gente não tinha como saber quando ia acontecer. Uma instrução é um pedido. Um pedido pode não ser atendido, e quando não é, não há aviso.

O que mudou de verdade

A segunda correção partiu de uma pergunta diferente: e se o agente simplesmente não pudesse dizer um valor que não estivesse na tabela?

Hoje o fluxo é este. Quando a resposta do agente contém um valor monetário, ela não vai direto para o cliente. Ela passa por uma conferência que extrai o valor, procura na tabela aprovada daquela empresa, e só libera a frase se encontrar. Se não encontrar, a resposta é descartada e o agente é obrigado a consultar o catálogo antes de responder de novo.

A diferença é de categoria, não de grau. Antes, o modelo era instruído a se comportar. Agora, o servidor confere. O modelo pode errar à vontade: o erro não chega ao cliente.

A mesma ideia em outros cinco lugares

Depois que a trava do preço entrou, ficou evidente que o mesmo raciocínio valia para todas as promessas que um agente faz. Toda frase do tipo "eu fiz X" é uma afirmação sobre o mundo, e o servidor sabe se X aconteceu:

• "Já enviei o link." A frase só é liberada depois de o envio ser confirmado. Antes disso, ela não existe.
• "Vou te transferir para o Financeiro." O horário de cada pessoa do time é consultado antes. Fora do horário, a frase não é permitida e o agente oferece retorno.
• "Posso te dar 12% de desconto." Desconto é decisão, não informação. Vai para o gestor pelo WhatsApp, com o cliente na linha, e espera a aprovação.
• "Vou te ligar amanhã." Discagem exige pedido explícito do cliente ou regra configurada, conferidos no servidor. Nem um pedido de API dispara ligação fora da janela de horário.
• "Tenho quinta às dez." O horário é lido da agenda da empresa no momento da fala, não de um cache de cinco minutos antes.

O que isso custa

Custa latência, e esse é o único argumento honesto contra. Cada conferência é uma ida ao banco antes de a frase sair. A gente reduziu isso mantendo a tabela aprovada em memória por empresa, mas não dá para zerar.

O cálculo que fizemos foi simples: um preço errado por dia custa mais que alguns milissegundos por frase. E diferente da latência, que o cliente esquece, um preço errado ele imprime e traz na mão.

O que a gente aprendeu

Que a tentação, quando um modelo de IA faz algo indesejado, é melhorar o texto que o orienta. É mais rápido, não exige mudar arquitetura, e dá a sensação de ter resolvido.

Mas instrução não é garantia. Se existe uma afirmação que o seu sistema não pode permitir, ela precisa ser impedida fora do modelo, por código que você possa testar. A nossa régua hoje é essa: toda promessa que o produto faz ao cliente final tem um teste automatizado que tenta quebrá-la. Se não tem, não é uma promessa, é uma esperança.