Ihr Agent handelt mit Ihren Rechten

Was die Agent-Dokumentation von SAP zur Prozessautorisierung beantwortet, was sie Ihrem Rollendesign überlässt, und die drei Entscheidungen, die daraus folgen

Executive Summary

Strategischer Kontext

Ausgangslage. SAP richtet seine Anwendungen neu auf Agents aus. Die Lernmaterialien beschreiben ein Schichtenmodell: Joule Assistants interpretieren die Absicht eines Users und koordinieren Joule Agents, die „plan, act, and execute complex multi-step tasks“, und zwar über fünf autonome Domänen hinweg: Finance, Spend, Supply Chain, HCM und Customer Experience. Governance wird als eingebaut positioniert, mit SAP AI Agent Hub als „command center“, in dem Agents herstellerübergreifend erfasst, verifiziert und beobachtet werden.

Komplikation. Ein früherer Artikel auf dieser Seite hat argumentiert, dass vier Fragen über das Agent-Risiko entscheiden: welche Prozessschritte ein Agent verändern darf, welche Schwellenwerte gelten, wo ein Mensch gegenzeichnet und wie eine falsche Entscheidung erkannt und zurückgenommen wird. Die SAP-Dokumentation gibt auf die erste dieser Fragen jetzt eine konkrete Antwort, und sie hat Gewicht. In SAPs eigenen Worten: „every agent action carries your identity and access permissions, so agents can only act on what you are entitled to act on.“ Dieser Satz verlagert die entscheidende Kontrolle aus dem Agent heraus in das Berechtigungskonzept, das die meisten SAP-Kunden vor Jahren für Menschen gebaut haben, die in menschlichem Tempo arbeiten.

Frage. Wenn ein Agent die Rechte eines Users erbt: Was kontrolliert die dokumentierte Architektur von SAP, was bleibt dem Kunden überlassen, und welche Entscheidungen müssen fallen, bevor Agents in wertschöpfenden Prozessen laufen?

Zentrale Befunde

1. Geerbte Rechte machen das Rollendesign zur wichtigsten Agent-Kontrolle. SAP stellt fest, dass Agents in allen drei Betriebsarten (conversational, embedded und system-triggered) „always operate within your organization’s authorization boundaries“ und mit der Identität des auslösenden Users handeln. Was folgt daraus? Welche Breite die Rollen eines Users auch haben: Der Agent hat sie ebenfalls. Ein Rollenkonzept, das tragbar war, weil ein Mensch Stunden brauchte, um seine Breite auszunutzen, wird jetzt von Software ausgeschöpft, die mehrstufige Arbeit plant und ausführt.

2. Die Dokumentation sagt nicht, welche Identität ein system-getriggerter Agent trägt. SAP beschreibt Agents, die „initiated by a business event, a schedule, or a system signal rather than a user request“ sind, und sagt in derselben Lektion, dass jede Agent-Aktion „your“ identity trägt. Weder die Lektion noch die für diesen Artikel gelesenen Produktseiten klären, welche Identität gilt, wenn kein User den Lauf ausgelöst hat. Was folgt daraus? Diese Frage gehört an SAP und an Ihr eigenes Architecture Board, bevor der erste Hintergrund-Agent live geht. In SAP-Landschaften läuft die Antwort sonst gern auf einen technischen User mit weitreichenden Rechten hinaus.

3. SAP AI Agent Hub steuert Agents und ihre Verbindungen, nicht einzelne Prozessentscheidungen. Dokumentiert sind ein herstellerübergreifendes Inventar, ein Verifikations-Workflow, Laufzeitrechte für Agents und MCP-Server („only verified MCP servers can be called in production workflows“), Architecture-Decision-Workflows „for approval gating“, Observability und Agent Mining. Was folgt daraus? Das sind echte Kontrollen dafür, welcher Agent laufen und welche Tools er aufrufen darf. Keine der gelesenen Seiten beschreibt einen Wertschwellenwert je Prozessschritt oder eine Gegenzeichnung je Aktion.

4. Conformance-Monitoring erkennt Abweichungen, nicht den korrekten Pfad mit falschem Ergebnis. Agent Mining misst, „whether a deployed agent is following the execution pathway it was built for.“ Was folgt daraus? Der Fehlerfall, der keinen Alarm auslöst, also eine formal gültige Entscheidung mit falschem Geschäftsergebnis, bleibt per Definition konform. Die Erkennung dieses Falls bleibt Designarbeit des Kunden.

5. „Reversible“ wird behauptet, nicht definiert. Die SAP-Lektion stellt fest, Agent-Aktionen seien „governed, auditable, and reversible.“ Was Rücknahme bei einer gebuchten Zahlung, einer bereits an den Lieferanten übermittelten Bestellung oder einem geänderten Stammsatz bedeutet, beschreiben die gelesenen Seiten nicht. Was folgt daraus? Behandeln Sie Rücknahme als Anforderung, die je Prozess zu spezifizieren ist, nicht als Plattformeigenschaft, die Sie bereits gekauft haben.

Wichtigste Empfehlungen

Priorität	Empfehlung	Aufwand	Zeitrahmen
Hoch	Rollen jeder User-Gruppe prüfen, die Agents auslösen wird, vor der Aktivierung und mit Segregation of Duties als Prüfmaßstab	Mittel	Vor dem Go-live
Hoch	Identität festlegen und dokumentieren, unter der system-getriggerte Agents laufen, und ihre Rechte begrenzen	Niedrig	Vor dem ersten Hintergrund-Agent
Hoch	Wert- und Mengenschwellen in der Prozesskonfiguration durchsetzen, außerhalb des Agents	Mittel	Je Prozess, vor der Skalierung
Mittel	Für jeden vom Agent ausgeführten Schritt festlegen, was Rücknahme bedeutet, und es einmal testen	Mittel	Ein Quartal
Mittel	Inventar und MCP-Verifikation im Agent Hub ab dem ersten Agent nutzen	Niedrig	Sofort
Niedrig	Ergebnisbasierte Erkennung für konforme, aber falsche Entscheidungen ergänzen	Hoch	Zwei Quartale

Fazit

SAP hat eine ernstzunehmende Governance dafür gebaut, welche Agents existieren und womit sie sich verbinden dürfen. Die Entscheidung, was ein Agent innerhalb eines Prozesses tun darf, wird an das Berechtigungskonzept delegiert, und dieses Konzept wurde für Menschen entworfen. Prüfen Sie es, als wäre es das Regelwerk des Agents, denn genau das ist es jetzt.

Wo dieser Artikel anknüpft

Der Artikel Welche Prozessschritte darf Ihr Agent auslösen? hat herstellerneutral argumentiert: Agent-Sicherheit ist weniger ein Modellproblem als ein Problem der Prozessautorisierung, und vier Fragen entscheiden darüber. Eine konkrete Plattform hat er bewusst nicht behandelt.

Dieser Artikel wendet die vier Fragen auf eine konkrete, dokumentierte Architektur an. SAP ist aus zwei Gründen ein sinnvoller Testfall. Es ist das führende System für viele der Prozesse, in denen Agents Geld und Waren bewegen werden, und SAP hat ungewöhnlich konkretes Material dazu veröffentlicht, wie seine Agents arbeiten, darunter partnerorientierte Lerninhalte, die über die Produktseiten hinausgehen.

Die Methode ist einfach: lesen, was SAP dokumentiert, es zitieren und den vier Fragen gegenüberstellen. Wo die Dokumentation schweigt, wird das benannt statt erschlossen.

Befund 1: Der Agent erbt den User

Der zentrale Satz steht in der SAP-Lernlektion zu Joule Agents:

„Across all three modes, agents always operate within your organization’s authorization boundaries. Every agent action carries your identity and access permissions, so agents can only act on what you are entitled to act on.“

Als Sicherheitsaussage gelesen ist das beruhigend. Ein Agent kann die Rechte des Users, für den er handelt, nicht überschreiten. Es gibt keinen separaten, unsichtbaren Superuser.

Als Aussage zur Prozessautorisierung gelesen hat der Satz eine zweite Konsequenz. Die Rechte, die den Agent begrenzen, sind die Rechte, die für den User entworfen wurden. In SAP-Landschaften sind diese typischerweise als Rollen ausgeprägt, die Transaktionen und Berechtigungsobjekte bündeln, nicht als Prozessschritte mit Schwellenwerten. Die Frage „welche Schritte darf dieser Agent verändern“ beantwortet also ein Rollendesign, das diese Frage nie vorhergesehen hat.

Erfahrung, nicht belegt. Rollenkonzepte in lange gewachsenen SAP-Landschaften sammeln Breite an: befristete Erweiterungen, die geblieben sind, Sammelrollen, die der Bequemlichkeit halber vergeben wurden, Notfallzugriffe, die nie ganz entzogen wurden. Das ist in der Praxis weit verbreitet und der Grund, warum es Reviews zur Segregation of Duties gibt. Eine Zahl wird hier nicht genannt, weil für diesen Artikel keine gelesen wurde.

Die praktische Konsequenz hängt nicht an einer Zahl. Breite, die tragbar war, weil ein Mensch Zeit und Absicht brauchte, um sie zu nutzen, wird zu einer anderen Exposition, wenn Software mit denselben Rechten mehrstufige Arbeit plant und ausführt. Der Agent tut nichts Verbotenes. Er tut, was die Rolle erlaubt, schneller und konsequenter, als es der Mensch je getan hätte.

Die Entscheidung, die daraus folgt. Bevor eine User-Gruppe Agents erhält, müssen ihre Rollen mit Blick auf den Agent geprüft werden. Der Maßstab ist nicht „braucht diese Person das“, sondern „ist es akzeptabel, dass ein Agent, der für diese Person handelt, das ohne Rückfrage ausführt“.

Befund 2: Die Identitätslücke im system-getriggerten Modus

SAP beschreibt drei Betriebsarten für Joule Agents:

Conversational. Ein User stellt in Joule eine Anfrage, etwa eine Spesenabrechnung zu genehmigen oder eine Bestellung anzulegen.
Embedded. Der Agent arbeitet innerhalb einer Anwendung, in der der User ohnehin ist.
System-triggered. Der Agent wird „initiated by a business event, a schedule, or a system signal rather than a user request.“ SAPs Beispiel ist ein Agent, der Änderungen der Handelspolitik überwacht und „autonomously propose[s] reclassifications when regulations shift.“

Die ersten beiden Modi haben eine offensichtliche Identität: den User vor dem Bildschirm. Der dritte hat nach SAPs eigener Beschreibung keinen anfragenden User. Trotzdem stellt dieselbe Lektion fest, dass jede Agent-Aktion „your“ identity und permissions trägt.

Die für diesen Artikel gelesenen Seiten lösen diese Spannung nicht auf. Weder die Lektion noch die Produktseiten legen fest, welche Identität ein system-getriggerter Agent trägt, wie diese Identität bereitgestellt wird oder wer ihre Berechtigungen verantwortet.

Das wiegt schwerer, als es aussieht. Der system-getriggerte Modus kommt dem Autonomous Enterprise, das SAP beschreibt, am nächsten: einem Unternehmen, in dem „demand changes no longer wait for planning cycles“ und stattdessen „automatically drive production adjustments, inventory reallocation, and procurement actions.“ Es ist zugleich der Modus mit der geringsten menschlichen Nähe.

Erfahrung, nicht belegt. Hintergrundverarbeitung lief in SAP historisch unter technischen oder Batch-Usern, und genau diese User sind häufige Prüfungsfeststellungen, weil sie weitreichende Rechte erhalten, damit Jobs nicht abbrechen. Übernehmen Hintergrund-Agents dieses Muster, läuft der autonomste Modus unter der am wenigsten geprüften Identität.

Die Entscheidung, die daraus folgt. Die Identität für system-getriggerte Agents ist eine Architekturentscheidung mit benanntem Verantwortlichen, getroffen, bevor der erste Hintergrund-Agent läuft. Fragen Sie SAP, wie das für die Agents gelöst ist, die Sie einsetzen wollen, und begrenzen Sie die Rechte der Identität, die dabei herauskommt.

Befund 3: Was SAP AI Agent Hub tatsächlich steuert

SAP positioniert AI Agent Hub als „a vendor-agnostic command center that provides a single entry point for the discovery and governance of AI agents, large language models (LLMs), and Model Context Protocol (MCP) servers.“ Ohne die Positionierung dokumentieren Produktseite und Lernlektion folgende Kontrollen:

Dokumentierte Fähigkeit	Was SAP sagt	Welcher der vier Fragen sie dient
AI Registry	Inventar von Agents, LLMs und MCP-Servern, mit automatischer Erkennung aus SAP, Microsoft, Google, AWS, Databricks und ServiceNow	Voraussetzung für alle vier: Was nicht inventarisiert ist, lässt sich nicht autorisieren
Evaluation und Verifikation	„AI risk rating, build type, attached architecture decisions, and compliance mappings,“ mit „a formal verification workflow“	Welche Agents überhaupt laufen dürfen
Identity and Access Control	„Determine the access, runtime permissions, and policies for agents and MCP servers. Only verified MCP servers can be called in production workflows, and when verification status changes, access is revoked.“	Welche Tools ein Agent aufrufen darf. Teilweise Frage 1
Approval Gating	„architecture decision workflows for approval gating“	Eine menschliche Entscheidung zur Design- und Deployment-Zeit. Keine Gegenzeichnung je Aktion
AI Observability	„session health, goal completion rate, tool call correctness,“ mit Tracing jedes Tool-Aufrufs	Frage 4, für technisches Versagen
Agent Mining	Misst „variants, path completion and conformance, and activity coverage“	Frage 4, für Abweichungen vom entworfenen Pfad
Org Chart und Skills Mapping	Ordnet Agents über SAP SuccessFactors „to the business units and roles it affects“ zu	Transparenz über die Belegschaft. Keine Autorisierung

Daraus folgen zwei Beobachtungen.

Erstens: Das ist mehr als ein Inventar. Die Regel, dass in Produktion nur verifizierte MCP-Server aufgerufen werden können und der Zugriff entzogen wird, sobald sich der Verifikationsstatus ändert, ist eine echte Laufzeitkontrolle darüber, was ein Agent erreichen kann. Viele Organisationen haben für ihre Nicht-SAP-Agents nichts Vergleichbares.

Zweitens: Gesteuert wird der Agent als Asset, nicht die Entscheidung, die der Agent trifft. Keine der dokumentierten Fähigkeiten beschreibt einen Schwellenwert wie „ab einem bestimmten Wert an einen Menschen übergeben“ oder eine Gegenzeichnung einer einzelnen Agent-Aktion. Die Spend-Management-Seite von SAP erwähnt „built-in policy checks, audit rules, approvals and proactive guidance that happen automatically in real time“, beschreibt aber nicht, wie diese konfiguriert werden, und eine Marketingzeile ist keine Kontrollspezifikation.

Eine Korrektur unserer eigenen früheren Einschätzung. Der frühere Artikel hatte festgehalten, dass die Produktdokumentation von SAP LeanIX Dependency Mapping nicht als benannte Fähigkeit beschreibt. Die Agent-Hub-Seite von SAP positioniert LeanIX jetzt als Lieferant von „the business capabilities [agents] support and the technology they depend and operate on“, und die Lernlektion sagt, LeanIX-Architekturkontext „is surfaced directly during agent creation.“ Das sind eine Produktseite und eine Lernlektion, keine Produktdokumentation, und es geht um Agents, nicht um Systeme im Allgemeinen. Die Lücke, die der frühere Artikel beschrieben hat, wird dadurch dennoch kleiner, und deshalb wird es hier festgehalten.

Die Entscheidung, die daraus folgt. Nutzen Sie den Hub für das, was er dokumentiert: Inventar ab dem ersten Agent, Verifikation jedes MCP-Servers, Approval Gating beim Deployment. Behandeln Sie ihn nicht als den Ort, an dem Prozessschwellen liegen, denn nichts Gelesenes deutet darauf hin.

Befund 4: Konformität ist nicht Richtigkeit

Agent Mining ist die interessanteste Fähigkeit auf der Liste, weil es Process Mining auf Agents anwendet. SAP beschreibt, es mache „it possible to determine whether a deployed agent is following the execution pathway it was built for.“

Damit ist eine wichtige Frage beantwortet: Hat der Agent getan, wofür er entworfen wurde? Nicht beantwortet ist die Frage, die der frühere Artikel als die schwierigere ausgemacht hat: War das, wofür er entworfen wurde, in diesem Fall das Richtige?

Nehmen Sie einen Sourcing-Agent, der seinem entworfenen Pfad genau folgt: Angebote einsammeln, das Scoring anwenden, die Vergabe empfehlen. Ist die Scoring-Regel für eine ungewöhnliche Warengruppe falsch, ist jeder Lauf konform und jedes Ergebnis falsch. Observability meldet gesunde Sessions, hohe Zielerreichung und korrekte Tool-Aufrufe. Agent Mining meldet volle Konformität. Nichts schlägt Alarm.

Das ist keine SAP-spezifische Schwäche. Es liegt im Wesen von Conformance-Monitoring, und genau deshalb ist dieser Fehlerfall überall gefährlich. Der Punkt ist enger gefasst: Eine Organisation, die Observability und Agent Mining im Agent Hub eingeführt hat, kann mit gutem Grund glauben, die Erkennung sei abgedeckt, und für diesen Fehlerfall ist sie es nicht.

Die Entscheidung, die daraus folgt. Ergänzen Sie für Agents in wertschöpfenden Prozessen mindestens eine ergebnisbasierte Prüfung, die vom Design des Agents unabhängig ist: eine stichprobenartige menschliche Prüfung von Entscheidungen, einen Abgleich mit einer fachlichen Benchmark oder eine nachgelagerte Abstimmung. Wählen Sie sie je Prozess, denn was ein „falsches Ergebnis“ ist, ist eine fachliche Definition.

Befund 5: „Reversible“ braucht eine Definition je Schritt

Die Einführungslektion von SAP macht eine starke Governance-Aussage:

„Actions taken by agents are governed, auditable, and reversible. The system operates within compliance frameworks, provides a complete audit trail, and maintains clearly defined escalation paths.“

„Auditable“ ist durch das übrige Material gut gestützt: SAP stellt fest, „every decision an agent makes is logged and traceable.“ Eskalationspfade werden auf den gelesenen Seiten ohne Details behauptet.

„Reversible“ ist die Aussage, die am genauesten zu prüfen ist, denn Umkehrbarkeit ist eine Eigenschaft des Geschäftsschritts, nicht der Plattform. Ein Entwurf lässt sich löschen. Ein Umklassifizierungsvorschlag lässt sich ablehnen. Eine gebuchte Zahlung hat das Unternehmen verlassen. Eine an den Lieferanten übermittelte Bestellung hat auf der Gegenseite eine Erwartung erzeugt, möglicherweise auch eine rechtliche. Ein geänderter Stammsatz hat sich womöglich schon weiterverbreitet.

Die Dokumentation beschreibt nicht, wie Rücknahme bei solchen Schritten funktioniert, und sie kann es auch nicht, denn die Antwort hängt von Prozess, Verträgen und Schnittstellen des Kunden ab.

Die Entscheidung, die daraus folgt. Halten Sie für jeden Schritt, den ein Agent ausführen darf, fest, was Rücknahme bedeutet, wer sie durchführt und in welcher Zeit. Wo Rücknahme nicht möglich ist, gehört der Schritt hinter einen Schwellenwert oder eine Gegenzeichnung, und damit sind Sie wieder bei Befund 3.

Implikationen für Führungskräfte

Das Berechtigungskonzept ist jetzt ein Artefakt der KI-Governance. Agents werden es lesen, ob es jemand zu diesem Zweck geprüft hat oder nicht. Die Verantwortung für das Rollendesign liegt meist bei SAP-Basis oder einer GRC-Funktion, die kein Mandat für KI hat. Dieses Mandat muss ausdrücklich vergeben werden.

Plattform-Governance und Prozess-Governance sind verschiedene Aufgaben mit verschiedenen Verantwortlichen. SAP AI Agent Hub gibt IT und Architektur einen starken Hebel für die erste. Die zweite gehört den Prozessverantwortlichen, die Schwellen und Gegenzeichnungen festlegen und selten mit am Tisch sitzen, wenn Agents aktiviert werden.

Die günstigsten Kontrollen sind Entscheidungen, keine Tools. Die Identität für Hintergrund-Agents, der Schwellenwert je Schritt, die Bedeutung von Rücknahme: Jede davon ist eine kurze, dokumentierte Entscheidung. Keine erfordert eine Beschaffung. Jede wird teuer, sobald Agents laufen und die Entscheidung stillschweigend per Voreinstellung gefallen ist.

Empfehlungen

Empfehlung	Begründung	Verantwortlich	Aufwand
Rollen der User-Gruppen prüfen, die Agents auslösen, mit SoD als Maßstab	Agents erben Breite, die für Menschen tragbar war	GRC mit Prozessverantwortlichem	Mittel
Identität für system-getriggerte Agents festlegen und ihre Rechte begrenzen	In der gelesenen Dokumentation nicht geklärt; läuft sonst gern auf breite technische User hinaus	Unternehmensarchitektur	Niedrig
Schwellenwerte im Prozess konfigurieren, außerhalb des Agents	Im Agent Hub ist kein Schwellenwert je Aktion dokumentiert	Prozessverantwortlicher	Mittel
Rücknahme je vom Agent ausgeführtem Schritt definieren und testen	„Reversible“ wird behauptet, nicht spezifiziert	Prozessverantwortlicher mit IT	Mittel
Inventar und MCP-Verifikation ab dem ersten Agent betreiben	Dokumentiert, wirksam, früh am günstigsten	IT und Architektur	Niedrig
Eine ergebnisbasierte Prüfung je wertkritischem Agent ergänzen	Conformance-Monitoring sieht keinen korrekten Pfad mit falschem Ergebnis	Prozessverantwortlicher mit interner Kontrolle	Hoch

Executive Dashboard

Frage	Was die SAP-Dokumentation liefert	Was Ihre Entscheidung bleibt	Konfidenz
Welche Prozessschritte darf der Agent verändern?	Geerbte User-Rechte; Rechte zur Build-Zeit festgelegt	Rollendesign für den Agent-Einsatz geprüft	Hoch
Unter welcher Identität laufen Hintergrund-Agents?	Auf den gelesenen Seiten nicht festgelegt	Benannte Identität mit begrenzten Rechten	Hoch, dass es nicht festgelegt ist
Welche Schwellenwerte gelten?	Über Marketingsprache hinaus nicht dokumentiert	Im Prozess konfigurierte Schwellenwerte	Mittel
Wo zeichnet ein Mensch gegen?	Approval Gating beim Deployment; „humans in the lead“ als Prinzip	Gegenzeichnung je Schritt und Rolle	Mittel
Wie wird eine falsche Entscheidung erkannt?	Observability und Agent Mining für technisches Versagen und Abweichung	Ergebnisbasierte Prüfungen für konforme Fehler	Hoch
Wie wird sie zurückgenommen?	„Reversible“ behauptet	Rücknahme je Schritt definiert und getestet	Hoch, dass es nicht definiert ist

Anhang: Methodik

Art der Untersuchung. Dokumentationsbasierte Lückenanalyse. Das Raster der vier Fragen stammt aus einem früheren Artikel auf dieser Seite; die Belege sind veröffentlichte Materialien von SAP selbst, diesem Raster gegenübergestellt.

Quellen und wie sie gelesen wurden. Vier SAP-Webseiten und drei Lektionen des SAP-Learning-Kurses „Introducing Joule“ wurden am 14. September 2026 geöffnet und vollständig gelesen. Mehrere sap.com-Seiten verweigern den automatisierten Abruf, deshalb wurden die sap.com-Seiten im Browser gelesen. Zitate sind wörtlich. Der Lernkurs gehört zu den Learning Journeys „Positioning the Autonomous Enterprise“ von SAP, einschließlich Varianten für Partner-Presales und -Vertrieb, und ist als Positionierungsmaterial mit mehr technischem Detail als die Produktseiten zu lesen, nicht als Produktdokumentation.

Angewandte Frameworks. SCQA für die Rahmung. Eine Zuordnung von Fähigkeiten zu Fragen für die Analyse, auf Basis der vier Fragen aus dem früheren Artikel.

Geprüfte, aber nicht angewandte Frameworks. Porter’s Five Forces und BCG-Matrix: Es geht nicht um Branchenstruktur oder Portfolio. Value Chain: Die Analyse betrifft Kontrollpunkte, nicht die Kostenstruktur. PESTEL: Der regulatorische Kontext zählt, aber die Frage ist operativ. Technology Adoption Curve: Belastbare Daten zu Praktiken der Agent-Autorisierung lagen nicht vor, und eine konstruierte Kurve hätte eine Schätzung als Beleg ausgegeben.

Belegstatus, klar benannt.

Belegt aus direkt gelesenem SAP-Material. Die Betriebsarten, die Aussage zu geerbten Rechten, die Fähigkeiten des Agent Hub, die Beschreibung der Konformität und die Aussage „reversible“.
Befunde zur Abwesenheit. Aussagen, dass etwas nicht beschrieben ist, beziehen sich auf die für diesen Artikel gelesenen Seiten. Weitere SAP-Produktdokumentation kann diese Punkte behandeln; wer Zugang dazu hat, sollte das prüfen.
Erfahrung, nicht belegt. Die Rollenbreite in lange gewachsenen SAP-Landschaften und die Prüfungshistorie technischer User. An den jeweiligen Stellen gekennzeichnet und als Argument angeboten, nicht als Beleg.

Konfidenz. Hoch für die Befunde 1, 3 und 4, die auf wörtlichen SAP-Aussagen beruhen. Mittel bis hoch für die Befunde 2 und 5, die Befunde zur Abwesenheit sind und deshalb durch das gelesene Material begrenzt werden.

Einschränkungen.

Produktseiten und Lernlektionen beschreiben Absicht und Positionierung. Konfigurationsleitfäden, die nicht gelesen wurden, können Schwellenwerte, Identitäten und Rücknahme genauer definieren.
SAP stellt fest, dass die Verfügbarkeit „spans general release, early access, and planned releases across 2026.“ Einige beschriebene Fähigkeiten sind möglicherweise noch nicht nutzbar.
Keine Kundenimplementierung wurde untersucht. Die Analyse betrifft, was dokumentiert ist, nicht was im Einsatz ist.

Was nicht beantwortet werden konnte. Das Identitätsmodell für system-getriggerte Agents und die Frage, ob Schwellenwerte je Aktion in der Agent-Schicht konfigurierbar sind oder nur im Workflow der darunterliegenden Anwendung.

Anlass zur Aktualisierung. Neu prüfen, wenn SAP Konfigurationsdokumentation zu Agent-Autorisierung oder Identität veröffentlicht oder wenn die ersten unabhängigen Implementierungsberichte erscheinen.

Häufige Fragen

Macht das Erben von User-Rechten die SAP-Agents unsicher?

Nein. Es ist ein solides Designprinzip, weil es verhindert, dass Agents mehr dürfen als ein User. Das Argument lautet, dass es die Kontrolle in das Rollenkonzept verlagert, das dann für diesen Zweck taugen muss.

Reicht SAP AI Agent Hub für die Agent-Governance?

Er deckt Inventar, Verifikation, Tool-Zugriff und Observability ab, und das ist notwendig. Schwellenwerte oder Gegenzeichnungen einzelner Agent-Entscheidungen deckt er nach der gelesenen Dokumentation nicht ab. Diese gehören in den Prozess.

Was sollten wir SAP fragen, bevor wir Hintergrund-Agents aktivieren?

Unter welcher Identität ein system-getriggerter Agent läuft, wie diese Identität bereitgestellt und geprüft wird und ob sich Schwellenwerte je Aktion durchsetzen lassen. Verlangen Sie die Antwort in der Dokumentation, nicht in einer Präsentation.

Erkennt Agent Mining falsche Entscheidungen?

Es erkennt Abweichungen vom entworfenen Pfad. Eine Entscheidung, die dem Pfad folgt und trotzdem ein falsches Geschäftsergebnis erzeugt, ist konform und wird nicht markiert.

Warum wurde die Technology Adoption Curve nicht verwendet?

Weil keine belastbaren Daten dazu vorlagen, wie Organisationen Agents autorisieren. Den Markt auf einer Kurve zu verorten hätte bedeutet, eine Schätzung als Beleg auszugeben.

Welche Teile sind Beleg und welche Erfahrung?

Die Aussagen von SAP sind wörtlich aus direkt gelesenem Material zitiert. Beobachtungen zur Rollenbreite und zu technischen Usern stammen aus der Praxis und sind als solche gekennzeichnet.

Wir haben einen ausgereiften GRC-Prozess für SAP-Rollen. Sind wir abgedeckt?

Möglicherweise, wenn sich die Prüfkriterien ändern. Ein Rollen-Review, das fragt, ob eine Person eine Berechtigung braucht, ist ein anderer Test als einer, der fragt, ob ein Agent, der für diese Person handelt, sie ohne Rückfrage nutzen darf.

Quellen

SAP, „Joule Agents and Joule Assistants“, https://www.sap.com/products/artificial-intelligence/ai-agents.html, abgerufen am 14. September 2026.
SAP, „SAP AI Agent Hub“, https://www.sap.com/products/artificial-intelligence/ai-agent-hub.html, abgerufen am 14. September 2026.
SAP Learning, „Introducing Joule“, Lektion „Discovering Joule“, https://learning.sap.com/courses/introducing-joule/discovering-joule_e055e58d-18c3-48fd-9137-80a96e4431e7, abgerufen am 14. September 2026.
SAP Learning, „Introducing Joule“, Lektion „Getting to Know Joule Agents“, https://learning.sap.com/courses/introducing-joule/getting-to-know-joule-agents_f9d18ca0-1021-4c1a-a044-4c00ec8c2898, abgerufen am 14. September 2026.
SAP Learning, „Introducing Joule“, Lektion „Getting to Know AI Assistants in Joule“, https://learning.sap.com/courses/introducing-joule/getting-to-know-ai-assistants-in-joule_f6252c97-c6fd-46e9-b0c5-2467efd1f1c9, abgerufen am 14. September 2026.
SAP, „The Autonomous Enterprise“, https://www.sap.com/products/business-suite.html, abgerufen am 14. September 2026.
SAP, „Spend Management Software Solutions“, https://www.sap.com/india/products/spend-management.html, abgerufen am 14. September 2026.
Sascha Theismann, „Welche Prozessschritte darf Ihr Agent auslösen?“, https://saschatheismann.de/welche-prozessschritte-darf-ihr-agent-ausloesen/, September 2026.