Los agentes empresariales más valiosos pueden no salir del sistema transaccional. La apuesta de Joule de SAP
SAP despliega Joule Work este mes y cuenta con más de 200 Joule Agents en flujos de trabajo deterministas. La arquitectura importa más que el número de agentes.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.

El lugar más seguro para un agente empresarial puede ser el único lugar que la mayoría de las arquitecturas de agentes evita: dentro del sistema de registro.
El diseño común funciona al revés. Un agente lee datos a través de una API, razona sobre ellos en otro lugar y escribe un resultado de vuelta. Cada salto es un lugar donde las reglas de negocio, los permisos y los registros de auditoría deben reconstruirse, y cada regla reconstruida es una copia que puede desviarse del original.
La ponencia de SAP en SAP Connect el 7 de octubre es la apuesta pública más fuerte hasta ahora por la alternativa.
Reglas que no tienen que copiarse
Cuando un agente propone una orden de compra dentro de la aplicación de compras, se aplican los mismos límites de aprobación, segregación de funciones y controles de contabilización que cuando lo hace una persona. Nada tiene que reimplementarse en una capa de orquestación, porque el agente nunca abandona el lugar donde esas reglas ya se ejecutan.
El registro de auditoría sigue la misma lógica. En finanzas y compras, la primera pregunta de un auditor es quién cambió qué, cuándo y bajo qué autoridad. Si la acción del agente es una transacción normal en el sistema de registro, queda en el mismo log que la de todos los demás. Vimos el mismo principio en el sistema de cuentas por pagar de Snowflake, que mantiene deterministas los pasos deterministas.
El significado también viene incluido. Una orden de compra, un centro de costes o un bloqueo de proveedor significan algo preciso en un ERP. Un agente que trabaja con esos objetos no tiene que reconstruir su significado a partir de documentos, de forma similar a como una ontología hizo el trabajo en Genie One de Databricks para fondos.
Lo que SAP realmente puso sobre la mesa
SAP dice que Joule Work se está desplegando este mes como una nueva interfaz para IA, para que las personas pidan resultados en lenguaje natural en lugar de aprender las pantallas de SAP, y que llega a todos sus más de 400 millones de usuarios. Cuenta con más de 20 Joule Assistants y más de 200 Joule Agents en finanzas, compras, cadena de suministro, RR. HH. y experiencia de cliente, y tiene como objetivo más de 400 agentes para finales de año.
La afirmación arquitectónica es explícita: los agentes se ejecutan dentro de flujos de trabajo de aplicaciones deterministas, con los mismos datos, reglas y registros de auditoría que la aplicación de negocio. SAP contrasta eso con un modelo de lenguaje por sí solo, que da la respuesta más probable en lugar de una verificada. Un grafo de conocimiento y SAP Business Data Cloud dan a los agentes una vista mapeada de los campos, tablas, API y productos de datos de SAP, con lógica de negocio adjunta.
SAP cita a Novartis pilotando agentes de abastecimiento para el análisis de ofertas, e informa de ganancias de productividad de más del 20% en sus propias funciones de RR. HH., finanzas y compras. Ambas son afirmaciones de SAP. Mida en sus propios procesos antes de planificar en torno a ellas.
De dónde vienen los controles del agente
Dentro del sistema de registro
- Límites de aprobación
- Segregación de funciones
- Controles de contabilización
- Registro de auditoría
- Significado del objeto de negocio
Heredado por el agente, no reconstruido
Más allá del límite del ERP
- CRM
- Correo electrónico
- Portal de proveedores
- Otro SaaS
La identidad, la política y el registro deben diseñarse de nuevo
Donde se detiene el argumento
La tesis se sostiene para el trabajo transaccional dentro de un sistema. Se debilita en los bordes.
Muchos procesos reales abarcan el ERP, un CRM, el correo electrónico y un portal de proveedores. Un agente que permanece dentro de SAP es seguro dentro de SAP; en el momento en que actúa en otro lugar, vuelven las preguntas de integración, identidad y política, y alguien tiene que decidir qué plataforma gobierna al agente más allá del límite.
El lock-in crece con cada agente construido sobre la lógica de aplicación de un proveedor. Puede ser un trade-off justo por los controles obtenidos, pero debe hacerse a propósito y tenerse en cuenta al comparar plataformas.
Y un flujo de trabajo determinista solo protege lo que modela. Si un límite de aprobación está configurado mal, un agente respetará el límite equivocado más rápido que cualquier persona. Antes de que los agentes hereden autorizaciones, límites de aprobación y reglas de contabilización, esa configuración merece una revisión, junto con una respuesta clara sobre cómo aparecerá la acción de un agente en el registro de auditoría: qué identidad, qué agente, qué solicitud.
Esa es la forma práctica de la apuesta de SAP. Dentro del sistema que ya conoce las reglas, los agentes pueden ser útiles y controlados a la vez. El trabajo de diseño más difícil empieza en el borde de ese sistema, donde realmente viven la mayoría de los procesos de extremo a extremo.