Como avaliar agentes de IA na empresa

A demonstração boa ainda não prova confiabilidade

Um agente de IA pode fazer uma tarefa corretamente diante do gestor, gerar uma resposta convincente e parecer pronto para uso. A impressão muda quando ele encontra cinquenta casos reais.

Alguns chegam incompletos. Outros trazem informações conflitantes. Há clientes prioritários, exceções comerciais, documentos vencidos e pedidos que deveriam parar para aprovação humana. É nesse conjunto menos organizado que a qualidade do agente aparece.

Por isso, avaliar agentes de IA exige testar a conclusão e a qualidade da tarefa. A empresa precisa saber com que frequência o resultado está correto, quais erros se repetem, onde o agente precisa de contexto e se a execução melhora um indicador operacional.

Essa disciplina é o que permite sair de uma boa demonstração e chegar a uma rotina confiável.

O que significa avaliar um agente de IA

Avaliar um agente significa submetê-lo a casos representativos, observar sua execução e comparar o resultado com critérios definidos antes do teste.

A análise pode incluir quatro dimensões:

• qualidade da saída: o resultado está correto, completo e adequado ao caso?
• qualidade da execução: o agente usou as fontes e ferramentas certas na sequência esperada?
• respeito aos limites: ele pediu aprovação, protegeu dados e interrompeu a ação quando deveria?
• impacto operacional: houve redução de tempo, retrabalho, atraso ou dependência de uma pessoa específica?

Essas dimensões evitam uma avaliação pobre baseada em gosto. “Ficou bom” não oferece base para decidir se o agente pode entrar em produção. “Acertou 43 de 50 classificações e encaminhou corretamente todos os cinco casos críticos” já permite uma decisão.

A avaliação também precisa acompanhar o tipo de responsabilidade. Um agente que resume reuniões tolera riscos diferentes de um agente que altera um cadastro financeiro. Quanto maior o impacto de uma ação, mais rigorosos devem ser os testes, as permissões e a revisão.

Comece por um conjunto de casos reais

O primeiro ativo de avaliação costuma estar dentro da própria empresa: o histórico da operação.

Conversas de atendimento, propostas, documentos, reuniões, tickets, registros do CRM e planilhas mostram como o trabalho acontece. Uma amostra bem escolhida deve incluir casos comuns, casos difíceis e exceções que já causaram problema.

Imagine um agente responsável por preparar follow-ups comerciais. Um conjunto útil de testes poderia conter:

• lead novo com informação completa;
• lead sem orçamento declarado;
• negociação parada há mais de duas semanas;
• cliente que pediu prazo e deve ser respeitado;
• proposta com condição comercial especial;
• contato duplicado no CRM;
• conversa com objeção que exige intervenção do vendedor;
• caso encerrado que não deveria receber nova mensagem.

Esse material precisa ser anonimizado quando houver dados pessoais ou informações sensíveis. O objetivo é preservar a complexidade operacional sem espalhar conteúdo que não deveria circular.

Casos sintéticos ajudam a cobrir cenários raros, mas não deveriam ser a única base. Eles costumam refletir uma operação mais limpa do que a empresa realmente possui.

Defina o resultado esperado antes de executar o teste

Cada caso precisa de uma referência. Pode ser uma resposta aprovada por um especialista, uma classificação correta, uma sequência de ações, um checklist obrigatório ou uma regra clara de escalonamento.

Sem essa referência, a equipe corre o risco de ajustar o critério depois de ver o resultado. A avaliação vira torcida: respostas convincentes recebem aprovação mesmo quando ignoram detalhes importantes.

Para o agente de follow-up, o resultado esperado pode registrar:

1. estágio correto do lead;
2. resumo da objeção principal;
3. próxima ação recomendada;
4. necessidade ou ausência de aprovação humana;
5. tom adequado da mensagem;
6. atualização que deve ser feita no CRM;
7. situações em que nenhuma mensagem deve ser enviada.

Nem tudo precisa ser medido de forma binária. Clareza e adequação de tom podem usar uma escala curta, desde que os avaliadores compartilhem a mesma definição. Já permissões, uso de dados e ações críticas pedem critérios objetivos.

Meça o agente e o processo ao redor dele

Uma taxa de acerto isolada conta apenas parte da história. O agente pode gerar bons textos e ainda acrescentar atrito ao fluxo. Pode economizar minutos na produção e criar horas de revisão. Pode acertar casos simples e falhar justamente nos casos de maior risco.

Vale organizar as métricas em três níveis.

Métricas de tarefa

Mostram se o agente fez o trabalho solicitado:

• percentual de respostas corretas;
• completude dos campos obrigatórios;
• precisão da classificação;
• taxa de uso correto das ferramentas;
• frequência de informação inventada ou sem fonte;
• cumprimento das regras de permissão;
• taxa de escalonamento correto para uma pessoa.

Métricas de fluxo

Mostram como a execução se comporta dentro da rotina:

• tempo até conclusão;
• custo por execução;
• número de tentativas ou chamadas de ferramenta;
• taxa de falha técnica;
• percentual de casos que exigem retrabalho;
• tempo gasto em revisão humana;
• quantidade de pendências que ficam sem registro.

Métricas de negócio

Mostram se a empresa ganhou capacidade:

• velocidade de resposta ao cliente;
• taxa de follow-up realizado no prazo;
• redução de backlog;
• tempo poupado pela equipe;
• diminuição de erros operacionais;
• melhora na conversão, retenção ou resolução, quando houver relação verificável;
• redução da dependência de uma pessoa para preparar cada decisão.

A métrica principal deve acompanhar o objetivo do agente. Se ele existe para reduzir atraso comercial, uma nota de estilo tem importância secundária. O indicador central precisa mostrar se os próximos passos estão sendo preparados e executados no prazo.

Toda mudança precisa enfrentar o mesmo teste

Agentes mudam com frequência. A equipe ajusta uma instrução, troca o modelo, adiciona uma fonte, altera uma ferramenta ou amplia uma permissão. Uma melhoria aparente em um caso pode piorar vários outros.

Por isso, a empresa precisa manter um conjunto fixo de casos para regressão. Depois de cada mudança relevante, o agente executa novamente essa amostra. A comparação mostra o que melhorou, o que piorou e se apareceu algum comportamento inesperado.

Uma estrutura simples pode registrar:

| Versão | Casos aprovados | Erros críticos | Tempo médio | Custo médio | Decisão | |---|---:|---:|---:|---:|---| | v1 | 34/50 | 4 | 3 min | R$ X | revisar contexto | | v2 | 42/50 | 1 | 3,4 min | R$ Y | piloto controlado | | v3 | 44/50 | 0 | 3,2 min | R$ Z | ampliar amostra |

Os valores acima são apenas um modelo de registro. Cada empresa deve preencher a tabela com dados reais do próprio fluxo.

O ponto importante é conservar evidência. Sem histórico de versões e resultados, a equipe não sabe se está melhorando o agente ou apenas mudando seu comportamento.

Essa prática complementa a rastreabilidade e o controle operacional necessários em rotinas sensíveis.

Aprender com falhas exige pequenas mudanças

Uma falha pode vir de várias camadas. Talvez a instrução esteja ambígua. Talvez falte um documento. A ferramenta pode ter retornado dado desatualizado. O processo humano pode não ter critério definido. Também pode haver um limite do modelo para aquela tarefa.

Mudar tudo ao mesmo tempo esconde a causa.

A abordagem mais útil é classificar os erros, escolher o padrão mais frequente e fazer uma alteração limitada. Depois, o agente volta ao conjunto de testes. Se o resultado melhora sem criar regressão relevante, a mudança é aceita e registrada.

Uma pesquisa recente da Microsoft Research sobre o SkillOpt explora essa lógica de forma técnica. O sistema trata instruções operacionais como uma camada que pode ser otimizada a partir das trajetórias de execução. As alterações são pequenas, passam por validação e só entram na versão final quando demonstram ganho no conjunto de teste.

A empresa não precisa adotar o método de pesquisa para aproveitar o princípio. O aprendizado do agente deve usar evidência, preservar versões e rejeitar mudanças que não melhoram o resultado.

Isso reduz o “prompt tuning por sensação”, prática comum em que alguém reescreve instruções até gostar de uma resposta isolada.

O humano continua responsável pelo critério

Avaliação automatizada ajuda a ganhar escala. Outro modelo pode conferir formato, presença de campos, aderência a regras e parte da qualidade textual. Código pode validar números, links, status e ações executadas.

Mesmo assim, casos importantes pedem revisão humana.

A empresa precisa decidir o que considera um bom resultado, quais riscos são aceitáveis e que tipo de erro impede a liberação. Esse julgamento vem do dono do processo, de especialistas e das pessoas que lidam com as consequências da execução.

Também vale medir a concordância entre avaliadores. Se duas pessoas experientes classificam o mesmo caso de formas opostas, talvez o problema esteja no processo, não no agente. A divergência revela um critério operacional que ainda vive na cabeça de indivíduos.

Nesse sentido, avaliar agentes também melhora a empresa. O teste força a organização a explicitar regras, exceções e prioridades que antes circulavam de maneira informal.

Um ciclo mínimo de avaliação para empresas menores

Uma pequena empresa não precisa começar com laboratório, plataforma complexa ou centenas de testes. Precisa de um ciclo legível.

1. Escolha uma rotina delimitada

Comece com uma tarefa repetida, de impacto mensurável e risco controlável. O artigo sobre como escalar pilotos de IA mostra por que uma fronteira clara facilita a passagem do experimento para a operação.

2. Separe de 20 a 50 casos

Inclua situações comuns, difíceis e críticas. Remova dados sensíveis e preserve as características que afetam a decisão.

3. Defina critérios e erros impeditivos

Liste o que caracteriza aprovação, o que pode ser corrigido e o que bloqueia o uso. Envio indevido, exposição de dado, alteração sem autorização e perda de informação costumam merecer tolerância muito baixa.

4. Registre a linha de base

Meça como o processo funciona hoje: tempo, retrabalho, atraso, qualidade e dependência humana. Sem linha de base, o ganho fica baseado em percepção.

5. Rode o agente e revise os erros

Classifique a origem provável de cada falha: contexto, instrução, ferramenta, modelo, permissão ou processo.

6. Altere uma camada por vez

Faça uma mudança pequena, repita os testes e compare com a versão anterior.

7. Libere por etapas

O agente pode começar sugerindo, depois registrar com revisão e só então executar ações delimitadas. O avanço depende dos resultados e do risco, não da empolgação com a tecnologia.

Esse ciclo já cria uma base séria de melhoria contínua. Conforme o uso cresce, a empresa pode ampliar os casos, automatizar verificações e adotar ferramentas específicas de observabilidade.

O ativo real é o histórico de aprendizado

Um agente confiável não surge de um prompt perfeito. Ele ganha qualidade quando a empresa acumula casos, explicita critérios, observa falhas e transforma esse aprendizado em versões melhores do sistema.

Com o tempo, o conjunto de avaliação vira um ativo operacional. Ele protege a empresa em trocas de modelo, mudanças de ferramenta e atualizações de processo. Também permite comparar fornecedores sem depender apenas de demonstrações.

A pergunta útil deixa de ser “qual agente parece mais inteligente?” e passa a ser “qual configuração produz o melhor resultado nos casos que realmente importam para nossa operação?”.

Empresas que conseguem responder isso têm uma vantagem prática. Elas podem aumentar a autonomia com evidência, manter controle sobre riscos e melhorar seus agentes sem reconstruir tudo a cada novidade do mercado.

Antes de criar outro agente, vale olhar para os que já existem. Quais possuem casos de teste, critérios de aprovação, histórico de versões e uma métrica ligada ao negócio? A resposta mostra o nível real de maturidade da arquitetura.