Integrando IA com ERP: 4 padrões que funcionam em produção
Conectar um LLM a um ERP é onde a maioria dos projetos de IA empaca. Quatro padrões de integração testados em produção — e o que evitar.
A demo de IA roda lindamente na apresentação. Aí chega a hora de conectar ao ERP da empresa — Totvs, SAP, ou aquele sistema próprio de 2011 — e o projeto trava. É aqui que a maioria das iniciativas de IA empresarial morre: não na IA, mas na integração com o sistema que de fato roda o negócio. Estes são quatro padrões que sobrevivem à produção.
Padrão 1: API como contrato (read-only primeiro)
O caminho mais seguro começa com leitura, não escrita. Você expõe os dados do ERP por uma API — REST quando ele já tem, ou uma camada de adaptação que você constrói por cima — e a IA consome essa API como ferramenta. O agente lê pedidos, consulta estoque, busca histórico de cliente. Não escreve nada ainda.
Por que começar read-only? Porque uma leitura errada é inofensiva; uma escrita errada move dinheiro. Você ganha valor cedo (consulta, classificação, sugestão) e constrói confiança no comportamento do agente antes de dar a ele o poder de alterar dados. Quando a escrita entra, ela entra cercada de validação.
Padrão 2: fila de eventos como desacoplamento
ERPs antigos não gostam de carga síncrona vinda de fora. Bombardear o sistema com chamadas em tempo real durante um pico é receita para derrubá-lo. O padrão que funciona é o desacoplamento por fila: o ERP (ou o agente) publica eventos em uma fila — RabbitMQ, Kafka — e o outro lado consome no seu próprio ritmo.
A IA processa o evento, decide, e publica o resultado de volta em outra fila, que o ERP consome quando pode. Isso protege o sistema crítico de picos, dá retry natural em falhas, e cria uma trilha de eventos auditável. É o padrão de integração mais robusto que conhecemos para sistemas legados que não podem cair.
Padrão 3: human-in-the-loop para ações de impacto
Nem toda decisão deve ser automática. Para ações de alto impacto — aprovar um crédito, cancelar um pedido grande, ajustar um preço fora da faixa — o padrão certo é o agente preparar a ação e um humano confirmar. A IA faz o trabalho pesado (reúne o contexto, calcula, recomenda); a pessoa dá o aval com um clique.
Isso não é "IA pela metade". É arquitetura honesta: você automatiza 90% do esforço (o levantamento e a análise) e mantém o controle humano sobre os 10% que carregam o risco. Conforme a confiança cresce e os dados de acerto se acumulam, dá para mover seletivamente certas ações para automático — com base em evidência, não em fé.
Padrão 4: camada anticorrupção sobre o legado
Quando o ERP é antigo, mal documentado e cheio de regras escondidas, conectar a IA direto a ele acopla todo o sistema novo às esquisitices do velho. O padrão da camada anticorrupção (vindo do DDD) resolve isso: você constrói uma camada intermediária que traduz o modelo bagunçado do ERP para um modelo limpo que a IA e os sistemas novos consomem.
A IA conversa com um modelo coerente; a camada absorve a complexidade de falar com o legado. Quando o ERP for modernizado no futuro, você troca a implementação da camada sem tocar na IA. É isolamento de risco em forma de arquitetura.
O que evitar
Três antipadrões aparecem sempre. Escrita direta sem validação — dar ao agente acesso de escrita ao ERP no dia 1, sem fallback nem auditoria, é convite a corrupção de dados. Chamadas síncronas em volume — acoplar a latência da IA à do ERP derruba os dois sob carga. E integração sem observabilidade — se você não loga cada interação entre a IA e o ERP, o primeiro bug em produção vira uma caça às cegas.
O fio condutor
Os quatro padrões compartilham um princípio: a IA é a parte fácil; a integração confiável com o sistema que roda o negócio é a parte difícil, e é onde mora o valor. Comece read-only, desacople por fila, mantenha o humano nas ações de risco e isole o legado atrás de uma camada limpa. Faça isso e a IA deixa de ser uma demo bonita para virar parte da operação — que é o único lugar onde ela paga a conta.