La empresa autónoma es inevitable; el proveedor único, no
En los próximos años, buena parte del trabajo administrativo de una empresa (cerrar el mes, conciliar, comprar, planificar la demanda, responderle a un cliente) dejará de ser una secuencia de pantallas operadas por personas. Lo ejecutarán agentes de IA que razonan sobre datos de negocio, actúan dentro de reglas y escalan a una persona cuando hace falta. SAP llama a ese destino la Autonomous Enterprise. Microsoft, Salesforce, ServiceNow, Oracle y Workday cuentan su propia versión del mismo relato. Que todos converjan en la misma idea es la mejor señal de que esta es la dirección en que se mueve el software empresarial.
Que tu empresa será autónoma ya parece resuelto. La pregunta abierta es cómo y con quién, y ahí conviene detenerse. La capa agéntica será la más íntima de la organización: concentrará su contexto, sus reglas, su memoria y, cada vez más, sus decisiones. Quien controle esa capa tendrá en sus manos algo más valioso que lo que fue el ERP durante los últimos veinte años.
Por eso, la idea que recorre este artículo es simple: conviene construir la empresa autónoma sin entregarle a un solo proveedor la llave de todas las puertas. La razón la entiende cualquier gerente de finanzas: la capacidad de elegir y el poder de negociación son activos, y se pierden de a poco, casi sin darse cuenta. Cuando ya se perdieron, se notan en el precio. Por eso, la empresa autónoma hay que decidirla proceso por proceso, y esa decisión vale más que cualquier plataforma.
Qué propone SAP: tres capas y un lenguaje nuevo
SAP presentó la Autonomous Enterprise en SAP Sapphire, en mayo de 2026, con una promesa ambiciosa: que “las personas y la IA trabajen juntas” para ejecutar los procesos más críticos del negocio de forma rentable y segura. En octubre, en SAP Connect, mostró clientes usando la propuesta, y en SAP TechEd, en Berlín, les dijo a los desarrolladores: “Ustedes pueden construir la empresa autónoma”.
La propuesta se ordena en tres capas:
- Joule Work, la capa de interacción con la IA (AI engagement layer), que SAP describe como “una nueva interfaz para la IA”. El usuario deja de navegar transacciones y conversa con Joule, que razona y actúa sobre datos SAP y no SAP. SAP lo resume así: durante décadas los usuarios aprendieron cómo funcionaba SAP; ahora “SAP aprende cómo trabajan las personas”.
- SAP Autonomous Suite, la capa de ejecución: asistentes y agentes gestionados por SAP en cinco dominios (finanzas, compras, supply chain, recursos humanos y experiencia de cliente). En Sapphire anunció más de 50 Joule Assistants que orquestan más de 200 agentes especializados; en TechEd ya hablaba de más de 300 Joule Agents estándar.
- SAP Business AI Platform, la infraestructura: unifica SAP BTP, SAP Business Data Cloud y SAP Business AI en un solo entorno gobernado, con tres capacidades: construir agentes, contextualizarlos con datos de negocio y gobernar cómo operan.
Debajo de esas capas están las piezas que hacen el trabajo fino:
- SAP Knowledge Graph: un mapa de entidades, procesos y relaciones del negocio que, según SAP, abarca más de 7 millones de campos, 50 millones de tablas, más de 50.000 APIs y 400 productos de datos. Es lo que SAP llama su contexto de negocio (business context) y, en palabras de sus propios ejecutivos, su “ingrediente secreto”.
- Joule Studio: el entorno para construir y extender agentes, sin código o con desarrollo profesional, con acceso a más de 70 modelos.
- SAP Business Data Cloud: el tejido de datos de negocio (business data fabric) que conecta datos, semántica, procesos y políticas, ahora con un lakehouse sobre Apache Iceberg (tras la compra de Dremio), Databricks nativo y SAP Reltio para los datos maestros.
- SAP AI Agent Hub, el agent gateway y el SAP Enterprise AI Gateway: la capa de gobierno, que verifica cada agente antes de que pueda ser invocado, lo traza y lo controla en tiempo de ejecución.
El discurso de confianza es lo más sólido de la propuesta. SAP insiste en que los modelos de lenguaje son probabilísticos y en que “una respuesta ‘probable’ simplemente no basta”. Sus agentes están “integrados en los flujos deterministas” de las aplicaciones: usan los mismos datos, siguen las mismas reglas y dejan la misma pista de auditoría. El cliente decide el nivel de autonomía de cada proceso, con tres grados de supervisión: la persona aprueba (human-in-the-loop), la persona monitorea (human-on-the-loop) o la persona conserva la autoridad final para intervenir (human-in-command). Todo bajo el principio de “libertad dentro de límites”.
Hay que reconocerlo: como arquitectura, está bien pensada. Lo que conviene examinar es el empaque.
Las capas de una empresa autónoma
Si se le quita la marca, la arquitectura que describe SAP es la misma que describen Microsoft, Google, AWS o Anthropic: siete capas y un gobierno que las cruza todas. Lo que cambia entre proveedores es quién controla cada pieza.
arquitectura de referencia · 7 capas y un gobierno transversal
Los modelos de lenguaje compiten entre sí y bajan de precio cada pocos meses. El contexto de negocio, en cambio, se construye en cada empresa, y es lo que le permite a un agente distinguir un pedido urgente de uno rutinario, o saber qué tabla no se toca durante el cierre. SAP lo dice con todas sus letras: “cualquier sistema de IA es tan bueno como los datos sobre los que razona”. Por eso la pregunta estratégica es quién construye, mantiene y es dueño de ese contexto.
Construir lo mismo con arquitectura abierta
El dato más revelador de la propuesta de SAP está en la lista de sus socios. Para construir su Autonomous Enterprise, SAP usa Claude, de Anthropic, entre los modelos que impulsan sus Joule Agents; n8n para la orquestación visual dentro de Joule Studio; NVIDIA para el entorno de ejecución seguro; Databricks dentro de Business Data Cloud; Apache Iceberg y Apache Polaris como formato y catálogo de datos; Mistral y Cohere como opciones de modelos soberanos, e interoperabilidad entre agentes (agent-to-agent) con los frameworks de Google y Microsoft. Joule Work, además, se conecta de fábrica con Office 365, Claude Cowork, Glean y ServiceNow.
Es decir: la empresa autónoma de SAP se arma, en buena parte, con piezas que cualquier empresa puede contratar directamente. El propio Manoj Swaminathan, a cargo de SAP Autonomous Suite, explicó que ofrecer más de 70 modelos “reduce la dependencia de un proveedor y controla el costo de los tokens”. Es exactamente el argumento de este artículo, extendido de los modelos a toda la pila.
Los estándares abiertos hacen que esa elección sea real. El Model Context Protocol (MCP), creado por Anthropic, es desde diciembre de 2025 un proyecto de la Agentic AI Foundation de la Linux Foundation, que en octubre de 2026 superó los 300 miembros. El protocolo A2A, nacido en Google, está en la Linux Foundation desde junio de 2025 y ya lo respaldan más de 150 organizaciones. Con MCP, un agente se conecta a cualquier sistema; con A2A, un agente conversa con otro de distinto proveedor. SAP adoptó ambos, y eso es una buena noticia para todos.
Esta tabla muestra, capa por capa, qué ofrece SAP y qué alternativas existen hoy en el mercado:
| Capa | En el framework SAP | Alternativas de mercado |
|---|---|---|
| Experiencia | Joule Work | Microsoft 365 Copilot, Claude, Gemini Enterprise, ChatGPT Enterprise, portales propios |
| Agentes y asistentes | SAP Autonomous Suite, Joule Studio | Microsoft Copilot Studio y Microsoft Foundry, Amazon Bedrock AgentCore, Google Vertex AI, Claude Agent SDK, OpenAI AgentKit, LangGraph |
| Modelos de IA | Más de 70 modelos seleccionados por SAP | Contrato directo con Anthropic, OpenAI, Google o Mistral, o a través de Azure, AWS y Google Cloud; modelos abiertos como Llama |
| Orquestación e integración | Agent gateway (A2A), SAP Integration Suite, SAP Enterprise AI Gateway | MCP y A2A como estándares; Workato, MuleSoft, Boomi, n8n; gateways de IA propios |
| Contexto de negocio | SAP Knowledge Graph, Ontology Manager | Ontologías y grafos propios (Palantir Foundry, Neo4j); servidores MCP que exponen el SAP real del cliente, como Atlas e IRIS de Novis |
| Datos | SAP Business Data Cloud, SAP Databricks, SAP Reltio | Databricks, Snowflake, Microsoft Fabric, Google BigQuery, con Apache Iceberg como formato común |
| Gobierno | SAP AI Agent Hub, SAP LeanIX, Signavio agent mining | Microsoft Agent 365 y Entra Agent ID, ServiceNow AI Control Tower, Celonis, observabilidad con Langfuse o Datadog |
| Sistemas de registro | SAP Cloud ERP (RISE with SAP, GROW with SAP) | El ERP que ya opera (SAP ECC, S/4HANA on-premise u otro) con clean core, más aplicaciones cloud-native propias |
La batalla más visible será por la capa de experiencia. Gartner estima que hacia 2028 un tercio de las experiencias de usuario pasará de las aplicaciones a interfaces agénticas. Joule Work es la apuesta de SAP por ese lugar, como Copilot lo es de Microsoft y Agentforce de Salesforce. Quien ocupe esa pantalla definirá por dónde entra el trabajo, y por eso conviene que la empresa la tome a conciencia, antes de que la decida el hábito.
En la capa de contexto está lo que más nos importa. En Novis desarrollamos Atlas, que analiza la configuración, el código propio y el uso real del SAP de cada cliente, e IRIS, un servidor MCP que pone ese conocimiento a disposición de los modelos de IA mediante un estándar abierto. Es el mismo principio del Knowledge Graph, pero construido sobre el sistema real de cada empresa, con sus desarrollos Z y sus particularidades, y sin atarlo a una plataforma.
Framework SAP o arquitectura abierta: una comparación
Ninguno de los dos caminos gana en todo. El framework de SAP es más rápido en los procesos estándar de SAP; la arquitectura abierta es más barata, más flexible y deja la puerta de salida abierta, a cambio de exigir más disciplina de diseño.
| Dimensión | Framework SAP | Arquitectura abierta |
|---|---|---|
| Punto de partida | Pensado para SAP Cloud ERP. Los clientes RISE activan tres asistentes el primer año; los de GROW, el portafolio completo. Las empresas on-premise o en ECC acceden a escenarios seleccionados si se comprometen a llevar la mayor parte de su landscape a SAP Cloud ERP | Se construye sobre lo que la empresa ya tiene, sea SAP o no |
| Contexto del SAP estándar | Nativo: Knowledge Graph y agentes dentro de flujos deterministas | Hay que construirlo; exige conocer SAP por dentro |
| Procesos que cruzan sistemas | Vía Business Data Cloud y A2A, con SAP al centro | Cada sistema es un par; el orquestador no pertenece a ningún proveedor de aplicaciones |
| Elección de modelos | Más de 70, seleccionados por SAP | Cualquiera, con contrato directo y cambio en semanas |
| Costo | Base AI incluida en las suscripciones cloud. Lo premium se paga en AI Units (de 8 a 1 por usuario al mes según volumen, o por consumo), que se compran por año y vencen a los 12 meses. Joule Studio consume créditos de BTP. No hay precio de lista público | Tokens a precio de mercado, muchas veces dentro de compromisos de nube ya contratados; herramientas abiertas; costo de construcción en caída |
| Gobierno | Integrado para los agentes SAP: verificación en AI Agent Hub antes de invocar | Hay que diseñarlo desde el primer día; las herramientas existen, pero no vienen armadas |
| Velocidad inicial | Alta en procesos estándar, con agentes preconstruidos | Menor al inicio; mayor en los procesos propios de la empresa |
| Salida | Contexto, agentes y gobierno quedan dentro de la plataforma | MCP, A2A e Iceberg permiten cambiar una pieza sin rehacer las demás |
El costo merece una nota aparte. En el modelo empaquetado, el precio del modelo de lenguaje llega envuelto en la unidad de consumo de la plataforma, y sin precio de lista público la comparación depende de cada negociación. En la arquitectura abierta, la empresa paga el token al proveedor que elige, al precio que la competencia entre modelos va bajando, y puede usar los compromisos de consumo que ya tiene con Azure, AWS o Google Cloud.
A eso se suma algo que cambió la ecuación por completo: el costo de construir software se desplomó. En Novis lo vivimos en carne propia. Construimos Praxia, nuestra plataforma de gestión de servicios, en cerca de seis meses con apoyo de IA. Hoy opera para nuestros 84 clientes y nos permite dejar atrás licencias por cerca de US$200.000 al año.
Lo normal, en todo caso, será una arquitectura híbrida: agentes SAP donde SAP tiene ventaja de contexto, como el cierre financiero sobre S/4HANA, y piezas abiertas donde el proceso cruza sistemas o donde está la diferenciación del negocio.
El costo que no aparece en la cotización: el lock-in
La comparación anterior mira el precio de hoy. El riesgo mayor está en el precio de mañana, y tiene nombre: lock-in, la dependencia de un solo proveedor. Usamos a SAP como ejemplo porque es el ERP de la mayoría de nuestros clientes, pero el análisis vale igual para Microsoft, Salesforce, Oracle o cualquier plataforma que empaquete agentes junto con sus aplicaciones.
Los agentes de una plataforma crean una dependencia más profunda que la que creó el ERP, por cuatro razones:
El agente reemplaza trabajo, no solo software. Cuando un proceso se rediseña en torno a un agente y el equipo se reorganiza, ese agente deja de ser una herramienta y pasa a ser un insumo crítico de la operación. No se puede apagar en medio de una negociación.
El contexto queda adentro. Las ontologías que la empresa agrega al Knowledge Graph, las skills que define en Joule Studio y la memoria que Joule Work acumula de cada usuario son el conocimiento más valioso de la organización. Construido dentro de la plataforma, no se lleva a otra parte con facilidad.
El precio lo fija quien mide. En un modelo de consumo, el proveedor define el valor de la unidad y cuántas unidades consume cada escenario. Hoy, por ejemplo, SAP cobra 0,005 AI Units por cada registro de document grounding. Esas tasas pueden cambiar en cada renovación, y las AI Units que no se usan vencen a los 12 meses.
Todo se negocia en el mismo paquete. El acceso a los asistentes está atado a las suscripciones cloud de SAP y, para los clientes on-premise, al compromiso de migrar a SAP Cloud ERP. En la renovación se negocian juntos el ERP y los agentes de los que dependen los procesos, con mucho menos margen para decir que no.
Las condiciones de entrada son buenas: los clientes RISE reciben tres asistentes activados el primer año, y SAP destinó un fondo de 100 millones de euros para que sus partners ayuden a desplegar agentes. Es lógico; así se construye la adopción en cualquier plataforma. La pregunta que debe hacerse un directorio es cuánto costará el año cinco, cuando una parte relevante de los procesos ya dependa de esos agentes.
La industria tiene un antecedente reciente. Tras la compra de VMware por Broadcom, los proveedores cloud europeos agrupados en CISPE reportaron a la Comisión Europea alzas de precio de entre 800% y 1.500%. VMware era una tecnología madura y con alternativas en el mercado, y aun así el costo de migrar dejó a muchos clientes sin margen para negociar. Es lo que ocurre cuando un proveedor sabe que el cliente no puede irse.
Hay otra asimetría, menos visible. El precio de los modelos de lenguaje cae año a año por la competencia entre Anthropic, OpenAI, Google y otros. En una arquitectura abierta, esa baja llega directo a la empresa. En un modelo empaquetado, llega solo si el proveedor decide traspasarla.
Por eso, mantenerse abierto es una ventaja estratégica. Una empresa que puede cambiar de modelo en semanas, mover sus agentes con estándares como MCP y A2A y conservar su contexto de negocio en formatos propios negocia siempre desde una posición de fuerza. Una que no puede, negocia desde la necesidad. El mismo argumento que usa SAP para ofrecer muchos modelos, reducir la dependencia de un proveedor, vale para sus clientes frente a una sola plataforma de agentes.
El Arquitecto de Soluciones de Negocio: decir SAP cuando conviene
Un Arquitecto de Soluciones de Negocio es el profesional que, antes de elegir tecnología, analiza cada proceso y define la mejor forma de resolverlo, comparando opciones por costo, valor para el negocio y experiencia de usuario. Parte siempre por el proceso y su indicador, y recomienda SAP cuando es la mejor respuesta.
La arquitectura abierta tiene un requisito que no aparece en ningún catálogo: alguien tiene que decidir, proceso por proceso, qué se compra, qué se configura y qué se construye. Esa decisión vale más que cualquier herramienta, y por eso conviene que la tome alguien sin conflicto de interés.
SAP también lo entendió: en TechEd presentó un Process Consulting Agent, un agente que, según SAP, “identifica dónde y qué construir antes de que comience el desarrollo”. Es una buena idea.
La pregunta es si quien decide qué construir debe ser el mismo que vende la plataforma donde se construye.
En Novis creamos un rol para responder esa pregunta: el Arquitecto de Soluciones de Negocio. Es la cara visible de nuestra Consultoría de Procesos de Negocio, que empieza siempre por el proceso, no por el producto. Sus reglas son simples:
Se parte por el proceso, su problema y su indicador: días de cierre, horas de conciliación o tiempo de respuesta. Si el cliente tiene SAP y es la mejor solución, propone SAP.
Si la mejor solución no es SAP, presenta un set de opciones que incluye a SAP y suma alternativas: aplicaciones nativas en la nube, integración inteligente entre sistemas o una aplicación específica del mercado.
Compara las opciones con tres criterios: costo, valor para el negocio y experiencia de usuario.
Para separar lo estándar de lo propio, el arquitecto aplica lo que en Novis llamamos la prueba del competidor: ¿si mi competidor tuviera esta misma capacidad, perdería ventaja? Si la respuesta es no, el proceso es estándar y lo lógico es comprarlo hecho, muchas veces en SAP. Si la respuesta es sí, ese proceso es parte de la capa diferencial de la empresa, y ahí conviene construir: sobre arquitectura abierta, integrada con SAP por APIs estables y sin meter más desarrollos Z en el núcleo.
Novis es partner SAP hace más de 25 años y además tiene plataformas propias, como Praxia. Por eso publicamos el criterio. Las cuatro reglas, los tres criterios de comparación y la prueba del competidor están a la vista, y cualquier cliente puede auditar con ellos cada recomendación que le hagamos.
El Arquitecto de Soluciones de Negocio es un perfil escaso por una razón estructural. Las consultoras de software rara vez conocen SAP por dentro, y las consultoras SAP rara vez construyen soluciones cloud-native con disciplina de producto. Después de más de 25 años como partner SAP, y con lo que aprendimos construyendo nuestras propias plataformas, creemos que podemos hacer ambas cosas. Seguiremos recomendando SAP cada vez que sea la mejor respuesta; justamente por eso, cuando digamos que no lo es, la recomendación tendrá valor.
Cómo empezar: seis pasos
No hace falta tener todo resuelto para avanzar. Este es el orden que recomendamos:
- Mapear los procesos y separar lo estándar de lo diferenciador. Con la prueba del competidor, identificar dónde conviene comprar, dónde configurar y dónde construir. Es el punto de partida de nuestra Consultoría de Procesos de Negocio y el primer trabajo del Arquitecto de Soluciones de Negocio.
- Convertir el contexto de negocio en un activo propio. Documentar la configuración, los desarrollos Z, las reglas y el uso real del ERP, y exponerlos con estándares abiertos como MCP, para que cualquier modelo pueda consultarlos.
- Ordenar los datos sobre formatos abiertos. Un lakehouse sobre Apache Iceberg, con datos SAP y no SAP, evita que el contexto quede atrapado en una sola plataforma. Y mantener el núcleo limpio (clean core): lo propio va al lado del ERP, no adentro.
- Definir el gobierno antes del primer agente. Identidad y permisos por agente, nivel de autonomía por proceso (aprobación, monitoreo o intervención humana), trazas auditables y presupuesto de consumo por área. En los procesos críticos, el modelo recomienda y una persona o una regla determinista autoriza.
- Partir con dos o tres casos medibles. Elegir procesos con un indicador claro (días de cierre, tiempo de respuesta, horas de conciliación) y empezar en modo consultivo antes de dar autonomía.
- Elegir por capa, con puerta de salida. Preferir estándares abiertos, contratos directos con los proveedores de modelos y portabilidad de datos, agentes y prompts. Así, cambiar una pieza será una decisión técnica, sin un proyecto de migración de por medio.
Libertad dentro de límites
La empresa autónoma va a llegar, y en la mayoría de nuestros clientes SAP será una parte importante de ella. La decisión de fondo es diseñar una arquitectura donde cada pieza esté ahí porque es la mejor para ese proceso, aunque eso signifique elegir algo distinto de lo que venía en el paquete. Mantenerse abierto es la manera de que el precio de mañana lo siga fijando la competencia.
SAP propone “libertad dentro de límites” como principio para gobernar a sus agentes. Es una buena regla, y sirve también para la relación con los proveedores: libertad para elegir y para cambiar, dentro de una arquitectura bien gobernada. Esa es la empresa autónoma que queremos ayudar a construir.
El primer paso es el más concreto: elegir dos o tres procesos y aplicarles la prueba del competidor. Con ese trabajo parte nuestra Consultoría de Procesos de Negocio, de la mano de un Arquitecto de Soluciones de Negocio que recomienda SAP cuando conviene y propone alternativas cuando existe una mejor. Si quieres conocer cómo trabajamos, aquí explicamos qué es la consultoría de procesos de negocio.
Feedback/discusión con el autor: Patricio Artiagoitia, Director Ejecutivo Novis.
Fuentes
- SAP Unveils the Autonomous Enterprise, SAP News, 12 de mayo de 2026
- SAP to Acquire Dremio to Unify SAP and Non-SAP Data to Power Agentic AI, SAP News, 4 de mayo de 2026
- SAP Showcases the Autonomous Enterprise in Action, SAP News, 7 de octubre de 2026
- How Joule Work and SAP Business AI Platform Are Powering the Next Generation of Business AI, SAP News, 8 de octubre de 2026
- SAP TechEd in 2026: SAP Tells Developers "You Can Build the Autonomous Enterprise", SAP News, 28 de octubre de 2026
- Advancing SAP Lakehouse and New Data Fabric Innovations in SAP Business Data Cloud, SAP News, 29 de octubre de 2026
- SAP AI plans and pricing, SAP
- Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Gartner, 26 de agosto de 2025
- Comunicados de la Linux Foundation sobre la Agentic AI Foundation y el protocolo A2A
- VMware price hikes? Between 800 and 1,500%, claim Euro customers, The Register, 22 de mayo de 2025