Benchmark de IA não é resultado de negócio: como testar agentes em processos reais

A OpenAI divulgou em 2 de novembro o LifeVal, uma avaliação de modelos em tarefas cotidianas. Segundo a empresa, o GPT-6 Astra obteve 80% de desempenho geral, contra 49,3% do GPT-5.2. A reportagem da CNN Brasil detalha exemplos como encontrar uma creche, organizar finanças e planejar refeições. São números interessantes. Mas não respondem à pergunta que uma liderança empresarial precisa fazer: esse agente melhora o resultado do meu processo, com os meus dados, sistemas e regras?

Essa distinção importa. Um benchmark pode mostrar que um modelo se saiu bem em tarefas construídas para uma avaliação. Não prova, por si só, que uma empresa vai atender melhor, gastar menos ou operar com segurança. Para chegar a essa conclusão, é preciso testar o sistema no contexto em que ele será usado.

O que um benchmark consegue mostrar — e o que não consegue

O LifeVal tenta aproximar a avaliação de tarefas do cotidiano, em vez de medir apenas respostas de conversa. De acordo com a reportagem da CNN, a OpenAI usou pesquisas sobre uso do tempo e entrevistou cerca de 4 mil pessoas para identificar atividades em que gostariam de receber ajuda. Um grupo menor descreveu tarefas e critérios para avaliar se foram concluídas. Isso dá ao benchmark uma intenção prática: observar se o modelo consegue executar etapas, usar contexto e chegar a um resultado definido.

Ainda assim, a avaliação foi criada e os resultados foram divulgados pela própria OpenAI, que apresentou pontuações de seus modelos. Isso não invalida o teste. Significa que devemos entender sua finalidade e seus limites: ele pode indicar evolução dentro daquela avaliação, mas não é uma comparação independente de todos os fornecedores nem uma medição do desempenho em cada empresa.

Um resultado agregado também esconde diferenças entre tarefas. Uma média alta não revela necessariamente quais casos falharam, se os erros foram graves ou quantas tentativas, chamadas de ferramenta e revisões humanas foram necessárias. E a conclusão de uma tarefa em ambiente de teste não garante que a operação real tenha dados tão organizados, instruções tão claras ou integrações igualmente disponíveis.

A unidade de teste deve ser o processo, não a demonstração

Quando avalio um agente para uma empresa, começo por delimitar um processo com começo, fim e responsável. Por exemplo, não basta pedir que o sistema “ajude no atendimento”. É melhor definir uma tarefa como consultar o histórico, verificar uma política de troca, propor a resposta e encaminhar para aprovação quando faltar informação ou houver exceção.

A equipe precisa estabelecer o que conta como sucesso antes de rodar o teste. A resposta correta é suficiente ou o agente também precisa atualizar o sistema, respeitar o prazo e registrar a decisão? O que deve acontecer diante de uma solicitação ambígua, de um dado ausente ou de uma instrução que contrarie a política? Sem critérios prévios, qualquer resultado pode parecer bom depois que já se conhece a pontuação.

Como desenhar um piloto que gere evidência

1. Use casos reais e representativos

Monte uma amostra que reflita o volume e a variedade do trabalho: casos comuns, exceções, dados incompletos, solicitações contraditórias e situações em que a resposta correta é não agir. Inclua exemplos que não foram usados para ajustar instruções ou selecionar o modelo. Se o teste só contém casos limpos, ele mede a capacidade de passar por uma demonstração, não de suportar a rotina.

2. Avalie o resultado e o caminho até ele

Registre se a tarefa foi concluída corretamente, mas examine também como: quais ferramentas foram acionadas, que dados foram consultados, se houve repetição, se o sistema excedeu permissões ou se precisou de intervenção. Um agente que chega à resposta certa depois de expor informação indevida ou fazer uma alteração não autorizada não teve sucesso operacional.

3. Meça custo, tempo e revisão humana

Acompanhe a latência de ponta a ponta, o custo de modelos e ferramentas, as tentativas repetidas e o tempo gasto por quem revisa ou corrige. Compare o custo por tarefa concluída corretamente, não apenas o preço de uma chamada ou a taxa de acerto. Se uma automação aumenta a taxa de conclusão, mas exige revisão manual extensa, o benefício líquido pode ser pequeno ou inexistente.

4. Teste segurança e limites de autonomia

Defina quais dados o agente pode acessar, que ações pode executar e quais exigem aprovação. Teste instruções maliciosas ou enganosas em documentos e páginas, tentativas de obter dados fora do escopo e falhas de integração. A revisão humana deve ocorrer no ponto de impacto — antes de enviar uma mensagem sensível, alterar um cadastro ou autorizar uma transação — e não ser tratada como um carimbo genérico no início do fluxo.

5. Compare com a linha de base

Meça o processo atual com os mesmos critérios. A comparação deve considerar qualidade, tempo, custo total, retrabalho e impacto para quem recebe o serviço. Quando possível, rode o piloto em modo de observação ou em um escopo controlado antes de permitir ações reais. Assim, a equipe aprende com falhas sem confundir uma boa resposta em teste com autorização para automatizar toda a operação.

A avaliação precisa continuar depois do piloto

Um piloto não encerra o trabalho. Mudanças no modelo, nas ferramentas, nas políticas ou nos dados podem alterar o comportamento. Por isso, é importante manter registros, acompanhar erros e revisar periodicamente os casos de maior risco. O NIST descreve o TEVV-Athlon como uma abordagem flexível para construir avaliações ajustadas aos objetivos de organizações e aplicações, incluindo sistemas agênticos. A ideia central é justamente produzir evidência relevante para o uso pretendido, em vez de tratar uma métrica universal como resposta para todos os contextos.

O guia do NIST sobre o TEVV-Athlon reforça uma noção útil: testar, avaliar, verificar e validar são atividades para reunir evidências de que um sistema atende a objetivos definidos e minimiza impactos negativos. Para a empresa, isso significa traduzir objetivos de negócio em testes concretos e acompanhar se o sistema continua atendendo a eles.

O número que importa é o valor no seu contexto

Benchmarks como o LifeVal são úteis porque ampliam a conversa: agentes precisam fazer mais do que produzir uma resposta convincente. Mas a passagem de uma avaliação para uma operação exige outra camada de evidência. É preciso saber se o sistema resolve o trabalho, se respeita limites, quanto custa e como se comporta quando o processo sai do roteiro.

Eu não escolheria um agente só porque lidera uma tabela, nem descartaria uma tecnologia por um resultado isolado. O melhor caminho é testar opções nos mesmos casos relevantes, com critérios acordados, linha de base e limites de risco. A pergunta final não é qual modelo venceu o benchmark. É: qual processo da sua empresa melhorou de forma mensurável, segura e sustentável depois que o agente entrou nele?