Kommentar von Karl Wibbecke, Deutsche Automatisierungsgesellschaft Vom Datenzugriff zur verantwortbaren Entscheidung

Ein KI-Agent darf Daten lesen, daraus aber nicht automatisch handeln. Ein belastbarer Rahmen prüft Kontext, Policy und Aktionsklasse, erzwingt Freigaben und sichert Abbruch sowie Wiederanlauf.

Ein KI-Agent kann auf aktuelle Auftrags-, Anlagen- oder Kundendaten zugreifen und dennoch eine falsche Aktion auslösen. Datenqualität beantwortet nur, ob ein Wert vollständig, aktuell und plausibel ist. Sie beantwortet nicht, ob das System in diesem Prozessschritt handeln darf. Dafür braucht der Agent zusätzlichen Kontext: den Status des Vorgangs, die Rolle des betroffenen Mitarbeiters, offene Freigaben, geltende Grenzwerte und die Folgen einer Änderung. Fehlt eine dieser Angaben, darf aus einer technisch möglichen Aktion keine automatische Ausführung werden.

Diese Trennung sollte sich in der Architektur wiederfinden. Das Sprachmodell oder ein anderes KI-Modell erzeugt eine Einschätzung und schlägt eine Aktion in einem festgelegten Schema vor. Eine separate, deterministische Policy-Schicht prüft anschließend Identität, Berechtigung, Prozesszustand, Wertebereich und Freigabebedarf. Erst wenn alle Regeln erfüllt sind, ruft ein kontrollierter Dienst das ERP-, Ticketsystem oder eine andere Fachanwendung auf. Das Modell erhält weder freie Zugangsdaten noch die Möglichkeit, die Prüfung zu umgehen.

Vor jedem Modellaufruf sollte außerdem feststehen, welche Daten für die konkrete Aufgabe nötig sind. Ein Agent, der eine Lieferabweichung einordnet, benötigt vielleicht Auftragsnummer, Solltermin, aktuellen Status und die letzte bestätigte Rückmeldung. Er braucht nicht automatisch den vollständigen Kundenstamm oder alle Vertragsdokumente. Eine Integrationsschicht kann Felder auswählen, Kennungen ersetzen und Anhänge sperren. So wird der Datenzugriff auf den Zweck begrenzt, bevor die eigentliche Entscheidung beginnt.

Kommentar von Nick Boyer, Conga

Wenn Angebotsprozesse zum Compliance-Risiko werden

Kontext-Policy und Aktionsklasse vor jeder Entscheidung prüfen

Damit die Policy nicht aus unübersichtlichen Einzelregeln besteht, hilft eine Einteilung in Aktionsklassen. Klasse eins umfasst reine Lese- und Vorbereitungsschritte, etwa das Zusammenfassen eines Vorgangs. Klasse zwei erlaubt reversible Änderungen in einem begrenzten Bereich, beispielsweise das Anlegen eines Entwurfs. Klasse drei betrifft wirksame Änderungen an Fristen, Mengen, Berechtigungen oder externen Nachrichten und benötigt eine menschliche Freigabe. Klasse vier umfasst Aktionen, deren Fehler erhebliche betriebliche, finanzielle oder rechtliche Folgen haben können. Sie bleiben außerhalb der autonomen Ausführung.

Die Einordnung gilt nicht pauschal für ein Werkzeug. Derselbe technische Aufruf kann je nach Objekt und Prozesszustand eine andere Wirkung haben. Das Ändern eines internen Notizfelds ist anders zu bewerten als die Änderung einer bestätigten Bestellmenge. Deshalb muss die Policy neben dem Werkzeug auch Objektart, Feld, Wert, vorherigen Zustand und auslösende Rolle prüfen. Die erlaubte Aktion wird als enges Schema beschrieben. Freitext, zusätzliche Felder oder unerwartete Werte führen zur Ablehnung und nicht zu einer großzügigen Interpretation.

Auch die Konfidenz des Modells ersetzt keine Handlungserlaubnis. Ein hoher Wert besagt nur, dass das Modell seine Einordnung für wahrscheinlich hält. Er sagt nichts über Berechtigung oder Schadenshöhe aus. Sinnvoll ist eine doppelte Schwelle: Unterhalb einer fachlichen Konfidenzgrenze wird der Vorgang zur Klärung vorgelegt. Oberhalb dieser Grenze entscheidet die Aktionsklasse, ob der Agent nur vorbereitet, eine reversible Änderung ausführt oder eine Freigabe anfordert. So bleibt das Risiko an die Wirkung der Aktion gebunden.

Freigaben-Audit-Log und Rückfallweg zusammendenken

Eine Freigabe ist nur belastbar, wenn der Entscheider genau den Zustand sieht, der später ausgeführt wird. Die Vorlage sollte Eingabedaten, vorgeschlagene Änderung, Begründung, betroffene Objekte und erwartete Wirkung enthalten. Nach der Freigabe prüft das System, ob sich der Fachzustand verändert hat. Ist etwa ein Auftrag inzwischen gesperrt oder der Wert bereits geändert, verfällt die Freigabe. Der Agent muss den Vorgang neu bewerten, statt eine veraltete Entscheidung auszuführen.

Kommentar von Rachel Laycock, Thoughtworks

KI-Agenten – rasante Fortschritte und neue Sicherheitsrisiken

Das Audit-Log verbindet diese Schritte zu einem nachvollziehbaren Vorgang. Es erfasst Eingabeversion, Modell- und Regelversion, Policy-Ergebnis, Freigabe, Werkzeugaufruf und Rückmeldung des Zielsystems. Eine bloße Sammlung von Modelltexten reicht nicht. Für die Prüfung muss erkennbar sein, welche strukturierte Aktion vorgeschlagen, welche Regel angewendet und welcher Fachzustand bestätigt wurde. Personenbezogene oder vertrauliche Inhalte gehören nur so weit in das Protokoll, wie es für Nachweis und Fehleranalyse erforderlich ist.

Für Abbruch und Wiederanlauf braucht jeder Vorgang eine dauerhafte Kennung und einen gespeicherten Prozesszustand. Bricht die Verbindung nach einem Schreibzugriff ab, darf der Agent nicht sofort erneut senden. Zuerst prüft er anhand einer Transaktionskennung, ob das Zielsystem die Aktion bereits übernommen hat. Ein Wiederholungsversuch ist nur zulässig, wenn das Ergebnis eindeutig aussteht und der Aufruf idempotent ausgelegt ist. Andernfalls wechselt der Vorgang in die manuelle Klärung. Der Rückfallweg ist damit Teil der Fachlogik und nicht nur eine technische Fehlermeldung.

Beispielworkflow und Prüfliste für den Pilotbetrieb

Ein Beispiel zeigt das Zusammenspiel. Ein Agent überwacht eingehende Liefermeldungen und erkennt, dass ein bestätigter Termin nicht zum Produktionsplan passt. Er liest nur die betroffene Bestellung, den aktuellen Bedarf und die letzte bestätigte Liefermeldung. Danach bewertet er die Abweichung und schlägt vor, einen internen Klärungsvorgang anzulegen. Diese reversible Aktion gehört zur zweiten Klasse und darf innerhalb definierter Felder automatisch ausgeführt werden.

Eine Änderung der Bestellmenge wäre dagegen Klasse drei. Der Agent bereitet den Vorschlag mit altem und neuem Wert, Begründung und betroffenen Produktionsaufträgen vor. Die zuständige Rolle genehmigt oder verwirft ihn. Vor der Ausführung prüft die Policy erneut Berechtigung, Sperrstatus und Wertebereich. Eine Bestellung, die zwischenzeitlich freigegeben oder geändert wurde, stoppt den Ablauf. Das ERP bleibt die führende Quelle; der Agent speichert keinen konkurrierenden Auftragszustand.

Kommentar von Uwe Specht, Pegasystems

Die KI regelt das – braucht aber klare Regeln

Fällt das ERP während der Ausführung aus, bleibt der Vorgang im Status unklar. Nach der Wiederherstellung liest der Orchestrator zuerst den aktuellen Fachzustand. Er setzt den Prozess nur fort, wenn sich die Wirkung eindeutig bestimmen lässt. Jede Abweichung geht mit den relevanten Informationen an einen benannten Verantwortlichen. Ein solcher Wiederanlauf muss vor dem Produktivbetrieb mit Timeouts, doppelten Nachrichten, veralteten Freigaben und widersprüchlichen Daten getestet werden.

(ID:50951760)