Cada vendor de ERP grande está anunciando, con distintos nombres, la misma promesa: un agente de IA que vive dentro de la plataforma, entrenado sobre sus datos, listo para sugerir o ejecutar decisiones sin que el usuario salga de la interfaz. Es una promesa cómoda porque resuelve, de una sola vez, el problema comercial del vendor: dar una razón nueva para renovar la licencia; y el problema aparente del cliente: tener IA "ya integrada" sin proyecto adicional. La pregunta que casi nadie hace en ese momento es si el proceso que se quiere automatizar vive, en realidad, dentro del ERP.
Casi nunca vive ahí. Una orden de compra que un agente podría aprobar automáticamente empieza en un correo o una solicitud interna, pasa por el ERP para el presupuesto, necesita validación contra el CRM para confirmar el contrato vigente con el proveedor, y termina en un banco o pasarela de pagos que el ERP apenas conoce. Una decisión de cobranza cruza el ERP, el sistema de atención al cliente y, con frecuencia, una hoja de cálculo que nadie admite que sigue existiendo. El agente nativo del ERP, por diseño, solo ve la porción del proceso que ocurre dentro de esa caja. Fuera de ella, no decide, sino que adivina o simplemente no actúa.
Esto convierte al agente embebido en una solución elegante para un problema que las empresas casi nunca tienen (decisiones que dependen exclusivamente del ERP), y en una solución débil para el problema que sí tienen: decisiones que cruzan varios sistemas y requieren contexto que ningún módulo por sí solo posee. La ironía es que mientras más "inteligente" se anuncia el agente nativo, más evidente se vuelve que su inteligencia está encerrada en las paredes del sistema que la vende.
Hay un segundo costo, menos visible que la limitación funcional y más caro a largo plazo. Adoptar el agente nativo del ERP no es solo comprar una funcionalidad; es aceptar una nueva capa de dependencia sobre el mismo proveedor. Antes, cambiar de ERP significaba migrar datos y reentrenar usuarios en una interfaz distinta. Con el agente nativo, cambiar de ERP significa además perder la capa de decisión automatizada que la empresa construyó encima, porque esa capa nunca fue portable: fue diseñada para vivir y morir dentro de esa plataforma específica. El lock-in tradicional era de datos, mientras que el nuevo lock-in es de criterio de decisión, y ese es mucho más difícil de reconstruir en otro lado.
La alternativa no es rechazar la IA agéntica dentro de los procesos que hoy corren en el ERP; es rechazar la premisa de que el lugar correcto para que viva el agente sea dentro del ERP mismo. Un agente que orquesta por encima de varios sistemas (el ERP, el CRM, el sistema de pagos, la mesa de servicio), puede ver el proceso completo en vez de un fragmento, y puede sobrevivir a que la empresa cambie de ERP el día de mañana, porque su lógica de decisión no depende de la licencia de ningún vendor particular. Es una arquitectura más exigente de construir que instalar el copiloto que ya viene incluido en la próxima actualización. También es la única que no ata el futuro de la automatización de una empresa al roadmap comercial de un tercero.
Ninguna empresa que está evaluando IA agéntica hoy se pregunta primero si el agente que le venden es portable. Se pregunta si funciona, si es fácil de activar, si viene "gratis" con el contrato que ya tiene firmado. Son las preguntas equivocadas para una decisión que, a diferencia de casi cualquier otra que se toma sobre un ERP, no se revierte con una migración de datos. Se revierte reconstruyendo, desde cero, todo el criterio que la empresa delegó.
