ERP-Algorithmen versus LLMs und KI-Agenten

Deterministisch versus Probabilistisch

Für den SAP-Bestandskunden entsteht ein neuartiges Bedrohungsszenario: Ein ERP-System fungiert traditionell als deterministische Exaktheitsmaschine, während generative KI-Modelle auf probabilistischen Stochastik-Logiken basieren, die unumstößlich zu strukturellen Halluzinationen neigen. Neben dieser inhaltlichen Disruption gibt es die Herausforderung der Sicherheit von Cloud-Systemen.

Angreifer und automatisierte KI-Modelle haben gelernt, den Code der Systeme rasch zu durchdringen und automatisierte Schnittstellen zu adressieren, was Angriffe mit exponentieller Geschwindigkeit ermöglicht. Die Frage der Cloud Security und der Beherrschbarkeit autonomer Agenten (Agentic AI) wandelt sich damit von einer rein technischen IT-Aufgabe zu einer existenziellen Frage des Risikomanagements und der betrieblichen Kontinuität.

Risikomanagement: KI-Agenten

Die konkrete Gefahr, dass KI-Agenten im SAP Autonomous Enterprise fehlerhafte Handlungen auslösen, falsche Buchungen tätigen oder Stammdaten korrumpieren, speist sich aus mehreren systemischen Ursachen: Wenn stochastische Sprachmodelle auf historisch verunreinigte Stammdaten oder veralteten Custom Code treffen, neigen die Systeme dazu, fehlerhafte Ableitungen mit hoher Überzeugung umzusetzen.

Wie Vorfälle bei IT-Konzernen wie Amazon und Microsoft eindrücklich belegten, können autonome Agenten mit weitreichenden Ausführungsrechten unbeabsichtigte Systemkonfigurationen auslösen oder kritische Prozesse lahmlegen.

Kurt Gödel und Alan Turing

Die informationstheoretischen Grenzen nach Kurt Gödel und Alan Turing belegen mathematisch, dass eine mathematisch fehlerfreie Wahrheitsmaschine bei stochastischen Modellen prinzipiell unmöglich ist. Zudem warnte die SAP-Führung selbst vor einer unbeherrschbaren „Frankenstein-Architektur“, wenn unkoordinierte KI-Agenten verschiedener Hersteller ohne übergreifende Spielregeln im selben ERP-System miteinander kollidieren.

Governance-as-Code und KI-Harnesses

Um das Korrumpieren des ERP-Kerns durch ungesteuerte Agenten wirksam zu unterbinden, müssen Anwenderunternehmen eine Governance-as-Code und mehrstufige Sicherheitsleitplanken (KI-Harnesses) etablieren.

Auf technischer Ebene setzt die Kontrolle bei der Identität und den Zugriffsrechten an: Ein KI-Agent darf niemals als privilegierter Platzhalter mit unbegrenzten Berechtigungen agieren, sondern muss als digitale Nicht-menschliche Identität (Non-Human Identity) unter dem Prinzip der Principal Propagation geführt werden. Das bedeutet, dass der Agent exakt im Sicherheits- und Berechtigungskontext des authentifizierten Benutzers läuft und keine Aktionen ausführen oder Daten einsehen kann, die dem menschlichen Anwender verwehrt sind.

Darüber hinaus sichert SAP über die Einbettung der quelloffenen Laufzeitumgebung Nvidia OpenShell in die Joule Studio Runtime eine isolierte Ausführungsschicht (Sandbox Boundary) ab, die festlegt, welche Werkzeuge ein Agent aufrufen darf und wohin Inferenzdaten fließen. Für geschäftskritische Transaktionen – wie Zahlungsfreigaben oder Stammdatenänderungen – bleibt das Prinzip Human in the Loop beziehungsweise Human above the Loop unverzichtbar, bei dem der Agent Vorschläge aufbereitet, die finale Ausführung jedoch durch ein menschliches Signal bestätigt werden muss.

Eine wesentliche Ergänzung bildet zudem der Einsatz des Model Context Protocol (MCP), das als herstellerneutraler Schnittstellenstandard fungiert und den Werkzeugzugriff von KI-Agenten über entkoppelte MCP-Server deterministisch und auditierbar auf Schiene bringt.

Die Kirschen in Nachbars Garten

Bezüglich der drängenden Sorge, ob SAP-KI-Agenten aus ihrer vorgesehenen Mandanten- oder Systemumgebung ausbrechen und in fremde S/4-Systeme oder andere Autonomous Enterprises einbrechen können, zeichnet die aktuelle Analyse ein differenziertes Bild: Ein physisches Ausbrechen aus der Laufzeitumgebung über Systemgrenzen hinweg wird auf Plattformebene durch mehrstufige Mandantentrennung (Tenant Isolation), verschlüsselte Geheimnisverwaltung (Secret Management) im AI Launchpad und isolierte Container-Sandboxes erschwert.

Dennoch existieren reale Angriffs- und Ausbreitungsrisiken (Lateral Movement), die primär über konzeptionelle Schwachstellen wie Prompt Injection, Memory Poisoning oder fehlerhaft konfigurierte BTP-Destinations entstehen. Wenn ein autonomer Agent über übergreifende Schnittstellen mit externen CRM- oder Partner-Systemen verbunden ist und dort auf manipulierte Daten stößt, kann er dazu verleitet werden, unberechtigte API-Aufrufe an andere S/4-Mandanten abzusetzen.

AI-API-Gateway und Behavioral Analytics

Die Verhinderung solcher Mandantenübergriffe erfordert ein zentrales AI-API-Gateway, das jeden Agenten-Traffic an einer einzigen, überwachten Schnittstelle bündelt, feingranulare Zugriffspolicies auf Parameter-Ebene durchsetzt und ungewöhnliche Verhaltensmuster über automatisierte Verhaltensanalysen (Behavioral Analytics) sofort blockiert.

Kommerziell nutzt SAP diese Sicherheitsbedenken jedoch auch als Hebel: Mit der im April 2026 erlassenen Version vier der SAP API Policy (Paragraf 2.2.2) reglementiert der Konzern den direkten, unlizenzierten Datenabzug durch Drittanbieter-Agenten streng und zwingt Kunden dazu, ihre Agenten-Workloads über die gebührenpflichtige Business Technology Platform (SAP BTP) und die Business Data Cloud (SAP BDC) zu schleusen. Dies schränkt zwar wilde Datenflüsse ein, treibt jedoch die Kosten über verbrauchsabhängige Capacity Units unbarmherzig nach oben.

SAP Cloud ERP Security

In der Betrachtung der Security von SAP Cloud ERP zeigt sich, dass der Wechsel in die Cloud – sei es über Rise with SAP (Private Cloud) oder Grow with SAP (Public Cloud) – ein völlig neues Betriebsmodell mit geteilter Verantwortung (Shared Responsibility Model) erzwingt. Das Versprechen, dass die Cloud per se eine uneinzunehmende Festung darstelle, wurde durch Vorfälle wie die schwere Zero-Day-Schwachstelle im SAP NetWeaver Visual Composer (CVE-2025-31324) relativiert, die zeigte, dass auch cloud-nahe Infrastrukturen kontinuierlich gehärtet und überwacht werden müssen.

SAP stellt für die Sicherheit seiner Bestandskunden in der Cloud ein umfangreiches Portfolio an Schutzmaßnahmen bereit. Die Basis bilden zertifizierte Rechenzentren nach ISO 27001, durchgängige Verschlüsselung ruhender und übertragener Daten (TLS/KMS), OAuth2-basierte Authentifizierung sowie automatisierte Bedrohungserkennung über Dienste wie SAP Enterprise Threat Detection. Auf der Infrastrukturebene kooperiert SAP eng mit den großen Hyperscalern wie Microsoft Azure, Amazon Web Services und Google Cloud Platform, wodurch erweiterte Sicherheits-Werkzeuge wie Microsoft Sentinel Threat Monitoring oder AWS Secrets Manager direkt eingebunden werden können.

Dennoch dürfen sich Anwenderunternehmen in der Cloud nicht in trügerischer Sicherheit wiegen. Um Risiken der Abhängigkeit von US-Hyperscalern und unberechenbaren Exportkontrollbestimmungen – wie der kurzfristigen US-Sperre von Anthropic-Sprachmodellen – zu begegnen, gewinnen datensouveräne Alternativen wie die AWS European Sovereign Cloud, die StackIT-Cloud der Schwarz-Gruppe oder die Rise-zertifizierte Private Cloud von T-Systems massiv an Bedeutung. Zudem entbindet auch die beste herstellerseitige Cloud-Sicherheit das Anwenderunternehmen nicht von seinen eigenen gesetzlichen Pflichten. Unter den strengen Vorgaben des europäischen EU AI Acts verbleibt die rechtliche und operative Letzthaftung für alle Entscheidungen und Aktionen, die von autonomen KI-Agenten im produktiven ERP-Kern ausgeführt werden, vollumfänglich und unübertragbar beim Anwender selbst.