Imagine a diretora de operações de uma indústria farmacêutica de médio porte. O SAP roda há sete anos. Os processos de supply chain estão estabilizados, os dados históricos são confiáveis, o time conhece o sistema. Aí chegam os consultores com apresentações sobre IA, e o board começa a fazer perguntas depois de ler relatórios da McKinsey. A pergunta que fica presa na cabeça dela não é se a IA funciona. É uma pergunta mais concreta: "Para conectar IA ao nosso SAP, vamos precisar trocar tudo?"
A resposta é não, mas o "não" precisa de uma explicação. Agentes de IA não substituem ERPs. Eles ficam em cima deles, lendo e escrevendo dados pela mesma camada de API que outros sistemas já usam hoje. O paralelo mais direto é o aplicativo de banco no celular: o app não substituiu os sistemas do banco, não tocou no banco de dados principal, não reformulou o processo de compensação. Ele se conectou aos sistemas existentes via API e ofereceu uma nova interface para operações que já existiam. Integrar IA ao ERP funciona pelo mesmo princípio: a infraestrutura central continua intacta, o agente se encaixa por cima.
Por que as empresas brasileiras estão integrando IA ao ERP agora
Esta não é uma seção sobre hype. É sobre três mudanças estruturais que tornaram 2025-2026 o momento certo para integração IA-ERP em operações industriais brasileiras, especificamente.
Os ERPs chegaram à maturidade de API. O TOTVS Protheus nas versões 12.1.2310 e posteriores tem o REST Framework estável. O SAP S/4HANA disponibiliza OData APIs em todas as versões cloud. O Oracle NetSuite oferece SuiteQL para consultas estruturadas por API. Cinco anos atrás, essas camadas ou não existiam ou estavam em estágio beta. Hoje são infrastructure-grade: documentadas, versionadas, com SLA de disponibilidade. A plomagem para conectar um agente externo ao ERP existe e funciona em produção.
O custo de não decidir ficou mensurável. A Gartner documentou que interrupções na cadeia de suprimentos custam às empresas, em média, 45% do lucro anual ao longo de um período de 10 anos. No Brasil, a combinação de volatilidade de fornecedores, flutuação cambial e a complexidade logística de nota fiscal e SPED torna as decisões de supply chain especialmente sensíveis a erros de timing. Um pedido de reposição que deveria ter saído na segunda-feira e saiu na quinta custa diferente no Brasil do que em mercados com logística mais previsível.
por interrupções em 10 anos
com agentes Think Process
documentado em clientes
Fontes: Gartner, 2020 (dado de custo de interrupções); dados operacionais documentados pela Think Process em clientes industriais brasileiros.
Os modelos de IA chegaram ao ponto onde fazem o que prometem, para problemas específicos. A frase que importa aqui é "para problemas específicos". IA que tenta otimizar a cadeia inteira de uma vez geralmente falha. IA treinada nos dados operacionais de uma empresa para uma decisão específica, como calcular o ponto de ressuprimento dos 100 SKUs de maior receita ou identificar fornecedores com desvio acima do histórico, performa de forma previsível e auditável. A especificidade não é limitação: é o que torna o resultado confiável o suficiente para operar em produção.
Os 5 modelos de integração IA + ERP
Cada modelo abaixo representa uma arquitetura distinta, com casos de uso, pré-condições e tradeoffs diferentes. Na prática, a maioria dos deployments em produção combina mais de um.
Integração via API REST (leitura e escrita direta)
O padrão mais comum e mais confiável. O agente de IA autentica com a API do ERP, lê dados operacionais (níveis de estoque por SKU, ordens de compra abertas, performance histórica de fornecedores) e escreve decisões de volta no sistema. Criar um rascunho de pedido de compra, atualizar um parâmetro de estoque de segurança, registrar uma exceção para revisão humana: tudo via chamadas REST, sem intervenção manual.
Integração via middleware (camada de eventos)
Em vez de conectar direto ao ERP, o agente se conecta a uma camada de middleware (MuleSoft, Dell Boomi, Azure Integration Services, ou uma solução customizada) que gerencia o fluxo de dados entre sistemas. O middleware cuida da transformação de formatos, do enfileiramento de mensagens e do tratamento de erros. O agente assina eventos, como stock_updated, order_received ou supplier_delay_detected, e publica ações de volta, como create_reorder ou update_safety_stock.
A vantagem central é a desacoplagem: o agente não precisa saber como cada sistema funciona internamente. Ele conversa com o middleware, que faz as traduções.
Camada de agente sobre dados replicados (data lake pattern)
Os dados do ERP são replicados para um data warehouse ou data lake (BigQuery, Snowflake, ou mais simples: PostgreSQL com ETL agendado). O agente opera sobre os dados replicados e nunca consulta o ERP de produção diretamente. Quando o agente chega a uma decisão, envia as instruções de volta ao ERP por uma API de escrita controlada.
Para análises que exigem histórico longo, como previsão de demanda com 18 meses de dados ou cálculo de lead time efetivo por fornecedor, operar sobre uma cópia analítica é a abordagem certa: sem impacto no ERP de produção, sem limitação de memória, com capacidade de rodar modelos sobre o dataset completo.
Integração via RPA + AI (para ERPs sem API)
Quando o ERP não tem camada de API, ferramentas de RPA (UiPath, Automation Anywhere, Blue Prism) leem e escrevem dados simulando as interações que um usuário faria pela interface gráfica. O agente de IA gera a decisão; o RPA executa navegando pela tela do ERP como um operador humano faria.
Aqui vale ser direto sobre os tradeoffs: RPA é frágil. Qualquer mudança de layout na interface do ERP, uma atualização de versão, uma alteração de campo, pode quebrar o fluxo automatizado. Este modelo é adequado como solução de ponte enquanto a empresa atualiza para uma versão com suporte a API, não como arquitetura permanente. Projetos que tratam RPA como destino final tendem a acumular custo de manutenção crescente.
Integração híbrida (o mais comum em produção)
Na prática, a maioria dos deployments de produção combina os modelos anteriores. O agente lê de uma camada de dados replicados para análise histórica (Modelo 3), usa chamadas de API diretas para dados de estoque em tempo real (Modelo 1), e roteia escritas complexas multi-sistema por middleware (Modelo 2).
Essa é a arquitetura que a Think Process usa nos deployments com clientes: dados replicados para inteligência, API direta para leituras em tempo real, API controlada para execução de decisões. Cada camada faz o que faz bem, sem sobrecarga desnecessária.
Pré-requisitos técnicos: o que verificar antes de começar
Esta é a lista que um CTO ou gerente de TI deveria percorrer antes de se comprometer com qualquer projeto de integração IA-ERP. Ela não torna o projeto mais lento, ela torna os problemas visíveis antes que apareçam no meio do desenvolvimento.
Versão do ERP e disponibilidade de API
Confirmar qual versão está instalada e se ela tem suporte a REST API. TOTVS Protheus: versões 12.1.2310+ têm o REST Framework estável. SAP S/4HANA: OData APIs disponíveis em todas as versões cloud. ERPs legados sem API: avaliar o custo de atualização versus a solução RPA bridge. A resposta a essa pergunta determina qual modelo de integração é viável.
Qualidade e histórico dos dados
O mínimo para um agente de previsão de demanda funcionar é 12 meses de histórico de vendas e movimentação de estoque, com menos de 5% de registros nulos ou corrompidos. Dados ruins geram decisões ruins, independente de qual agente os processa. Esta é a causa mais comum de falha em projetos de IA: não a tecnologia, os dados que alimentam o modelo.
Conectividade e escopo de segurança
ERP em cloud: acesso de API é nativo. ERP on-premise: requer VPN configurada ou proxy seguro para o agente se conectar. Definir as permissões antes de começar: quais tabelas o agente pode ler, quais endpoints pode escrever. O escopo de acesso mínimo necessário é diferente para cada processo sendo automatizado.
Capacidade do servidor (para ERPs on-premise)
Se o agente vai consultar o ERP de produção diretamente com alta frequência, avaliar o impacto em performance. Para instalações on-premise com recursos limitados, o data lake pattern (Modelo 3) resolve isso: o agente consulta a cópia, não o ERP de produção.
Processo de governança nos primeiros 30 dias
Quem é responsável por validar as decisões do agente na fase inicial? Há um fluxo de aprovação para pedidos acima de um determinado valor? Em quais situações o agente escala para revisão humana em vez de executar? Essas perguntas precisam ter resposta antes de o agente entrar em produção, não depois.
Integrações laterais necessárias
O agente precisa de dados além do ERP? WMS, TMS, planilhas de fornecedores, portais de compra, sistemas de qualidade? Mapear no início do projeto evita descobertas que mudam o escopo no meio do desenvolvimento. Cada sistema adicional é uma integração, um conjunto de credenciais e um contrato de dados.
Quanto tempo e quanto custa
Compradores B2B de TI têm tempo limitado e orçamentos com aprovação formal. Os números abaixo são diretos porque vagueza aqui prejudica todos os lados.
Tempo
O piloto da Think Process roda em 90 dias, o que cobre todas as fases acima com margem para iteração. A fase de testes em paralelo é onde mais projetos subestimam o tempo necessário: o agente precisa provar que suas decisões são iguais ou melhores que as decisões manuais antes de ganhar autonomia sobre o processo.
Custo
A diferença entre um piloto delimitado e um projeto de R$300k não é qualidade: é escopo. Começar com um processo, medir o resultado, e expandir o que funciona é a estratégia que produz ROI demonstrável antes de comprometer budget significativo de TI. Vendedor que insiste em escopo amplo desde o dia 1 tem incentivos diferentes dos seus.
Erros comuns que tornam projetos de integração IA-ERP mais caros
Começar com o processo errado
O processo mais importante para o negócio raramente é o melhor ponto de entrada para uma integração com IA. "Otimização completa do planejamento de demanda" envolve dezenas de variáveis, exceções de negócio acumuladas por anos e validação com múltiplas áreas. Leva meses para chegar a resultados mensuráveis. Uma decisão mais simples e de alta frequência, como a reposição automática dos 50 SKUs de maior receita, prova o conceito em 6 semanas e gera buy-in organizacional para expandir. Projetos que começam pelo mais complexo frequentemente morrem por fadiga antes de entregar resultado.
Subestimar a qualidade dos dados
Que os dados existam no ERP não significa que estejam em condição de alimentar um agente de IA. Em projetos que falharam, 60% das falhas foram causadas por problemas de qualidade de dados descobertos depois do início do desenvolvimento, não antes. Um campo de lead time preenchido como "0" porque o analista não sabia o valor real. Registros duplicados de fornecedor com nomes diferentes. SKUs descontinuados que ainda aparecem em relatórios de estoque. Uma auditoria de dados de 2 semanas antes de iniciar a integração economiza meses de debugging depois.
Não definir critérios de sucesso antes de começar
"Vamos saber que está funcionando quando sentir melhor" não é um critério de sucesso. Sem uma definição quantificada de sucesso antes do início, qualquer resultado se torna ambíguo: os defensores do projeto dizem que está ótimo, os céticos dizem que não provou nada. Um critério como "tempo de ciclo de ressuprimento para os 100 SKUs de maior receita reduzido de 4 horas para 20 minutos" é verificável, auditável e impossível de interpretar de forma conveniente. Defina o critério antes de começar, não depois de ver os primeiros resultados.
Construir em vez de integrar
Construir um modelo de IA do zero para supply chain requer uma equipe de data science, dados históricos limpos, ciclos de treinamento e validação, e no mínimo 6 a 12 meses antes dos primeiros resultados confiáveis. Agentes pré-construídos, treinados em padrões de supply chain e configurados para os dados específicos da empresa, chegam à produção em semanas e performam melhor porque foram desenvolvidos com foco em decisões operacionais reais, não em demonstrações acadêmicas.
Perguntas frequentes
Depende do modelo de integração. Integração direta por API com alta frequência de consultas pode impactar ERPs on-premise que rodam em servidores com recursos limitados. Para esses casos, o modelo recomendado é o data lake pattern: o agente lê de dados replicados e nunca consulta o ERP de produção diretamente. ERPs em cloud (SAP S/4HANA Cloud, TOTVS Fluig) lidam com requisições simultâneas de API sem impacto perceptível de performance. A avaliação da capacidade do servidor faz parte do diagnóstico inicial.
Sim, mas o envolvimento é delimitado. A equipe interna de TI precisa fornecer credenciais de API e documentação dos endpoints disponíveis, validar a arquitetura de integração proposta e aprovar o escopo de acesso aos dados. Não precisa construir nada. O desenvolvimento da integração é feito pela equipe da Think Process. O envolvimento interno de TI ao longo de um piloto de 90 dias é tipicamente de 10 a 15 horas no total, concentradas nas primeiras 2 semanas.
Integrações baseadas em API são significativamente mais resilientes a atualizações do ERP do que integrações baseadas em RPA. Vendors de ERP mantêm compatibilidade retroativa de API por 2 a 3 versões principais. Mudanças que quebram integrações existentes são anunciadas com 6 a 12 meses de antecedência no roadmap oficial. A integração vai requerer manutenção quando o ERP mudar (isso é normal e deve entrar no custo total de propriedade), mas não exige reescrita do zero. É o mesmo comportamento de qualquer integração via API: uma mudança de versão do sistema bancário não derruba o app do banco no celular, ela gera um ciclo de atualização planejado.
Somente se essas regras não estiverem configuradas. A lógica de decisão do agente é definida pela equipe do cliente durante a fase de configuração, antes de entrar em produção. Limites de valor para criação automática de pedido, preferências de fornecedor por categoria, fluxos de aprovação para exceções, e critérios de escalada para revisão humana são todos configurados como regras que o agente segue. O agente não improvisa: opera dentro dos parâmetros definidos. Situações fora desses parâmetros são escaladas para revisão, não executadas automaticamente.
A arquitetura construída no piloto é projetada para escalar. Adicionar novos processos ao agente significa estender a integração existente com novos endpoints de API e novas regras de decisão, não reconstruir do zero. O piloto de 90 dias entrega uma camada de integração em produção que serve de base para expansão. Na prática, clientes que expandem após um piloto bem-sucedido levam de 3 a 4 semanas para adicionar um segundo processo, porque a infraestrutura de conectividade, autenticação e governança já existe.
Qual modelo de integração faz sentido para a sua operação?
Se sua empresa tem um ERP ativo e quer entender onde um agente de IA encaixa na sua infraestrutura, o próximo passo é um diagnóstico de 30 minutos. A Think Process mapeia os processos com maior potencial de automação e avalia a prontidão técnica da sua infraestrutura, sem custo e sem compromisso.
Solicitar diagnóstico técnicoComeça por um diagnóstico estruturado de 30 dias. Resultado documentado, com soberania de dados LGPD.