Observabilidade de agentes de IA: como saber se o seu está funcionando

Um agente de IA pode responder rápido, com texto bonito, e ainda assim estar errando metade das vezes. Sem observabilidade, ninguém percebe até o cliente reclamar ou o time de vendas perder um lead. Observabilidade de agentes de IA é o conjunto de métricas e logs que mostra, em tempo real, se o agente está fazendo o trabalho direito.

O que é observabilidade de agentes de IA

Observabilidade é diferente de “o agente está no ar”. É saber, com dado, três coisas: o que o agente respondeu, quanto isso custou e se a resposta resolveu o problema do usuário.

Em software tradicional, observabilidade é logs, métricas e traces. Em agentes de IA, a lógica é parecida, mas os sinais mudam: latência de resposta, custo por token, taxa de escalonamento pra humano, e principalmente, se a resposta estava certa.

O problema é que um agente nunca “quebra” do jeito que um servidor quebra. Ele continua respondendo. Só que errado, incompleto, ou fora do tom. Sem observabilidade, esse tipo de falha é invisível.

Por que “está funcionando” não quer dizer nada

Times costumam medir agente de IA por uptime: o agente respondeu, então está tudo certo. Isso esconde os problemas reais.

Um agente pode ter 100% de uptime e ainda assim:

• Alucinar uma política de reembolso que não existe.
• Demorar 40 segundos pra responder uma pergunta simples, fazendo o cliente desistir.
• Custar 5x mais por conversa do que deveria, porque está usando o modelo errado pra tarefa errada.
• Escalar pra um humano em 60% das conversas, o que significa que a automação não está automatizando nada.

Nenhum desses problemas aparece num dashboard de “está online ou não”. Todos aparecem quando você olha as métricas certas.

Um exemplo real de “estava tudo certo”

Um agente de atendimento no WhatsApp respondia em menos de 3 segundos e tinha 99,8% de uptime no mês. No papel, perfeito.

O problema apareceu só quando alguém leu uma amostra de 30 conversas: em 6 delas, o agente tinha inventado um prazo de entrega que não existia no sistema. Ninguém tinha notado, porque nenhuma métrica de uptime ou latência captura “a resposta estava errada”. O uptime continuava em 99,8%. A taxa de alucinação, se alguém tivesse medido, estava em 20%.

Esse é o padrão mais comum: o painel de infraestrutura diz que está tudo bem, e o painel de qualidade nem existe.

As métricas que realmente importam

Quatro números contam a maior parte da história de um agente em produção.

1. Latência por resposta

Tempo entre a pergunta do usuário e a resposta do agente. Acima de alguns segundos, a conversa começa a parecer travada, principalmente em canais como WhatsApp, onde a expectativa é de resposta quase instantânea.

2. Custo por conversa

Quanto cada interação completa custa em tokens. Modelos diferentes têm preços muito diferentes, e a mesma tarefa pode custar 10x mais dependendo de qual modelo o agente usa. Sem medir isso por conversa, o custo só aparece na fatura do mês, tarde demais pra corrigir.

3. Taxa de escalonamento pra humano

Quantas conversas terminam com “vou te transferir pra um atendente”. Uma taxa alta não é sinal de cuidado, é sinal de que o agente não está resolvendo sozinho o que deveria resolver.

4. Taxa de erro e alucinação

A métrica mais difícil de capturar e a mais importante. Quantas respostas estavam factualmente erradas, inventaram uma informação ou fugiram do que a base de conhecimento realmente diz.

Como montar um painel sem virar projeto de engenharia

A tentação é construir um sistema de observabilidade do zero: logging customizado, dashboard em Grafana, alertas no Slack. Isso funciona, mas leva semanas e vira mais um sistema pra manter.

O caminho mais rápido pra maioria das empresas é usar uma plataforma que já registra isso nativamente:

1. Log de cada conversa, com o modelo usado, o tempo de resposta e o custo em tokens.
2. Marcação de escalonamento, sempre que o agente passa a conversa pra um humano.
3. Revisão amostral, onde alguém do time lê uma fatia das conversas por semana pra pegar erro que a métrica sozinha não capta.
4. Alerta automático quando um número foge do padrão, como custo médio subindo 30% de uma semana pra outra.

Não precisa ser sofisticado no primeiro mês. Precisa existir. A maioria dos agentes que “davam errado silenciosamente” tinha zero desses quatro pontos.

Construir isso do zero costuma levar de duas a seis semanas de trabalho de engenharia: instrumentar cada chamada de modelo, montar o dashboard, configurar alerta. É trabalho real, mas é trabalho que já vem pronto em plataformas que tratam observabilidade como parte do produto, não como projeto interno separado.

Sinais de que o agente está piorando sem ninguém notar

Alguns padrões aparecem antes de virar reclamação de cliente:

Custo por conversa subindo aos poucos. Geralmente sinal de que o agente está usando mais tokens pra chegar na mesma resposta, ou trocou de modelo sem ninguém perceber.

Escalonamento subindo mês a mês. A base de conhecimento ficou desatualizada, ou apareceu um tipo de pergunta novo que o agente não sabe responder.

Tempo de resposta variando muito. Se a latência fica instável (rápida às vezes, lenta outras), geralmente é sinal de que o modelo ou a integração está sob carga ou mal configurada.

Respostas mais genéricas. Quando o agente começa a responder de forma vaga em vez de específica, é sinal de que ele não está encontrando a informação certa na base.

Nenhum desses sinais é dramático sozinho. Juntos, eles mostram um agente que precisa de atenção antes que o cliente perceba primeiro.

Observabilidade não é a mesma coisa que auditoria

É fácil confundir os dois. Auditoria responde “quem disse o quê pra quem”, pensando em compliance e governança: rastrear cada conversa, garantir que dados sensíveis não vazaram, provar conformidade quando alguém perguntar.

Observabilidade responde “o agente está fazendo um bom trabalho”, pensando em performance: velocidade, custo, taxa de acerto.

Você precisa das duas. Mas são times e perguntas diferentes. Uma empresa pode ter auditoria perfeita (todo log guardado) e zero observabilidade (ninguém olha o log pra saber se o agente está bom).

Na prática, quem cuida de compliance costuma pedir auditoria. Quem cuida do produto ou do time de atendimento costuma precisar de observabilidade. Se só uma área está pedindo isso na sua empresa, provavelmente falta a outra.

Checklist prático pra começar

Se você não mede nada hoje, comece por aqui, nessa ordem:

1. Escolha as 4 métricas acima e garanta que sua plataforma registra as 4 por conversa.
2. Defina um número aceitável pra cada uma (ex.: latência abaixo de 5 segundos, escalonamento abaixo de 20%).
3. Marque um dia fixo por semana pra olhar o painel e ler uma amostra de conversas reais.
4. Configure um alerta simples pra quando um número sair da faixa aceitável.

Isso já resolve a maior parte dos problemas de “descobrimos tarde demais”.

Com que frequência olhar o painel

Não existe uma resposta única, mas dá pra usar essa régua:

• Diário, só pra alertas automáticos (custo fora da faixa, latência disparando). Ninguém precisa abrir o painel todo dia se o alerta avisa quando algo sai do normal.
• Semanal, pra revisão de amostra de conversas e leitura das quatro métricas principais. É o ritmo mínimo pra pegar uma tendência antes dela virar problema.
• Mensal, pra revisão de tendência de custo total e comparação entre modelos, pensando em decisão de orçamento e troca de modelo.

Empresas que só olham o painel uma vez por mês descobrem problema com um mês de atraso. Empresas que só olham quando o cliente reclama não têm observabilidade, têm reação.

O jeito mais rápido de ter isso pronto

Construir observabilidade do zero é possível, mas caro em tempo de engenharia. O SquadOS já registra latência, custo por conversa e escalonamento nativamente, com dezenas de modelos disponíveis e processamento multimodal com até 95% de economia em tokens. Você troca de modelo, compara custo real e enxerga o que o agente está fazendo, sem montar infraestrutura própria.