Como avaliar agentes de IA que executam ações

Quando um agente de IA executa ações, a avaliação precisa começar pelo que ele pode alterar: objetos, permissões, escopo, custo e efeitos colaterais. A mensagem de conclusão não prova que a ação aconteceu, nem que aconteceu de modo aceitável. Para ampliar autonomia com menos improviso, a equipe precisa olhar para evidências externas ao relato do agente: estado do sistema, registros, ferramentas usadas, tentativas e efeitos colaterais.

Quando a mensagem de conclusão não prova que a ação ocorreu

Um agente de inteligência artificial que executa ações não entrega apenas uma resposta. Ele consulta sistemas, chama ferramentas, altera objetos, cria registros, aciona fluxos e pode tomar decisões intermediárias até chegar ao objetivo pedido.

É por isso que a mensagem final é uma evidência fraca. Ela mostra o que o agente afirma ter feito, não o que o ambiente confirma.

A diferença parece pequena até entrar em produção. Um agente pode dizer que atualizou uma configuração, mas ter alterado o campo errado. Pode ter criado um item duplicado. Pode ter executado a ação certa em um escopo maior do que o autorizado. Pode ter falhado em uma etapa, tentado contornar o erro e mesmo assim narrado sucesso.

A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente. Também observa que uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. Essa separação ajuda equipes que estejam avaliando agentes de IA com capacidade de agir.

Na prática, a avaliação começa fora da resposta do agente. A pergunta não é “ele pareceu confiante?”. A pergunta é “o sistema ficou no estado esperado, pelo caminho que aceitaríamos?”.

Isso exige evidências como:

Objeto criado, alterado ou removido no local correto.
Registro de auditoria ou histórico de mudança compatível com a tarefa.
Ausência de alteração em objetos fora do escopo.
Chamadas de ferramenta coerentes com a permissão concedida.
Registro de falhas, interrupções e novas tentativas.

Sem esses rastros, a equipe continua avaliando a narrativa do agente, não a execução.

Resultado e trajetória são duas camadas da mesma avaliação

Avaliar resultado é conferir o estado final. A regra foi criada? O chamado foi classificado? A configuração foi aplicada? O arquivo foi atualizado? A ação esperada aparece no sistema certo?

Avaliar trajetória é conferir o caminho. Quais ferramentas foram usadas? Que permissões entraram em jogo? O agente tentou a mesma operação várias vezes? Alterou a ordem esperada dos passos? Pediu autorização quando encontrou incerteza? Parou quando deveria parar?

As duas camadas devem ser aprovadas separadamente.

Um resultado correto por trajetória inadequada não deve ser tratado como execução aceita. Se uma pessoa resolvesse uma tarefa simples usando acesso administrativo amplo, apagando histórico intermediário ou mexendo em dados fora do escopo, a equipe provavelmente investigaria. O mesmo critério deve valer para agentes.

O contrário também importa. Um agente pode seguir uma trajetória aparentemente adequada, mas não produzir efeito real. Nesse caso, a execução também não foi bem-sucedida. O ritual foi cumprido, mas o ambiente não mudou como precisava.

Essa distinção reduz uma confusão comum: testar agente como se fosse apenas testar texto. Em aplicações que só respondem, qualidade da saída é parte central da avaliação. Em agentes que executam ações, a saída textual pode ser apenas um recibo narrativo. O que precisa ser comprovado está no ambiente.

Essa discussão se conecta à disciplina mais ampla de qualidade de software com IA, mas tem uma exigência própria: o teste precisa observar o efeito da ação, não apenas a plausibilidade da explicação.

Como definir verificadores antes de soltar o agente

Um verificador é um critério observável que confirma se uma execução foi bem-sucedida, aceitável ou bloqueável. Ele precisa existir antes da execução, não depois que o agente já agiu e a equipe está tentando interpretar o que aconteceu.

A Anthropic descreve avaliações com entradas, critérios de sucesso e verificadores, e reconhece que podem ser necessárias várias tentativas. A aplicação prática disso, em produto e engenharia, é simples de dizer e difícil de manter: não basta perguntar ao agente se deu certo. É preciso definir como o sistema provará que deu certo.

Um bom conjunto de verificadores responde a perguntas concretas:

Qual objeto deve mudar?
Qual objeto não pode mudar?
Que campo, status, regra, evento ou registro comprova a ação?
Que permissão o agente pode usar?
Quantas tentativas são aceitáveis antes de parar?
Que erro obriga intervenção humana?
Como evitar duplicidade se a mesma entrada for reexecutada?
Como desfazer, pausar ou isolar o efeito se algo sair do esperado?

Essas perguntas parecem operacionais, e são. Essa é a virtude delas. Na avaliação, ajudam a testar riscos concretos: escopo errado, ferramenta errada, repetição sem controle, autorização ambígua, registro insuficiente, efeito lateral não percebido.

A avaliação de agentes de IA deve transformar essas falhas possíveis em critérios de aceite. Esse raciocínio também vale para funcionalidades de IA mais amplas, como discutido em como criar uma estratégia de inteligência artificial conectada ao negócio: capacidade técnica precisa vir acompanhada de decisão, limite e aprendizado operacional.

Exemplo fictício: agente que atualiza uma regra de atendimento

Considere um exemplo fictício. Uma empresa usa um agente interno para atualizar regras de roteamento de chamados. A tarefa recebida é ajustar uma regra para que solicitações de um determinado tipo sejam encaminhadas a uma fila específica de atendimento.

O agente tem acesso a uma ferramenta de configuração, a um histórico de mudanças e a uma base de políticas internas. Ao final, ele responde: “Regra atualizada com sucesso”.

Essa frase não encerra a avaliação. Ela começa a checagem.

O resultado esperado poderia ser conferido por evidências como:

A regra correta foi criada ou alterada.
O tipo de solicitação previsto aponta para a fila definida.
A regra antiga, se substituída, aparece no histórico.
Filas fora do escopo não foram modificadas.
O registro de mudança identifica a tarefa, o horário do evento e o agente responsável.

A trajetória aceitável exigiria outra camada de análise:

O agente consultou a política antes de alterar a regra.
Usou apenas a ferramenta autorizada para configuração.
Não solicitou permissão administrativa ampla para uma alteração restrita.
Não tentou alterar várias filas para compensar incerteza.
Interrompeu a execução se encontrou conflito entre regra existente e solicitação recebida.

Note que não há necessidade de transformar esse exemplo em um caso de sucesso. Ele é um cenário de teste. Os efeitos são hipóteses a medir: a regra pode ter sido aplicada corretamente, pode ter produzido conflito, pode ter criado duplicidade, pode ter revelado que a instrução era ambígua.

A maturidade aparece na forma como a equipe decide, antes da execução, o que aceitar, o que investigar e o que bloquear. Sem isso, o agente vira uma caixa de ação com recibo bonito.

Checklist de avaliação de agente que executa ações

Este checklist serve para decidir se uma execução pode ser aceita, investigada, repetida ou bloqueada. Ele não substitui os testes específicos do domínio, mas ajuda engenharia, qualidade e produto a conversar sobre o mesmo objeto.

Resultado verificável

Pergunta: o estado do sistema confirma a ação esperada sem depender da mensagem final do agente?

Aceite quando houver evidência externa: objeto criado, campo alterado, registro atualizado, tarefa concluída ou evento emitido no local correto.

Investigue quando o agente declarou sucesso, mas o estado do ambiente não comprova a conclusão.

Escopo preservado

Pergunta: a ação ficou limitada aos objetos, usuários, dados ou configurações autorizados?

Aceite quando a execução afetou apenas o escopo previsto.

Investigue quando houve alteração fora do escopo, mesmo que o objetivo principal tenha sido alcançado.

Trajetória aceitável

Pergunta: o agente usou ferramentas, permissões e sequência de passos compatíveis com a tarefa?

Aceite quando as chamadas de ferramenta e decisões intermediárias fazem sentido para o objetivo e respeitam as restrições.

Investigue quando o agente chegou ao resultado usando atalhos, permissões excessivas, repetição desnecessária ou caminho que a equipe não aceitaria de uma pessoa.

Condições de parada

Pergunta: o agente interrompeu a execução quando encontrou incerteza, erro, ausência de permissão ou risco de efeito colateral?

Aceite quando há registro claro de parada ou pedido de intervenção nos pontos definidos.

Investigue quando o agente continuou tentando, contornou uma falha ou mudou a estratégia sem autorização.

Repetibilidade controlada

Pergunta: a mesma entrada pode ser reexecutada sem duplicar ações, gerar conflitos ou mascarar falhas?

Aceite quando a execução é idempotente, ou seja, pode ser repetida sem multiplicar efeitos indevidos, ou quando possui proteção contra duplicidade.

Investigue quando uma nova tentativa pode criar objetos duplicados, sobrescrever decisões anteriores ou alterar o ambiente de forma acumulativa.

Reversibilidade

Pergunta: existe forma conhecida de desfazer, pausar ou isolar o efeito da ação?

Aceite quando a reversão foi definida antes da execução ou quando o impacto é limitado e isolável.

Investigue quando a ação produz efeito difícil de rastrear, desfazer ou conter.

Evidência para aprendizagem

Pergunta: a execução deixa rastros suficientes para melhorar instruções, ferramentas, permissões ou casos de teste?

Aceite quando entradas, passos relevantes, resultado e falhas ficam disponíveis para revisão.

Investigue quando a equipe só tem a resposta final do agente e não consegue entender como a decisão foi tomada.

Esse checklist funciona melhor quando usado antes da ampliação de autonomia. Depois que o agente já atua em um escopo grande, a organização tende a negociar com o incidente, não com o desenho.

Quando ampliar autonomia, permissões e ações reversíveis

Nem toda ação de agente precisa começar com exposição ampla. Quando há risco de efeito sistêmico, faz sentido ativar primeiro em um recorte controlado de uso, usuários, filas, dados ou configurações.

O capítulo de canary releases do Google SRE trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição. Também distingue disponibilizar código de ativar funcionalidades e discute configurações para separar essas decisões.

A analogia é útil para agentes. Disponibilizar a capacidade não é o mesmo que ativar autonomia. A equipe pode ter o agente instalado, integrado a ferramentas e tecnicamente pronto, mas ainda limitar onde ele age, com quais permissões e sob quais verificadores.

Essa separação permite decisões mais finas:

O agente pode sugerir, mas não executar.
Pode executar apenas em objetos de baixo risco.
Pode agir em um recorte de usuários internos.
Pode exigir aprovação humana em determinadas condições.
Pode ser interrompido automaticamente quando um verificador falha.

O ponto não é criar burocracia por princípio. É reduzir o raio de impacto enquanto a equipe aprende com execuções reais. Para isso, limites de autonomia precisam ser desenhados como parte do produto, não como correção tardia. Esse tema conversa diretamente com decisões de maturidade em IA, porque autonomia sem critério costuma revelar mais sobre a organização do que sobre o modelo.

Limites da avaliação: o que ela não resolve sozinha

Avaliar bem a execução de um agente não prova, por si só, valor de negócio, produtividade da equipe ou melhoria de desempenho organizacional. Prova algo mais específico: que, em determinadas entradas, ferramentas e permissões, o agente produziu um resultado verificável por uma trajetória aceitável.

Esse limite importa.

Na atualização de fevereiro de 2026, a METR trata seus novos dados como sinal pouco confiável do efeito atual da IA sobre produtividade. Entre as dificuldades citadas estão seleção de participantes e tarefas e medição de tempo com agentes concorrentes. Para este artigo, o ponto é metodológico: em agentes, resultado, trajetória e tempo de execução podem se misturar quando várias atividades acontecem em paralelo.

Também há limites de domínio. Uma trajetória aceitável para uma tarefa interna de baixo risco pode ser inadequada em contextos com dados pessoais, comunicação com clientes, segurança ou efeitos difíceis de reverter. O critério não é universal. Ele precisa acompanhar o impacto da ação.

Há ainda um limite de desenho. Avaliação não substitui permissão bem configurada. Se o agente recebe acesso amplo demais, a avaliação posterior vira uma rede de contenção frágil. Melhor restringir antes o que ele pode ver, alterar, acionar e repetir.

Por fim, avaliação não elimina julgamento humano. Ela o posiciona melhor. Em vez de chamar uma pessoa apenas para apagar incêndio, a equipe define quando o agente pode agir, quando deve pedir autorização e quando deve parar.

A decisão operacional fica mais estreita e mais útil: aceitar execuções comprovadas, investigar caminhos inadequados e bloquear ações que não deixam evidência suficiente. Antes de ampliar autonomia, a equipe precisa definir qual prova externa ao relato do agente autoriza a mudança.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.