IA por dentro do ERP legado: o que muda quando o agente grava por dentro

Durante anos, a conversa sobre IA em operações industriais girou em torno de dashboards, copilots e análises preditivas. Todas essas ferramentas têm algo em comum: ficam do lado de fora do sistema que realmente manda. O ERP legado, com seus campos crípticos e sua lógica de negócio encapsulada em décadas de customização, continua sendo onde a operação vive. E a IA, na maioria das implementações, continua batendo na vitrine.

Por que a integração por fora é estruturalmente frágil

A resposta direta é que APIs e middlewares foram construídos para expor dados, não para executar operações. Quando uma ferramenta externa tenta criar um pedido de compra via integração, ela enfrenta o mesmo problema de sempre: a lógica de validação, os gatilhos de workflow, as regras de aprovação e os campos obrigatórios condicionais existem dentro do ERP. A integração por fora precisa reimplementar parte dessa lógica, e inevitavelmente fica desatualizada à medida que o sistema evolui.

O resultado é o que equipes de TI conhecem bem: integrações que quebram a cada atualização do ERP, campos que somem sem aviso, comportamentos que funcionam em homologação e falham em produção. A manutenção dessas pontes consome energia que a equipe deveria dedicar à evolução do sistema. O custo não aparece em nenhum orçamento formal, mas aparece em todo ciclo de atualização.

O que significa gravar transacionalmente por dentro do ERP

Gravar transacionalmente por dentro significa que o agente opera como um usuário nativo do sistema. Ele aciona as mesmas rotinas que um operador humano acionaria: preenche campos, navega por abas, dispara validações, recebe erros e os trata. No Protheus, da TOTVS, isso passa pelas funções ExecAuto, que executam as rotinas de negócio padrão com os mesmos parâmetros que a interface gráfica usa.

A diferença vai além do puramente técnico: é operacional, e muda o que a equipe consegue fazer. Quando o agente grava por dentro, a transação passa pelo mesmo motor de regras que governa qualquer entrada humana. Se o fornecedor está bloqueado, o agente recebe o bloqueio. Se o centro de custo exige aprovação, o workflow é disparado normalmente. O ERP processa a transação, gera os lançamentos contábeis, atualiza o estoque, dispara as comunicações, tudo como deveria.

Quando o agente grava por dentro, o ERP processa a transação como se fosse um operador humano. As regras de negócio, os workflows e os controles contábeis funcionam sem exceção.

Como o Protheus resiste, e como se entra de verdade

O Protheus não foi projetado para ser consumido por agentes. As funções ExecAuto foram criadas para automação interna, não para exposição a sistemas externos. O comportamento muda conforme a versão, o patch e a customização de cada cliente. Campos que existem numa instalação não existem em outra. Mensagens de erro são genéricas e exigem interpretação contextual. O ambiente de produção, com locks de sessão e regras de concorrência, é diferente do ambiente de homologação de maneiras que só aparecem sob carga real.

Entrar por dentro exige dominar esse território: saber quais rotinas aceitam automação, como tratar retornos de erro em código numérico sem documentação pública, como gerenciar sessões sem criar locks que travem operadores humanos simultâneos. Esse conhecimento não está no manual do fornecedor. Está em anos de operação com o sistema.

O que muda na prática quando o agente vira usuário nativo

A mudança mais imediata é na velocidade. Em uma operação de mineração que acompanhamos sob NDA, o ciclo de criação de pedido de compra foi de 30 minutos para 5 minutos por pedido, com zero erros de digitação no ERP. A mesma equipe passou a processar seis vezes mais volume sem contratação adicional.

A mudança mais profunda, porém, é outra. Quando o agente opera por dentro, o registro que fica no ERP é limpo: a transação passou pelas regras do sistema, pelo caminho certo, com os dados corretos. Não há uma camada paralela de dados que precise ser reconciliada com o que o ERP registrou. Isso muda a conversa com auditoria, com o financeiro e, fundamentalmente, muda a confiança da operação no sistema.

A maioria das ferramentas de IA cria uma camada paralela de dados que depois precisa ser reconciliada com o ERP. Quando o agente grava por dentro, essa reconciliação deixa de existir.

Por que a maioria dos pilotos de IA não chega à produção

McKinsey e Deloitte têm documentado, em relatórios de transformação digital dos últimos anos, que a maioria dos projetos de IA em empresas não escala para produção. O padrão de falha é bem conhecido: o piloto funciona num ambiente controlado, com dados limpos, sem as exceções e as peculiaridades do sistema real. Quando chega à operação plena, as bordas aparecem.

No contexto de sistemas legados, esse padrão é ainda mais agudo. O piloto conecta a uma API que expõe uma fração dos dados. Funciona. Vai para produção e descobre que aquela API não atualiza em tempo real, que alguns campos não estão disponíveis via integração, que a regra de negócio que o piloto ignorou é exatamente a que mais aparece no dia a dia. Entrar pelo caminho certo desde o começo é o que diferencia projetos que chegam à produção dos que ficam em piloto permanente: operar por dentro, com as mesmas restrições e os mesmos controles que a operação real exige.

Governança e rastreabilidade quando o agente escreve no ERP

A objeção mais comum que ouvimos é sobre controle. Se o agente escreve diretamente no ERP, quem responde quando algo dá errado? A resposta começa no próprio sistema: o Protheus registra quem fez o quê, quando, com qual usuário. Um agente configurado corretamente opera com um usuário de sistema rastreável, com permissões específicas, sem acesso a operações fora do seu escopo definido.

O que se adiciona é uma camada de supervisão no nível do agente: cada decisão tomada, cada transação executada, cada erro tratado fica registrado no sistema de orquestração. Em vez de perder rastreabilidade, ganha-se uma dupla camada: o que o ERP registrou e o raciocínio que levou o agente àquela transação específica. Para auditoria, isso representa mais visibilidade do que qualquer planilha de controle manual consegue oferecer.

O que é necessário para chegar lá

Três pré-requisitos raramente aparecem nas conversas de venda sobre IA em ERP. Primeiro: conhecimento profundo do sistema de destino, não o manual de integração, mas o comportamento real em produção, com os patches instalados, com as customizações do cliente, com os volumes e as concorrências do dia a dia. Segundo: infraestrutura de orquestração que trate falha como estado normal. O ERP vai retornar erros. O agente precisa saber o que fazer com cada um deles: tentar novamente, escalar para um humano, pausar e aguardar uma condição.

Terceiro: uma fase de estabilização real em produção, não uma extensão do piloto em ambiente controlado. Os primeiros ciclos operacionais vão revelar comportamentos que o ambiente de testes não revelou. O processo de aprendizado com esses comportamentos e de ajuste do agente é onde o valor real se consolida, e onde a distância entre o que foi vendido e o que funciona de fato é eliminada.

Um agente que para diante do primeiro erro do ERP não é um agente de produção. A diferença entre piloto e operação está em como o sistema trata a falha.

Quer ler a sua operação a fundo?