Alertas de uso anormal de IA: pare um agente em loop cedo

Um alerta de uso anormal de IA é uma regra que compara a atividade de um agente, como chamadas de ferramentas, tokens ou execuções por hora, com o padrão que aquele fluxo costuma apresentar, e avisa um responsável nomeado quando esse padrão se quebra. A parada automática é a segunda camada: um limite que pausa o agente sozinho quando o uso ultrapassa uma linha mais alta, para que uma execução presa em loop não continue consumindo até alguém abrir a fatura do mês. Configure as duas por fluxo de trabalho e meça por tarefa concluída, não apenas pelo total da conta.

Principais pontos

• Alertas avisam uma pessoa de que algo saiu do padrão. Paradas automáticas limitam o estrago enquanto essa pessoa é acionada.
• A fatura mensal mostra o total, não o loop, então os sinais precisam ser lidos em minutos ou horas.
• Construa os limites a partir de uma semana normal de execuções de cada fluxo e alerte quando houver desvio dessa referência.
• Dê a cada alerta um responsável nomeado, um prazo de resposta e uma ação de pausa documentada.
• Teste a proteção com uma execução em loop provocada de propósito antes de depender dela.

Por que a revisão da fatura mensal chega tarde demais

A fatura mensal é um resumo de tudo o que aconteceu, com a média de dias em que o mesmo agente funcionou normalmente. Um agente em loop raramente aparece como um pico claro nesse resumo, a menos que o loop dure bastante, e, nesse ponto, o gasto já aconteceu. O loop em si costuma ser simples: uma ferramenta devolve erro, o agente interpreta o erro como motivo para tentar de novo, e a nova tentativa produz o mesmo erro com os mesmos argumentos. Cada volta custa uma chamada ao modelo e, muitas vezes, uma chamada de ferramenta, e nada na saída comum do agente indica que ele travou.

A lição prática é que o custo é um sinal atrasado. As proteções úteis leem comportamentos que mudam primeiro: execuções que não terminam, chamadas repetidas com entradas idênticas, uma subida repentina de execuções por hora em um fluxo específico. O objetivo é saber em minutos que um fluxo está fazendo algo que não fazia ontem, e deixar o sistema se interromper quando o padrão estiver claramente errado.

Quais sinais vale acompanhar?

Comece com uma lista curta de sinais por fluxo, em vez de um painel com tudo. Bons candidatos são:

• Execuções iniciadas por hora, comparadas com o pico normal daquele fluxo
• Chamadas de ferramenta por execução, especialmente para o mesmo endpoint
• Chamadas repetidas com os mesmos argumentos dentro de uma mesma execução
• Chamadas ao modelo ou tokens por execução, que mostram se o contexto ou o número de passos está crescendo sem limite
• Execuções que terminam sem resultado concluído, como por tempo esgotado ou por limite de tentativas
• Custo por tarefa concluída, que liga o gasto à entrega útil

O último sinal é o que mais importa para o responsável. Um agente pode parecer ocupado e, ainda assim, concluir menos tarefas, e o custo por tarefa concluída revela isso antes do total bruto. Para um tratamento mais completo dessa medida, veja Meça o custo de IA por tarefa concluída, não por mensagem. Orientações de economia unitária da FinOps Foundation explicam por que uma medida por unidade é mais informativa que um total bruto. A telemetria também deve seguir um modelo consistente: o material introdutório do OpenTelemetry descreve como traces, métricas e logs se encaixam, e essa é a base para ligar uma execução ao seu gasto.

Como definir limites sem chutar?

Limites inventados em uma reunião tendem a ser sensíveis demais, o que ensina as pessoas a ignorar alertas, ou frouxos demais, o que deixa um loop rodar por uma hora. O método confiável é ler primeiro o comportamento normal. Use esta sequência para cada fluxo:

• Extraia uma semana normal de execuções, excluindo incidentes conhecidos e lançamentos planejados
• Registre o nível típico e a faixa alta de cada sinal: execuções por hora, chamadas de ferramenta por execução, custo por tarefa concluída
• Defina a linha de alerta acima da faixa alta, com uma margem que o responsável consiga explicar em uma frase
• Defina a linha de parada automática bem acima da linha de alerta, para que ela dispare apenas em uma execução claramente fora do padrão
• Adicione uma regra para chamadas repetidas idênticas, que não precisa de referência porque uma execução saudável raramente repete a mesma ação com as mesmas entradas
• Revise os limites depois de duas semanas, já que os primeiros alertas mostram se as linhas estão apertadas ou frouxas demais

Anote cada limite junto com o motivo. Se ninguém souber dizer por que uma linha está onde está, ninguém saberá se deve mudá-la depois de uma temporada de pico ou de uma atualização de modelo.

Duas etapas: avisar o responsável, depois pausar o fluxo

Separe o alerta da parada. O alerta vai para um canal que uma pessoa nomeada acompanha e deve trazer contexto suficiente para agir sem abrir três ferramentas: o fluxo, o sinal que disparou, o identificador da execução, o último passo concluído e o gasto atual daquele fluxo. A parada automática suspende novas execuções daquele fluxo. Execuções em andamento podem terminar ou parar em um checkpoint, dependendo de como o fluxo foi construído, e o trabalho novo deve ficar em fila para uma pessoa ou aguardar a liberação do responsável.

Um guia curto de decisão ajuda o responsável a reagir sem adivinhar:

• Alerta dispara uma vez e volta ao normal dentro da janela: registre e revise na próxima verificação
• Alerta dispara várias vezes na mesma execução: trate como loop e inspecione as últimas cinco ações da execução
• Parada automática dispara: confirme que a pausa surtiu efeito, verifique efeitos colaterais duplicados e então decida entre retomar, corrigir ou reverter
• Alertas disparam em vários fluxos ao mesmo tempo: suspeite de uma dependência compartilhada, como uma ferramenta, um provedor ou uma credencial, e siga o plano de contingência

Efeitos colaterais duplicados são o motivo para verificar antes de retomar. Uma escrita repetida pode criar um segundo registro ou uma segunda mensagem, por isso combine esta etapa com o desenho de ações idempotentes. O padrão está coberto em Ações idempotentes em agentes de IA: como evitar reembolsos duplicados. Condições de parada específicas para loops estão em Agente de IA preso em loop: condições de parada que funcionam.

Como impedir que a proteção falhe em silêncio?

A proteção também é software, e pode falhar sem aviso. Três modos de falha merecem um plano. O pipeline de métricas pode parar de receber dados, o que faz um agente em execução parecer ocioso. O canal de alerta pode ficar inacessível, e a mensagem não chega a lugar nenhum. O contador pode zerar quando um serviço reinicia, e o loop parece começar de novo do zero.

Planeje esses casos explicitamente. Trate a ausência de telemetria em um fluxo em execução como um aviso que pausa novos inícios, e não como silêncio. Envie o alerta para um segundo canal se o primeiro não for reconhecido dentro da janela de resposta. Guarde os contadores fora do processo que pode reiniciar, para que a visão de gasto sobreviva a uma implantação. O NIST AI Risk Management Framework é uma referência útil para tratar o monitoramento como controle de risco contínuo, e não como configuração única. Para saber o que registrar em cada execução, de modo que essas verificações possam ser auditadas depois, veja Observabilidade de agentes de IA: o que registrar?.

Cenário ilustrativo: um agente de triagem que insiste nas tentativas

Este é um cenário ilustrativo, não um caso de cliente. Um agente de triagem de suporte lê tickets que chegam e consulta o status de pedidos em um serviço interno. Em uma tarde, esse serviço passa a devolver tempo esgotado. O agente, seguindo a instrução de repetir consultas que falharam, refaz a mesma requisição com o mesmo número de pedido. Em um ticket normal, ele faz duas ou três consultas. Nessa execução, faz dezenas em poucos minutos, o custo por tarefa concluída sobe e o número de tickets fechados fica parado.

A regra de chamada idêntica dispara depois da terceira repetição, e o alerta chega ao responsável por operações de suporte com o identificador do ticket e o endpoint que falha. Pouco depois, a regra de execuções por hora ultrapassa a linha de parada automática e o fluxo pausa a triagem nova, de modo que os tickets ficam em fila para uma pessoa. O responsável confirma que o tempo esgotado é a causa, espera o serviço se recuperar e verifica se algum cliente recebeu resposta duplicada. Antes de o fluxo voltar à produção, a equipe reproduz um teste que simula o tempo esgotado, e assim o comportamento de parada é verificado sem tocar no serviço real. Essa abordagem está descrita em Testar chamadas de ferramentas de agente de IA sem sistemas reais.

Como revisar as proteções ao longo do tempo?

As proteções perdem precisão à medida que os fluxos mudam. Uma nova ferramenta adiciona um novo sinal, um pico sazonal eleva a faixa normal, e uma atualização de modelo pode mudar quantos passos uma tarefa exige. Agende uma revisão curta dos limites e dos destinatários dos alertas todo mês e depois de qualquer mudança no fluxo, no modelo ou nas ferramentas. Guarde o resultado da revisão junto às notas operacionais do agente, para que a próxima pessoa veja por que cada linha está onde está. A rotina se encaixa no ciclo regular de manutenção descrito em Suporte e manutenção de agentes de IA: rotina mensal de revisão.

Nas operações gerenciadas da Be Human, essas proteções são configuradas como parte do primeiro trabalho. O time define os sinais para o papel escolhido, combina a referência e as duas linhas com o responsável, registra quem recebe cada alerta e testa o caminho de pausa antes de o agente ganhar permissão de escrita. O monitoramento contínuo acompanha os sinais, revisa os limites em cronograma e cobre a pausa, a verificação de duplicidades e a decisão de retomar durante a resposta a incidentes.

Para encontrar a primeira tarefa que vale entregar a um agente, faça o diagnóstico gratuito de IA da Be Human.

Perguntas frequentes

Em que um alerta de anomalia difere de um teto de orçamento? Um alerta de anomalia compara o comportamento com o padrão normal de um fluxo e avisa uma pessoa, enquanto um teto de orçamento é um limite fixo de gasto. Use os dois: o alerta pega uma execução incomum cedo, e o teto limita o pior caso se o alerta for perdido ou ignorado.

Quantos alertas um fluxo deve ter? Mantenha o conjunto pequeno, normalmente um sinal de taxa, um sinal de repetição e um sinal de custo por tarefa concluída, cada um com uma linha de alerta e uma linha de parada automática. Cada sinal adicional precisa de um responsável que vá agir sobre ele, senão será ignorado e o time aprenderá a desconsiderar o canal.

Quem deve receber os alertas? O alerta deve ir para a pessoa responsável pelo resultado do fluxo, com um substituto para ausências. A equipe técnica também pode precisar, mas o dono do negócio precisa saber quando um fluxo foi pausado, porque a decisão de retomar ou de aceitar um acúmulo de trabalho é dele.

Uma parada automática deve retomar sozinha algum dia? Normalmente não, porque um fluxo pausado pode ter deixado trabalho parcial ou efeitos colaterais duplicados que uma pessoa precisa conferir. A retomada automática pode fazer sentido em fluxos de baixo risco, somente de leitura, com ações idempotentes e um caminho de recuperação claro, mas deve ser uma decisão deliberada registrada nas regras do fluxo.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.