IA de SAP: las tres capas que el comité de TI confunde
SAP Business AI no es un producto único: son tres capas con licenciamiento distinto. Qué activó realmente su utility al firmar el contrato.
· 11 min de lectura
En el comité de compra de una distribuidora eléctrica o de una operadora de oil & gas en América Latina, la conversación sobre inteligencia artificial suele resolverse con una sola palabra: Joule. El proveedor la menciona, TI la anota en el acta, finanzas la presupuesta. Meses después, cuando alguien pregunta por qué la funcionalidad prometida no aparece en el ambiente productivo —o por qué hay un consumo que nadie proyectó—, se descubre lo que nunca se dijo en esa reunión: «IA de SAP» jamás fue una sola cosa.
Esta es la primera pieza de una serie de seis. Su único objetivo es nombrar el problema de raíz, porque un comité que no distingue las piezas no puede evaluar la oferta que tiene enfrente.
SAP Business AI no es un producto: es una arquitectura en capas
La SAP Business AI Platform, presentada por SAP en Sapphire 2026, se estructura en tres capas —contexto, construcción y gobierno—, con un frontend compartido que es Joule —hoy activo en 35 soluciones SAP (SAP News Center, 2026)— y con funciones de IA embebidas a lo largo del portafolio (FinOptory, 2026). Esa frase es toda la tesis de este artículo: el mercado latinoamericano compra «Joule» y recibe, en realidad, una porción variable de una arquitectura de tres pisos.
Capa de contexto: lo que hace que la IA sepa de su negocio
Es la base invisible. Aquí viven el Generative AI Hub —el punto de acceso a modelos de fundación dentro del ecosistema SAP—, los modelos propios de SAP y el grafo de conocimiento que aporta el contexto de proceso (FinOptory, 2026). Sin esta capa, cualquier copiloto responde como un chatbot general: fluido, plausible y ajeno a su tarifa, su ciclo de facturación y su parque de medidores.
Esta capa también evoluciona por su cuenta. En sus notas de novedades del primer trimestre de 2026, SAP reportó la incorporación de nuevos modelos al generative AI hub de AI Foundation y capacidades adicionales para desarrolladores ABAP, con reducciones estimadas de 20 % en el esfuerzo de escribir código y de 25 % en el de probarlo (SAP News Center, 2026).
Capa de construcción: donde su equipo arma algo propio
Es el entorno de desarrollo para agentes construidos por el cliente, sobre habilidades preexistentes de SAP y sobre datos propios (FinOptory, 2026). Un comité que aprueba «IA» pensando en un asistente de preguntas y respuestas, y termina financiando un programa de construcción de agentes, no cometió un error técnico: aprobó dos cosas distintas creyendo que era una.
Capa de gobierno: quién vigila a los agentes
Es la capa de inventario, verificación, observabilidad y política sobre los agentes que operan en el tenant (FinOptory, 2026). Para una utility regulada, esta capa no es un lujo de madurez: es la que permite responder qué agente accedió a qué dato de qué cliente, y bajo qué autorización.
Lo que está incluido y lo que se mide aparte
Aquí es donde la confusión se vuelve financiera. SAP distingue entre Base AI —las capacidades fundacionales incluidas en todas las aplicaciones cloud, sin costo adicional y sin límite— y Premium AI, que agrupa escenarios embebidos avanzados, habilidades premium de Joule y agentes, con precio por usuario/mes o por consumo según la función (SAP, 2026).
El vehículo de medición del consumo son las AI Units: una moneda virtual que el cliente adquiere, se usa de forma flexible entre soluciones desde un pool central y cuyo saldo se consulta en SAP for Me. Cuando el modelo por usuario no aplica, la medición se hace por métricas de uso predefinidas; SAP documenta, por ejemplo, un consumo de 0,005 AI Units por registro en Document Grounding (SAP, 2026).
Traducido al lenguaje del comité: hay funciones que ya están pagadas, funciones que se pagan por cabeza y funciones que se pagan por uso. Tres lógicas comerciales conviviendo bajo la misma palabra.
Por qué esto pesa más en una utility latinoamericana
Una operación de servicios públicos en la región llega a esta decisión con tres condiciones simultáneas: presupuesto acotado en dólares, presión regulatoria sobre continuidad y calidad de servicio, y procesos meter-to-cash donde el margen se pierde en lecturas duplicadas, eventos de medición sin normalizar y colas de integración congestionadas.
En ese contexto, cada capa responde a una necesidad distinta y ninguna sustituye a las otras:
---
config:
theme: base
fontFamily: 'Inter Variable, system-ui, sans-serif'
themeVariables:
darkMode: true
fontFamily: 'Inter Variable, system-ui, sans-serif'
fontSize: '15px'
background: '#111113'
primaryColor: '#1A1A1D'
primaryTextColor: '#F4F5F8'
primaryBorderColor: '#00C2FF'
secondaryColor: '#242428'
tertiaryColor: '#1A1A1D'
mainBkg: '#1A1A1D'
secondBkg: '#242428'
tertiaryBkg: '#2E2E33'
lineColor: '#00C2FF'
textColor: '#F4F5F8'
titleColor: '#F4F5F8'
nodeBorder: '#00C2FF'
clusterBkg: '#1A1A1D'
clusterBorder: '#2E2E33'
edgeLabelBackground: '#242428'
pie1: '#00C2FF'
pie2: '#f59e0b'
pie3: '#22c55e'
pie4: '#59d7ff'
pie5: '#f97316'
pie6: '#ef4444'
pieTitleTextColor: '#F4F5F8'
pieSectionTextColor: '#F4F5F8'
pieLegendTextColor: '#F4F5F8'
pieStrokeColor: '#111113'
pieOuterStrokeColor: '#111113'
---
flowchart TD
A([¿Qué problema motiva la compra?]) --> B{Necesidad a resolver}
B -->|Búsqueda| C[El analista de facturación tarda en encontrar el dato]
C --> D([Frontend y funciones embebidas])
B -->|Automatización| E[Triage de eventos de medición entre AMI y core]
E --> F([Capa de construcción])
B -->|Trazabilidad| G[Demostrar ante el ente regulador quién decidió qué]
G --> H([Capa de gobierno])
class A inicio
class B decision
class C,E,G proceso
class D,F,H bueno
classDef inicio fill:#113d4f,stroke:#00C2FF,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
- Si el problema es que el analista de facturación tarda en encontrar el dato, la conversación es sobre el frontend y las funciones embebidas.
- Si el problema es automatizar el triage de eventos de medición entre el AMI y el core, la conversación es sobre la capa de construcción.
- Si el problema es demostrar ante el ente regulador quién decidió qué, la conversación es sobre gobierno.
Comprar la capa equivocada no produce un fracaso ruidoso. Produce algo peor para un presupuesto ajustado: una inversión que funciona técnicamente y no mueve el indicador que motivó la compra.
Tres preguntas antes de firmar
Si el proveedor responde las tres con la misma palabra, la conversación todavía no empezó.
Lo que sigue
En AGT ayudamos a comités de TI de utilities y oil & gas de la región a traducir esta arquitectura en una decisión de compra defendible: qué capa se activa primero, con qué caso de uso y con qué mecanismo de control de consumo. Acompañamos ese proceso con el mismo criterio con que se evalúa cualquier inversión en el core: por el indicador que debe mover, no por la etiqueta que trae.
La segunda pieza de esta serie desarma la confusión más costosa de todas: por qué Joule es el copiloto con anclaje en su dato de negocio y no un chatbot genérico.
Fuentes
- FinOptory — What SAP Business AI Really Is in 2026: Three Layers, Joule Studio 2.0, and the End of Premium Plus (2026): https://finoptory.ai/en/resources/blog/sap-business-ai-2026-overview/
- SAP — Software Packages and Pricing | SAP Business AI: https://www.sap.com/products/artificial-intelligence/pricing.html
- SAP News Center — SAP Business AI: Release Highlights Q1 2026 (2026): https://news.sap.com/2026/04/sap-business-ai-release-highlights-q1-2026/
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
