Ein AI-Agent, der in SAP arbeiten kann, wirkt zunächst wie eine Produktivitätschance: Er liest eine Rechnung, prüft eine Bestellung, klärt eine Ausnahme und bereitet den nächsten Schritt vor. In Finanzwesen, Beschaffung und ERP-Betrieb liegt jedoch genau darin das Risiko, dass eine scheinbar nützliche Automatisierung zum Problem der internen Kontrolle wird.
Viele Unternehmen behandeln den Zugriff eines Agenten als Frage von Identität und Berechtigungen. Sie fragen, ob der Agent Leserechte erhalten soll, ob er einen technischen Benutzer verwenden muss und ob eine Führungskraft sein Deployment freigeben soll. Diese Fragen sind wichtig, beantworten aber nicht die entscheidende Frage für den Produktivbetrieb: Welche unvereinbaren Geschäftsaktionen kann dieser Agent innerhalb eines einzelnen Workflows miteinander verbinden?
Ein Agent braucht keinen uneingeschränkten Administratorzugriff, um einen schwerwiegenden Kontrollfehler zu verursachen. Er kann über mehrere klar begrenzte Tools arbeiten, freigegebene Schnittstellen aufrufen und dennoch eine riskante Kette zusammensetzen: Lieferanteninformationen anlegen oder ändern, Zahlungsdaten ändern, eine Rechnungsabweichung bereinigen und eine Zahlungsanforderung einreichen. Kann ein automatisiertes System diese Schritte ohne Unterbrechung durchlaufen, hebt es faktisch Aufgaben auf, die das Unternehmen bewusst auf verschiedene Personen verteilt hat.
Deshalb braucht ein AI-Agent eine Funktionstrennungsmatrix, bevor er SAP anfasst. Die Matrix ist keine Dokumentation, die nach dem Deployment erstellt wird. Sie ist die Entwurfsbedingung, die festlegt, was der Agent tun darf, was er empfehlen darf, an welcher Stelle eine menschliche Entscheidung zwingend erforderlich ist und welche Nachweise jede Ausnahme überdauern müssen.
Warum herkömmliche Zugriffskontrollen nicht ausreichen
Das klassische Berechtigungsdesign in SAP befasst sich in der Regel damit, ob ein Benutzer eine Transaktion ausführen, einen Datensatz ändern oder auf ein Datenobjekt zugreifen darf. Funktionstrennung stellt eine andere Frage: Was wird möglich, wenn diese Berechtigungen kombiniert werden?
Mit agentischer AI wird dieser Unterschied noch deutlicher. Ein menschlicher Benutzer arbeitet normalerweise in einer definierten Rolle, innerhalb eines erwartbaren Geschäftskontexts und trifft während eines Arbeitstags nur eine begrenzte Zahl von Entscheidungen. Ein Agent kann sich systemübergreifend bewegen, unstrukturierte Dokumente interpretieren, Kontext aus einer Wissensdatenbank abrufen und Tools nacheinander aufrufen. Seine tatsächliche Fähigkeit ergibt sich daher nicht allein aus der Liste der seiner Identität zugeordneten Berechtigungen. Entscheidend ist die kombinierte Wirkung seiner Tools, Anweisungen, Datenzugriffe, Eskalationsregeln und seiner Fähigkeit, den nächsten Schritt einzuleiten.
Betrachten wir einen Beschaffungs-Agenten, der bei der Verarbeitung einer Rechnung feststellt, dass ein Lieferantenstammsatz fehlt. Ihm die Möglichkeit zu geben, einen Lieferanten anzulegen, kann sinnvoll erscheinen. Ihm zu erlauben, Bankdaten aus einer Rechnung zu extrahieren und in Stammdaten zu schreiben, wirkt wie der logische nächste Schritt. Wenn er die Rechnung anschließend einer Bestellung zuordnen und zur Zahlung weiterleiten darf, scheint das effizient. Die gesamte Kette schafft jedoch einen Weg über Lieferantenanlage, Änderung von Bankdaten und Zahlungsabwicklung, den eine gut organisierte Finanzfunktion niemals einer einzelnen Person übertragen würde.
Das Problem besteht nicht darin, dass der Agent böswillig handelt. Das Problem ist, dass das Betriebsmodell den unabhängigen Punkt der Kontrolle entfernt hat. Eine schlechte Anweisung, ein manipuliertes Dokument, eine ungenaue Extraktion oder ein falsch abgerufener Datensatz können sehr viel weiter wirken, wenn dasselbe System sowohl die Bedingung schaffen als auch darauf reagieren kann.
Behandeln Sie den Agenten als Rolle mit einem Workflow, nicht als clevere Oberfläche
Der praktische Ausgangspunkt besteht darin, jeden geplanten Agenten nach derselben Kontrolllogik abzubilden wie eine Geschäftsrolle. Beginnen Sie nicht mit einer allgemeinen Frage wie: „Welchen SAP-Zugriff braucht der Agent?“ Beginnen Sie mit den Geschäftsergebnissen, die er beeinflussen darf.
Beobachtung und Aktion trennen. Ein Agent darf beispielsweise einen Lieferantenstammsatz lesen, feststellen, dass sich ein Bankkonto von der jüngsten Rechnung unterscheidet, und eine Änderung vorschlagen. Das bedeutet nicht, dass er diese Änderung auch verbindlich vornehmen sollte. Lesen, analysieren und empfehlen sind materiell andere Berechtigungen als anlegen, ändern, freigeben und ausführen. Sie müssen entsprechend gestaltet und durch Governance abgesichert werden.
Diese Unterscheidung ist besonders wichtig, weil Natural-Language-Oberflächen die tatsächlich ausgeführte Aktion verschleiern können. Ein Kollege könnte einen Agenten bitten, „dieses Lieferantenproblem zu bereinigen“. Hinter dieser Anfrage stehen mehrere mögliche Systemänderungen. Der Agent darf aus einer weit gefassten Geschäftsanweisung nicht ableiten, dass er zur Durchführung sämtlicher nachgelagerter Schritte autorisiert ist. Seine Tool-Ebene muss die Grenze durchsetzen, selbst wenn die Anweisung im Gespräch unpräzise ist.
Definieren Sie verbotene Kombinationen, nicht nur erlaubte Aktionen. Eine hilfreiche agentenspezifische Matrix benennt die Kombinationen, die innerhalb einer automatisierten Kette niemals verfügbar sein dürfen. Im Finanzkontext betrifft das häufig Kombinationen aus Stammdatenpflege, Rechnungsbearbeitung, Freigabe, Zahlungsfreigabe und Abstimmung. In der Beschaffung kann es Lieferanten-Onboarding, Änderungen an Bestellungen, Bestätigung von Wareneingängen und Rechnungsfreigabe betreffen.
Die relevante Analyseeinheit ist der Workflow-Pfad. Ein Agent mit separaten Tools für jeden Schritt kann dennoch einen Konflikt erzeugen, wenn seine Orchestrierungsebene diese Tools ohne unabhängige Autorisierung nacheinander aufrufen kann. Technische Modularität ist keine Funktionstrennung.
Ordnen Sie die menschliche Rolle der Entscheidung zu, nicht bloß dem Klick auf einen Button. Ein schwaches Design lässt eine Führungskraft eine Aktion freigeben, nachdem der Agent bereits alle wesentlichen Entscheidungen getroffen hat. Ein stärkeres Design bestimmt den Punkt, an dem geschäftliches Urteilsvermögen erforderlich ist, und stellt sicher, dass die verantwortliche Person ausreichend Kontext erhält, um dieses Urteil auszuüben.
Ein Agent kann beispielsweise Dokumente zusammenstellen, nicht übereinstimmende Felder erkennen, die Ausnahme klassifizieren und einen empfohlenen Weg entwerfen. Die freigebende Person sollte die relevanten Nachweise, die vorgeschlagenen Systemänderungen, die Begründung der Empfehlung und alle nicht erfüllten Richtlinienbedingungen sehen. Ein Freigabebildschirm, der lediglich sagt: „AI empfiehlt Freigabe“, stellt keine Kontrolle wieder her. Er macht den Menschen nur zum Abnicker.
Übersetzen Sie die bestehende Matrix in Aktionsgrenzen für Agenten
Die meisten etablierten Unternehmen verfügen bereits über irgendeine Form eines Frameworks zur Funktionstrennung, sei es in SAP-Rollen, Dokumentationen interner Kontrollen, Audit-Arbeitspapieren oder Finanzrichtlinien. Die Aufgabe besteht nicht darin, diese Arbeit durch ein AI-Governance-Deck zu ersetzen. Sie besteht darin, sie in maschinell durchsetzbares Verhalten zu übersetzen.
Beginnen Sie damit, den vorgesehenen Geschäftsbereich des Agenten zu bestimmen. Ein eng abgegrenzter Kreditoren-Agent, ein Lieferanten-Onboarding-Agent und ein Cash-Management-Agent sollten nicht als ein breiter „Finanzassistent“ konzipiert werden. Jeder hat andere sensible Aktionen, Datenabhängigkeiten und Eskalationsanforderungen. Sie unter einer Agentenidentität zusammenzufassen, mag für ein Plattformteam bequem sein, erschwert jedoch die Pflege eines sauberen Kontrollmodells erheblich.
Ordnen Sie anschließend jedes Tool, das der Agent aufrufen kann, einer Kategorie von Geschäftsaktionen zu. Ein Tool, das Lieferantenstammdaten aktualisiert, ist nicht nur ein API-Aufruf, sondern eine Fähigkeit zur Stammdatenänderung. Ein Tool, das einen Zahlungslauf einreicht, ist nicht bloß eine Workflow-Integration, sondern eine Fähigkeit zur Zahlungsauslösung. Diese Übersetzung verhindert, dass technische Sprache eine wesentliche Kontrollentscheidung verdeckt.
Definieren Sie dann für jede Aktion drei mögliche Ergebnisse. Der Agent darf die Aktion autonom ausführen, wenn sie risikoarm und richtlinienkonform ist. Er darf die Aktion vorbereiten, benötigt jedoch eine Freigabe, bevor sie verbindlich umgesetzt wird. Oder es ist ihm vollständig untersagt, die Aktion auszuführen, selbst wenn er das Problem erkennen kann. Die dritte Kategorie ist unverzichtbar. Ohne sie behandeln Teams Eskalationen häufig als vorübergehende Unannehmlichkeit statt als dauerhafte Kontrollgrenze.
Eine Änderung von Lieferantenbankdaten ist ein gutes Beispiel. Der Agent darf eine Anfrage erkennen, relevante Informationen extrahieren und prüfen, ob die erforderlichen Belege vorhanden sind. Er darf nicht entscheiden, dass die Belege ausreichen, die Bankdaten ändern und anschließend einen Zahlungs-Workflow vorantreiben. Darf er den Datensatz vorbereiten, muss die vorgeschlagene Änderung vom freigegebenen Stammdatensatz getrennt bleiben, bis eine ausreichend unabhängige Rolle sie autorisiert.
Bauen Sie Freigaben in die Workflow-Architektur ein
Eine Freigabe darf kein allgemeiner Auffangmechanismus sein, der am Ende eines Agenten-Workflows platziert wird. Sie muss durch die Art der Aktion, die Kombination der versuchten Aktionen sowie die Verlässlichkeit oder Vollständigkeit der verfügbaren Nachweise ausgelöst werden.
Ein Agent sollte an eine harte Grenze stoßen, sobald er eine verbotene Kombination erreicht. Er darf diese Grenze nicht umgehen können, indem er eine Tool-Anfrage anders formuliert, ein benachbartes System aufruft oder Arbeit an einen anderen Agenten mit denselben tatsächlichen Berechtigungen übergibt. Hier entscheidet die Architektur. Getrennte Service-Identitäten, klar abgegrenzte Tool-Berechtigungen, explizite Statusübergänge und zentral durchgesetzte Richtlinien sind verlässlicher als Anweisungen, die nur in einem Prompt hinterlegt sind.
Nutzen Sie Policy-Entscheidungen außerhalb des Modells. Das Sprachmodell kann Dokumente interpretieren, eine Anfrage klassifizieren und einen nächsten Schritt vorschlagen. Es sollte jedoch nicht die letzte Instanz dafür sein, ob eine sensible Aktion zulässig ist. Diese Entscheidung gehört in deterministische Policy-Logik, die mit dem Kontrollmodell des Unternehmens verknüpft ist.
Eine Policy-Ebene kann beispielsweise festlegen, dass eine bestimmte Kombination aus Änderung von Lieferantendaten und zahlungsbezogener Aktion eine separate menschliche Freigabe erfordert. Das Modell kann erklären, warum der Fall eskaliert wurde, darf die Regel jedoch nicht außer Kraft setzen, weil es die Anfrage für dringend oder gut belegt hält. Diese Trennung schützt vor Modellfehlern, Prompt Injection und inkonsistentem Schlussfolgern.
Bewahren Sie die Nachweiskette. Wenn ein Agent eine Aktion ausführt oder empfiehlt, muss das Unternehmen nachvollziehen können, was geschehen ist. Der Datensatz sollte die auslösende Anfrage, die vom Agenten verwendeten Informationen, berücksichtigte Dokumente oder Systemdatensätze, aufgerufene Tools, vorgeschlagene Änderungen, durchgeführte Policy-Prüfungen, eingeholte Freigaben und das Endergebnis zeigen.
Dafür müssen nicht alle internen Gedankengänge des Modells gespeichert werden. Erforderlich ist jedoch ein operativer Nachweis, der Finanzwesen, Interner Revision und IT ermöglicht, den Entscheidungsweg zu verstehen. Hat ein Agent eine Lieferantenrichtlinie abgerufen, Rechnungsfelder verglichen und einen Ausnahmeprozess ausgelöst, sollten diese Ereignisse in einer Nachweiskette sichtbar sein, die mit der Geschäftstransaktion verknüpft ist.
Ausnahmen zeigen, ob das Kontrollmodell trägt
Die vollautomatische Verarbeitung ist meist der einfache Teil. Schwieriger sind unvollständige Dokumente, widersprüchliche Lieferantendaten, dringende Zahlungsanfragen, fehlende Bestellungen und Anweisungen, die per E-Mail oder Chat mit unklarer Autorität eintreffen.
Ein Agent darf Unklarheit nicht dadurch lösen, dass er seine eigene Autorität ausweitet. Sein Ausnahmedesign sollte benennen, welche Informationen fehlen, welche Kontrollbedingung nicht erfüllt ist, wer die Entscheidung verantwortet und welche Aktionen bis zur Klärung nicht verfügbar bleiben. Das ist besonders im Mittelstand wichtig, wo erfahrene Mitarbeitende im Finanzwesen häufig relevantes Prozesswissen besitzen, das nie vollständig formalisiert wurde.
Die Versuchung besteht darin, dem Agenten weitergehende Rechte zu geben, weil Ausnahmefälle manuelle Arbeit verursachen. Das spart kurzfristig Aufwand, macht das Betriebsmodell aber weniger vertretbar. Besser ist es, frühe Deployments zu nutzen, um unklare Richtlinien, fehlende Verantwortlichkeiten für Freigaben und wiederkehrende Prozessausnahmen sichtbar zu machen. Diese Erkenntnisse verbessern sowohl den Workflow als auch den zugrunde liegenden Geschäftsprozess.
Produktionsreife heißt, die Grenzen nachzuweisen
Bevor Sie einen Agenten mit produktiven SAP-Prozessen verbinden, testen Sie seine Fähigkeit, eine Aktion abzulehnen. Teams prüfen häufig, ob ein Agent den Idealablauf abschließen kann. Sie sollten ebenso prüfen, ob er stoppt, wenn er aufgefordert wird, widersprüchliche Aktionen zu kombinieren, wenn ein Benutzer eine Ausnahmegenehmigung verlangt, wenn Eingaben unvollständig belegt sind oder wenn ein anderes Tool einen indirekten Weg um eine Beschränkung anbietet.
Der Maßstab sollte eindeutig sein: Ein Agent ist nicht produktionsreif, wenn er die meisten Schritte automatisieren kann, sondern wenn seine Aktionsgrenzen auch unter unübersichtlichen, realistischen Betriebsbedingungen zuverlässig bestehen bleiben.
Für DACH-Unternehmen liegt der Wert dieser Disziplin nicht allein darin, einen Kontrollvorfall zu vermeiden. Sie schafft einen glaubwürdigen Weg von isolierten AI-Experimenten zu geschäftskritischen Use Cases. Finanzverantwortliche können Automatisierung unterstützen, wenn klar erkennbar ist, wer rechenschaftspflichtig bleibt. Die IT kann das System betreiben, wenn Berechtigungen und die Durchsetzung von Richtlinien explizit sind. Verantwortliche für interne Kontrollen können es bewerten, wenn Nachweise von Anfang an verfügbar sind, statt im Nachhinein zusammengesucht zu werden.
Ein AI-Agent sollte einen kontrollierten Prozess beschleunigen, nicht ihn stillschweigend neu gestalten.
Ein Diagnostic gleicht Ihre geplanten AI-Agent-Workflows mit bestehenden ERP-Kontrollen ab, identifiziert unvereinbare Aktionsketten und definiert das Freigabe- und Nachweismodell, das erforderlich ist, bevor Produktivzugriff vermeidbare Risiken schafft.
Kontextnotiz: Dieser Artikel basiert auf praktischen Prinzipien der internen Kontrolle und des AI-Systemdesigns; externe Quellen wurden nicht zitiert.