Por que agentes de IA na empresa precisam de evals, não de mais usuários

Lucas Smaira, co-fundador da Vetto AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → e ex-pesquisador do Google DeepMind, publicou um texto de opinião no Brazil Journal que deveria estar pregado na parede de todo time de engenharia que está colocando agente de IA em produção. A tese dele é simples e incômoda: a pergunta "quantas pessoas usam IA na empresa" já é irrelevante. A que importa é quanto trabalho a IA executa de ponta a ponta, com qualidade mensurável e retorno econômico claro.

Concordo com o diagnóstico, mas quero puxar o fio para onde ele realmente se resolve: no código, não na reunião de board. Porque a distância entre "ter um agente rodando" e "ter um agente que gera valor" não se fecha com mais prompt engineering. Fecha-se com disciplina de teste, a mesma que qualquer time maduro já aplica a software que não tem uma linha de IA.

Do chatbot ao agente: a diferença que ninguém está medindo

Smaira dá um exemplo bom: um chatbot diz ao cliente se ele pode devolver um produto; um agente localiza o pedido, consulta a política, emite a etiqueta, acompanha o retorno ao estoque e dispara o reembolso. No primeiro caso a IA ajuda alguém a trabalhar. No segundo, ela executa parte do trabalho sozinha.

A diferença parece sutil, mas muda tudo sobre o que precisa existir ao redor do sistema. Um chatbot que erra gera um ticket chato. Um agente que erra altera um pedido real, aprova uma transação real ou mexe num sistema crítico de verdade. O risco deixou de ser conversacional e virou operacional.

E aqui está o ponto que eu acho mais importante para quem constrói: a maioria das empresas brasileiras, segundo o próprio autor em conversas com grandes companhias, já não tem problema de acesso a bons modelos. O gargalo é administrá-los. Dezenas de agentes em produção, e ninguém sabe ao certo quais geram valor, quanto custam ou onde falham.

Evals são o CI/CD que falta no seu pipeline de IA

Aqui o texto do Brazil Journal usa um termo que todo engenheiro já deveria reconhecer, só que aplicado a um domínio novo: evals. São as avaliações que medem qualidade, eficiência e confiabilidade do trabalho de um agente, do mesmo jeito que um time de produto usa OKRs para medir gente.

Traduzindo para quem escreve código: eval é teste automatizado para comportamento de modelo. Não basta dizer que um agente de atendimento "está atendendo bem". É preciso saber:

• Que percentual de casos ele resolve corretamente, com critério verificável e não impressão subjetiva.
• Em que situações ele deveria escalar para um humano e não escala (ou escala demais).
• Quais erros são toleráveis e quais são inaceitáveis, categorizados por severidade.
• Quanto custa, em dinheiro e tempo, cada resolução correta.

Sem essa camada, o agente é um experimento travestido de produto. Com ela, vira disciplina de engenharia, com o mesmo rigor que você já aplica a uma suíte de testes de integração antes de um merge em main.

O indicador que separa quem evolui de quem estagna

O exemplo mais concreto do texto é também o mais útil para engenharia. Duas empresas com agentes de qualidade parecida: na primeira, identificar uma falha, corrigir e validar uma nova versão leva seis semanas. Na segunda, as interações de produção alimentam os evals automaticamente, cada erro novo vira caso de teste, e regressões aparecem antes de chegar ao cliente. O ciclo leva dois dias.

Se eu tivesse que escolher um único indicador para avaliar a estratégia de IA de uma empresa, seria este: quanto tempo leva para um erro em produção virar um teste e a correção chegar ao cliente.

Lucas Smaira, co-fundador da Vetto AI e ex-pesquisador do Google DeepMind

Esse indicador é, essencialmente, lead time de correção, o mesmo conceito que o DevOps↳DevOps29 conteúdosHabilite o Código de Segurança Azure DevOpsDevSecOps · jun 2025O que é DevOps – minha experiência como executivo nessa frenteDev (Back & Front) · abr 2026DevOps: a automação de processos de TI como estratégia de eficiência operacionalDev (Back & Front) · set 2024Ver tudo em DevSecOps → Research and Assessment (DORA) já usa há anos para medir maturidade de entrega de software. A novidade não está na métrica, está em aplicá-la a sistemas que tomam decisão probabilística em vez de executar lógica determinística. É um problema de observabilidade e pipeline, não de modelo.

O contra-argumento que o texto não encara de frente

Aqui preciso discordar de um ponto, ou pelo menos completá-lo. O texto cita programação e matemática como os domínios onde os modelos avançam mais rápido, justamente porque é possível verificar se a resposta está certa. Isso é verdade, e é exatamente o motivo pelo qual construir evals para esses domínios é relativamente barato: existe função de verificação objetiva (o código compila, o teste passa, a prova fecha).

O problema é que boa parte do trabalho corporativo não tem essa propriedade. Avaliar se um agente de atendimento "resolveu bem" um caso ambíguo, se um agente de vendas conduziu uma negociação de forma aceitável, ou se um agente jurídico interpretou um contrato de maneira razoável, exige critério humano, nem sempre redutível a métrica binária. Construir evals confiáveis para tarefas de julgamento é um projeto de engenharia tão grande quanto o próprio agente, às vezes maior.

Isso cria um risco que o texto não menciona: empresas vão naturalmente automatizar primeiro o que é fácil de medir, não o que gera mais valor. O resultado pode ser um ecossistema de agentes excelentes em tarefas triviais e verificáveis, e ainda tão imaturos quanto hoje nas tarefas que realmente movem receita, porque essas são as difíceis de avaliar.

O que muda para quem constrói isso

Se você é quem escreve o código do agente, não quem assina o relatório de resultado trimestral, a mensagem prática é direta: parar de medir sucesso em número de agentes publicados ou tokens consumidos, e começar a instrumentar cada agente como se fosse um serviço em produção com SLO.

Isso significa, na prática:

1. Definir, antes de publicar um agente, qual é o critério de sucesso verificável para a tarefa dele, não depois.
2. Construir um harness de eval que rode a cada mudança de prompt, de modelo ou de ferramenta, como um teste de regressão.
3. Instrumentar produção para capturar casos reais de falha e convertê-los automaticamente em novos casos de teste, fechando o ciclo que o texto chama de recursive self-improvement em miniatura.
4. Priorizar, pelo menos no começo, tarefas com critério de sucesso objetivo, e tratar tarefas de julgamento como projeto à parte, com avaliação humana amostral.

O ponto final do texto do Brazil Journal é que acesso ao melhor modelo deixará de ser vantagem competitiva, porque todo mundo vai ter acesso a modelos muito bons. Concordo, e completo: a vantagem vai estar em quem já tiver a infraestrutura de teste madura quando esse momento chegar. Isso não se compra em uma rodada nem se contrata num fim de semana. É trabalho de engenharia, construído caso a caso, eval por eval, igual sempre foi com software que ninguém queria ver quebrar em produção.

Fonte: Brazil Journal