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, CEO 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 e compliance

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.

Cada conexão roda sobre infraestrutura da Amazon Web Services (AWS) certificada sob ISO 27001, SOC 1/2/3 e PCI DSS; os controles próprios da Egixia estão alinhados à ISO 27001 e são validados com testes de penetração externos, cujo relatório executivo está disponível sob acordo de confidencialidade.

TLS 1.3

Criptografia dos dados em trânsito em toda comunicação.

OAuth 2.0

Autenticação segura com tokens.

AES-256

Criptografia dos documentos armazenados; a criptografia do banco de dados e dos volumes é habilitada por projeto, conforme as políticas do cliente.

SSO SAML

Single Sign-On empresarial para o acesso de usuários: habilitado por projeto, conforme as políticas do cliente.

Ver o detalhe no Trust Center →

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 garantem a segurança da integração?

TLS 1.3 para os dados em trânsito. Os documentos que seus fornecedores carregam são armazenados criptografados com AES-256; a criptografia do banco de dados e dos volumes é habilitada por projeto, conforme as políticas do cliente. A conexão com o ERP usa autenticação OAuth 2.0 e respeita os perfis de cada ERP; o Single Sign-On empresarial (SAML) para o acesso de usuários é habilitado por projeto, conforme as políticas do cliente. As conexões são monitoradas de forma contínua com detecção automatizada. Sobre certificações: a infraestrutura da Amazon Web Services (AWS) está certificada sob ISO 27001, SOC 1/2/3 e PCI DSS; os controles próprios da Egixia estão alinhados à ISO 27001 e são validados com testes de penetração externos, cujo relatório executivo está disponível sob acordo de confidencialidade. A Egixia não é certificada em ISO 27001 nem possui um relatório SOC 2 Tipo II emitido: o detalhe está no nosso Trust Center.

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