Integrar IA sem trocar o ERP: como a conexão acontece

Um desenho possível para conectar IA aos sistemas existentes:

flowchart LR
    ERP[ERP] --> INT[Camada de integração]
    TMS[TMS] --> INT
    DB[Banco de dados] --> INT
    TEL[Telemetria] --> INT
    INT --> AI[Solução de IA]
    AI --> OUT[Decisão / ação / alerta]
    OUT --> FLOW[Retorno à equipe ou ao sistema, conforme o acesso]

Quatro entradas possíveis alimentam uma camada de integração e um módulo de IA. A saída pode chegar à equipe ou ao sistema, conforme o acesso disponível. O desenho não exige trocar o ERP; cada fronteira pede uma decisão.

Use os quatro pontos para avaliar uma proposta de integração: origem dos dados, interface, acesso e destino da saída. Neste exemplo ilustrativo, considere um TMS sem API pública, mas com exportação periódica de relatórios.

Ponto 1: as origens continuam origens

O ERP, o TMS, o banco de dados e a plataforma de telemetria mantêm seus papéis. O pedido continua no ERP, o frete continua no TMS. A camada de IA lê e devolve informação ao mesmo fluxo.

A decisão: ler, não migrar. Os sistemas que já rodam permanecem como fonte da verdade, e a camada de IA consome dados dessas origens e entrega uma saída ao fluxo, sem substituir os registros oficiais.

O motivo: trocar um ERP é um projeto de anos, com impacto em toda a operação. A integração pode ser delimitada a um fluxo para testar a viabilidade antes de considerar mudanças maiores.

O que mudaria a decisão: um sistema em desativação iminente, ou uma origem tão instável que ler seja menos confiável do que substituir. Esses casos exigem uma avaliação separada no diagnóstico.

Ponto 2: a interface de cada fronteira

Cada seta que sai de uma origem rumo à camada de integração é uma decisão de interface. Na prática, aparecem três tipos:

• APIs, quando o sistema expõe um contrato estável e documentado. Troca direta, autenticação, controle de acesso, o caminho mais fácil de monitorar e versionar.
• Leitura de banco, quando não existe API. Funciona, com cuidado: entender o modelo de dados, respeitar a carga do sistema em produção e tratar a leitura como algo sensível. Lemos, e evitamos escrever direto nas tabelas do sistema.
• Importação de arquivos, em sistemas fechados e plataformas de governo: CSV, XML ou layouts próprios. Algumas plataformas também exigem certificado digital para o acesso.

No exemplo ilustrativo, o TMS não tem API pública, mas permite exportar relatórios periódicos. Três jeitos de desenhar a seta dele:

• um relatório exportado do TMS e importado pela camada de integração;
• leituras controladas de uma tabela ou visão específica, se o fornecedor autorizar e a carga for aceitável;
• uma exportação intermediária feita pela própria equipe, alimentando a camada de IA sem acesso direto dela ao TMS.

A decisão: a importação de arquivo. O processo tolera atualização em lote, a equipe pode solicitar aprovação para a exportação, e o piloto mede o processo, não o transporte.

O que mudaria a decisão: uma operação que precisa de dados de frete quase em tempo real. Aí a leitura controlada passa a valer a conversa com o fornecedor e o cuidado de performance. A decisão segue a frequência de atualização que o processo precisa, não a elegância da interface.

Ponto 3: o portão de acesso

Entre as interfaces e a camada de integração está um item que pode atrasar o projeto: credenciais. Trate isso como parte do desenho, não como detalhe de infraestrutura.

• quem autoriza o acesso, por qual processo interno;
• qual conta será usada, com as permissões mínimas que o fluxo precisa;
• como as credenciais são guardadas e rotacionadas;
• quais ambientes são conectados: produção, staging ou uma cópia;
• quais restrições de rede valem: VPN, firewall, faixas de IP liberadas.

A decisão: credenciais de leitura, limitadas ao processo, ampliadas só com justificativa. Escrever em um sistema de origem só entra quando o fluxo exige, com regras e registro de cada ação.

O motivo: acesso amplo resolve hoje e cria risco amanhã. Acesso mínimo demora mais para organizar e custa menos para conviver.

Ponto 4: o caminho de volta

A borda direita do diagrama é onde a maioria das propostas fica vaga. A saída precisa chegar a algum lugar: uma decisão mostrada a uma pessoa, uma ação escrita em um sistema, um alerta encaminhado a uma fila. A anotação deste ponto nomeia o destino e as regras da volta.

No exemplo do TMS, a saída vai para a equipe de operação, no fluxo que ela já usa. Escrever de volta no TMS exigiria escrita autorizada pelo fornecedor, o que a interface escolhida para este exemplo não oferece, então a volta é para pessoas, não para o sistema. Essa é uma consequência de desenho, e é melhor registrá-la aqui do que descobri-la na entrega.

Lendo o diagrama sobre os seus sistemas

A integração é decidida no diagnóstico, enquanto o escopo ainda pode mudar. Ao identificar onde a IA faz sentido, o diagnóstico costuma ser planejado para 2 a 3 semanas, e parte dele é exatamente preencher este diagrama: quais sistemas participam, quais interfaces cada um oferece, quem autoriza acesso, qual frequência de atualização o processo precisa e quais dados são sensíveis.

O piloto costuma ser estimado em 4 a 6 semanas após a definição do escopo; acessos e dados identificados no diagnóstico ainda podem afetar esse prazo.

Mapear as dependências cedo ajuda a planejar o piloto, mas não elimina o risco técnico ou o trabalho de adoção.

Em resumo

A arquitetura é sem graça de propósito: as origens continuam origens, a interface de cada fronteira segue o que o sistema oferece e a frequência que o processo precisa, o acesso é o mínimo necessário e a saída retorna à equipe ou ao sistema, conforme as permissões disponíveis. Falta de API define o desenho, não encerra o projeto. Antes de construir, confira se a proposta define origens, interfaces, acessos e destino da saída.

Solicitar diagnóstico