Governance für KI-Agenten, die in Ihre führenden Systeme eingreifen

Die meisten KI-Governance-Programme in Unternehmen wurden für eine Welt entworfen, in der KI ein Ergebnis liefert und ein Mensch entscheidet, was damit geschieht. Ein Modell bewertet einen Kreditantrag. Ein Assistent entwirft eine E-Mail. Ein Chatbot beantwortet eine Frage zu einer Richtlinie. Der Mensch bleibt dazwischen – und er verantwortet die Handlung.

KI-Agenten verändern dieses Gefüge. Ein Agent kann einen Kundendatensatz lesen, entscheiden, dass etwas zu tun ist, und es dann selbst tun: ein Feld im CRM aktualisieren, eine Bestellung im ERP auslösen, einen Servicefall schließen oder eine Kontoeinstellung in einem Kernbankensystem ändern. Das Ergebnis ist kein Vorschlag mehr. Es ist eine Änderung in einem führenden System.

Ich habe mehr als zwei Jahrzehnte damit verbracht, solche führenden Systeme einzuführen und zu betreiben, und die Lehre ist stets dieselbe: Das Risiko liegt in dem, was geschrieben wird, nicht in dem, was gesagt wird. Dieser Beitrag erläutert, warum Agenten andere Kontrollen brauchen und wie ein tragfähiger Kontrollrahmen aussieht.

Warum Antworten und Handlungen unterschiedliche Risiken bergen

Ein Modell, das eine Antwort erzeugt, kann falsch liegen, verzerrt sein oder unzureichend erklärbar sein. Das sind reale Risiken, doch in der Regel fängt sie die Person ab, die die Antwort liest. Ein Agent, der handelt, bringt zusätzliche Risiken mit sich, die näher am operationellen Risiko als am Modellrisiko liegen.

• Skalierung. Eine fehlerhafte Anweisung kann tausendfach ausgeführt werden, bevor es jemand bemerkt, denn Agenten ermüden nicht und halten nicht inne, um ein Muster zu hinterfragen.
• Reichweite. Agenten nutzen oft Integrations-Zugangsdaten, die für die Kommunikation zwischen Systemen eingerichtet wurden und weit mehr Zugriff gewähren können, als ein einzelner Mitarbeiter je hätte.
• Verkettung. Die Ausgabe eines Agenten kann zur Eingabe eines anderen werden, sodass sich ein Fehler über Systeme und Teams hinweg ausbreiten kann.
• Umkehrbarkeit. Manche Handlungen, etwa eine Kundenmitteilung oder eine Zahlung, lassen sich nicht einfach rückgängig machen.
• Verantwortlichkeit. Ändert sich ein Datensatz, fragen Prüfer und Aufsichtsbehörden, wer die Änderung vorgenommen hat und in wessen Auftrag. „Die KI war es“ ist keine akzeptable Antwort.

Das alles heißt nicht, dass man auf Agenten verzichten sollte. Es heißt, dass sich das Governance-Modell von der Prüfung von Ergebnissen hin zur Kontrolle von Handlungen bewegen muss.

Jeden Agenten kennen und an eine Identität binden

Was man nicht sieht, kann man nicht steuern. Die erste Kontrolle ist ein stets aktuelles Inventar aller eingesetzten Agenten – ob intern entwickelt, in eine Anbieterplattform eingebettet oder von einem Fachbereich in einer bestehenden Anwendung aktiviert.

Für jeden Agenten sollte das Inventar mindestens Folgendes erfassen:

• Zweck und Verantwortliche. Wofür der Agent da ist und welche namentlich benannte Person im Fachbereich für sein Verhalten verantwortlich ist.
• Systeme und Daten. Aus welchen führenden Systemen er lesen und in welche er schreiben kann und mit welchen Datenklassifizierungen er arbeitet.
• Aktionen. Die konkreten Operationen, die er ausführen kann, etwa anlegen, ändern, löschen, genehmigen, versenden oder zahlen.
• Zugrunde liegende Modelle und Anbieter. Auf welche Modelle er sich stützt und wer sie bereitstellt.
• Risikostufe. Eine Einstufung nach der Tragweite seiner Handlungen, die alle weiteren unten beschriebenen Kontrollen bestimmt.

Viele Organisationen stellen fest, dass in lizenzierten Plattformen bereits Agenten aktiv sind – freigeschaltet über eine Konfigurationseinstellung statt über ein formelles Projekt. Die Bestandsaufnahme ist daher oft der wertvollste erste Schritt.

Als Nächstes sollte jeder Agent unter einer eigenen Identität handeln – nicht unter einem gemeinsam genutzten Dienstkonto und nicht mit den Zugangsdaten der Person, die ihn eingerichtet hat. Diese Identität sollte wie jeder andere privilegierte Benutzer in Ihren Prozessen für Identitäts- und Zugriffsmanagement registriert sein.

Berechtigungen sollten dem Prinzip der minimalen Rechte folgen, und zwar auf Ebene von Objekten, Feldern und Operationen. Ein Agent, der den Status von Servicefällen aktualisiert, muss keine Bankverbindungen von Kunden bearbeiten. Ein Agent, der Zahlungsanweisungen vorbereitet, braucht keine Befugnis, sie freizugeben. Handelt ein Agent im Auftrag eines bestimmten Benutzers, sollte er höchstens dessen eigene Zugriffsrechte erhalten.

Wer Zugriffsprüfungen auf CRM- oder ERP-Plattformen durchgeführt hat, kennt dieses Terrain. Der Unterschied: Agentenberechtigungen werden meist schnell, während eines Pilotprojekts, vergeben und danach nie wieder überprüft. Beziehen Sie Agentenidentitäten vom ersten Tag an in die regelmäßige Rezertifizierung von Zugriffsrechten ein.

Freigabeschwellen nach Risiko festlegen, nicht nach Gewohnheit

„Human in the Loop“ wird oft wie ein einzelner Schalter behandelt. In der Praxis sollte es ein Satz von Schwellenwerten sein, die an die Risikostufe jeder Handlung geknüpft sind.

• Autonom. Handlungen mit geringer Tragweite, die sich leicht rückgängig machen lassen, etwa das Verschlagworten eines Falls oder das Aktualisieren einer internen Notiz, können ohne Prüfung ablaufen, sofern sie überwacht werden.
• Human on the Loop. Handlungen mittlerer Tragweite laufen automatisch, doch ein Mensch prüft im Nachhinein Stichproben oder Ausnahmen und kann eingreifen.
• Human in the Loop. Handlungen mit hoher Tragweite, etwa Änderungen an Finanzdaten von Kunden, Kreditentscheidungen, Zahlungen oder externe Mitteilungen, erfordern eine ausdrückliche Freigabe, bevor sie wirksam werden.
• Unzulässig. Manche Handlungen sollten gar nicht an einen Agenten delegiert werden, unabhängig von den Kontrollen.

Schwellenwerte sollten auch Menge und Betrag berücksichtigen. Einem Agenten kann man eine kleine Kulanzgutschrift anvertrauen, aber nicht Hunderte davon in einer Stunde oder eine oberhalb eines festgelegten Betrags. Freigebende brauchen genügend Kontext für eine echte Entscheidung – sonst wird die Freigabe zum bloßen Abnicken.

Leitplanken, Protokollierung und Überwachung von Anfang an einplanen

Leitplanken sind die technischen Grenzen, die unabhängig davon gelten, was das Modell entscheidet. Dazu gehören Filter für Ein- und Ausgaben, Validierungsregeln für die Datensätze, die ein Agent schreibt, Ratenbegrenzungen, Ausgaben- und Betragsobergrenzen, Beschränkungen der Tools, die ein Agent aufrufen darf, sowie Schutz vor Prompt Injection aus nicht vertrauenswürdigen Inhalten wie eingehenden E-Mails oder Dokumenten.

Erst die Aktivitätsprotokollierung macht aus einem Agenten statt einer Blackbox etwas, das sich prüfen lässt. Für jede Handlung sollten Sie nachvollziehen können:

• welcher Agent gehandelt hat, unter welcher Identität und in wessen Auftrag;
• was ihn ausgelöst hat und auf welche Informationen er sich gestützt hat;
• welches Modell und welche Konfigurationsversion im Einsatz waren;
• was er geändert hat, mit Werten vor und nach der Änderung;
• wer die Handlung freigegeben hat, sofern eine Freigabe erforderlich war.

Protokolle sollten manipulationssicher sein, gemäß Ihren Aufbewahrungsrichtlinien vorgehalten werden und mit dem Audit-Trail des führenden Systems selbst verknüpft sein, sodass sich die Änderung eines Agenten für einen Prüfer genauso nachverfolgen lässt wie die eines Menschen.

Die Überwachung nutzt diese Protokolle dann, um Abweichungen und Missbrauch zu erkennen: ungewöhnliche Mengen, Handlungen außerhalb der üblichen Zeiten, steigende Quoten menschlicher Korrekturen oder auffällig gehäufte Änderungen bei bestimmten Kunden oder Konten. Agenten verhalten sich anders, wenn sich Daten, Prompts und zugrunde liegende Modelle ändern. Die Überwachung muss daher kontinuierlich erfolgen und darf kein einmaliger Test vor dem Start sein.

Vorfälle und Rückabwicklung planen, bevor es darauf ankommt

Jeder Agent, der in ein führendes System schreibt, braucht einen Notfallplan, der vor dem Go-live schriftlich festgelegt und getestet ist. Dieser Plan sollte mindestens Folgendes abdecken:

• Einen Notschalter. Einen schnellen, allgemein verstandenen Weg, einen Agenten zu stoppen oder ihm die Berechtigungen zu entziehen, ohne die gesamte Plattform lahmzulegen.
• Eine Analyse des Schadensumfangs. Die Fähigkeit, anhand des Aktivitätsprotokolls jeden Datensatz zu ermitteln, den ein Agent in einem bestimmten Zeitraum verändert hat.
• Rückabwicklung. Ein getestetes Verfahren, um betroffene Datensätze in ihren vorherigen Zustand zurückzuversetzen, und ein klarer Prozess für Handlungen, die sich nicht rückgängig machen lassen, etwa die Wiedergutmachung gegenüber Kunden.
• Eskalation. Festgelegte Wege in Ihre bestehenden Prozesse für operationelles Risiko, Informationssicherheit und gegebenenfalls aufsichtsrechtliche Meldungen.

Die gute Nachricht: Die meisten Organisationen verfügen für andere Systeme bereits über diese Fähigkeiten. Es geht darum, sie auf Agenten auszuweiten und sicherzustellen, dass die Verantwortlichen wissen, dass Agenten dazugehören.

Wo Sie beginnen sollten

Agenten-Governance braucht keine neue Bürokratie. Sie braucht bewährte Disziplinen – Identitätsmanagement, Change Control, operationelles Risikomanagement und Audit –, gezielt angewandt auf eine neue Art von Akteur. Eine sinnvolle Reihenfolge: erfassen, was bereits im Einsatz ist, nach der Tragweite der Handlungen einstufen, Berechtigungen und Freigaben in den höchsten Stufen verschärfen und sicherstellen, dass Sie das Handeln dieser Agenten protokollieren, überwachen und rückgängig machen können.

Richtig umgesetzt, bremst das die Einführung nicht. Es gibt Führungskräften, Risikoteams und Aufsichtsbehörden das Vertrauen, Agenten mehr zu überlassen.

Dieser Beitrag dient der allgemeinen Information und stellt keine Rechts- oder Aufsichtsberatung dar.