Zum Inhalt springen
Ihr Kompass für die digitale Welt.
Künstliche Intelligenz

Sechs Fragen an SAP, bevor KI-Agenten auf OpenShell laufen

SAP will Governance und abgesicherte Ausführung für KI-Agenten zusammenführen, doch vieles steht noch auf der Roadmap. Sechs Fragen helfen IT-Leitungen, Angaben und Planung zu trennen.

Serverraum als Sinnbild für die abgesicherte Ausführung von KI-Agenten mit OpenShell.Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptExecutives around a conference table in a bright office looking at a large wall display with an abstract diagram of connected AI agents and a shield symbol, business mood. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.
Wer KI-Agenten mit OpenShell betreiben will, muss Zuständigkeiten und Nachweise vorab klären (Symbolbild)

SAP will Joule Studio als Governance-Schicht mit NVIDIA OpenShell als abgesicherter Ausführungsumgebung für KI-Agenten zusammenführen. Nach SAP-Angaben läuft die Integration, geplant ist die Verbindung der SAP Business AI Platform mit OpenShell; FedRAMP- und FIPS-Unterstützung stehen nur auf einer gemeinsamen Roadmap. Die Joule-Studio-Laufzeitumgebung ist im Oktober 2026 für SAP-Kundschaft und Partner kostenlos. Einen Termin für die Zusammenführung nennt SAP nicht.

Wer Agenten auf dieser Grundlage betreiben will, muss vorab klären, welche Teile belegt tragen und welche bislang nur als Absicht beschrieben sind. Davon hängen Projektplan, Verantwortlichkeiten und Prüfbarkeit ab.

Wer im Stack wofür zuständig sein soll

Die Arbeitsteilung stammt aus einem Herstellerbeitrag im SAP News Center vom 22. Oktober. Es sind keine Produktbezeichnungen, sondern SAPs Beschreibung: Joule Studio, so SAP, bringt als AI-First-Entwicklungsumgebung einen vollständigen Stack für Ausführung und Governance von KI-Agenten mit. OpenShell dagegen soll die Implementierung von Agenten unter besonderer Berücksichtigung der Sicherheit unterstützen.

Die Governance-Schicht ist nach SAP die Joule-Studio-Laufzeitumgebung. Sie hilft zu ermitteln, ob eine Aktion überhaupt ausgeführt werden soll. Dazu wendet sie Berechtigungen, rollenbasierte Richtlinien und Prozesskontext an, bevor eine Anforderung an die Laufzeitumgebung übermittelt wird. Rollenbasiert heißt: Die Regel hängt an der Rolle, die ein Agent oder die auslösende Person im Prozess innehat, nicht an Einzelfallentscheidungen.

OpenShell ist eine Open-Source-Laufzeitumgebung für autonome Agenten, also eine Art abgeschotteter Raum, oft Sandbox genannt. Laut SAP steuert sie, wie der Agent ausgeführt wird, worauf er zugreifen kann, welche Aufgaben er ausführen darf und welche Schlüsse er zieht. Die Prüfung vor der Aktion und die Begrenzung während der Aktion sitzen damit in zwei getrennten Schichten.

Das eigentliche Ziel liegt in der Verbindung. SAP nennt als Vorhaben, die isolierte OpenShell-Umgebung mit der Governance-Schicht zu koppeln, indem technische Ausführungsgrenzen mit Berechtigungsmodellen, IAM-Frameworks und Prüfpfaden verknüpft werden. IAM steht für Identity and Access Management, die Systeme, die festlegen, wer oder was sich anmelden und welche Rechte erhalten darf. Prüfpfade sind die Aufzeichnungen, mit denen sich später nachvollziehen lässt, wer was ausgelöst hat.

Ein hypothetisches Beispiel zeigt die Arbeitsteilung: Ein Agent soll in einem Einkaufsprozess eine Zahlung freigeben. In Joule Studio würde vor der Aktion geprüft, ob die Berechtigung vorliegt, ob die Rolle die Freigabe erlaubt und ob der Prozesskontext dazu passt. Erst danach ginge die Anforderung an die Laufzeitumgebung. In OpenShell wäre während der Ausführung begrenzt, worauf der Agent zugreifen kann und welche Aufgaben er ausführen darf.

dm-Einordnung: Der Audit-Nachweis müsste dort entstehen, wo Berechtigungsentscheidung und Ausführungsgrenze zusammenlaufen. SAP nennt Prüfpfade als Ziel der Verknüpfung, sagt aber nicht, wo sie entstehen oder wer sie verwahrt.

Ein Teil der Architektur betrifft den Supervisor. Das ist eine eigene Schicht der Laufzeitumgebung, die laut SAP von der Ausführungsschicht der Agenten getrennt ist, sodass beide unabhängig skalieren können. Wie Joule Studio technisch mit OpenShell gekoppelt wird, beschreibt SAP nicht.

Die Ankündigung selbst hat dm bereits am 29. September in einer früheren Analyse zur Ausführungsgrenze eingeordnet. Hier geht es um die Anschlussfrage: Wo endet die Zusage, und wo beginnt die eigene Arbeit der IT?

Für die Verantwortung folgt aus der Trennung etwas Praktisches. Wer Richtlinien pflegt, muss nicht dieselbe Stelle sein wie jene, die Container-Umgebungen betreibt. Diese Zuordnung sollte vor dem ersten Agenten schriftlich stehen, weil Audit-Fragen sonst zwischen den Schichten hängen bleiben.

Was SAP schon tut und was nur geplant ist

Am 28. September stellte NVIDIA die Open Agent Safety Platform vor und gab die allgemeine Verfügbarkeit von OpenShell bekannt. SAP kündigte am selben Tag den weiteren Ausbau der Zusammenarbeit an. Die technische Kooperation war nach SAP-Angaben bereits auf der SAP Sapphire in diesem Jahr verkündet worden.

Die Zeitformen im SAP-Text sind aufschlussreich. „Geplant ist, die SAP Business AI Platform mit OpenShell zusammenzuführen“ beschreibt eine Planung. Dass SAP-Teams direkt zur Codebasis von OpenShell beitragen und OpenShell in die SAP Business AI Platform „integrieren“, beschreibt laufende Arbeit. Von einer abgeschlossenen Integration schreibt SAP nichts, einen Termin für die Zusammenführung nennt SAP nicht.

Nach SAPs eigener Darstellung lässt sich der Stand in drei Stufen trennen:

  • Geleistet: Code-Beiträge zum OpenShell-Projekt in vier Bereichen; die Joule-Studio-Laufzeitumgebung ist im Oktober 2026 für Kundschaft und Partner kostenlos.
  • Laufend: Beiträge zur OpenShell-Codebasis und Integration in die SAP Business AI Platform, ohne beschriebenen Abschluss.
  • Geplant: Zusammenführung mit OpenShell, Absicherung für regulierte Branchen und FedRAMP- und FIPS-Unterstützung per Roadmap, jeweils ohne Termin.

Bereits geleistet haben SAP-Teams nach eigener Darstellung Beiträge in vier Bereichen des Open-Source-Projekts. Erstens zerlegten sie die Laufzeitumgebung in Komponenten, die sich unabhängig voneinander implementieren lassen. Supervisor-Schicht und Ausführungsschicht für Agenten sind getrennt und können unabhängig skaliert werden.

Zweitens geht es um den Betrieb auf Kubernetes, der verbreiteten Plattform für Container. SAP nennt Unterstützung für Operatoren (Programme, die Anwendungen in Kubernetes automatisiert verwalten), die Verwaltung von Image Pull Secrets (Zugangsdaten für private Container-Registries), benutzerdefinierte Vorlagen für Volume Claims (Anforderungen von Speicherplatz) und die Foreground-Löschung von Sandbox-Ressourcen, bei der abhängige Ressourcen vor dem Hauptobjekt entfernt werden.

Drittens half SAP, den Speicherbedarf der Gateway-Images zu verringern und die Treiber-Unterstützung für heterogene Infrastrukturen zu verbessern. Viertens trugen SAP-Teams zur Zustandsüberwachung des Supervisors und zur strukturierten Konfiguration auf Protokollebene bei. Dadurch erfülle die Laufzeitumgebung nun auch Standards für die Beobachtbarkeit. Das ist eine Herstellerangabe; welche Standards gemeint sind, präzisiert SAP nicht.

Geplant dagegen sind weitere Ziele. SAP will die OpenShell-Laufzeitumgebung für den Einsatz im Unternehmen absichern, auch in regulierten Branchen mit strengen Sicherheits- und Compliance-Anforderungen. Und SAP will die Einhaltung von FedRAMP, FIPS und Vorschriften regulierter Branchen im Rahmen einer gemeinsamen Roadmap unterstützen. FedRAMP ist das US-Programm zur Sicherheitsfreigabe von Cloud-Diensten, FIPS sind US-Standards unter anderem für kryptografische Module. Eine Roadmap ist ausdrücklich kein Zertifikat.

SAP nennt außerdem die Mitgliedschaft in der Open Secure AI Alliance, die offene Forschung und die Sicherheit von KI fördern soll. SAP und NVIDIA gehören ihr gemeinsam mit anderen Unternehmen als Gründungsmitglieder an; eine Mitgliederliste nennt SAP nicht.

Fragen an Anbieter und eigene Architektur

SAP OpenShell: IT-Leiter skizziert Architekturfragen am WhiteboardDieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptIT director standing in front of a whiteboard sketching abstract boxes and arrows for an enterprise architecture, colleagues taking notes, modern open office. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.
Fragen an die Architektur (Symbolbild)

Sechs Fragen gehören auf die Liste, bevor Agenten auf OpenShell laufen; zu keiner liefert der SAP-Beitrag bisher eine Antwort. Jede knüpft an eine konkrete SAP-Aussage an.

  • (a) Welche Teile sind produktiv nutzbar? SAP schreibt, die Integration laufe, und zugleich, die Zusammenführung sei geplant. Für Betrieb und Projektplan zählt, was in welchem Release tatsächlich bereitsteht. Eine brauchbare Antwort enthält eine Aufstellung der Funktionen mit Release und Status, getrennt nach verfügbar und geplant. Ohne sie lässt sich kein Plan belastbar aufsetzen.
  • (b) Welche Berechtigungsmodelle und IAM-Systeme werden angebunden? SAP will Ausführungsgrenzen mit Berechtigungsmodellen, IAM-Frameworks und Prüfpfaden verknüpfen. Ob Ihr Identity-Provider und Ihre Rollenkonzepte dazugehören, ist offen. Davon hängt ab, ob Rechte doppelt gepflegt werden müssen. Eine gute Antwort nennt die unterstützten Systeme, die Schnittstellen und die Stelle, an der der Audit-Nachweis entsteht und wer ihn verwahrt.
  • (c) Was akzeptieren Prüfende bei FedRAMP und FIPS? SAP spricht von Unterstützung im Rahmen einer gemeinsamen Roadmap, nicht von einer Zertifizierung. In regulierten Branchen entscheidet die Revision oder Aufsicht, ob ein Planungsstand genügt. Eine brauchbare Antwort liegt als schriftliche Einschätzung dieser Stellen vor und benennt, welcher Nachweis zu welchem Zeitpunkt nötig ist.
  • (d) Wer betreibt Supervisor und Gateway? SAP nennt Operator-Unterstützung für Kubernetes, also die automatisierte Verwaltung von Anwendungen auf der Container-Plattform, und die Trennung von Supervisor- und Agentenausführung. Ob Ihr Team die Komponenten selbst betreibt oder SAP sie bereitstellt, bleibt offen. Daran hängen Patch-Zuständigkeit, Bereitschaftsdienst und Haftung. Die Antwort muss eine klare Rollenverteilung samt Reaktionszeiten enthalten.
  • (e) Was gilt nach Oktober 2026? Die Joule-Studio-Laufzeitumgebung ist im Oktober 2026 kostenlos, zur Zeit danach schweigt SAP. Für Budget und Ausstiegsfähigkeit ist das entscheidend, sobald Abhängigkeiten entstehen. Eine brauchbare Antwort nennt Preismodell, Laufzeit und Bedingungen schriftlich, bevor ein Pilot beginnt.
  • (f) Wie gelangen die strukturierten Logs ins eigene SIEM? SAP verweist auf strukturierte Konfiguration auf Protokollebene und auf Beobachtbarkeit. Ein SIEM ist das zentrale System, das Sicherheitsereignisse sammelt und auswertet. Ohne definierte Anbindung fehlt der Weg von der Aufzeichnung zur Alarmierung. Die Antwort muss Formate, Schnittstellen und Aufbewahrungsfristen benennen.

Als dm-Einordnung empfiehlt sich diese Reihenfolge: zuerst (a), weil sie den Rahmen für alle anderen Antworten setzt, dann (e), weil Folgekosten den Pilotvertrag direkt betreffen, danach (c) in regulierten Branchen. Die Fragen (b), (d) und (f) lassen sich im Pilot klären, sollten aber vertraglich zugesagt sein.

Wie belastbar die Aussagen sind

Die Grundlage ist ein Feature im SAP News Center vom 22. Oktober, verfasst von Andre Lamego, Senior Vice President und Chief Product Officer für SAP Business AI Platform Fabric. Es ist damit eine Herstellerdarstellung. Unabhängige Prüfungen, Kundenzahlen oder Benchmarks enthält der Text nicht.

Ebenfalls fehlen Preise für die Zeit nach Oktober 2026, Verfügbarkeitstermine für die Zusammenführung und jeder Zertifizierungsstatus. Auch zur technischen Kopplung von Joule Studio und OpenShell gibt es keine Angabe. Formulierungen wie „soll es ermöglichen“ oder „soll unterstützt werden“ sind Absicht des Herstellers, kein Ergebnis. Das Fehlen einer Angabe beweist allerdings nicht, dass es sie nicht gibt; es heißt nur, dass sie erfragt werden muss.

Für die Aussagen liegt nur ein Herausgeber vor: das Feature im SAP News Center vom 22. Oktober, geprüft mit Stand 27. Oktober. dm hat keine zweite unabhängige Bestätigung für die genannten Angaben herangezogen. Das gilt auch für die Beobachtbarkeit: SAP schreibt, die Laufzeitumgebung erfülle durch die Beiträge „nun auch Standards für die Beobachtbarkeit“, benennt aber keinen Standard. Die „besondere Berücksichtigung der Sicherheit“ bei OpenShell ist ebenfalls Selbstbeschreibung. Als dm-Einordnung folgt daraus: Lassen Sie sich vertraglich zusichern, welche Standards konkret gemeint sind, welche Sicherheitsmerkmale mit welchem Release gelten und welche Nachweise SAP dafür liefert.

Für die Einordnung im eigenen Betrieb hilft die Frage, wer Agenten überhaupt verantworten soll. Dazu hat dm Zuständigkeiten und Betriebsmodelle für SAP-Agenten im Unternehmen betrachtet. Die OpenShell-Fragen oben setzen genau dort an, weil Ausführungsgrenzen ohne benannte Verantwortliche keine Kontrolle ergeben.

Einen Anspruch formuliert SAP selbst: Das Vorhaben gehe über eine reine Integration hinaus und stehe für die gemeinsame Absicht von SAP und NVIDIA, die Bedeutung des Begriffs „für Unternehmen“ im Zusammenhang mit autonomen KI-Systemen zu definieren. Wie diese Definition aussehen soll, sagt der Beitrag nicht. Bis dahin legen Kundinnen und Kunden mit ihren Anforderungen an Nachweise und Betrieb selbst mit fest, was „für Unternehmen“ bedeuten muss.