Camada anticorrupção para integrar IA a um ERP legado

Conectar uma aplicação de IA diretamente a um ERP legado é uma tentação comum e um erro de arquitetura recorrente. O ERP tem seu próprio modelo de dados, suas próprias regras implícitas e, com frequência, limites de capacidade que não foram desenhados para tráfego de leitura de alta frequência gerado por agentes. A resposta de engenharia é a anti-corruption layer (ACL): uma camada intermediária que traduz, protege e governa o acesso, evitando que o modelo mental do sistema legado — ou sua fragilidade operacional — se propague para a aplicação de IA.

O que a ACL precisa resolver

Uma anti-corruption layer entre ERP e IA tem cinco responsabilidades concretas, não apenas "servir de proxy":

1. 1.Tradução de modelo de dados — expor entidades de negócio estáveis (pedido, cliente, estoque) em vez de tabelas internas do ERP, que mudam com upgrades e patches.
2. 2.Isolamento de carga — impedir que consultas de IA saturem o sistema transacional de origem.
3. 3.Consistência e idempotência — garantir que reprocessamentos (comuns em pipelines de IA) não dupliquem efeitos.
4. 4.Propagação de identidade e permissão — assegurar que o agente de IA opera com o contexto de autorização correto, não com uma credencial de serviço genérica.
5. 5.Reconciliação — detectar e corrigir divergências entre o que a camada expõe e o estado real do ERP.

Contratos de API: o que expor, o que esconder

O contrato da ACL deve ser modelado a partir do domínio de negócio, não do schema do ERP. Isso significa versionar contratos de forma independente das versões internas do sistema legado:

GET /v1/orders/{order_id}
{
  "order_id": "string",
  "status": "enum(open, fulfilled, cancelled)",
  "customer_ref": "string",
  "line_items": [...],
  "source_system_version": "string",
  "as_of": "datetime"
}

Note o campo ${'as_of'}: toda resposta vinda de um ERP legado via replicação ou cache tem uma janela de defasagem, e a aplicação de IA precisa saber disso para decidir se a informação é fresca o suficiente para a decisão em questão (por exemplo, confirmar disponibilidade de estoque antes de prometer uma data de entrega).

Erros de contrato a evitar: expor códigos internos do ERP sem tradução (o modelo de IA vai aprender a lidar com "status = 7", que muda de significado entre módulos), e omitir metadados de proveniência que permitiriam auditar de onde veio cada dado.

CDC vs. batch

A escolha entre Change Data Capture e replicação em batch depende do padrão de uso da IA, não de preferência de arquitetura:

Para agentes de IA que respondem em tempo real a perguntas operacionais (status de pedido, disponibilidade), CDC é normalmente necessário. Para RAG sobre documentação e políticas que mudam pouco, batch diário é suficiente e mais simples de operar.

Idempotência

Pipelines de IA reprocessam com frequência — por retry de falha, por reexecução de um agente, ou por correção de um erro de recuperação. A ACL precisa garantir que qualquer operação de escrita de volta ao ERP (por exemplo, um agente criando um ticket ou atualizando um status) seja idempotente por construção:

POST /v1/tickets
Idempotency-Key: {agent_run_id}-{action_id}

Sem essa chave, cada reexecução do agente pode duplicar o efeito no sistema de origem — um problema silencioso e caro de depurar, porque só aparece como dado duplicado no ERP, não como erro visível na aplicação de IA.

Propagação de identidade

O erro mais comum em integrações ERP-IA é usar uma única credencial de serviço para todo o tráfego da aplicação de IA. Isso quebra o modelo de permissões do ERP e cria um vazamento de dados silencioso: um usuário sem acesso a dados financeiros pode, via agente, obter respostas derivadas desses dados.

A ACL deve propagar o contexto de identidade do usuário final (ou do processo de negócio) em cada chamada, aplicando os mesmos controles de autorização que o ERP aplicaria a um acesso direto. Isso normalmente significa carregar um token de identidade federada (OAuth2/OIDC) desde a aplicação de IA até a ACL, e mapear esse contexto para as regras de autorização nativas do ERP — não simplesmente confiar na aplicação de IA para filtrar depois.

Limites de carga e cache

ERPs legados frequentemente não foram dimensionados para o padrão de acesso de agentes de IA, que podem gerar rajadas de consultas ao decompor uma tarefa em múltiplos passos. A ACL deve implementar:

• Rate limiting por consumidor, não apenas global, para isolar o impacto de um agente com comportamento anômalo.
• Cache com TTL alinhado à volatilidade real do dado (estoque muda rápido; cadastro de fornecedor, raramente) — e sempre expondo o campo ${'as_of'} mencionado acima.
• Circuit breaker que degrade a resposta (dados em cache, marcados como potencialmente defasados) em vez de propagar timeout do ERP para o agente.

Reconciliação

Toda camada de cache ou replicação introduz risco de divergência. Um job de reconciliação periódico, comparando amostras da ACL contra o ERP de origem, é a forma prática de detectar drift antes que ele afete uma decisão de negócio automatizada. Trate divergências encontradas como incidente, não como ruído estatístico — a IA vai agir sobre o que a ACL disser, certo ou errado.

O que fazer na segunda-feira

1. 1.Mapeie todos os pontos onde a aplicação de IA hoje acessa o ERP diretamente ou via credencial genérica — essa é a lista de riscos a priorizar.
2. 2.Defina o contrato de domínio (não o schema do ERP) para o primeiro caso de uso de IA e inclua ${'as_of'} e proveniência desde a primeira versão.
3. 3.Decida CDC vs. batch com base na latência real exigida pelo caso de uso, não pela infraestrutura já disponível.
4. 4.Implemente idempotência em qualquer operação de escrita de volta antes de habilitar reexecução automática de agentes.

Leitura complementar

Trilha executiva:

• Seu ERP tem 20 anos e a IA precisa conversar com ele — a leitura de negócio deste mesmo tema.