En el artículo anterior expliqué el cambio filosófico que representa la Empresa Autónoma: de sistema que recuerda a sistema que actúa.
Ahora toca entrar en la arquitectura que lo hace posible, porque sin entender las cuatro capas que la sostienen, el concepto se queda en marketing.
Y antes de empezar, una aclaración que atraviesa todo el artículo: autónoma no significa desatendida. Las personas dejan de ejecutar cada paso, pero siguen definiendo objetivos, permisos, excepciones y límites. La autonomía está en la ejecución, no en la dirección.
Joule: la capa de engagement
Joule no debe entenderse ya simplemente como el asistente conversacional que apareció inicialmente integrado en las aplicaciones SAP. En la arquitectura de la Empresa Autónoma pasa a convertirse en la capa desde la que el usuario expresa una intención y el sistema coordina datos, aplicaciones, asistentes y agentes para ejecutarla.
Dentro de Joule hay tres elementos que conviene distinguir con precisión.
La experiencia de usuario: el espacio desde el que planteas qué quieres conseguir y desde el que el sistema toma el relevo.
Entienden la intención, el rol y el contexto de negocio del usuario, y coordinan lo que tiene que pasar para conseguir el resultado.
Son los que ejecutan: conectan datos, herramientas y aplicaciones, y realizan los pasos del proceso sin intervención humana en cada uno.
La jerarquía es clara: Joule Work es donde trabajas con Joule. El Assistant entiende qué quieres conseguir y coordina. El Agent ejecuta el trabajo.
El asistente habla contigo. El agente trabaja.
SAP Autonomous Suite: el núcleo operativo
Ya cubierto en el artículo anterior: los cinco dominios autónomos (Finance, Spend, Supply Chain, HCM y CX) funcionando como sistema integrado, con un ciclo continuo en cada dominio donde las personas fijan dirección, las aplicaciones generan señales, los datos proveen contexto y los agentes actúan.
Lo que añade la perspectiva arquitectónica es el papel que desempeña esta capa en el conjunto. Los agentes no operan sobre procesos abstractos. Operan sobre aplicaciones de negocio que ya contienen transacciones, reglas, autorizaciones y lógica empresarial. La Autonomous Suite es, por tanto, el lugar donde la inteligencia termina convirtiéndose en acción: crear un pedido, modificar una previsión, resolver una incidencia, ejecutar un proceso financiero.
Industry AI: la capa de verticalización
La verticalización es donde la promesa de la IA de propósito general encuentra sus límites. Un modelo de lenguaje genérico puede leer datos de mantenimiento de activos industriales, pero no sabe que en el sector Oil & Gas la planificación de paradas tiene implicaciones regulatorias específicas, ni que la secuencia de permisos de trabajo tiene una lógica que no está en los datos sino en décadas de operación industrial.
Industry AI embebe ese conocimiento directamente en las capacidades de IA. Los modelos de datos, la lógica regulatoria y el conocimiento de procesos verticales forman parte del contexto con el que opera la IA desde su diseño, no son una capa de prompting añadida posteriormente.
Para un CIO de utilities, retail o producción discreta, esto marca la diferencia entre un agente que ejecuta procesos genéricos y un agente que entiende cómo funciona su negocio.
SAP Business AI Platform: la fundación
SAP Business AI Platform reúne capacidades de SAP BTP, SAP Business Data Cloud y gestión tecnológica bajo una arquitectura común orientada a IA. El argumento no es solo de marketing: mantener separadas la construcción, los datos, el contexto y la gobernanza multiplica la complejidad de operar agentes a escala.
La plataforma se articula en tres pilares.
Es donde se construyen los agentes. Joule Studio es el entorno de desarrollo AI-first, desde no-code hasta pro-code, que permite describir la intención de negocio para que la plataforma la traduzca en flujos ejecutables. SAP Integration Suite provee la conectividad con APIs, eventos y protocolos como MCP (Model Context Protocol, el estándar que permite a los agentes conectarse con herramientas y fuentes de datos externas) y A2A (Agent2Agent, el protocolo abierto que permite a distintos agentes comunicarse y colaborar) para que los agentes operen sobre datos reales de sistemas SAP y no-SAP en tiempo real.
Es lo que diferencia a un agente SAP de un agente genérico. El SAP Knowledge Graph de S/4HANA se basa en 452.000 tablas ABAP, 80.000 CDS Views y 7,3 millones de campos. En términos prácticos, ese contexto permite relacionar conceptos de negocio, por ejemplo un material, una posición de pedido y sus implicaciones contables, en lugar de tratar los datos como campos aislados.
Aquí está probablemente la principal ventaja estructural de SAP frente a quien intente construir una capa de IA por encima de un ERP: SAP no solo tiene acceso al dato, tiene el modelo semántico que explica qué significa ese dato y cómo se relaciona con el proceso de negocio. Cincuenta años de lógica de procesos empresariales convertida en contexto que el agente puede razonar.
Los modelos fundacionales se democratizan. El contexto empresarial no.
Es donde se gestiona el ciclo de vida de los agentes en producción. SAP habla ya de más de 55.000 live agents gestionados mediante SAP AI Agent Hub. Cada acción es auditable y trazable desde el primer día, no como añadido posterior. En sectores regulados, la pregunta del auditor no es «¿qué decidió el sistema?» sino «¿por qué lo decidió y quién lo autorizó?». La gobernanza tiene que estar en el diseño, no en el manual de usuario.
La integración no desaparece, cambia
Esto tampoco significa que la integración desaparezca. Al contrario: APIs, eventos, Integration Suite y protocolos como MCP y A2A pasan a ser parte de la infraestructura que permite actuar a los agentes. Lo que debería desaparecer es la integración como problema visible para el usuario que intenta completar un proceso. El landscape sigue siendo complejo. Lo que cambia es quién gestiona esa complejidad.
Lo que esto implica para el arquitecto y el consultor
Ya escribí anteriormente que:
El argumento entonces era estructural: actualizaciones continuas, extensibilidad, integración e IA embebida necesitan un núcleo estable para poder escalar, pero la Empresa Autónoma añade ahora otra razón. Un agente que tiene que navegar decenas de personalizaciones no estándar, excepciones y comportamientos específicos pierde precisamente la ventaja de contexto, velocidad y fiabilidad que justifica su existencia.
Clean Core no solo facilita mantener y evolucionar el sistema, facilita que el sistema pueda ser entendido y operado por agentes.
La deuda técnica adquiere así una dimensión nueva: ya no condiciona únicamente cuánto cuesta mantener un sistema, sino hasta qué punto ese sistema puede automatizarse.
Y aparece también una nueva responsabilidad para el arquitecto. No se trata de conectar el agente con el proceso, eso lo resuelve SAP. Se trata de garantizar que el dato sobre el que el agente razona sea correcto, esté donde tiene que estar y tenga la calidad suficiente para que la decisión que tome el agente sea fiable. La deuda de datos es tan bloqueadora como la deuda técnica.
En el artículo anterior decía que estábamos pasando del sistema que recuerda al sistema que actúa. Después de mirar la arquitectura, añadiría una condición. Para que el sistema pueda actuar, primero tiene que poder entender. Entender el dato, entender el proceso, entender quién puede hacer qué y entender las consecuencias de cada acción.
Por eso la pregunta arquitectónica más importante para cualquier proyecto SAP que empiece hoy ya no es únicamente si estamos construyendo un sistema mantenible. La pregunta es si estamos construyendo un sistema que un agente pueda entender y operar mañana, o si estamos añadiendo deuda que se lo impedirá.
Este artículo es la segunda parte de Autonomous Enterprise: De sistema de Registro a sistema de Acción.
Jorge Ocampos 