Seu agente não erra na tela, erra no banco

Um benchmark publicado no arXiv colocou seis agentes de IA para trabalhar dentro de um ERP real e mediu o resultado onde ele importa: no banco de dados. A distância entre "salvou" e "salvou certo" é grande o bastante para mudar o critério de aceite de qualquer projeto de automação.

Existe um tipo de erro que não aparece.

O agente abre o sistema, navega até o formulário certo, preenche os campos, clica em salvar. A tela confirma. O print da execução mostra sucesso. E o registro gravado está errado.

Esse é o achado central do ERPBench, benchmark publicado como preprint no arXiv em 15 de setembro de 2026 por Kratika Bhagtani, Kusha Sridhar, Maziyar Baran Pouyan, Yuying Zhao e Eugene Siow. A proposta é simples de enunciar e desconfortável de encarar: avaliar agentes que operam só por captura de tela e ações simuladas — os chamados *computer-use agents* — dentro de um ERP de verdade, e pontuar cada tarefa contra o valor real gravado no banco, não contra o que a interface mostrou.

A mudança de régua é o ponto. Não é um benchmark mais difícil. É um benchmark que mede outra coisa.

1. O que o ERPBench faz de diferente

A avaliação de agentes de computador amadureceu em cima de tarefas de desktop genérico e de navegação web. Os autores argumentam que ERPs impõem desafios distintos: interfaces densas, interações coordenadas de vários passos e erros que alteram registros de negócio persistentes em vez de se manifestarem na tela.

O benchmark roda sobre o ERPNext, ERP de código aberto, instalado localmente em Docker — escolha que torna o ambiente reproduzível, ao contrário de plataformas proprietárias fechadas. São 30 tarefas distribuídas em três níveis de complexidade, cobrindo finanças, compras, estoque e gestão de clientes: desde a edição de um campo único até fluxos encadeados que atravessam várias telas e ligam documentos dependentes entre si. Cada tarefa é executada cinco vezes de forma independente, o que dá 150 execuções por modelo.

Junto ao benchmark, os pesquisadores apresentam também um harness de produção que submete as ações do agente a aprovação humana antes de executá-las. O ERPBench roda esse mesmo harness em modo autônomo.

2. Chegar no formulário não é o mesmo que gravar o dado

Os resultados separam três coisas que costumam ser tratadas como uma só: chegar ao registro certo, disparar o salvamento e deixar o valor correto no banco.

Nas tarefas de nível 1 — as mais simples, de edição de registro único —, a tabela do estudo fica assim:

*T1: edição de registro único. T3: fluxos encadeados em várias telas. Dados das tabelas do preprint.*

A linha do UI-TARS-7B é a que merece atenção, e os próprios autores a destacam: o agente "chega ao alvo em 95% das execuções e dispara um salvamento em 68%, mas apenas 9% deixam o valor correto no banco de dados, de modo que quase todo salvamento que ele confirma está errado".

Leia de novo essa proporção. Não é um agente que falha e avisa. É um agente que conclui, confirma e entrega lixo.

No abstract, os autores resumem o padrão de forma ainda mais direta: alguns agentes salvam em até 85% das execuções e escrevem o valor correto em apenas 3%. E a conclusão que eles tiram do conjunto é a frase que deveria circular em qualquer comitê de automação: desempenho forte em interface gráfica geral não se transfere para confiabilidade empresarial.

Há uma exceção relevante, e ela não deve ser lida como conforto. Um único modelo proprietário, o Claude Sonnet 4.6, atingiu patamar próximo ao humano — e o estudo tem referência humana: três anotadores executaram as mesmas tarefas na mesma instância, pontuados pelo mesmo verificador de banco. Os usuários experientes ficaram entre 95% e 100%. Mesmo o anotador que nunca havia usado o ERPNext antes chegou a 87% no nível mais difícil, acima de todos os modelos de peso aberto testados.

3. Os cinco jeitos de quebrar

O estudo organiza as falhas numa taxonomia, e ela é útil muito além do paper — porque é um vocabulário para conversar com fornecedor.

Quatro dessas falhas são barulhentas. A tarefa não completa, o fluxo trava, alguém percebe.

A quarta é silenciosa. E é a única que gera passivo contábil.

4. Onde isso encosta na sua operação

Aqui a leitura deixa de ser sobre modelos e passa a ser sobre processo — e é uma interpretação minha, não uma conclusão do estudo.

O gargalo do agente empresarial não é a inteligência do modelo. É a ausência de critério de verificação no processo que o recebe.

Quando uma empresa avalia automação de contas a pagar, de compras ou de movimentação de estoque, a demonstração quase sempre é visual: alguém mostra a gravação da execução, o agente navegando, o formulário sendo preenchido, a mensagem de confirmação. É uma demonstração de interface. O ERPBench mostra, com método, que interface e estado do dado são duas variáveis diferentes — e que a primeira não prova a segunda.

Um erro de agente em ERP não gera tela vermelha. Gera um lançamento errado que só aparece no fechamento, quando o rastro de quem fez o quê já esfriou.

O que isso muda na prática é o aceite. Critério de aceite de automação em sistema de registro não pode ser o print da execução. Tem que ser o estado do dado, verificado contra uma fonte independente, com conciliação e trilha de auditoria.

E existe uma pergunta anterior a essa, que a maioria das empresas descobre que não sabe responder:

**Antes de plugar agente em ERP**

- Qual é o "dado-verdade" desse processo — o valor que define, sem ambiguidade, que a tarefa deu certo?

- Esse dado já existe hoje, sem o agente? Alguém consegue consultá-lo?

- Quem confere, com que frequência, e em quanto tempo um erro seria detectado?

- O que acontece com o registro errado entre a gravação e a detecção?

- Existe reversão, ou só correção manual no fechamento?

Onde a empresa não sabe dizer qual estado do dado define sucesso, o agente não resolve a incerteza. Ele só a acelera.

Isso, aliás, não é um problema de IA. É um problema de processo que a IA torna visível — e caro. Automatizar uma etapa que ninguém sabe conferir é escalar uma falha de controle que já existia.

5. Os limites do que foi mostrado

Vale dizer com clareza o que o estudo não é.

É um preprint, sem revisão por pares, submetido para avaliação na ICASSP 2027 e ainda sem replicação independente. São 30 tarefas em uma instância padrão do ERPNext — não um ERP customizado, com integrações, permissões, campos próprios e exceções de processo, que é o que existe na vida real de qualquer empresa com alguns anos de operação. O recorte de modelos é de um momento específico do mercado, e essa é a variável que envelhece mais rápido: um resultado ruim em setembro de 2026 pode não descrever o mesmo modelo dali a dois trimestres.

Há ainda uma limitação que os próprios autores registram e que corta nos dois sentidos: o harness de produção submete as ações a aprovação humana. Isso protege, mas também pode mascarar erros que uma operação autônoma deixaria passar.

Benchmark não é operação. Desempenho em ambiente controlado não se traduz automaticamente em ambiente real — nem para pior, nem para melhor.

Mas nada disso enfraquece o ponto metodológico, que é o que interessa a quem decide. A contribuição do ERPBench não é o placar. É a régua.

Se a sua avaliação de um agente termina na tela, você não avaliou o agente. Avaliou o vídeo dele.