SAP Joule Studio: Wie Unternehmen eigene Agenten bauen und was die API Policy erlaubt

Der Beitrag richtet sich an SAP-Verantwortliche, Enterprise-Architekten und IT-Leitungen, die SAP-Prozesse mit eigenen KI-Agenten erweitern wollen. Er setzt dort an, wo der Joule-Unternehmenscheck und der Beitrag zu Joule Work aufhören: bei der Frage, wann ein Unternehmen selbst baut und auf welchem Weg. Sinnvoll beginnt man nicht mit dem Werkzeug, sondern mit einer Bestandsaufnahme: Welche KI-Zugriffe auf SAP gibt es schon, und welche davon sind nach der API Policy noch zulässig?

Wo Joule Studio im SAP-Angebot steht

SAP ordnet seine KI-Angebote in drei Ebenen, wie die Seite SAP für Unternehmen zeigt: KI-Funktionen in den Anwendungen (SAP Business AI), Joule und Joule Work als Arbeitsoberfläche und Erweiterungen mit Joule Studio und SAP BTP. Joule Studio gehört zur dritten Ebene. Es ist der Weg für Fälle, die die mitgelieferten Joule-Agenten nicht abdecken. Bevor ein Unternehmen baut, sollte es deshalb prüfen, ob eine Standardfunktion den Vorgang schon unterstützt. Die Grundlagen dazu stehen im Beitrag KI in SAP-Lösungen.

SAP hat die neue, vollständig verwaltete Fassung von Joule Studio am 13. Mai 2026 vorgestellt. Sie ist von der früheren Joule-Studio-Variante in SAP Build zu unterscheiden. Laut SAP beschreiben Nutzer ihr Ziel in natürlicher Sprache. Joule Studio ermittelt mit SAP Signavio, SAP LeanIX, dem SAP Knowledge Graph und den SAP Domain Models Prozesse, Daten und Schnittstellen und erzeugt daraus Anforderungsdokument, Spezifikation, Code-Gerüst und Tests. Fertige Agenten laufen auf der Joule-Studio-Laufzeit, die laut SAP jeden Agenten in einer isolierten Umgebung auf Basis von NVIDIA OpenShell ausführt, und erscheinen in Joule Work.

Nicht abgedeckt sind laut SAP-Unterlagen bisher der Datenzugriff über SAP Business Data Cloud direkt aus Joule Studio und das Entwerfen und Ausführen von n8n-Workflows, beides geplant für das erste Quartal 2027. Auch das zentrale SAP Enterprise AI Gateway für die gesamte KI-Kommunikation soll erst im ersten Quartal 2027 kommen.

Welche Bauwege es gibt

Laut SAP-Referenzarchitektur (Stand 26. Oktober 2026) gibt es zwei Wege, Agenten zu bauen, und mehrere Wege, sie anzubinden. Die Tabelle fasst die Varianten zusammen.

Eigene Zusammenfassung nach SAP Architecture Center und TechEd-Leitfaden, Stand 11. November 2026. SAP weist darauf hin, dass Teile der Architektur noch nicht allgemein verfügbar sind, darunter die vollständige Zwei-Wege-Kommunikation mit Agenten anderer Anbieter über das Agent Gateway.

Laut TechEd-Leitfaden sind die meisten Bausteine in der schrittweisen allgemeinen Verfügbarkeit: die CLI, die Erweiterung bestehender Joule-Agenten mit Anweisungen und Werkzeugen, die Bereitstellung auf der Laufzeit, eine Testumgebung vor dem Produktivgang und Rollen für die Mitarbeit von Fachbereich und Entwicklung. „Schrittweise“ heißt: Nicht jeder Kunde hat jede Funktion sofort. Was im eigenen Mandanten tatsächlich freigeschaltet ist, muss SAP bestätigen.

Was die API Policy für eigene Agenten bedeutet

Die SAP API Policy in der Fassung v.4.2026a verbietet in Abschnitt 2.2.2 die API-Nutzung für teilautonome oder generative KI-Systeme, die Folgen von API-Aufrufen planen, auswählen oder ausführen, außer über von SAP freigegebene Architekturen, Datendienste oder ausdrücklich dafür vorgesehene Wege. Ebenso verboten sind Umgehungen über Proxys, eigenen Code, Gateways oder fremde Identitäten. SAP kann die Nutzung überwachen und Zugriffe drosseln, sperren oder beenden. Den Hintergrund haben wir im Beitrag zur neuen API Policy beschrieben.

Eine abschließende Liste der zulässigen Wege enthält die Policy selbst nicht. Die SAP-Referenzarchitektur beschreibt Joule Studio, eigene Agenten im Subaccount mit Anbindung über A2A, das MCP Gateway der Integration Suite und den Zugriff externer Agenten über Joule-Agenten. Diese Referenzarchitektur zeigt, was SAP technisch vorsieht. Eine verbindliche Freigabe für den einzelnen Kunden ist sie nicht, dafür zählen die Dokumentation der eingesetzten Produkte und der eigene Vertrag.

Für Unternehmen folgt daraus: Jede bestehende Integration, bei der ein KI-System selbst Folgen von SAP-API-Aufrufen plant, gehört auf den Prüfstand. Lässt sich der Weg nicht auf die Produktdokumentation oder eine schriftliche Bestätigung von SAP stützen, kann eine Umstellung nötig werden, etwa auf Joule Studio oder das MCP Gateway. Diese Bestandsaufnahme ist der erste Arbeitsschritt, noch vor jedem neuen Agenten.

Welche Rechte ein Agent bekommt

Für die Identität sieht die SAP-Referenzarchitektur zwei Betriebsarten vor, beide über SAP Cloud Identity Services. Ein Agent kann im Kontext eines Nutzers arbeiten, mit eigenen Einschränkungen für den Agenten. Oder er läuft autonom mit eigener technischer Identität, eigenen Token und eigenem Prüfpfad. Im ersten Fall gilt laut SAP: Die wirksame Berechtigung ist die Schnittmenge aus Nutzer- und Agentenrechten, durchgesetzt vom Agent Gateway bei jedem Schritt.

Redaktionelle, schematische Darstellung von AI-Fabrik nach der SAP-Referenzarchitektur, kein Produkt-Screenshot. Die drei Aktionen sind hypothetische Beispiele. Die Schnittmenge gilt für Agenten im Nutzerkontext; autonome Agenten mit eigener Identität haben eigene Rechte.

Die Schnittmenge ist eine gute Nachricht, aber keine Abkürzung. Sie schützt davor, dass ein Agent mehr darf als der Mensch, für den er arbeitet. Sie schützt nicht davor, dass ein Agent mit breit gefassten Rechten im Namen eines Nutzers mit breiten Rechten etwas Falsches tut. Die Agentenrechte müssen deshalb eigens und eng gefasst werden, am besten nur für die Aktionen des gewählten Vorgangs. Für autonome Agenten mit eigener Identität fehlt diese Bremse ganz. Hier gelten die Regeln wie für jeden technischen Benutzer: minimale Rechte, eigener Prüfpfad, regelmäßige Rezertifizierung.

Zur Abnahme bietet Joule Studio laut TechEd-Leitfaden eine Testumgebung mit Testanfragen, Ablaufverfolgung und automatisch erzeugten Tests. Änderungen an Produktivagenten sollen nachvollziehbar freigegeben und zurückgenommen werden können. Automatische Prüfungen auf Genauigkeit, korrekte Agentenaufrufe und Anfälligkeit für Prompt-Injection kündigt SAP erst für Ende des vierten Quartals 2026 an. Bis dahin muss ein Unternehmen solche Tests selbst entwerfen, etwa mit präparierten Dokumenten oder Belegtexten, die dem Agenten Anweisungen unterschieben.

Ein Pilot in der richtigen Größe

Für den ersten Pilot eignet sich ein lesender oder vorbereitender Vorgang mit klarer Verantwortung, etwa das Zusammentragen von Informationen zu einer gesperrten Rechnung mit Vorschlag für den nächsten Schritt. Der Agent liest, der Mensch entscheidet und bucht. Das ist ein hypothetisches Beispiel, das sich an typischen Klärungsfällen orientiert. Es hält die Rechte klein und macht den Nutzen trotzdem messbar: Zeit bis zur Klärung, Zahl der Rückfragen, Anteil der übernommenen Vorschläge.

Wie viel Kontrolle nötig ist, hängt nicht von der Größe des Unternehmens ab, sondern von der Wirkung des Vorgangs. Ein Agent, der nur liest und Vorschläge macht, kommt mit einer kurzen Liste seiner Rechte, einer festen Freigaberegel und Stichproben aus. Sobald er schreibt, etwa Belege, Stammdaten oder Freigaben, braucht er Betragsgrenzen, eine fachliche Freigabe und Sicherheitstests vor jeder Änderung. Wer mehrere Agenten produktiv betreibt, braucht zusätzlich ein Register aller Agenten, etwa im SAP AI Agent Hub, und eine Rechteprüfung in festen Abständen. Bei Zugriff auf Finanz- oder Personaldaten oder bei schwer umkehrbaren Aktionen kommen eine unabhängige Prüfung und ein Not-Aus hinzu.

Pilotfragen vor dem ersten eigenen Agenten

1. Welche Joule-Studio-Funktionen sind in unserem Vertrag und unserer Region heute freigeschaltet, und was kostet der Betrieb ab 2027?
2. Welche bestehenden KI-Zugriffe auf SAP-APIs fallen unter Abschnitt 2.2.2 der API Policy, und stützt sich ihr Weg auf Produktdokumentation oder Vertrag, oder müssen sie umgestellt werden?
3. Arbeitet der Agent im Nutzerkontext oder mit eigener Identität, und welche Aktionen bekommt er ausdrücklich?
4. Welche schreibenden Aktionen brauchen eine Freigabe, und wie werden Agent, Nutzer und Aktion protokolliert?
5. Mit welchen eigenen Testfällen prüfen wir Prompt-Injection und Fehlaktionen, solange SAPs automatische Prüfungen noch nicht verfügbar sind?

Fazit: Erst den Weg klären, dann den Agenten bauen

Quellen

Weiterführende Artikel auf AI-Fabrik