Falha silenciosa: quando o agente de IA não avisa que errou

Software normal falha alto. Ele trava, devolve código de erro, some da porta 443, acende o painel. A cultura inteira de operação foi construída em cima disso: a máquina avisa quando quebra.

Agente de IA falha educado. Ele termina o turno, escreve um resumo bem estruturado do que fez, e o resumo está errado. Não há exceção, não há código diferente de zero, não há alerta — porque, do ponto de vista da execução, nada deu errado. O que deu errado está no conteúdo do relatório, e nenhum monitoramento lê conteúdo de relatório.

A tese em uma frase: a falha silenciosa é o modo normal de um agente falhar, e o problema não é ele errar — é que a sua capacidade de saber que ele errou depende de um texto que ele mesmo escreveu.

Por que a falha silenciosa é o padrão aqui

Um sistema tradicional tem estados discretos. Rodou ou não rodou. Código zero ou diferente de zero. Registro gravado ou não gravado. A observabilidade funciona porque existe um sinal binário para observar.

O agente tem um estado só: ele terminou o turno. Se cumpriu a tarefa, terminou o turno. Se não cumpriu, também terminou o turno. A diferença entre os dois casos está codificada numa narrativa em português — escrita pelo próprio responsável, sobre o próprio trabalho.

É isso que muda a natureza do problema. Você não está lendo uma medição: está lendo um autorrelato. E a habilidade central do sistema é justamente produzir texto plausível.

Isso conversa direto com a distância entre percepção e medição que eu mostrei em quando não usar IA — só que aqui a percepção enganada não é a sua: é a que o próprio sistema te entrega, já formatada.

Dois modos que estão documentados, não são hipótese

Vale começar pelos dois modos de falha silenciosa que não são especulação minha — estão descritos na documentação de quem constrói essas ferramentas, o que os torna especialmente úteis para quem precisa convencer alguém de que o risco é real.

A chamada de ferramenta que vira texto. Em certas configurações, o modelo escreve a chamada da ferramenta dentro da resposta em texto, em vez de emiti-la como uma chamada de verdade. O efeito é preciso e desconfortável: o turno completa normalmente, a ferramenta nunca roda, e não há erro nenhum para capturar. Quem está de fora vê um turno bem-sucedido que silenciosamente não fez nada — e, num agente que continua trabalhando, aquele texto falso fica no histórico e contamina os passos seguintes.

O turno que pausa e é servido como resposta final. Quando um agente usa ferramentas do lado do servidor, a execução pode pausar ao bater um limite interno de iterações. A documentação de estados de parada é explícita: a aplicação precisa tratar essa pausa e devolver o conteúdo para continuar. Se o laço que conduz o agente não faz isso, ele encerra e entrega o que tinha como se fosse a resposta final — sem erro, sem aviso. O resultado é uma resposta truncada com cara de completa.

Os dois têm a mesma assinatura: sucesso aparente, trabalho ausente. E os dois são invisíveis para qualquer monitoramento que olhe status em vez de conteúdo.

Os outros três modos

Laço. A falha silenciosa mais cara: o agente repete tentativas equivalentes — reformula a mesma busca, tenta o mesmo caminho com outras palavras — até bater um limite. Consome tempo e dinheiro, e termina com um relatório de "não foi possível encontrar" que parece uma conclusão de pesquisa. Em arranjos com subagentes isso multiplica: cinco agentes podem laçar em paralelo, cada um gerando seu relatório.

Desvio de escopo. Pediu-se A; ele entrega B, que é adjacente, defensável e não é A. É o modo mais difícil de pegar, porque o resultado tem qualidade — só não é o que foi pedido. Aparece bastante quando a tarefa foi descrita de forma ambígua.

Conclusão parcial relatada como total. Ele fez seis dos dez itens e escreve o resumo no plural, sem mentir explicitamente: "os registros foram atualizados". Tecnicamente alguns foram. É o modo que mais gera prejuízo operacional, porque a lacuna aparece semanas depois, num relatório que não bate.

E, atravessando todos, o relatório confiante e errado — que é a alucinação de IA aplicada ao próprio trabalho, em vez de aplicada ao conteúdo. Vale o mesmo alerta: não existe sinal, não existe hesitação, o tom é idêntico ao do relatório correto.

O que não funciona para detectar

Três coisas que parecem controle contra falha silenciosa e não são:

• Ler o relatório com atenção. O relatório é a parte comprometida. Ler melhor um texto potencialmente inventado não muda nada.
• Perguntar ao agente se ele concluiu. Gera outro texto plausível sobre o primeiro. É o mesmo erro de pedir à IA para conferir a própria resposta.
• Monitorar erro e disponibilidade. Seu painel vai continuar verde, porque nada falhou tecnicamente. Aliás, é justamente essa a natureza do problema.

O que funciona: registro do que foi executado

A única detecção confiável de falha silenciosa compara o que ele disse com o que de fato aconteceu. Isso exige registro de execução, não de conversa:

• Qual ferramenta foi chamada, com quais parâmetros, e o que voltou.
• Quantas vezes — se ele diz que atualizou dez registros, precisa haver dez chamadas de atualização.
• Quando — para distinguir trabalho da execução atual de resultado herdado de antes.

Essa é a mesma exigência que aparece em riscos de segurança do MCP, e não é coincidência: quando o agente ganha ferramentas que agem, "o que foi executado" deixa de ser questão de qualidade e vira questão de segurança. Sem registro, não há investigação possível — e o plano de resposta a incidentes vira adivinhação.

Some-se a isso a verificação independente do resultado: conferir a saída na fonte, não no resumo. Se o agente atualizou o CRM, abra o CRM.

A escala de gravidade: ler, escrever, enviar

Nem toda falha silenciosa custa o mesmo, e vale separar antes de decidir quanto controle montar. O que muda a gravidade não é o modo da falha — é o que o agente tinha permissão de fazer.

A linha do meio é a pior, e é a menos vigiada. Uma pesquisa incompleta você percebe ao usar; um envio errado alguém responde. Uma atualização parcial em base de dados não reclama de nada — ela só produz relatórios ligeiramente errados por meses.

A regra que sai daí é a mesma da permissão mínima: agente que só lê pode operar com conferência por amostragem; agente que escreve precisa de registro desde o primeiro dia. Não é rigor extra — é a única forma de responder "isso realmente aconteceu?" depois.

As três perguntas de quem opera

Curtas o bastante para virar checklist de reunião:

1. Se ele não tivesse feito, eu saberia? Se a resposta for "só quando alguém reclamar", você não tem detecção — tem sorte.
2. Onde está o registro do que foi executado? Se a resposta for "está na conversa", isso é autorrelato, não registro.
3. Quem confere, e com que frequência? Amostragem semanal já muda muito. Zero conferência com autonomia alta é a configuração que produz incidente.

E uma pergunta anterior às três, que resolve boa parte dos casos: essa tarefa precisava mesmo de um agente? Se o caminho era estável, um fluxo determinístico falharia alto — quebrando de forma visível em vez de relatar sucesso. É o critério de agente de IA ou automação, visto pela lente da observabilidade: fluxo erra barulhento, agente erra educado.

O ponto que fica

O risco de agente que mais aparece em conteúdo é o dramático: a IA que faz algo que ninguém pediu. Ele existe, e é o assunto de ataques agênticos.

Mas a falha silenciosa é o que vai atrapalhar a sua operação primeiro, e ela é o oposto — o agente que não faz o que foi pedido e diz que fez. Não há malícia, não há invasão, não há alerta. Há um texto bem escrito e um trabalho que não aconteceu.

A pergunta que vale levar daqui é curta: se ele tivesse falhado, o que exatamente teria me avisado? Se não houver resposta com nome — um log, uma conferência, uma pessoa —, então a resposta é ninguém.