KI-Agenten-Governance: Warum Agentic Orchestration eine kontrollierte Integrationsschicht braucht

Ein KI-Agent sollte vorschlagen, eine Integrationsschicht sollte entscheiden, was tatsächlich ausgeführt wird. Bei einer Migration auf SAP S/4HANA liefen 180 Schnittstellen über eine einzige Integrationsschicht: ein Ort, an dem Validierung, Berechtigungen und Protokollierung durchgesetzt werden, statt 180. 

 

Bis vor Kurzem bedeutete KI in den meisten Unternehmen ein Chatfenster. Jemand fragte, das Modell antwortete, und ein Mensch entschied, was mit der Antwort passiert. Das ändert sich gerade. Agenten beginnen, selbst Aufträge anzulegen, Meldungen vorzubereiten und Datensätze zu ändern, und jede dieser Aktionen landet in einem System, von dem andere Prozesse abhängen. Die Frage ist nicht mehr, was ein Agent weiß. Sondern was er tun darf und wer das prüft. 

Governance für KI-Agenten ist vor allem eine Integrationsfrage, keine Modellfrage. Sie legt fest, welche Geschäftssysteme ein Agent erreichen darf, welche Daten er senden darf und welche Schritte eine Freigabe durch einen Menschen brauchen. Diese Regeln gehören in die Integrationsschicht, nicht in den Prompt des Agenten. Einen Prompt kann ein Modell ignorieren. Eine Validierungsregel nicht. 

 

Ein Agent auf Basis eines großen Sprachmodells liest eine Anfrage, plant und erstellt einen Vorschlag: eine Auftragsänderung, eine Meldung an eine Behörde, ein Mapping zwischen zwei Datenformaten. Die Integrationsschicht kommuniziert über REST, SOAP, OData, RFC, IDoc oder Dateiübertragung mit der ERP-Plattform, dem Produktionsleitsystem oder der Behördenschnittstelle und führt den eigentlichen Datenaustausch durch. 

 

Der Agent darf alles vorschlagen. Die Integrationsschicht führt nur aus, was die Prüfung besteht.

KI-Agenten sollten nicht direkt in Unternehmenssysteme schreiben, da ein Sprachmodell eine Ausgabe liefern kann, die zwar richtig aussieht, aber dennoch fehlerhaft ist: ein fehlendes Pflichtfeld, ein nicht existierender Einheitencode, ein vom Modell erfundenes Attribut. Bei einer direkten Verbindung erhält das Zielsystem diese Ausgabe ungeprüft. 

 

Strenge Schnittstellen machen das Problem schnell sichtbar. Ein SOAP-Endpunkt mit einem festen XML-Schema lehnt die Anfrage ab – und das ist noch der günstige Fall. Der ungünstige Fall ist eine Schnittstelle, die den falschen Wert akzeptiert und verarbeitet. 

 

Ein Fall aus unserer eigenen Arbeit veranschaulicht dieses Muster, ohne dass ein Sprachmodell beteiligt war. Für einen Kunden haben wir die ABBYY FineReader Engine in einen Scheer PAS-Dienst integriert, um gescannte Änderungsprotokolle zu lesen. Die meisten Seiten wurden einwandfrei verarbeitet. Bei gelochten Seiten war dies jedoch nicht der Fall: Die OCR-Engine interpretierte einige Lochungen als Minuszeichen, wodurch ein positiver Wert in einen negativen umgewandelt wurde. Formal gesehen war das Ergebnis eine gültige Zahl. Inhaltlich war es jedoch falsch. Eine Überprüfung mittels regulärer Ausdrücke im Dienst kennzeichnete Werte, die nicht dem erwarteten Muster entsprachen, woraufhin ein manueller Validierungsschritt folgte, bevor irgendetwas das Zielsystem erreichte. 

 

Ein KI-Agent versagt auf dieselbe Weise, nur weniger vorhersehbar. Seine Ausgabe sieht gültig aus und kann dennoch falsch sein; daher benötigt er dieselben zwei Ebenen: zunächst eine automatische Überprüfung und anschließend eine Person für die Fälle, die die Überprüfung nicht klären kann. 

 

Zwei weitere Probleme sind schwerer zu erkennen. Ein Agent sieht eine einzelne Anfrage, nicht die Systeme, die von derselben Datenstruktur abhängen. Eine Änderung, die lokal aussieht, kann deshalb mehrere Systeme gleichzeitig stören. Und ein Modell behandelt einen Testaufruf genauso wie einen Schreibzugriff auf das Produktivsystem, solange nichts um es herum den Unterschied erzwingt. 

 

Der Agent plant. Die Integrationsschicht führt aus.

Der Agent schreibt nie selbst in ein Zielsystem. Die Integrationsschicht validiert jeden Vorschlag, gibt abgelehnte oder markierte Anfragen an den Agenten zurück, holt wo nötig die Freigabe einer Person ein und protokolliert jeden Schritt. 

In Scheer PAS ergibt sich diese Kontrolle daraus, wo der Agent angesiedelt ist. Agenten werden mit PAS Code gebaut, der Entwicklungsumgebung der Plattform, und jeder Agent ist ein Feature eines Service. Er hat keinen eigenen Endpunkt und kann nur über die Operationen handeln, die sein Service bereitstellt. Welche Operationen das sind, wie ihre Eingaben validiert werden und welche davon eine Freigabe durch eine Person brauchen, ist im Code des Service festgelegt, nicht im Prompt des Agenten. Dieser Code wird gegen eine freigegebene Spezifikation geschrieben und vor dem Merge geprüft. Was ein Agent ausführen darf, entscheidet also das Team, im Voraus und an einer Stelle. 

Nichts in dieser Tabelle ist neu. Integrationsteams nutzen seit Jahren Validierung, Zuordnungen, Berechtigungen und zentrale Protokollierung für System-zu-System-Schnittstellen. Was sich ändert, ist der Aufrufer. 

Eine Freigabe durch einen Menschen gehört zu Agentenaktionen, die sich nicht rückgängig machen lassen, die Kunden oder Behörden direkt erreichen oder bei denen das Ergebnis des Agenten unsicher ist. Alles andere kann selbstständig laufen.

 

Daten lesen, einen Status abfragen und einen Wert schreiben, der die Validierung besteht und innerhalb seiner Grenzen bleibt, läuft automatisiert. Ein Wert ohne Treffer in der Mapping-Tabelle ist ein anderer Fall. Der Schritt hält an, sammelt seinen Kontext und übergibt an eine Person, die dann in einer Minute entscheiden kann, statt von vorn mit der Fehlersuche zu beginnen.

 

Freigabe im engeren Sinn gilt für eine kurze Liste von Operationen, etwa eine Meldung an eine Behörde, eine Änderung am Produktivsystem oder den Abschluss eines sensiblen Kundenfalls. Das sollte Human-in-the-Loop (HITL) in der Praxis bedeuten: Menschen prüfen die wenigen Schritte, bei denen eine falsche Aktion teuer ist, nicht jeden Schritt des Agenten.

 

Die Regel für jede Operation liegt in der Integrationsschicht. Nicht im Agenten.

Ein Audit-Log für Agentenaktionen hält pro Anfrage und mit Zeitstempel fest, wer sie gestartet hat, was hineinging, welche Regel gegriffen hat, wer freigegeben hat und was das Zielsystem geantwortet hat. Liegt all das in einer Integrationsschicht, verfolgt ein Team einen Prozess über fünf Systeme hinweg, statt fünf einzelne Backend-Logs zu vergleichen. 

 

Dieselben Daten speisen das Monitoring: fehlgeschlagene Schritte, ungewöhnliche Muster, offene Freigaben. 

 

Bei regulierten Prozessen ist das Log außerdem der Nachweis, dass eine automatisierte Aktion den festgelegten Regeln gefolgt ist. Ohne Log ist „Das war der Agent“ keine Antwort, die irgendjemand prüfen kann.

Vier Integrationsprojekte von Scheer PAS zeigen dieselben Guardrails im Einsatz, jedes aus einem anderen Grund. Keines dieser Projekte hat KI-Agenten eingesetzt. Sie zeigen, auf welchen Teil einer bestehenden Integrationsschicht ein Agent angewiesen wäre und was ohne ihn kaputtgeht. 

 

Behördenschnittstellen: Meldungen, die sich nicht einfach zurückziehen lassen.

 

Ein Automobilhersteller tauscht über eine SOAP-Schnittstelle Fahrzeugdaten mit dem Kraftfahrt-Bundesamt (KBA) aus. Auf dem Papier klingt das nach Routine. In der Praxis war die offizielle Spezifikation unvollständig, sodass die Integration iterativ gegen einen Endpunkt getestet werden musste, dessen Verhalten teilweise nicht dokumentiert war. Zugangsdaten laufen in einem festen Zyklus ab, und eine verpasste Erneuerung sperrt das Konto und stoppt die Zulassungen. Dann änderte die Behörde die Schnittstelle mit kurzer Umsetzungsfrist. Jede Meldung wird bei der Behörde erfasst, und eine falsche zu korrigieren ist ein Verwaltungsvorgang. Ein Agent, der hier Meldungen vorbereitet, bräuchte eine Schema-Prüfung und Zugangsdaten, auf die er selbst keinen Zugriff hat. 

 

SAP-Migration: Schnittstellenverträge über viele abhängige Systeme.

 

Als SAP ECC durch SAP S/4HANA ersetzt wurde, waren bereits 30 Schnittstellen in Scheer PAS gebaut, und die Systeme dahinter erwarteten, dass ihre Datenstrukturen gleich bleiben. Bei rund 80 % davon fingen Mappings und zusätzliche Systemanbindungen in der Integrationsschicht die Änderung ab. Ein Agent, der über diese Systeme hinweg arbeitet, stünde vor derselben Einschränkung, ohne sie zu sehen. 

 

ERP und Shopfloor: Parameter mit physischen Folgen.

 

Aufträge kommen als IDocs oder als CSV-Dateien per SFTP an, werden validiert und angereichert und durchlaufen eine Sequenzierungsbibliothek, bevor sie ein Produktionsleitsystem (PCS) erreichen. Während der Ablösung eines PCS liefen altes und neues System parallel, damit das Werk nicht stillstehen musste. Ein falscher Parameter oder eine Anweisung in falscher Reihenfolge kann eine Linie stoppen. 

 

Retail: Änderungen, die Kunden sofort sehen.

 

Hier liegt das Risiko in einer Änderung am Produktivsystem oder in einem Kundenfall, der nicht hätte abgeschlossen werden dürfen. Ein Agent braucht deshalb vor beidem Freigaberegeln. 

 

Nebeneinander betrachtet haben die vier Projekte eines gemeinsam. Keines setzt einen KI-Agenten ein, und jedes hat bereits die Schicht, die ein Agent bräuchte: definierte Schnittstellen, Mappings, Validierung und Protokollierung. Unterschiedlich ist der Grund, warum diese Prüfungen zählen. Eine behördlich erfasste Meldung, ein Schnittstellenvertrag, eine Produktionslinie und eine Änderung mit Kundenwirkung scheitern jeweils auf eigene Weise. Governance für KI-Agenten lässt sich deshalb nicht als generische Richtlinie einkaufen. Sie muss zu dem Prozess passen, den sie schützt. 

 

Für Unternehmen, die eine solche Schicht schon betreiben, ist Agentic Orchestration näher, als es aussieht. Für Unternehmen ohne eine solche Schicht ist sie der Ausgangspunkt, nicht der Agent. Ein später hinzugefügter Agent ändert, wer die Anfragen sendet. Er ändert nicht, was geprüft werden muss, bevor eine Anfrage ein System erreicht. 

 

Wo Sie anfangen sollten 

 

Halten Sie den ersten Schritt klein. Listen Sie die Operationen auf, die ein Agent ausführen soll, geben Sie ihm Lesezugriff plus eine Handvoll freigegebener Schreiboperationen und legen Sie für jede davon Validierung, Grenzwerte und Protokollierung in der Integrationsschicht fest. Die meisten Unternehmen betreiben die Schnittstellen, die ein Agent bräuchte, bereits. Die Arbeit liegt darin, zu entscheiden, was der Agent damit tun darf, und das als Regeln festzuhalten, die das System durchsetzt. 

Als wir die FineReader-Integration gebaut haben, stand die Prüfung der OCR-Ausgabe nie zur Debatte. Jeder wusste, dass ein Scanner eine Seite falsch lesen kann. Also lief jeder Wert durch eine Musterprüfung, und der Rest ging an eine Person. Bei Sprachmodellen scheint dieser Instinkt verloren zu gehen. Die Ausgabe liest sich gut, also fühlt sie sich richtig an. 

 

Ich glaube nicht, dass Agenten scheitern, weil die Modelle schlecht sind. Sie scheitern dort, wo Unternehmen sie an Geschäftssysteme anbinden, wie sie nie einen neuen Scanner anschließen würden: direkt, ohne etwas dazwischen. Die Integrationsarbeit, die viele von uns seit Jahren machen, ist genau das, was das verhindert. Sie hat jetzt nur einen neuen Aufrufer. 

 

Häufige Fragen 

 

Was ist Agentic Orchestration?

 

Die Koordination von Arbeit über mehrere Geschäftssysteme hinweg, bei der KI-Agenten die Schritte planen und eine Orchestrierungsschicht sie ausführt. Der Agent interpretiert die Anfrage, zum Beispiel indem er einen Vorfall einordnet oder eine Meldung vorbereitet. Die Orchestrierungs- und Integrationsschicht kommuniziert mit den Zielsystemen, wendet Validierung und Berechtigungen an und protokolliert jeden Schritt. 

 

Brauchen KI-Agenten eine eigene Integrationsplattform?

 

Meist nicht. Eine bestehende Integrationsplattform bringt Schnittstellen, Mappings, Berechtigungen, Protokollierung und Monitoring bereits mit. Wiederverwendbare Komponenten sorgen dafür, dass jeder Agent einen getesteten Baustein aufruft, statt eine eigene Backend-Verbindung zu bauen. Hinzukommen müssen Freigaberegeln und Parametergrenzen pro Operation, weil der Aufrufer jetzt ein Agent ist. 

 

Wer ist verantwortlich, wenn ein KI-Agent eine falsche Änderung macht?

 

Das Unternehmen, das den Agenten betreibt und seine Berechtigungen festlegt. Das Audit-Log zeigt, welcher Agent die Anfrage gestellt hat, welche Regeln gegriffen haben und wer freigegeben hat. So findet das Team die Regel, die die Änderung durchgelassen hat, und kann sie korrigieren. 

 

Über den Autor

Lukas Peter

ist Entwickler und technischer Consultant bei Scheer PAS. Er entwickelt Integrationsservices mit dem Scheer PAS Designer und PAS Code. Dazu gehören xUML- und BPMN-Servicemodelle, REST- und dateibasierte Adapter sowie Anbindungen an SAP-Datenquellen.