Integrando IA com ERP e sistemas legados: arquitetura de referência para empresa brasileira

O cenário típico de mid-market e enterprise brasileiro em 2026: ERP central (SAP ou TOTVS) com 10-20 anos de customização, vários sistemas satélites (CRM, ticketing, WMS, MES), dados em planilhas no meio. O CIO quer levar IA pra área que vai entregar mais valor — e percebe que a tecnologia não é o gargalo. A integração é.

Este post detalha a arquitetura de referência que está sendo adotada por empresas brasileiras com IA em produção, os padrões emergentes (MCP, agentic patterns) e o framework de build vs buy em 2026.

Por que conectar LLM direto em ERP é má ideia

1. Segurança: LLM ganha acesso amplo demais. Risco de prompt injection que escala pra leitura de dado proibido.
2. Custo: cada query estoura context window. Sem cache, custo escala linearmente com uso.
3. Auditoria: sem trilha de quem decidiu o quê com que dado. PL 2338 exige.
4. Escalabilidade: autenticação, rate-limit, retry, fallback ficam todos no lado do LLM. Quebra em produção.
5. Manutenção: schema do ERP muda; LLM cai. Sem camada de abstração, cada mudança quebra integração.

A camada de orquestração: o que precisa ter

Padrão de arquitetura que funciona em mid-market brasileiro:

• Gateway de LLM — roteamento entre modelos, fallback, cache, rate-limit. Ferramentas: LiteLLM, Portkey, Helicone.
• Camada de ferramentas (tool layer) — funções nomeadas que o LLM chama, sem acesso direto ao ERP. Cada ferramenta tem least-privilege definido.
• Vector store + RAG — para contexto de documentos, base de conhecimento, comunicação histórica.
• Audit log — prompt, resposta, ferramenta chamada, ação executada, com timestamp e usuário.
• Guardrails — classificadores de PII, validação de output, escalação humana em incerteza.
• Observability — latência, custo, qualidade, taxa de fallback.

Model Context Protocol: o que é e quando usar

MCP é um padrão aberto criado pela Anthropic em 2024 e adotado por OpenAI e Google em 2025-2026. Resolve o problema de cada integração entre LLM e fonte de dados/ferramenta ser bespoke.

• O que oferece: protocolo padronizado de conexão entre LLM (cliente) e servidores de ferramentas/dados (servers). Pode ser stdio, HTTP, ou SSE.
• Quando usar: múltiplos LLMs ou agentes; integração com 3+ sistemas; time pequeno de engenharia que não quer manter conectores customizados.
• Quando não usar: caso de uso único com 1 LLM e 1 sistema — overhead de adotar MCP não compensa.
• Maturidade em 2026: emergente mas crescendo rápido. Adoção corporativa começou em 2025; bibliotecas estão maturando.

RAG sobre dado de ERP: armadilhas comuns

1. Chunking ingênuo — quebrar registro relacionado em pedaços perde contexto. Solução: chunk por entidade lógica, não por tamanho.
2. Embedding de dado sensível sem governança — exposição LGPD. Solução: PII masking antes do embedding, vector DB com criptografia.
3. Sem refresh contínuo — agente responde com dado de ontem. Solução: pipeline de delta capture; refresh mínimo diário.
4. Sem reranking — busca semântica traz lixo relevante. Solução: reranker (Cohere Rerank, BGE) após retrieval.
5. Sem citação de fonte — auditoria impossível. Solução: retornar IDs dos documentos usados em cada resposta.

Padrões obrigatórios de segurança

1. Least-privilege access — agente só acessa o estritamente necessário. Ferramentas escopadas, não acesso amplo.
2. PII masking antes do LLM — CPF, email, telefone mascarados em prompt e contexto.
3. Audit log completo — prompt, resposta, ferramentas chamadas, ações executadas, timestamp, usuário.
4. Human-in-the-loop em decisões críticas — confirmação obrigatória antes de ação irreversível.
5. Rate-limit e budget por agente — proteção contra loop infinito e ataque por usuário malicioso.

Caminhos específicos: SAP, TOTVS, Oracle

SAP

• SAP Joule — LLM nativo. Boa pra casos genéricos de produtividade dentro do SAP.
• SAP BTP + LLM externo — mais flexível, melhor pra casos vertical. Caminho mais comum em mid-market.
• Middleware customizado — empresas com customização ABAP profunda. Mais complexo, mais controle.

TOTVS

• TOTVS Carol — plataforma de IA da TOTVS. Maturidade variável por módulo.
• API REST + camada externa — mais comum em produção. Engenharia externa controla orquestração.

Oracle

• Oracle Cloud Infrastructure (OCI) + Generative AI — para quem já é Oracle Cloud.
• APIs Fusion + LLM externo — abordagem multi-cloud, mais flexível.

Build vs Buy: framework de decisão 2026

• Buy faz sentido em: chat empresarial geral (ChatGPT Enterprise, Claude for Work, Copilot), busca interna (Glean), copilots de produtividade. Vence em TCO e time-to-market.
• Build faz sentido em: diferenciação vertical (atendimento específico do produto, automação de processo core que cria vantagem competitiva). Vale com volume acima de US$ 200k/ano sustentado.
• Híbrido: plataforma + customização vertical. Cobre 70% dos casos em mid-market brasileiro.

Resumo executivo

1. API direta no LLM é antipadrão. Use camada de orquestração.
2. 6 componentes obrigatórios: gateway, tool layer, vector store, audit log, guardrails, observabilidade.
3. MCP está virando padrão pra integração; vale começar a adotar em 2026.
4. RAG sobre ERP exige chunk lógico, PII masking, refresh contínuo, reranking, citação.
5. 5 padrões de segurança são obrigatórios — least-privilege, PII masking, audit log, human-in-the-loop, rate-limit.
6. Build vs Buy: híbrido vence em mid-market.

Maturidade de integração aparece como dimensão explícita no diagnóstico Fronteira. Empresas com Integração ≤2 não conseguem agentes em CX ou back-office, independente de qualidade do modelo escolhido.