Como integrar agentes de IA ao ERP sem migrar nada

A premissa de que é preciso substituir o ERP para implementar agentes de IA é, na prática, o maior inibidor de adoção em empresas com sistemas estabelecidos. O padrão que chega à produção preserva o ERP como fonte da verdade imutável, empilhando camadas de decisão agêntica por cima via APIs, pontes de RPA e event hooks, sem tocar no núcleo do sistema. Isso não é uma solução de contorno: é arquitetura.

A McKinsey reporta, em seus surveys anuais sobre adoção de IA, que a maioria dos projetos de inteligência artificial corporativa não passa da fase piloto. Um dos fatores recorrentes nesse bloqueio é a crença de que a integração exige modernização prévia da stack, o que gera cronogramas de 18 a 36 meses antes de qualquer valor entregue. A abordagem oposta, conectar agentes ao sistema existente sem alterá-lo, reduz esse ciclo para semanas.

Por que você não precisa migrar o ERP para usar agentes

ERPs como o TOTVS Protheus carregam décadas de regras de negócio, customizações e dados históricos que nenhuma migração replica fielmente. Preservar o ERP como núcleo significa reconhecer que o risco de perda de dados e regras em uma migração é sistematicamente subestimado. Com agentes de IA, o que muda é quem processa esses dados e como as decisões são tomadas antes de qualquer gravação, não onde os dados vivem.

Na prática, isso significa que o ERP continua sendo o repositório de registro para pedidos, estoques, fornecedores e lançamentos contábeis. Os agentes operam em uma camada separada: consomem dados via API ou leitura de eventos, raciocinam sobre eles, e só interagem com o ERP quando têm uma ação a executar, seja uma criação de pedido, uma aprovação ou uma consulta de saldo. A linha entre leitura e escrita no ERP é a linha mais importante dessa arquitetura.

As três pontes que conectam agentes a sistemas legados

Existe um espectro de opções de integração, e a escolha depende do que o ERP expõe. As três pontes mais usadas em produção são: APIs REST nativas, pontes de RPA e event hooks baseados em banco ou fila de mensagens.

APIs REST nativas são o caminho preferencial quando disponíveis. O Protheus expõe endpoints REST via servidor TOTVS Framework, permitindo que agentes consultem pedidos, criem solicitações de compra ou atualizem registros via chamadas HTTP padrão. Essa camada é tipicamente versionada, documentada e menos frágil do que acesso direto ao banco. O agente autentica, faz a chamada, trata o retorno e decide o próximo passo.

Pontes de RPA entram quando não há API, ou quando o processo existe apenas na interface gráfica do ERP. O agente instrui um robô de automação a navegar nas telas, preencher campos e confirmar ações, como se fosse um operador humano. É mais frágil do que uma API, mas preserva o mesmo princípio: o ERP não é modificado, e os dados gravados passam pelas mesmas validações do sistema original.

Event hooks baseados em banco ou fila de mensagens são a terceira via, mais sofisticada. O ERP publica eventos, seja via triggers de banco, tabelas de fila internas (como as filas nativas do Protheus) ou um middleware de integração, e os agentes consomem esses eventos de forma assíncrona. Esse padrão é ideal para operações de alto volume onde latência baixa e resiliência a falhas são requisitos.

Quando não existe API: como agentes operam em ERPs sem endpoints

Muitos ERPs de médio porte e versões antigas do Protheus não têm camada REST ativa. Nesses casos, a integração exige uma camada de mediação. As opções mais comuns são: ativação e configuração da camada REST nativa (quando o produto suporta mas nunca foi configurado), acesso via banco de dados com uma camada estritamente de leitura, e RPA para as operações que só existem em tela.

A leitura direta de banco, quando usada, deve ser estritamente leitura. Gravações feitas fora do sistema passam ao largo das validações, triggers e regras de negócio embutidas, criando inconsistências que são difíceis de rastrear e impossíveis de auditar. O agente que lê o banco e escreve via interface ou API preserva a integridade. O agente que grava direto no banco cria dívida técnica imediata.

Gravar diretamente no banco do ERP sem passar pela camada de aplicação é o caminho mais rápido para criar dados inconsistentes que o próprio sistema não consegue validar.

TOTVS Protheus como arquitetura de referência

O Protheus é o ERP mais implantado no Brasil e serve como caso de uso concreto para praticamente todos os padrões de integração agêntica. Sua arquitetura tem três pontos de entrada relevantes para agentes: o servidor REST via TOTVS Framework, as funções ExecAuto para automação de processos internos, e as filas de integração nativas para troca de mensagens assíncronas.

Em um dos projetos que conduzimos em ambiente de mineração, integramos agentes ao fluxo de compras do Protheus via REST: o agente recebia solicitações em linguagem natural, consultava cotações, validava regras de aprovação e criava pedidos diretamente no sistema. O resultado foi uma redução de 30 para 5 minutos no tempo médio por pedido, zero erros de registro no ERP e a mesma equipe operando com 6 vezes mais capacidade de processamento. O Protheus não foi alterado, e todas as rastreabilidades e aprovações continuaram funcionando dentro do sistema.

O ponto crítico na integração com o Protheus é o mapeamento de TES (Tipo de Entrada e Saída) e a validação de fornecedor antes de qualquer criação de pedido. Agentes que pulam essas validações geram erros 422 no endpoint REST. A solução é consultar essas tabelas via GET antes de submeter o POST, como parte do fluxo de raciocínio do próprio agente.

No Protheus, o agente bem integrado não tenta adivinhar: ele consulta primeiro, valida depois, e só então grava. Esse ciclo é o que garante zero erros no ERP.

Como garantir que o ERP permanece a única fonte da verdade

A tentação arquitetural mais comum é criar um banco de dados paralelo para os agentes, com dados sincronizados do ERP. Isso resolve latência no curto prazo e cria inconsistência no médio prazo. Se o ERP e o banco do agente divergem, qual é a verdade? A resposta prática: não crie repositórios paralelos de dados operacionais. Use o ERP como repositório de registro e mantenha nos agentes apenas estado de sessão e contexto de raciocínio.

Isso implica que cada ação do agente com efeito no negócio, seja uma compra, uma aprovação ou uma atualização de estoque, precisa terminar com uma gravação no ERP. O agente pode ter raciocínio intermediário em memória ou em banco auxiliar, mas o estado final do processo vive no ERP. Esse princípio garante auditabilidade e reversibilidade sem depender de sincronização frágil entre sistemas.

Governança: quando e como o agente pode escrever no ERP

A questão de autonomia de escrita é onde a maioria das implementações vacila. Agentes que escrevem no ERP sem supervisão humana geram resistência nas equipes de operação, com razão. Agentes que precisam de aprovação humana para cada ação não entregam o valor prometido. O equilíbrio está no design do envelope de autonomia.

A abordagem que funciona em produção é baseada em limiares: o agente tem permissão irrestrita para ler e consultar, permissão condicional para escrever dentro de parâmetros predefinidos (valor abaixo de X, fornecedor aprovado, categoria autorizada) e encaminha para aprovação humana tudo o que excede esses limites. Esse envelope é definido em conjunto com o cliente antes da implantação e codificado como regra, nunca como instrução em prompt.

Autonomia sem limites definidos gera risco sem nome. O envelope de decisão do agente precisa ser acordado com o negócio antes de qualquer linha de código ser escrita.

Checklist de auditoria antes de contratar uma integração agêntica

Antes de assinar qualquer proposta de integração de agentes com ERP e sistemas de back-office, há um conjunto de verificações que o comprador deve conduzir internamente. Elas determinam a complexidade real do projeto e evitam surpresas após o início do engajamento.

Primeiro: o ERP expõe API REST ativa? Qual versão? Há documentação dos endpoints relevantes para o processo alvo? Segundo: onde estão as regras de negócio, no ERP, em planilhas externas, na cabeça das pessoas? Regras fora do ERP precisam ser codificadas antes de qualquer agente poder segui-las. Terceiro: o ERP tem gestão de credenciais por serviço, ou apenas por usuário? Agentes precisam de credenciais de serviço com permissões mínimas, nunca credenciais pessoais reutilizadas.

Quarto: o volume e a frequência das operações alvo são compatíveis com a ponte escolhida? RPA funciona para baixo volume, APIs funcionam para qualquer volume, filas assíncronas são necessárias a partir de certo volume por segundo. Quinto: quais decisões hoje passam por um humano? Esses são os pontos onde o design do envelope de autonomia vai ser mais contestado. Sexto: há um ambiente de homologação do ERP disponível para testes? Integrar agentes diretamente em produção sem sandbox é um risco desnecessário e frequentemente evitável.

Esses seis pontos não resolvem todos os riscos, mas revelam os que vão custar mais caro se descobertos depois do início do projeto. Uma integração bem-sucedida começa antes da primeira reunião técnica.

Quer ler a sua operação a fundo?