SAP: IA on-premise para quien no puede migrar a la nube

SAP vende IA en la nube, pero no todos sus clientes pueden comprarla

Dos de cada tres contratos nuevos de SAP ya incluyen componentes de inteligencia artificial. Lo confirmó el consejero delegado del grupo de Walldorf, Christian Klein, y la cifra resume la estrategia de la compañía: IA dentro de S/4HANA y de la nube de SAP. El problema aparece en el otro extremo del mercado.

Existe una base enorme de clientes que sigue ejecutando SAP ECC en sus propios servidores, con personalizaciones construidas durante décadas. Para ellos, migrar a S/4HANA y a la nube no es una decisión de TI: es un proyecto de varios años, con coste incierto y con buena parte del trabajo hecho a medida que se perdería en el camino.

Para un founder que arrastra un ERP heredado, la pregunta ya no es si la IA sirve. Es si puede aprovecharla sin entregar sus datos y sin rehacer el sistema completo.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Por qué la nube no es una opción para todos

El primer freno es la soberanía de los datos. Cada vez más empresas miran con desconfianza la externalización de sistemas críticos a las nubes de los hiperescaladores, por miedo a perder control y a quedar atrapadas en dependencias difíciles de deshacer: subidas repentinas de coste, cambios funcionales que no se pidieron o restricciones de acceso a servicios.

El segundo freno son los requisitos normativos. En sectores como el financiero y el sanitario, las reglas de gestión de datos hacen que el acceso a la nube siga estando, en la práctica, vedado. Esas empresas quedan fuera de los componentes de IA que SAP ofrece, como SAP Joule, y no pueden explotar el tesoro de datos que ya viven en sus sistemas SAP.

El tercer freno es la fecha límite. Según BI-Spain, el mantenimiento principal de SAP para ECC finaliza en 2027, y a partir de ahí las organizaciones que no hayan migrado tendrán que elegir entre un soporte extendido costoso o un sistema sin soporte. Esa presión convive mal con la realidad: no todas las migraciones son viables en ese plazo.

El modelo side-by-side: IA al lado del ERP, no dentro

La alternativa que describe la propia SAP es el enfoque side-by-side. Los sistemas de IA se mantienen separados del núcleo de SAP y se ejecutan en una arquitectura independiente, pero conectada de forma estrecha.

El entorno SAP existente no se transforma ni se migra. Sigue siendo el sistema central de datos empresariales, y los sistemas de IA acceden a él mediante interfaces estandarizadas como OData o REST. Los resultados vuelven por API, normalmente en formato JSON, y se visualizan dentro de las aplicaciones de SAP o en herramientas propias construidas con el sistema de diseño Fiori, para que la experiencia de usuario sea la misma de siempre.

¿Qué gana una empresa al sacar la IA del núcleo SAP?

El núcleo queda intacto. No aparecen problemas de compatibilidad con las actualizaciones y mejoras posteriores, y el equipo de TI no tiene que tocar lo que ya funciona.
Desarrollo independiente. Los sistemas de IA se pueden implementar y mantener por separado, lo que acelera la puesta en marcha y el mantenimiento continuo.
Libertad de modelo. La empresa no queda atada a un proveedor: puede elegir entre grandes modelos de lenguaje (LLM) y modelos de lenguaje pequeños (SLM).
Coste de hardware menor. Los SLM no tienen el conocimiento general de un LLM de miles de millones de parámetros, pero sí conocimiento especializado y detallado en áreas concretas, y sus requisitos de recursos son considerablemente menores.
Trazabilidad. Los modelos de código abierto ofrecen ventajas de explicabilidad frente a los modelos propietarios que funcionan como caja negra, algo crítico en sectores regulados y en casos donde se espera un resultado determinista: seguridad funcional, diagnósticos médicos, decisiones crediticias o evaluación de candidatos.

Entre las familias de modelos que la fuente menciona como probadas para analizar datos empresariales de sistemas SAP están SAP-RPT-1, IBM Granite, LLaMA y Mistral.

Fine-tuning o RAG: cómo se conecta la IA a los datos de SAP

Hay dos caminos para que un modelo entienda el negocio, y no son excluyentes.

El ajuste fino (fine-tuning) incorpora el conocimiento directamente al modelo y mejora su comprensión contextual y su capacidad generativa con la terminología del sector. Es más laborioso: exige clústeres de GPU potentes, a menudo en la nube, y obliga a anonimizar datos o generar datos sintéticos para el entrenamiento. Cada vez que se quiere añadir conocimiento nuevo, hay que volver a entrenar.

RAG (Retrieval Augmented Generation) funciona distinto: el modelo consulta una base de datos vectorial con la información de la empresa. La base de conocimiento se actualiza más fácil y los resultados pueden acompañarse de referencias para que los empleados los verifiquen. Para casos de uso centrados en análisis de datos, suele ser suficiente.

Para bajar la barrera del ajuste fino existe InstructLab, un proyecto de código abierto creado por IBM y Red Hat que permite adaptar modelos con menos datos, genera datos sintéticos de calidad y ahorra recursos de cómputo. Es una vía pensada justamente para empresas sin científicos de datos dedicados.

El costo que casi nadie mira: la inferencia

Ejecutar la IA en la propia infraestructura tiene una ventaja silenciosa: la IA corre cerca de los datos. No hay que trasladar volúmenes masivos a la nube, así que desaparecen los costes de red asociados.

Pero la inferencia —la toma de decisiones y la generación de respuestas— necesita infraestructura local. Sus requisitos son menores que los del entrenamiento, aunque a medida que crecen los usuarios o se suman proyectos de IA, el consumo se dispara. Un servidor de inferencia eficiente, que aproveche bien las GPU y su memoria, es lo que evita que el coste de hardware se descontrole y que los usuarios esperen demasiado por una respuesta.

El reto de fondo del modelo side-by-side no es técnico, es de gobierno: alojar, adaptar, desplegar y supervisar modelos de forma coherente para distintos casos de uso, sin crear silos de IA dentro de la empresa. Centralizar el control también simplifica el cumplimiento de seguridad y protección de datos, porque permite revisar todas las entradas y salidas e impedir que el modelo sea manipulado o devuelva resultados erróneos.

¿Qué significa esto para tu startup?

Si tu empresa depende de un ERP heredado, la buena noticia es que no tienes que elegir entre migrar todo o quedarte sin IA. El enfoque side-by-side abre una tercera vía, y estas son las decisiones que conviene tomar antes de escribir una línea de código:

Empieza por un caso de uso acotado y medible. La propia fuente menciona ejemplos concretos: cotejar datos financieros con facturas para detectar anomalías y prevenir fraude, optimizar niveles de existencias según el clima y los acontecimientos del momento, preseleccionar candidaturas usando las descripciones de puesto de SAP, o analizar imágenes de cámaras en planta para detectar defectos de fabricación. Elige uno, define la métrica de éxito y no abras cinco frentes a la vez.
Define tu estrategia de salida antes de firmar. Según un estudio de Red Hat citado en la fuente, solo el 57% de las empresas alemanas tiene una estrategia de salida definida para su proveedor principal de IA, y de esas, el 37% calcula que cambiar de proveedor tendría un impacto de moderado a considerable en su continuidad de negocio. La libertad de modelo que da el side-by-side solo sirve si la ejerces: prueba al menos dos modelos y documenta cuánto cuesta cambiarlos.
Evalúa un SLM antes de ir directo a un LLM. Si tu caso de uso es específico —clasificar, extraer, conciliar—, un modelo pequeño puede darte mejores resultados con menos hardware y menores costes de adquisición y operación.
Distingue fine-tuning de RAG desde el principio. Si tus datos cambian todas las semanas, RAG te ahorra reentrenamientos. Si necesitas que el modelo domine terminología propia del sector, el ajuste fino sigue siendo el camino.
No subestimes el conocimiento interno. La fuente es explícita: adaptar y gestionar la IA por cuenta propia exige experiencia. Un socio que ya haya hecho esto evita proyectos eternos que nunca llegan a producción.

El contexto de mercado refuerza la urgencia. Un caso documentado por McKinsey y recogido por BI-Spain muestra a una empresa global de bienes de consumo que integró más de 100 fuentes de datos separadas en una sola plataforma con S/4HANA: el proyecto redujo el inventario un 27%, disminuyó el trabajo manual un 60%, mejoró la precisión de las previsiones entre un 6% y un 10% y aceleró los tiempos de reacción aproximadamente cuatro veces. Son resultados de transformación, no de una simple actualización de software.

Conclusión

SAP tiene un incentivo claro para llevar a sus clientes a la nube, y la IA es el argumento de venta. Pero la realidad de miles de empresas con ECC es otra: entornos complejos, regulación estricta y una desconfianza creciente hacia depender de un hiperescalador. El modelo side-by-side no resuelve la migración, la esquiva con inteligencia: deja el núcleo donde está y pone la IA al lado, con interfaces estándar y libertad para cambiar de modelo cuando el mercado se mueva.

Para un founder, la lección es de arquitectura y de negociación. Antes de firmar con cualquier proveedor de IA, pregunta cuánto cuesta salir. Si la respuesta no es clara, el problema no es la tecnología.