Agente de voz com IA mentia para clientes e confundia quem ligava: desenvolvedor achou a causa fora do prompt

O desenvolvedor de um agente de voz com IA para empresas passou três meses em condições reais e documentou todas as armadilhas: o agente mentia, confundia clientes e falsificava a voz de um jeito bem diferente do planejado.

As três grandes falhas do agente

Nos primeiros meses em produção, o agente de voz protagonizou vários episódios.

Primeiro incidente: o agente disse a um cliente que o «administrador Aleksei» ligaria de volta em uma hora. Nenhum Aleksei existia. O agente gerou o nome a partir do contexto de chamadas anteriores, misturando trechos de diálogos. O cliente esperou e registrou uma reclamação.

O segundo bug foi mais grave: o agente passou a tratar todos os chamadores como a mesma pessoa. A sessão não era reiniciada entre as ligações, e a memória do cliente anterior vazava para a conversa seguinte. Tecnicamente, é o problema clássico de contexto compartilhado sem isolamento explícito.

• O agente chamava o novo cliente pelo nome de quem ligou antes
• Lembrava detalhes do pedido de outra pessoa e oferecia «continuar o cadastro»
• Confirmava acordos inexistentes de sessões passadas
• Pedia desculpas por um «atraso» que não houve, confundindo a ligação atual com a anterior

O terceiro caso foi o que levou mais tempo para ser descoberto. Durante um mês inteiro, o agente usou síntese TTS comum enquanto se apresentava aos clientes como «voz clonada». A clonagem não foi conectada por causa de um erro de configuração, mas não lançou exceção em lugar nenhum: simplesmente degradou em silêncio para a síntese padrão.

Por que o prompt não resolve

A primeira reação intuitiva é acrescentar ao prompt frases como «não invente nomes», «não lembre de quem ligou antes», «sempre verifique se existe perfil de voz». O autor tentou e explica por que isso não funciona de forma sistemática.

Um modelo de linguagem não diferencia a proibição do prompt dos dados do contexto da sessão. Se o histórico da ligação anterior entra fisicamente na janela de contexto, o modelo o usa. Uma instrução não consegue proibir o que já está na memória.

«Prompt é uma recomendação, não uma barreira de arquitetura.

A barreira precisa estar no código.»

A solução é isolar o estado na camada de infraestrutura: reinício completo do contexto entre as ligações, verificação do perfil de voz antes do início da chamada (e não durante), e validação explícita de cada fato antes de ele ser falado.

A stack russa e suas particularidades

O autor trabalha inteiramente com ferramentas nacionais: um LLM russo, um provedor russo de TTS e telefonia por meio de uma operadora local. Isso impõe limitações específicas.

A documentação de várias dessas ferramentas é incompleta ou fica atrás da API. Por isso o erro de clonagem de voz ficou invisível: na ausência de perfil de voz, o provedor não devolvia erro. Entregava quietamente a síntese padrão com código 200. A troca só podia ser detectada analisando o áudio de saída ou verificando explicitamente os metadados da resposta.

Lições práticas de três meses de experiência:

• Verifique se todos os recursos (voz, perfil, sessão) existem antes de iniciar a operação, não durante ela
• Registre em log não só os erros, mas também as respostas «bem-sucedidas»: degradação silenciosa é mais perigosa que uma falha explícita
• Isole o estado do agente entre sessões no código, não no prompt
• Teste a saída de áudio, não só o log de texto: síntese e clone soam diferentes

O que isso significa

Agentes de voz com IA quebram em produção de um jeito diferente dos chatbots: os erros são falados em voz alta, o cliente os ouve em tempo real e não consegue reler nem ignorar. Isso torna crítico o cuidado com a arquitetura.

A maior parte do «comportamento estranho» de um agente de voz não é alucinação do modelo, mas buracos de arquitetura no código ao redor dele. Dá para consertar. Mas não com prompt.