SAP AI Core: modelos propios de SAP, precios y los errores que hay que evitar (Parte 3 de 3)

SAP AI Core: modelos propios de SAP, precios y los errores que hay que evitar (Parte 3 de 3)

Tercera y última entrega de la serie. En las dos anteriores vimos qué es SAP AI Core y cómo funciona el Generative AI Hub junto con el Orchestration Service. Si has llegado aquí en frío, también se puede leer suelta, pero el contexto ayuda.

Aquí toca lo más jugoso: los modelos que SAP ha entrenado para su propio terreno, cómo se hace RAG con HANA Cloud, cuánto cuesta esto realmente y los cinco errores que vemos repetirse en proyectos cuando los equipos adoptan AI Core sin la disciplina adecuada.

Los modelos que SAP construyó para su propia casa

Un argumento que sale enseguida en cuanto presentas AI Core en una arquitectura SAP es: “vale, pero GPT no conoce mi sistema”. Y, sinceramente, tiene buena parte de razón.

Los modelos generales son brillantes para escribir, resumir o razonar sobre problemas abiertos. El día que les pides que generen ABAP o que toquen CDS sobre un sistema real, empiezan a inventar. Módulos de función que no existen. APIs que llevan obsoletas dos releases. Mezclas alegres de ABAP clásico con ABAP Cloud sin avisar. Quien haya intentado dejar a Claude o GPT trabajar solo sobre un sistema SAP medianamente complejo sabe de lo que hablo.

SAP lleva tiempo respondiendo a este problema con modelos propios, todos disponibles dentro del Generative AI Hub.

https://www.sap.com/products/artificial-intelligence/sap-rpt.html

SAP-RPT-1 (Relational Pretrained Transformer)

Es un modelo distinto a todo lo que estamos acostumbrados, porque no genera texto: hace predicciones sobre datos tabulares de negocio. Maestros de clientes, pedidos de compra, posiciones financieras, métricas de RRHH. Lo que vive en las tablas de un ERP.

Lo más curioso es cómo funciona: usa “in-context learning”. No hace falta entrenarlo con tus datos; le pasas los datos en el contexto y predice. Caso de uso típico: probabilidad de retraso en una entrega, riesgo de impago de un cliente, predicción de cierre de un sales order.

Está disponible en dos variantes: sap-rpt-1-small para predicciones muy rápidas y sap-rpt-1-large para máxima precisión. Fue declarado GA en Q4 2025 y se presentó en SAP TechEd Berlín de noviembre de 2025. Existe además una versión open source (SAP-RPT-1-OSS) publicada en Hugging Face y GitHub, lo cual es una señal interesante: SAP no quiere encerrar el modelo, quiere que se use.

SAP-ABAP-1

Modelo entrenado sobre código ABAP, orientado en su primera entrega a explicar y entender código ABAP Cloud. Su release inicial cubre lo que SAP llama “code explain”: acompañar al desarrollador en mantener código ABAP y CDS heredado. No es un generador completo de código todavía, pero la dirección está marcada.

Se anunció en SAP TechEd 2025 y quedó disponible en el Generative AI Hub a comienzos de 2026 (Q1 2026). La página oficial del producto está en sap.com/products/artificial-intelligence/sap-abap.html.


https://www.sap.com/products/artificial-intelligence/sap-abap.html

La jugada que funciona: combinar, no elegir

La pregunta que sale siempre en clase: ¿modelos de SAP o modelos generales?

La respuesta correcta es: los dos. Y cada uno para lo suyo.

Los modelos generales —GPT, Claude, Gemini— para conversación, razonamiento abierto, generación de texto, traducción y todo lo que no requiera conocimiento profundo del modelo de datos SAP. Los modelos propios de SAP cuando el contexto SAP es determinante: predicciones sobre datos tabulares con RPT-1, explicación o asistencia sobre código ABAP con ABAP-1. Y, por encima de los dos, grounding sobre documentación corporativa real con HANA Vector Engine.

Esa combinación —que es la que SAP ofrece integrada— es difícil de replicar fuera de la plataforma sin asumir un coste sustancial de integración y mantenimiento. En 2026, montar una infraestructura propia para esto teniendo SAP ya en casa es duplicar lo que está resuelto.

Grounding con SAP HANA Cloud Vector Engine

El Document Grounding Service de SAP AI Core implementa RAG usando el Vector Engine de SAP HANA Cloud como almacén de vectores. Para empresas que ya tienen HANA Cloud en la arquitectura, esto es importante: tus datos ya están donde van a vivir los vectores. No hay que duplicarlos en un Pinecone o un Weaviate aparte, ni preocuparse de cómo se sincronizan.

https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/grounding-854f2b3c967f43779e3ad795ec5b4132

El flujo, en limpio, es el siguiente:

  1. Se ingiere documentación vía Pipeline API o Vector API desde Amazon S3, Microsoft SharePoint o SFTP.
  2. Se generan embeddings con modelos como text-embedding-3 de Azure OpenAI o el modelo interno de HANA.
  3. Los vectores se guardan en SAP HANA Cloud Vector Engine.
  4. En cada inferencia, el Orchestration Service recupera los fragmentos más relevantes por similitud coseno y los inyecta al prompt antes de llamar al LLM.

Una variante interesante: SAP ofrece grounding directo sobre el SAP Help Portal, sin necesidad de ingerir nada. Cuando el caso de uso es responder preguntas sobre documentación SAP oficial (que es más frecuente de lo que parece), esto ahorra un pipeline entero.

Un par de avisos prácticos. El primero: la calidad del RAG depende muchísimo de cómo se trocea el documento (chunking) y de qué metadatos se conservan. La pipeline de SAP hace lo razonable por defecto, pero para corpus específicos —contratos, normativa interna, hojas técnicas— suele compensar revisar los parámetros antes de dar el RAG por bueno. El segundo: en Q1 2026 SAP amplió el límite del pipeline a 8.000 documentos. Por encima de ese volumen toca segmentar.

¿Cuánto cuesta SAP AI Core?

Datos oficiales del capítulo Metering and Pricing de la guía oficial de SAP AI Core.

Los tres planes:

Repito porque es la trampa más frecuente: el Generative AI Hub, los modelos del catálogo y el Orchestration Service solo están en Extended. No hay manera de tocarlos desde Free ni desde Standard.

Cambiar de Standard a Extended se hace en BTP Cockpit (Instances and Subscriptions → Update). Según la documentación, “all metadata and transaction data, including trained models, is retained” durante el cambio. Es decir, el upgrade no pierde lo que ya tienes montado.

Otros dos puntos de los que conviene enterarse antes:

  • AI Core no está disponible en cuentas BTP Trial (literal en la documentación: “not available in SAP BTP trial”). Esto sorprende a más gente de la que debería.
  • Sí está disponible en BTP Free Tier (que es una cuenta enterprise en modo gratuito).
  • En Q1 2026, SAP anunció un trial gratuito de 30 días específico del Generative AI Hub. Sirve para hacer pruebas serias sin tener que pelearse antes con compras.

Cómo se factura

Toda BTP factura en Capacity Units (CUs), y AI Core sigue ese modelo.

Para Predictive AI (modelos propios o custom): compute (node hours) + storage (gigabyte hours) + baseline (tenant hours, máximo 730 al mes).

Para Generative AI (foundation models): por tokens de input y output, convertidos a CUs según la tasa específica de cada modelo. Cuando usas foundation models y grounding, SAP exime los costes de compute, storage y baseline. Pagas solo tokens.

Los módulos de orquestación tienen sus propias métricas: GB/día en el Vector Engine, text blocks recuperados o procesados por content filtering, y llamadas API contra SAP Data Privacy Integration para masking. Detallitos a tener controlados desde el primer POC, porque suman.

Una recomendación práctica: usa el SAP AI Core Cost Calculator que aparece en la documentación oficial para estimar antes, y revisa el consumo real en BTP Cockpit → Usage filtrando por AI Core. En proyectos reales, la diferencia entre la estimación y el consumo suele estar en los tokens de output, que cuestan más que los de input. Estándar de la industria, pero conviene tenerlo presente.

 

Los 5 errores que más se repiten en proyectos reales

Cerramos con lo que aporta valor de verdad. Si estás evaluando AI Core para tu empresa, estos son los errores que vemos repetir con más frecuencia.

  1. Empezar por la tecnología y no por el caso de uso.
    “Necesitamos GenAI.” Vale, ¿para qué exactamente? Si la respuesta es “para innovar” o “para no quedarnos atrás”, el proyecto va a naufragar antes de tres meses. AI Core acelera casos de uso definidos y medibles; no los inventa. Cuando entras a un proyecto y no hay un dueño funcional con un KPI claro, conviene decirlo el primer día.
  2. Reconstruir lo que el Orchestration Service ya da resuelto.
    Equipos que se montan su propio router de modelos, su propio vector store, su propio masking de PII. Todo eso está hecho, certificado y mantenido por SAP. Reinventarlo no es solo coste extra; es comprometer el cumplimiento, porque cualquier auditoría te va a pedir cómo certificas tu masking custom. Mejor explicar al cliente por qué no hace falta construirlo que justificar después por qué se construyó.
  3. Usar modelos generales sobre ABAP, CDS o RAP sin grounding.
    Esto es el error técnico más caro. Pegar Claude o GPT directamente contra el modelo de datos de un sistema productivo, sin contexto, esperando que “el modelo entienda”. El modelo no entiende: adivina. En SAP, adivinar significa proponer cambios que rompen procesos. Hay que dar contexto: grounding sobre documentación interna, RPT-1 o ABAP-1 para tareas específicas, y revisión humana donde toque.
  4. Trabajar los prompts directamente en código.
    Equipos que tratan los prompts como strings dentro del repo, sin templating, sin control de versiones, sin trazabilidad. El Prompt Editor del AI Launchpad existe precisamente para que el ciclo de iteración no requiera un deployment cada vez que se cambia una coma. Y para que el responsable funcional pueda iterar sin pedirle un sprint al equipo técnico.
  5. Empezar en Standard cuando el destino es Extended.
    Clásico. Se monta un POC en Standard porque “es más barato”, llega el momento de meter LLMs y descubres que tienes que cambiar de plan, replantear arquitectura, volver a pasar por compras y justificar de nuevo el presupuesto. Si la hoja de ruta a doce meses contempla modelos generativos, empieza directamente en Extended y ahorra el viaje.

Conclusión de la serie

SAP AI Core es la columna vertebral de lo que SAP llama Business AI. No es visible para el usuario final, pero está detrás de cada respuesta de Joule, de cada agente y de cada integración de IA con datos de negocio reales.

En estas tres entregas hemos cubierto desde lo conceptual hasta los precios, pasando por el catálogo de modelos, el Orchestration Service, el grounding con HANA y los modelos propios de SAP. Si algo te ha generado más preguntas que respuestas, es buena señal: significa que estás en el punto justo para seguir profundizando.

Fuentes oficiales (verificadas mayo 2026)

  • SAP Help Portal — Service Guide SAP AI Core (capítulos Metering and Pricing, Generative AI Hub, Orchestration, Service Plans)
  • SAP Note 3437766 — Availability of Generative AI Models
  • SAP — sap.com/products/artificial-intelligence/sap-rpt.html
  • SAP — sap.com/products/artificial-intelligence/sap-abap.html
  • SAP Help Portal — SAP-RPT-1 y SAP-ABAP-1 (help.sap.com/docs/sap-ai-core/generative-ai)
  • SAP Help Portal — Document Grounding Service y HANA Cloud Vector Engine
  • SAP News — Business AI Innovation at SAP TechEd (noviembre 2025)
  • SAP News — Q1 2026 Release Highlights (abril 2026)
  • SAP Trust Center — Responsible AI FAQ (enero 2026)
  • SAP Architecture Center — Reference Architecture Generative AI on SAP BTP

Artículo elaborado por el equipo de formación de Logali Group con base en datos oficiales SAP de mayo de 2026.

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *