Guia estratégico · Arquitetura · 2026

IA em procurement sobre o ERP, sem substituir o core

Como incorporar analítica e agentes de IA ao ciclo de compras mantendo o ERP como sistema de registro: uma arquitetura em camadas, a divisão exata de responsabilidades e as respostas ao que um CIO pergunta antes de aprovar a conexão.

Por Oscar Gamboa, fundador e Gerente de IA da EGIXIA · Atualizado em 11 de agosto de 2026

Ler o guia Falar com um arquiteto

Guia completo nesta página · sem formulário e sem download

Capa do guia da Egixia sobre integração de IA em procurement sobre o ERP

Resumo executivo

A adoção de inteligência artificial nas áreas de suprimentos e compras das grandes empresas latino-americanas costuma esbarrar em um dilema de arquitetura: substituir o ERP por uma suíte que já vem com IA, ou ficar parado diante da complexidade de integrar. Nenhuma das duas é uma decisão de arquitetura; são duas formas de evitá-la. Este guia descreve o terceiro caminho: uma arquitetura em camadas na qual a analítica e os agentes de IA operam sobre o ERP existente e o núcleo transacional mantém intacta sua função de registro, controle contábil e compliance.

O princípio ordenador é simples e tem consequências em todo o desenho: a IA propõe, o ERP dispõe. Tudo o que compromete orçamento, cria uma obrigação contratual ou afeta a contabilidade é executado dentro dos fluxos autorizados do ERP. Tudo o que analisa, normaliza, compara, verifica ou redige pode viver em uma camada superior desacoplada, que se conecta pelas APIs padrão do próprio ERP e que pode ser desligada sem deixar o negócio sem operar.

Para quem é este guia

Foi escrito para quem precisa aprovar —ou rejeitar— a conexão de uma camada de IA com o sistema onde o dinheiro da companhia é registrado.

CIO, CTO e arquitetura empresarial

Precisam saber o que se conecta, com qual protocolo, o que acontece em um upgrade do ERP e como a decisão é revertida se o projeto não prosperar.

CPO e diretores de compras

Buscam resultados no ciclo de compras sem abrir um programa de substituição de ERP que consuma o orçamento e a atenção da área por dois anos.

CFO, controles internos e auditoria

Perguntam o que fica registrado, quem autorizou cada movimento e como se demonstra a um auditor que uma recomendação algorítmica não executou nada por conta própria.

Contexto: por que o core não é o lugar da IA

O núcleo transacional de um ERP é otimizado para a estabilidade, a integridade contábil e o cumprimento normativo estrito. Essa rigidez não é um defeito: é exatamente o que se exige dele. A inteligência artificial, por outro lado, precisa iterar rápido, processar dados não estruturados, errar em um ambiente controlado e trocar de modelo sem abrir um projeto de meses. Colocar essa dinâmica dentro do core é pedir ao mesmo sistema que seja duas coisas incompatíveis ao mesmo tempo.

O ERP core continua sendo o sistema de registro da operação e da contabilidade; as capacidades de IA operam em uma camada superior de orquestração analítica e de apoio à decisão, com a governança e a rastreabilidade como parte do desenho e não como um acréscimo posterior.
— Síntese do princípio de arquitetura em camadas descrito nas referências [1] e [2]

Na América Latina o argumento pesa ainda mais, porque os cenários tecnológicos são fragmentados: várias instâncias de ERP herdadas de aquisições, sociedades com regras fiscais distintas por país e camadas locais de nota fiscal eletrônica que nenhum ERP global traz de fábrica. Substituir o core apenas para poder usar IA transforma um projeto de doze semanas em um programa de dois anos, e concentra o risco justamente onde a empresa não pode se dar a esse luxo.

Dois dados de mercado que convém ter à vista antes de aprovar o primeiro piloto:

Mais de 40%

dos projetos de IA agêntica serão cancelados antes do fim de 2027, por custos crescentes, valor de negócio pouco claro ou controles de risco insuficientes.

Gartner, junho de 2025

30%

mais rápido será o fechamento financeiro em 2028 graças à IA embarcada nas aplicações de ERP em nuvem.

Gartner, fevereiro de 2026

A arquitetura em camadas

Quatro camadas com responsabilidades separadas. A prova de que o desenho está correto é que cada camada também pode ser descrita pelo que NÃO faz: é aí que as arquiteturas que falham se quebram.

Camada ERP core

Do que responde: Execução contábil, emissão definitiva de pedidos de compra, recebimento, registro de notas, pagamentos e cumprimento normativo. É a única fonte de verdade transacional.

O que não faz: Não hospeda modelos, não executa lógica algorítmica e não muda sua configuração para acomodar um piloto de IA.

Camada de integração e dados

Do que responde: Conecta o ERP com o resto do ecossistema usando as APIs padrão do próprio ERP, sincroniza cadastros e documentos, e mantém a correspondência de identificadores entre sistemas.

O que não faz: Não duplica a base transacional nem se torna um segundo livro contábil: transporta e concilia, não substitui.

Camada de orquestração e IA

Do que responde: Normaliza e classifica o gasto, verifica documentos, extrai dados de notas, compara ofertas, detecta anomalias e deixa a decisão preparada com seu embasamento.

O que não faz: Não emite documentos definitivos, não compromete orçamento e não escreve no ERP sem que uma pessoa autorizada aprove o resultado.

Camada de governança e supervisão humana

Do que responde: Limiares de autonomia por valor e por categoria, controle de acesso por perfil, revisão humana obrigatória antes de aplicar um resultado e registro auditável de cada passo.

O que não faz: Não é documentação: se não estiver implementada como controle técnico, não existe no dia da auditoria.

Como se implementa: quatro fases

A ordem importa mais que a velocidade. As três primeiras fases não exigem tocar no ERP; a quarta só escreve nele quando todo o anterior estiver comprovado.

Fase 1

Diagnóstico do cenário e dos dados

Antes de conectar qualquer coisa, auditar o que já existe.

Inventário das interfaces vivas com o ERP: o que se conecta hoje, com qual protocolo e quem mantém.
Estado real do cadastro de fornecedores: duplicados, identificadores fiscais inválidos e categorias inconsistentes.
Mapa das aprovações vigentes por valor, categoria e sociedade.
Definição explícita de quais dados não vão sair do ERP.

Fase 2

Desenho da arquitetura e dos limites

Escrever a divisão de responsabilidades antes de escrever código.

Atribuir cada objeto de negócio à camada que o governa e ao seu sistema dono.
Definir direção e frequência de cada sincronização, e o que acontece quando ela falha.
Fixar os limiares de autonomia por valor e categoria, com o perfil que aprova nomeado.
Especificar o que é registrado no log de auditoria e por quanto tempo é conservado.

Fase 3

Casos de uso de alto volume e baixo risco

O primeiro caso se escolhe pela relação entre volume e risco, não pelo quanto impressiona em uma demo.

Verificação documental e homologação de fornecedores.
Extração e validação de notas, com conciliação contra o pedido e o recebimento.
Normalização e classificação do gasto disperso entre sociedades.
Detecção de duplicados e anomalias antes que os documentos entrem no ERP.

Fase 4

Piloto delimitado, medição e escala

Um piloto que não pode ser comparado a uma linha de base não é um piloto: é uma demo longa.

Medir a linha de base antes de ligar qualquer coisa: horas, volume e taxa de erro atuais.
Delimitar o piloto a uma sociedade ou a uma categoria, com critério de sucesso escrito.
Monitorar a estabilidade do ERP como métrica de primeira classe, não como anedota.
Escalar por objeto de negócio, não por área inteira de uma só vez.

A divisão de responsabilidades, objeto por objeto

A tabela resume onde cada coisa vive. Se em uma discussão de desenho você não conseguir colocar um objeto em uma única coluna, o limite ainda não está definido.

Objeto de negócio	Papel do ERP core	Papel da camada de IA	Mecanismo de interação
Cadastro de fornecedores	Fonte de verdade do registro do fornecedor: dados fiscais, contábeis e bancários.	Normalização, deduplicação, enriquecimento de categorias e verificação documental antes de criar ou atualizar o registro.	O fornecedor se autoatende e valida seus documentos na camada de compras; ao ser aprovado o fluxo, o registro é criado ou atualizado no ERP.
Requisições e pedidos de compra	Emissão formal, validação orçamentária e compromisso contábil.	Rascunhos de requisição, seleção de fornecedores habilitados por categoria, envio de cotações e quadro comparativo consolidado.	A camada de IA entrega a decisão pronta; o pedido definitivo é criado no ERP após a aprovação de um usuário autorizado.
Notas e pagamentos	Registro contábil, retenções, programação e execução do pagamento.	Captura, validação fiscal, detecção de duplicados e anomalias, e conciliação contra o pedido e o recebimento.	A nota chega já validada ao ERP; o status do pagamento retorna do ERP ao portal para que o fornecedor consulte sem ligar para contas a pagar.
Controle e auditoria	Registro histórico das transações financeiras e de pagamento.	Monitoramento contínuo de exceções, riscos de compliance e desvios frente ao que foi negociado.	Relatórios de exceção e registro de cada ação com data, hora e usuário, confrontáveis com os documentos do ERP.

As seis perguntas que um CIO faz antes de aprovar

Nenhuma destas perguntas é sobre modelos de IA. Todas são sobre o que acontece no dia em que algo dá errado, e são elas que de fato decidem se o projeto avança.

Onde vivem os dados e quem pode vê-los?

Os dados transacionais continuam no ERP. Na camada de compras vive o que o processo colaborativo precisa: documentos do fornecedor, cotações, avaliações e trilhas. No caso da EGIXIA essa camada é uma plataforma 100% SaaS sobre Amazon Web Services (AWS), nos Estados Unidos (região Norte da Virgínia), com redundância em múltiplas zonas de disponibilidade. O isolamento é por cliente: instância dedicada e banco de dados com segregação lógica; cada cliente opera sobre seu próprio bucket de armazenamento, com políticas de acesso que impedem o cruzamento entre clientes.

O que acontece quando atualizamos o ERP?

Nada, se a integração usar exclusivamente APIs padrão do ERP e não instalar desenvolvimentos próprios dentro dele. É o critério que convém exigir por escrito de qualquer fornecedor. Na integração com SAP, a EGIXIA trabalha com OData, BAPI, RFC e IDoc: não se instalam desenvolvimentos Z nem add-ons e não se transporta código da EGIXIA para o landscape do cliente, por isso os upgrades de Support Pack ou de release não quebram a conexão. Essa é a diferença prática frente a um desenvolvimento sob medida dentro do core.

Quem é o dono do cadastro de fornecedores?

O ERP, sempre. A camada de compras gerencia o ciclo com o fornecedor —homologação, validação documental, atualização de dados bancários e renovação de certificados— e sincroniza o resultado com o registro do ERP; não cria um segundo cadastro paralelo. É a diferença entre integrar e duplicar, e é o que evita que duas áreas terminem discutindo qual das duas bases está certa.

O que fica registrado para uma auditoria?

Cada movimento sincronizado fica rastreado com data, hora e usuário, e cada transação entre sistemas deixa seu próprio registro. Para uma recomendação gerada por IA é preciso exigir mais: quais dados foram usados, com qual critério e quem a aprovou. Sem isso, a recomendação não é auditável mesmo que tenha sido correta. A retenção dos logs de auditoria é habilitada por projeto, conforme as políticas do cliente.

Como se reverte a decisão se quisermos parar?

Como o ERP é o sistema de registro, tudo o que é contábil e transacional já está dentro dele: reverter é desconectar a camada, não migrar de volta. E como não há desenvolvimentos instalados no ERP, também não há nada a desinstalar. O que convém acordar em contrato desde o início é a devolução dos documentos e dados que vivem na camada de compras; sua retenção é habilitada por projeto, conforme as políticas do cliente.

O que acontece se a camada de IA ficar indisponível?

O ciclo de compras precisa poder continuar operando no ERP, ainda que com mais trabalho manual. Esse plano de contingência é escrito antes do go-live, não depois do primeiro incidente, e é testado ao menos uma vez. Do lado do serviço, a EGIXIA opera com SLA de disponibilidade de 99,6%, com implantação Multi-AZ na AWS.

Checklist para o comitê de TI e compras

Seis verificações antes de assinar. Responda com evidência: se não puder mostrar o documento, conte como um não.

1
Interfaces
Cada conexão viva com o ERP está inventariada, com seu protocolo, seu dono e sua frequência?
2
Dados mestres
Existe um protocolo escrito para deduplicar, validar identificadores fiscais e unificar categorias antes de alimentar qualquer modelo?
3
Limiares de autonomia
Estão fixados por valor e categoria os limites em que uma recomendação exige aprovação humana, e o perfil que aprova está nomeado?
4
Rastreabilidade
Cada resultado gerado por IA fica com registro dos dados que usou, do critério aplicado e de quem o aprovou?
5
Continuidade
Há um plano de contingência escrito e testado para operar o ciclo de compras se a camada de IA estiver indisponível?
6
Saída
Está acordado em contrato o que é devolvido, em qual formato e em qual prazo se o serviço terminar?

As seis são respondidas na fase de desenho. Nenhuma exige ter escolhido um fornecedor ainda, e por isso também servem para comparar propostas.

Riscos, limites e o que este guia não cobre

Os três riscos que mais vezes param um projeto de IA em compras. Nenhum deles é o modelo.

Erros do modelo tomados como fatos

Um motor pode interpretar mal uma condição contratual ou uma cláusula de preço e apresentar o erro com a mesma confiança de um acerto. A IA é apoio à decisão: a revisão humana antes de aplicar um resultado é um requisito de desenho, não uma limitação temporária da tecnologia.

A superfície de integração

Cada ponto de conexão com o core é uma porta. Exija autenticação padrão, criptografia dos dados em trânsito, privilégios mínimos por serviço e um usuário técnico com autorizações restritas, definido com sua equipe de segurança antes da primeira chamada.

Dados mestres sujos

Um cadastro com duplicados e categorias inconsistentes produz resultados inúteis com aparência de precisão. A limpeza precede a implantação algorítmica: é o trabalho chato que decide o resultado do piloto.

Nota esclarecedora: este guia oferece orientação metodológica de caráter geral e não constitui assessoria jurídica, fiscal, financeira nem formal em matéria de cibersegurança ou compliance normativo. Cada organização deve validar sua arquitetura com seus comitês internos e com a normativa que lhe é aplicável.

Como medir que a arquitetura funciona

Quatro indicadores. O quarto é o que costuma faltar e é justamente o que importa ao CIO.

Ciclo de aquisição (cycle time)

Dias da requisição até o pedido de compra aprovado, comparados com a linha de base medida antes do piloto.

Taxa de aceitação das recomendações

Percentual de sugestões da camada de IA que o comprador aceita sem modificar. Uma taxa muito baixa indica critério mal calibrado; uma taxa perfeita indica que ninguém está revisando.

Precisão na classificação do gasto

Percentual de transações catalogadas corretamente pelos motores, sem correção manual posterior.

Estabilidade do ERP core

Incidentes e degradações do sistema transacional atribuíveis à camada de integração. A meta é zero e se mede desde o primeiro dia.

Como a EGIXIA faz

A EGIXIA ajuda grandes empresas latino-americanas a simplificar todo o seu ciclo de compras, combinando software enterprise, serviços especializados e operação assistida por IA sobre o ERP que já possuem. A plataforma opera como camada de compras sobre o ERP: os fornecedores se autoatendem, as cotações e as validações documentais acontecem na camada, e o ERP continua sendo o sistema de registro contábil, de estoques e de pagamentos.

A conexão usa as APIs padrão de cada ERP —OData, BAPI, RFC, IDoc e SAP CPI no SAP S/4HANA e ECC; REST API, SuiteScript e SuiteTalk no Oracle NetSuite; Service Layer e DI API no SAP Business One— com sincronização programada ou por eventos, conforme o caso. Sem desenvolvimento ABAP e sem código da EGIXIA transportado para o landscape do cliente. A implementação se mede em semanas, não meses.

Sobre a camada de IA o compromisso é explícito: os agentes preparam a decisão e nenhuma de suas saídas é aplicada sem revisão humana prévia. Os dados processados pelos agentes de IA não são usados para treinar modelos: é uma garantia contratual que a EGIXIA mantém com seus subprocessadores, e estes com seus provedores de modelos. Cada tarefa roda em um ambiente isolado, sem acesso a dados de outros clientes, e a EGIXIA executa exclusão proativa em até 72 horas após a entrega. A pseudonimização reversível antes do processamento por IA é habilitada por projeto, conforme as políticas do cliente.

Nos casos de negócio que construímos, a alavanca de maior valor é levar mais gasto à concorrência: a faixa que utilizamos para dimensioná-la é 2-4% de melhoria de preço no gasto levado à concorrência.

Faixa de referências de mercado que a EGIXIA utiliza em seus casos de negócio.

O detalhe técnico, em sua própria página

Integração com SAP

Conectores, objetos suportados, metodologia de implementação e o que acontece exatamente em um upgrade.

Ver a integração com SAP

SRM integrado com SAP e Oracle

Quais objetos são sincronizados em cada ERP, em qual direção e com qual protocolo.

Ver o detalhe da sincronização

Os 8 tipos de agente de IA

O que cada tipo faz, sua maturidade real em 2026 e os sete critérios para avaliar a versão de qualquer fornecedor.

Ler o guia de avaliação

Segurança na era da IA

A camada de integração é a superfície que a área de segurança de TI revisa. Estas são as respostas que publicamos, com o mesmo texto que usamos nas páginas de integrações.

Operamos sobre infraestrutura AWS certificada sob ISO 27001, SOC 1/2/3 e PCI DSS. Essas certificações pertencem à AWS: os controles próprios da Egixia estão alinhados à ISO 27001, sem certificação própria nem relatório SOC 2 Tipo II emitido. O relatório executivo dos testes de penetração externos está disponível sob acordo de confidencialidade.

Informações protegidas

A Egixia protege por criptografia as informações em trânsito e os documentos de fornecedores armazenados. Sua equipe controla o acesso por perfis e permissões; o suporte só acessa com autorização expressa e por tempo limitado. Realizamos testes de penetração externos e disponibilizamos o relatório executivo sob acordo de confidencialidade.

Acesso controlado

Sua equipe controla os acessos por perfis e permissões. O suporte só acessa com autorização expressa e por tempo limitado. MFA é obrigatória para perfis administrativos; MFA geral e acesso com identidade corporativa são funções avançadas habilitadas por projeto, conforme as políticas do cliente.

Avaliação com TI

Evidência independente

Sua equipe pode solicitar o relatório executivo dos testes de penetração externos e revisar o escopo dos controles de acesso, proteção de informações e continuidade sob acordo de confidencialidade. Os requisitos de cada projeto são acordados antes da contratação.

Segurança e Confiança

Perguntas frequentes

É necessário substituir o ERP para usar IA em compras?

Não. Uma arquitetura em camadas permite acoplar analítica e agentes de IA por meio das APIs padrão do próprio ERP, deixando o núcleo transacional como sistema de registro. Substituir o core é uma decisão distinta, com outro horizonte, outro orçamento e outro risco: não é um pré-requisito para ter IA no ciclo de compras.

Como se garante que a IA não execute uma transação financeira sem autorização?

Com limiares de autonomia escritos e revisão humana obrigatória antes que qualquer resultado seja aplicado. Os agentes geram rascunhos, comparações e análises; a emissão formal do pedido, o compromisso orçamentário e o pagamento acontecem dentro dos fluxos de aprovação do ERP. Tecnicamente um agente poderia adjudicar sozinho; não deve, porque uma adjudicação compromete orçamento e só é defensável em uma auditoria se alguém a assinou.

O que acontece com a integração quando o ERP é atualizado?

Se a integração usar exclusivamente APIs padrão e não instalar desenvolvimentos dentro do ERP, os upgrades não a quebram. Na integração da EGIXIA com SAP não se instalam desenvolvimentos Z nem add-ons e não se transporta código para o landscape do cliente, por isso os upgrades de Support Pack ou de release não afetam a conexão.

Quem é o dono do cadastro de fornecedores nesta arquitetura?

O ERP. A camada de compras gerencia o ciclo colaborativo com o fornecedor —homologação, validação documental e atualização de dados— e sincroniza o resultado com o registro do ERP, sem criar um segundo cadastro paralelo. No SAP, esse registro é o cadastro de fornecedores do próprio sistema.

Quais desafios de dados são os mais comuns na América Latina ao integrar IA?

A fragmentação do cadastro de fornecedores entre subsidiárias e sistemas herdados de aquisições, e as categorias inconsistentes entre sociedades. Antes de alimentar qualquer modelo é preciso deduplicar, validar os identificadores fiscais e unificar a taxonomia: é o trabalho que decide se o piloto produz um resultado ou uma lista de exceções.

Quanto tempo leva montar a camada de integração sem tocar no core?

Depende do cenário tecnológico, mas um escopo modular por fases permite ter o primeiro caso de uso funcionando sem esperar pelo projeto completo: começa-se pelo registro e pela validação de fornecedores e escala-se por objeto de negócio. Na EGIXIA a implementação se mede em semanas, não meses.

Como a segurança da integração é avaliada?

Avalie a integração com sua equipe de TI e segurança: defina o escopo, as permissões e as evidências necessárias antes de conectar seu ERP. A Egixia complementa seu sistema; os detalhes técnicos são revisados de forma privada sob acordo de confidencialidade. A Egixia protege por criptografia as informações em trânsito e os documentos de fornecedores armazenados. Sua equipe controla o acesso por perfis e permissões; o suporte só acessa com autorização expressa e por tempo limitado. Realizamos testes de penetração externos e disponibilizamos o relatório executivo sob acordo de confidencialidade.

Continuar lendo

Integração com SAP: conectores S/4HANA, ECC e Ariba

A página técnica do conector: protocolos, objetos suportados e metodologia de implementação.

Os melhores agentes de IA para procurement em 2026

Quais tipos de agente existem, qual é sua maturidade real e os sete critérios para avaliá-los.

Benchmark de maturidade digital de procurement

Onde está hoje sua área de compras e o que separa sua operação do próximo nível.

Referências

Fontes consultadas para este guia. As duas cifras de mercado citadas vêm de [3] e [4].

[1]DAX Software Solutions, Agentic ERP Architecture: Designing AI-Driven Enterprise Systems, abril de 2026. https://erpsoftwareblog.com/2026/04/agentic-erp-architecture-designing-ai-framework/
[2]Simfoni (Ryan Monte), How to Integrate AI Procurement Platforms with ERP Systems: Architecture, Challenges, and Best Practices, junio de 2026. https://simfoni.com/procurement-technology/how-to-integrate-ai-procurement-platforms-with-erp-systems-architecture-challenges-and-best-practices/
[3]Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, junio de 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[4]Gartner, Gartner Predicts Embedded AI in Cloud ERP Applications will Drive a 30% Faster Financial Close by 2028, febrero de 2026. https://www.gartner.com/en/newsroom/press-releases/2026-02-24-gartner-predicts-embedded-ai-in-cloud-erp-applications-will-drive-a-30-percent-faster-financial-close-by-2028

Quer revisar esta arquitetura sobre o seu próprio ERP?

Agende uma conversa de 30 minutos: revisamos seu cenário tecnológico, quais objetos você precisaria sincronizar e por onde começar sem tocar no core.

Agendar uma conversa

Segurança na era da IA

Os dados processados pelos agentes de IA não são usados para treinar modelos: é uma garantia contratual com nossos subprocessadores e seus fornecedores de modelos. Nenhum resultado é aplicado sem revisão humana prévia. Isso não significa que os dados nunca sejam armazenados temporariamente para processar uma tarefa.

Segurança e Confiança