Guía estratégica · Arquitectura · 2026

IA en procurement sobre el ERP, sin reemplazar el core

Cómo incorporar analítica y agentes de IA al ciclo de compras dejando el ERP como sistema de registro: una arquitectura por capas, el reparto exacto de responsabilidades y las respuestas a lo que pregunta un CIO antes de aprobar la conexión.

Por Oscar Gamboa, CEO de EGIXIA · Actualizado el 11 de agosto de 2026

Leer la guía Hablar con un arquitecto

Guía completa en esta página · sin formulario y sin descarga

Portada de la guía de integración de IA en procurement sobre el ERP, de Egixia

Resumen ejecutivo

La adopción de inteligencia artificial en las áreas de abastecimiento y compras de las grandes empresas latinoamericanas suele chocar con un dilema de arquitectura: reemplazar el ERP por una suite que ya trae IA incorporada, o quedarse quieto ante la complejidad de integrar. Ninguna de las dos es una decisión de arquitectura; son dos formas de evitarla. Esta guía describe la tercera vía: una arquitectura por capas donde la analítica y los agentes de IA operan sobre el ERP existente y el núcleo transaccional conserva intacta su función de registro, control contable y cumplimiento.

El principio ordenador es simple y tiene consecuencias en todo el diseño: la IA propone, el ERP dispone. Todo lo que compromete presupuesto, crea una obligación contractual o afecta la contabilidad se ejecuta dentro de los flujos autorizados del ERP. Todo lo que analiza, normaliza, compara, verifica o redacta puede vivir en una capa superior desacoplada, que se conecta por APIs estándar del propio ERP y que se puede apagar sin dejar al negocio sin operar.

Para quién es esta guía

Está escrita para quien tiene que aprobar —o rechazar— la conexión de una capa de IA con el sistema donde se registra el dinero de la compañía.

CIO, CTO y arquitectura empresarial

Necesitan saber qué se conecta, con qué protocolo, qué pasa en un upgrade del ERP y cómo se revierte la decisión si el proyecto no prospera.

CPO y directores de compras

Buscan resultados en el ciclo de compras sin abrir un programa de reemplazo de ERP que consuma el presupuesto y la atención del área durante dos años.

CFO, control interno y auditoría

Preguntan qué queda registrado, quién autorizó cada movimiento y cómo se demuestra ante un auditor que una recomendación algorítmica no ejecutó nada por su cuenta.

Contexto: por qué el core no es el lugar de la IA

El núcleo transaccional de un ERP está optimizado para la estabilidad, la integridad contable y el cumplimiento normativo estricto. Esa rigidez no es un defecto: es exactamente lo que se le exige. La inteligencia artificial, en cambio, necesita iterar rápido, procesar datos no estructurados, equivocarse en un ambiente controlado y cambiar de modelo sin abrir un proyecto de meses. Meter esa dinámica dentro del core es pedirle al mismo sistema que sea dos cosas incompatibles a la vez.

El ERP core sigue siendo el sistema de registro de la operación y de la contabilidad; las capacidades de IA operan en una capa superior de orquestación analítica y de apoyo a la decisión, con la gobernanza y la trazabilidad como parte del diseño y no como un añadido posterior.
— Síntesis del principio de arquitectura por capas descrito en las referencias [1] y [2]

En Latinoamérica el argumento pesa todavía más, porque los paisajes tecnológicos son fragmentados: varias instancias de ERP heredadas de adquisiciones, sociedades con reglas fiscales distintas por país y capas locales de facturación electrónica que ningún ERP global trae de fábrica. Reemplazar el core para poder usar IA convierte un proyecto de doce semanas en un programa de dos años, y concentra el riesgo justo donde la empresa no se lo puede permitir.

Dos datos de mercado que conviene tener a la vista antes de aprobar el primer piloto:

Más del 40%

de los proyectos de IA agéntica se cancelarán antes de que termine 2027, por costos crecientes, valor de negocio poco claro o controles de riesgo insuficientes.

Gartner, junio de 2025

30%

más rápido será el cierre financiero en 2028 gracias a la IA embebida en las aplicaciones de ERP en la nube.

Gartner, febrero de 2026

La arquitectura por capas

Cuatro capas con responsabilidades separadas. La prueba de que el diseño está bien hecho es que cada capa se puede describir también por lo que NO hace: ahí es donde se rompen las arquitecturas que fallan.

Capa ERP core

De qué responde: Ejecución contable, emisión definitiva de órdenes de compra, recepción, registro de facturas, pagos y cumplimiento normativo. Es la única fuente de verdad transaccional.

Qué no hace: No aloja modelos, no ejecuta lógica algorítmica y no cambia su configuración para acomodar un piloto de IA.

Capa de integración y datos

De qué responde: Conecta el ERP con el resto del ecosistema usando las APIs estándar del propio ERP, sincroniza maestros y documentos, y mantiene la correspondencia de identificadores entre sistemas.

Qué no hace: No duplica la base transaccional ni se convierte en un segundo libro contable: transporta y concilia, no reemplaza.

Capa de orquestación e IA

De qué responde: Normaliza y clasifica el gasto, verifica documentos, extrae datos de facturas, compara ofertas, detecta anomalías y deja la decisión preparada con su sustento.

Qué no hace: No emite documentos definitivos, no compromete presupuesto y no escribe en el ERP sin que una persona autorizada apruebe el resultado.

Capa de gobernanza y supervisión humana

De qué responde: Umbrales de autonomía por monto y por categoría, control de acceso por rol, revisión humana obligatoria antes de aplicar un resultado y registro auditable de cada paso.

Qué no hace: No es documentación: si no está implementada como control técnico, no existe el día de la auditoría.

Cómo se implementa: cuatro fases

El orden importa más que la velocidad. Las tres primeras fases no requieren tocar el ERP; la cuarta solo escribe en él cuando todo lo anterior está probado.

Fase 1

Diagnóstico del paisaje y de los datos

Antes de conectar nada, auditar lo que ya existe.

Inventario de interfaces vivas con el ERP: qué se conecta hoy, con qué protocolo y quién lo mantiene.
Estado real del maestro de proveedores: duplicados, identificadores fiscales inválidos y categorías inconsistentes.
Mapa de las aprobaciones vigentes por monto, categoría y sociedad.
Definición explícita de qué datos no van a salir del ERP.

Fase 2

Diseño de la arquitectura y de los límites

Escribir el reparto de responsabilidades antes de escribir código.

Asignar cada objeto de negocio a la capa que lo gobierna y a su sistema dueño.
Definir dirección y frecuencia de cada sincronización, y qué pasa cuando falla.
Fijar los umbrales de autonomía por monto y categoría, con el rol que aprueba nombrado.
Especificar qué se registra en el log de auditoría y cuánto tiempo se conserva.

Fase 3

Casos de uso de alto volumen y bajo riesgo

El primer caso se elige por su relación entre volumen y riesgo, no por lo impresionante que suene en una demo.

Verificación documental y homologación de proveedores.
Extracción y validación de facturas, con conciliación contra la orden y la recepción.
Normalización y clasificación del gasto disperso entre sociedades.
Detección de duplicados y anomalías antes de que los documentos entren al ERP.

Fase 4

Piloto acotado, medición y escalamiento

Un piloto que no se puede comparar contra una línea base no es un piloto: es una demo larga.

Medir la línea base antes de encender nada: horas, volumen y tasa de error actuales.
Acotar el piloto a una sociedad o a una categoría, con criterio de éxito escrito.
Monitorear la estabilidad del ERP como métrica de primera clase, no como anécdota.
Escalar por objeto de negocio, no por área completa de una sola vez.

El reparto de responsabilidades, objeto por objeto

La tabla resume dónde vive cada cosa. Si en una discusión de diseño no logra ubicar un objeto en una sola columna, el límite todavía no está definido.

Objeto de negocio	Rol del ERP core	Rol de la capa de IA	Mecanismo de interacción
Maestro de proveedores	Fuente de verdad del registro del proveedor: datos fiscales, contables y bancarios.	Normalización, deduplicación, enriquecimiento de categorías y verificación documental antes de crear o actualizar el registro.	El proveedor se autogestiona y valida sus documentos en la capa de compras; al aprobarse el flujo, se crea o actualiza el registro en el ERP.
Solicitudes y órdenes de compra	Emisión formal, validación presupuestaria y compromiso contable.	Borradores de solicitud, selección de proveedores habilitados por categoría, envío de cotizaciones y cuadro comparativo consolidado.	La capa de IA deja la decisión servida; la orden definitiva se crea en el ERP tras la aprobación de un usuario autorizado.
Facturas y pagos	Registro contable, retenciones, programación y ejecución del pago.	Captura, validación fiscal, detección de duplicados y anomalías, y conciliación contra la orden y la recepción.	La factura llega ya validada al ERP; el estado del pago vuelve del ERP al portal para que el proveedor lo consulte sin llamar a cuentas por pagar.
Control y auditoría	Registro histórico de las transacciones financieras y de pago.	Monitoreo continuo de excepciones, riesgos de cumplimiento y desvíos frente a lo negociado.	Reportes de excepción y registro de cada acción con fecha, hora y usuario, contrastables contra los documentos del ERP.

Las seis preguntas que hace un CIO antes de aprobar

Ninguna de estas preguntas es sobre modelos de IA. Todas son sobre lo que pasa el día que algo sale mal, y son las que deciden de verdad si el proyecto avanza.

¿Dónde viven los datos y quién puede verlos?

Los datos transaccionales siguen en el ERP. En la capa de compras vive lo que el proceso colaborativo necesita: documentos del proveedor, cotizaciones, evaluaciones y trazas. En el caso de EGIXIA esa capa es una plataforma 100% SaaS sobre Amazon Web Services (AWS), en Estados Unidos (región Norte de Virginia), con redundancia en múltiples zonas de disponibilidad. El aislamiento es por cliente: instancia dedicada y base de datos con segregación lógica; cada cliente opera sobre su propio bucket de almacenamiento, con políticas de acceso que impiden el cruce entre clientes.

¿Qué pasa cuando actualizamos el ERP?

Nada, si la integración usa exclusivamente APIs estándar del ERP y no instala desarrollos propios dentro de él. Es el criterio que conviene exigir por escrito a cualquier proveedor. En la integración con SAP, EGIXIA trabaja con OData, BAPI, RFC e IDoc: no se instalan desarrollos Z ni add-ons y no se transporta código de EGIXIA al landscape del cliente, por lo que los upgrades de Support Pack o de release no rompen la conexión. Esa es la diferencia práctica frente a un desarrollo a medida dentro del core.

¿Quién es el dueño del maestro de proveedores?

El ERP, siempre. La capa de compras gestiona el ciclo con el proveedor —vinculación, validación documental, actualización de datos bancarios y renovación de certificados— y sincroniza el resultado con el registro del ERP; no crea un segundo maestro paralelo. Es la diferencia entre integrar y duplicar, y es lo que evita que dos áreas terminen discutiendo cuál de las dos bases tiene la razón.

¿Qué queda registrado para una auditoría?

Cada movimiento sincronizado queda trazado con fecha, hora y usuario, y cada transacción entre sistemas deja su propio registro. Para una recomendación generada por IA hay que exigir algo más: qué datos se usaron, con qué criterio y quién la aprobó. Sin eso, la recomendación no es auditable aunque haya sido correcta. La retención de los logs de auditoría se habilita por proyecto, según las políticas del cliente.

¿Cómo se revierte la decisión si queremos parar?

Como el ERP es el sistema de registro, todo lo contable y lo transaccional ya está dentro de él: revertir es desconectar la capa, no migrar de vuelta. Y al no haber desarrollos instalados en el ERP, tampoco hay nada que desinstalar. Lo que sí conviene acordar por contrato desde el inicio es la devolución de los documentos y datos que viven en la capa de compras; su retención se habilita por proyecto, según las políticas del cliente.

¿Qué pasa si la capa de IA deja de estar disponible?

El ciclo de compras tiene que poder seguir operando en el ERP, aunque sea con más trabajo manual. Ese plan de contingencia se escribe antes del go-live, no después del primer incidente, y se prueba al menos una vez. Del lado del servicio, EGIXIA opera con un SLA de disponibilidad del 99,6%, con despliegue Multi-AZ en AWS.

Checklist para el comité de TI y compras

Seis verificaciones antes de firmar. Respóndalas con evidencia: si no puede mostrar el documento, cuéntelo como un no.

1
Interfaces
¿Está inventariada cada conexión viva con el ERP, con su protocolo, su dueño y su frecuencia?
2
Datos maestros
¿Existe un protocolo escrito para deduplicar, validar identificadores fiscales y unificar categorías antes de alimentar cualquier modelo?
3
Umbrales de autonomía
¿Están fijados por monto y categoría los límites en los que una recomendación exige aprobación humana, y está nombrado el rol que aprueba?
4
Trazabilidad
¿Cada resultado generado por IA queda con registro de los datos que usó, del criterio aplicado y de quién lo aprobó?
5
Continuidad
¿Hay un plan de contingencia escrito y probado para operar el ciclo de compras si la capa de IA no está disponible?
6
Salida
¿Está acordado por contrato qué se devuelve, en qué formato y en qué plazo si el servicio termina?

Las seis se responden en la fase de diseño. Ninguna exige haber elegido todavía un proveedor, y por eso sirven también para comparar propuestas.

Riesgos, límites y lo que esta guía no cubre

Los tres riesgos que más veces detienen un proyecto de IA en compras. Ninguno es el modelo.

Errores del modelo tomados por hechos

Un motor puede interpretar mal una condición contractual o una cláusula de precio y presentar el error con la misma confianza que un acierto. La IA es apoyo a la decisión: la revisión humana antes de aplicar un resultado es un requisito de diseño, no una limitación temporal de la tecnología.

La superficie de integración

Cada punto de conexión con el core es una puerta. Exija autenticación estándar, cifrado de los datos en tránsito, privilegios mínimos por servicio y un usuario técnico con autorizaciones acotadas, definido con su equipo de seguridad antes del primer llamado.

Datos maestros sucios

Un maestro con duplicados y categorías inconsistentes produce resultados inútiles con apariencia de precisión. La depuración precede al despliegue algorítmico: es el trabajo aburrido que decide el resultado del piloto.

Nota aclaratoria: esta guía ofrece orientación metodológica de carácter general y no constituye asesoría legal, fiscal, financiera ni formal en materia de ciberseguridad o cumplimiento normativo. Cada organización debe validar su arquitectura con sus comités internos y con la normativa que le aplique.

Cómo medir que la arquitectura funciona

Cuatro indicadores. El cuarto es el que suele faltar y es justamente el que le importa al CIO.

Ciclo de adquisición (cycle time)

Días desde la requisición hasta la orden de compra aprobada, comparados contra la línea base medida antes del piloto.

Tasa de aceptación de recomendaciones

Porcentaje de sugerencias de la capa de IA que el comprador acepta sin modificar. Una tasa muy baja indica un criterio mal calibrado; una tasa perfecta indica que nadie está revisando.

Precisión en la clasificación del gasto

Porcentaje de transacciones catalogadas correctamente por los motores, sin corrección manual posterior.

Estabilidad del ERP core

Incidentes y degradaciones del sistema transaccional atribuibles a la capa de integración. El objetivo es cero y se mide desde el primer día.

Cómo lo hace EGIXIA

EGIXIA ayuda a grandes empresas latinoamericanas a simplificar su ciclo de compras completo, combinando software enterprise, servicios especializados y operación asistida por IA sobre el ERP que ya tienen. La plataforma opera como capa de compras sobre el ERP: los proveedores se autogestionan, las cotizaciones y las validaciones documentales ocurren en la capa, y el ERP sigue siendo el sistema de registro contable, de inventarios y de pagos.

La conexión usa las APIs estándar de cada ERP —OData, BAPI, RFC, IDoc y SAP CPI en SAP S/4HANA y ECC; REST API, SuiteScript y SuiteTalk en Oracle NetSuite; Service Layer y DI API en SAP Business One— con sincronización programada o por eventos, según el caso. Sin desarrollo ABAP y sin código de EGIXIA transportado al landscape del cliente. La implementación se mide en semanas, no meses.

Sobre la capa de IA, el compromiso es explícito: los agentes preparan la decisión y ninguna de sus salidas se aplica sin revisión humana previa. Los datos que procesan los agentes de IA no se usan para entrenar modelos: es una garantía contractual que EGIXIA sostiene con sus subprocesadores y estos con sus proveedores de modelos. Cada tarea corre en un entorno aislado, sin acceso a datos de otros clientes, y EGIXIA ejecuta un borrado proactivo dentro de las 72 horas siguientes a la entrega. La pseudonimización reversible antes del procesamiento por IA se habilita por proyecto, según las políticas del cliente.

En los casos de negocio que construimos, la palanca de mayor valor es llevar más gasto a competencia: el rango que utilizamos para dimensionarla es 2-4% de mejora de precio en el gasto llevado a competencia.

Rango de referencias de mercado que EGIXIA utiliza en sus casos de negocio.

El detalle técnico, en su propia página

Integración con SAP

Conectores, objetos soportados, metodología de implementación y qué pasa exactamente en un upgrade.

Ver la integración con SAP

SRM integrado con SAP y Oracle

Qué objetos se sincronizan en cada ERP, en qué dirección y con qué protocolo.

Ver el detalle de sincronización

Los 8 tipos de agente de IA

Qué hace cada tipo, su madurez real en 2026 y los siete criterios para evaluar la versión de cualquier proveedor.

Leer la guía de evaluación

Seguridad y compliance

La capa de integración es la superficie que revisa el área de seguridad de TI. Estas son las respuestas que publicamos, con el mismo texto que usamos en las páginas de integraciones.

Cada conexión corre sobre infraestructura de Amazon Web Services (AWS) certificada bajo ISO 27001, SOC 1/2/3 y PCI DSS; los controles propios de Egixia están alineados a ISO 27001 y se validan con pruebas de penetración externas, cuyo informe ejecutivo está disponible bajo acuerdo de confidencialidad.

TLS 1.3

Cifrado de los datos en tránsito en toda comunicación.

OAuth 2.0

Autenticación segura con tokens.

AES-256

Cifrado de los documentos almacenados; el cifrado de la base de datos y de los volúmenes se habilita por proyecto, según las políticas del cliente.

SSO SAML

Single Sign-On empresarial para el acceso de usuarios: se habilita por proyecto, según las políticas del cliente.

Ver el detalle en el Trust Center →

Preguntas frecuentes

¿Es necesario reemplazar el ERP para usar IA en compras?

No. Una arquitectura por capas permite acoplar analítica y agentes de IA mediante las APIs estándar del propio ERP, dejando el núcleo transaccional como sistema de registro. Reemplazar el core es una decisión distinta, con otro horizonte, otro presupuesto y otro riesgo: no es un prerrequisito para tener IA en el ciclo de compras.

¿Cómo se garantiza que la IA no ejecute una transacción financiera sin autorización?

Con umbrales de autonomía escritos y revisión humana obligatoria antes de que cualquier resultado se aplique. Los agentes generan borradores, comparaciones y análisis; la emisión formal de la orden, el compromiso presupuestario y el pago ocurren dentro de los flujos de aprobación del ERP. Técnicamente un agente podría adjudicar solo; no debe, porque una adjudicación compromete presupuesto y solo es defendible ante una auditoría si alguien la firmó.

¿Qué pasa con la integración cuando se actualiza el ERP?

Si la integración usa exclusivamente APIs estándar y no instala desarrollos dentro del ERP, los upgrades no la rompen. En la integración de EGIXIA con SAP no se instalan desarrollos Z ni add-ons y no se transporta código al landscape del cliente, por lo que los upgrades de Support Pack o de release no afectan la conexión.

¿Quién es el dueño del maestro de proveedores en esta arquitectura?

El ERP. La capa de compras gestiona el ciclo colaborativo con el proveedor —vinculación, validación documental y actualización de datos— y sincroniza el resultado con el registro del ERP, sin crear un segundo maestro paralelo. En SAP, ese registro es el maestro de proveedores del propio sistema.

¿Qué desafíos de datos son los más comunes en Latinoamérica al integrar IA?

La fragmentación del maestro de proveedores entre subsidiarias y sistemas heredados de adquisiciones, y las categorías inconsistentes entre sociedades. Antes de alimentar cualquier modelo hay que deduplicar, validar los identificadores fiscales y unificar la taxonomía: es el trabajo que decide si el piloto produce un resultado o una lista de excepciones.

¿Cuánto tarda montar la capa de integración sin tocar el core?

Depende del paisaje tecnológico, pero un alcance modular por fases permite tener funcionando el primer caso de uso sin esperar al proyecto completo: se empieza por el registro y la validación de proveedores y se escala por objeto de negocio. En EGIXIA la implementación se mide en semanas, no meses.

¿Cómo garantizan la seguridad de la integración?

TLS 1.3 para los datos en tránsito. Los documentos que cargan tus proveedores se almacenan cifrados con AES-256; el cifrado de la base de datos y de los volúmenes se habilita por proyecto, según las políticas del cliente. La conexión con el ERP usa autenticación OAuth 2.0 y respeta los roles y perfiles de cada ERP; el Single Sign-On empresarial (SAML) para el acceso de usuarios se habilita por proyecto, según las políticas del cliente. Las conexiones se monitorean de forma continua con detección automatizada. Sobre certificaciones: la infraestructura de Amazon Web Services (AWS) está certificada bajo ISO 27001, SOC 1/2/3 y PCI DSS; los controles propios de Egixia están alineados a ISO 27001 y se validan con pruebas de penetración externas, cuyo informe ejecutivo está disponible bajo acuerdo de confidencialidad. Egixia no está certificada en ISO 27001 ni cuenta con un informe SOC 2 Tipo II emitido: el detalle está en nuestro Trust Center.

Referencias

Fuentes consultadas para esta guía. Las dos cifras de mercado citadas provienen de [3] y [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

¿Quiere revisar esta arquitectura sobre su propio ERP?

Agende una conversación de 30 minutos: revisamos su paisaje tecnológico, qué objetos tendría que sincronizar y por dónde empezar sin tocar el core.

Agendar una conversación