Algoritmos ERP frente a modelos de lenguaje grande (LLM) y agentes de IA

Determinista frente a probabilístico

Para los clientes actuales de SAP surge un nuevo escenario de amenaza: un sistema ERP funciona tradicionalmente como una máquina determinista de precisión, mientras que los modelos de IA generativa se basan en lógicas estocásticas probabilísticas que tienden inevitablemente a producir alucinaciones estructurales. Además de esta disrupción en cuanto al contenido, existe el reto de la seguridad de los sistemas en la nube.

Los atacantes y los modelos de IA automatizados han aprendido a penetrar rápidamente en el código de los sistemas y a dirigirse a las interfaces automatizadas, lo que permite que los ataques se produzcan a una velocidad exponencial. La cuestión de la seguridad en la nube y del control de los agentes autónomos (IA agencial) pasa así de ser una tarea puramente técnica de TI a convertirse en una cuestión existencial de gestión de riesgos y continuidad operativa.

Gestión de riesgos: agentes de IA

El riesgo concreto de que los agentes de IA de SAP Autonomous Enterprise provoquen acciones erróneas, realicen contabilizaciones incorrectas o corrompan los datos maestros se debe a varias causas sistémicas: Cuando los modelos lingüísticos estocásticos se encuentran con datos maestros históricamente contaminados o con código personalizado obsoleto, los sistemas tienden a aplicar deducciones erróneas con gran convicción.

Como han demostrado de forma contundente los incidentes ocurridos en empresas de TI como Amazon y Microsoft, los agentes autónomos con amplios derechos de ejecución pueden provocar configuraciones involuntarias del sistema o paralizar procesos críticos.

Kurt Gödel y Alan Turing

Los límites de la teoría de la información, según Kurt Gödel y Alan Turing, demuestran matemáticamente que, en principio, es imposible crear una „máquina de la verdad“ matemáticamente infalible en el ámbito de los modelos estocásticos. Además, la propia dirección de SAP advirtió del riesgo de una «arquitectura Frankenstein» incontrolable si agentes de IA de distintos fabricantes, sin una coordinación previa y sin unas reglas generales, entran en conflicto entre sí en un mismo sistema ERP.

Gobernanza como código y sistemas de control de IA

Para evitar de forma eficaz que el núcleo del ERP se vea afectado por agentes no controlados, las empresas usuarias deben establecer una «gobernanza como código» y medidas de seguridad en varias capas (harnesses de IA).

A nivel técnico, el control se centra en la identidad y los derechos de acceso: un agente de IA nunca debe actuar como un sustituto privilegiado con permisos ilimitados, sino que debe gestionarse como una identidad digital no humana (Non-Human Identity) bajo el principio de la propagación del principal. Esto significa que el agente se ejecuta exactamente en el contexto de seguridad y autorizaciones del usuario autenticado y no puede realizar acciones ni consultar datos a los que el usuario humano no tiene acceso.

Además, mediante la integración del entorno de ejecución de código abierto Nvidia OpenShell en Joule Studio Runtime, SAP garantiza una capa de ejecución aislada (Sandbox Boundary) que determina qué herramientas puede utilizar un agente y hacia dónde fluyen los datos de inferencia. Para las transacciones críticas para el negocio —como las autorizaciones de pago o las modificaciones de datos maestros—, sigue siendo indispensable el principio «Human in the Loop» o «Human above the Loop», según el cual el agente elabora propuestas, pero la ejecución final debe ser confirmada mediante una señal humana.

Además, el uso del Model Context Protocol (MCP) constituye un complemento esencial, ya que actúa como estándar de interfaz independiente del fabricante y garantiza el acceso de los agentes de IA a las herramientas de forma determinista y auditable a través de servidores MCP desacoplados.

Las cerezas del jardín del vecino

En cuanto a la preocupación acuciante de si los agentes de IA de SAP pueden salirse de su entorno de cliente o de sistema previsto e infiltrarse en sistemas S/4 ajenos u otras «Autonomous Enterprises», el análisis actual ofrece un panorama matizado: La salida física del entorno de ejecución más allá de los límites del sistema se ve dificultada a nivel de plataforma mediante la separación de clientes en varias etapas (Tenant Isolation), la gestión cifrada de secretos (Secret Management) en el AI Launchpad y los entornos aislados de tipo «sandbox» en contenedores.

No obstante, existen riesgos reales de ataque y propagación (movimiento lateral) que se deben principalmente a vulnerabilidades de diseño, como la inyección de comandos, el envenenamiento de memoria o destinos BTP mal configurados. Si un agente autónomo está conectado a través de interfaces transversales con sistemas CRM externos o de socios y se encuentra allí con datos manipulados, puede verse inducido a realizar llamadas a la API no autorizadas a otros mandantes de S/4.

Pasarela de API de IA y análisis de comportamiento

Para evitar este tipo de intrusiones entre clientes, se requiere una pasarela centralizada de API de IA que agrupe todo el tráfico de los agentes en una única interfaz supervisada, aplique políticas de acceso de alta granularidad a nivel de parámetros y bloquee inmediatamente los patrones de comportamiento inusuales mediante análisis de comportamiento automatizados (análisis de comportamiento) que bloquean de inmediato los patrones de comportamiento inusuales.

Sin embargo, desde el punto de vista comercial, SAP también utiliza estas preocupaciones en materia de seguridad como palanca: Con la versión cuatro de la Política de API de SAP (apartado 2.2.2), promulgada en abril de 2026, el grupo regula estrictamente la extracción directa de datos sin licencia por parte de agentes de terceros y obliga a los clientes a canalizar las cargas de trabajo de sus agentes a través de la Business Technology Platform (SAP BTP) y la Business Data Cloud (SAP BDC), servicios de pago. Si bien esto limita los flujos de datos no controlados, también dispara implacablemente los costes a través de las «Capacity Units», que se facturan en función del consumo.

Seguridad de SAP Cloud ERP

Al analizar la seguridad de SAP Cloud ERP, se observa que la transición a la nube —ya sea a través de «Rise with SAP» (nube privada) o «Grow with SAP» (nube pública)— impone un modelo operativo completamente nuevo basado en la responsabilidad compartida (Shared Responsibility Model). La promesa de que la nube es, por sí misma, una fortaleza inexpugnable se ha visto relativizada por incidentes como la grave vulnerabilidad de día cero en SAP NetWeaver Visual Composer (CVE-2025-31324), que demostró que incluso las infraestructuras cercanas a la nube deben reforzarse y supervisarse continuamente.

SAP ofrece una amplia gama de medidas de protección para garantizar la seguridad de sus clientes actuales en la nube. La base la constituyen centros de datos certificados según la norma ISO 27001, el cifrado de extremo a extremo de los datos en reposo y en tránsito (TLS/KMS), la autenticación basada en OAuth2 y la detección automatizada de amenazas a través de servicios como SAP Enterprise Threat Detection. A nivel de infraestructura, SAP colabora estrechamente con los principales hiperescaladores, como Microsoft Azure, Amazon Web Services y Google Cloud Platform, lo que permite integrar directamente herramientas de seguridad avanzadas como Microsoft Sentinel Threat Monitoring o AWS Secrets Manager.

No obstante, las empresas usuarias de la nube no deben dejarse llevar por una falsa sensación de seguridad. Para hacer frente a los riesgos que entraña la dependencia de los hiperescaladores estadounidenses y a las impredecibles normas de control de exportaciones —como el bloqueo temporal por parte de EE. UU. de los modelos de voz de Anthropic—, están cobrando una enorme importancia las alternativas que garantizan la soberanía de los datos, como la AWS European Sovereign Cloud, la nube StackIT del Grupo Schwarz o la nube privada certificada por Rise de T-Systems están cobrando una importancia enorme. Además, ni siquiera la mejor seguridad en la nube ofrecida por el proveedor exime a la empresa usuaria de sus propias obligaciones legales. Bajo los estrictos requisitos de la Ley de IA de la UE, la responsabilidad jurídica y operativa última por todas las decisiones y acciones llevadas a cabo por agentes de IA autónomos en el núcleo productivo del ERP recae íntegramente y de forma intransferible en el propio usuario.