Wie KI-Agenten sicher in SAP schreiben

Viele KI-Projekte rund um SAP beginnen mit Lesezugriffen. Ein Agent fragt Auftragsstatus, offene Posten oder Liefertermine ab und fasst sie zusammen. Geht dabei etwas schief, ist die Antwort falsch. Im System selbst hat sich nichts verändert.

Beim Schreiben sieht das anders aus. Ein angelegter Kundenauftrag stößt Folgeprozesse an, von der Bedarfsplanung über die Lieferung bis zur Faktura. Ein falscher Preis landet auf der Rechnung, ein doppelter Auftrag im Lager. Einem Sprachmodell eine Schnittstelle zu geben und auf gute Ergebnisse zu hoffen, reicht dafür nicht.

Technisch ruft ein KI-Agent ein Tool auf, also eine Funktion mit Parametern. Welche Funktion mit welchen Werten aufgerufen wird, entscheidet das Modell. Für eine Websuche genügt das.

Bei einer Buchung in SAP fehlt dagegen fast alles, was eine Enterprise-Transaktion ausmacht. Wer handelt hier, und mit welchen Rechten? Wer hat geprüft, ob die Aktion erlaubt ist? Was passiert, wenn derselbe Aufruf zweimal ankommt? Wie lässt sich in einem Jahr nachvollziehen, warum der Auftrag genau so angelegt wurde?

Diese Fragen sollte kein Sprachmodell beantworten müssen. Sie gehören in eine Schicht zwischen Agent und SAP, die nach festen Regeln arbeitet. In voluro Nexus ist das die Ausführungsschicht: Über Governance entscheidet nicht das Sprachmodell, sondern Nexus. Die folgenden Bausteine zeigen, woraus diese Schicht besteht.

Ein Agent arbeitet in SAP nie mit einem Sammel- oder Administratorkonto. Er bekommt eine eigene technische Identität mit Rollen, die zu seiner Aufgabe passen. Ein Order-Agent darf zum Beispiel Kundenaufträge anlegen und Kundenstammdaten lesen, aber keine Konditionen pflegen. Das SAP-Berechtigungskonzept bleibt wirksam.

Vor jeder Aktion prüft Nexus zusätzlich, ob der Agent dieses Tool in diesem System für diesen Vorgang nutzen darf. Diese Policy-Prüfung läuft außerhalb des Sprachmodells. Auch ein geschickt formulierter Prompt ändert an ihrem Ergebnis nichts.

Verbindungen brechen ab, Timeouts lösen Wiederholungen aus, ein Agent setzt nach einem Fehler neu an. Ohne Schutz entsteht dabei schnell ein zweiter Auftrag für denselben Vorgang.

Schreibende Aktionen tragen in Nexus deshalb einen eindeutigen Vorgangsschlüssel. Kommt derselbe Aufruf erneut an, erkennt Nexus ihn und führt ihn nicht ein zweites Mal aus. Für den Agent sieht das aus wie ein erfolgreicher Aufruf, in SAP gibt es trotzdem nur einen Beleg.

Ein Agent-Tool wie erp.salesOrder.create ist Software und wird wie Software behandelt. Tools, Policies und Agent-Deployments sind in Nexus versioniert, ein produktives Deployment lässt sich nicht nachträglich verändern. Änderungen laufen über DEV, TEST und PROD, ähnlich wie SAP-Teams es von ihren Transporten kennen.

Das hat einen praktischen Nutzen: Fällt im Betrieb ein Vorgang auf, lässt sich der Run mit genau der Version von Agent, Tool und Policy nachstellen, die damals aktiv war.

Jeder Schritt wird protokolliert: welcher Agent in welcher Version, mit welchen Eingaben, welche Policy-Entscheidung, wer freigegeben hat und was SAP zurückgemeldet hat. Sensible Inhalte lassen sich in Ausgaben und Logs schwärzen. Für Revision und interne Kontrolle ist eine Buchung durch einen Agent damit so nachvollziehbar wie eine Buchung durch einen Mitarbeiter.

SAP-Systeme sind aus gutem Grund meist nicht aus dem Internet erreichbar. Damit ein Agent trotzdem mit ihnen arbeiten kann, läuft ein kleiner Relay-Dienst im Netzwerk des Unternehmens. Er baut nur ausgehende Verbindungen auf und braucht keinen eingehenden Port. Aufrufe leitet er nur an Zielsysteme weiter, die auf seiner lokalen Allowlist stehen.

Für SAP S/4HANA gilt das Prinzip Clean Core: Erweiterungen sollen den Standard nicht verändern. Agents passen gut dazu, solange sie über freigegebene Schnittstellen arbeiten.

Nexus liest die Metadaten vorhandener OData-Services aus, also Entity Sets, Actions und Function Imports, dazu eigene Custom APIs. Daraus entstehen kontrollierte Agent-Tools. Bestehendes Customizing und eigene Services werden weitergenutzt, am SAP-Kern muss nichts modifiziert werden.

Bevor ein Agent in SAP produktiv schreibt, sollten diese Punkte geklärt sein:

• Agent-Identität: eigener technischer Benutzer je Agent, Rollen nach dem Minimalprinzip, kein Sammelkonto.
• Policy-Prüfung: Berechtigungen und Regeln werden vor jeder Aktion außerhalb des Sprachmodells geprüft.
• Autonomie-Regeln: Für jede schreibende Aktion ist festgelegt, wann sie automatisch läuft, eine Freigabe braucht oder gestoppt wird.
• Idempotenz: Wiederholte Aufrufe erzeugen keine doppelten Belege.
• Versionierung: Tools, Policies und Deployments sind versioniert und durchlaufen DEV, TEST und PROD.
• Audit Trail: Agent, Version, Eingaben, Entscheidung, Freigabe und Systemantwort sind protokolliert.
• Netzwerk: Zugriff über ausgehende Verbindungen und eine Allowlist der Zielsysteme, kein offener Port.
• Clean Core: Zugriff über OData-Services und freigegebene APIs, keine Modifikationen.