KI-Orchestration-Layer ohne Blackbox: Wie Banken Agentenentscheidungen protokollieren und stoppen

Ein KI-Orchestration-Layer verteilt in der Bank Aufgaben an Fachagenten, prüft Ergebnisse und übergibt an Menschen. Welche Rollen er dafür braucht, haben wir im Beitrag über Router, Planer, Fachagenten und Prüfer beschrieben. Dieser Beitrag beantwortet eine engere Frage: Wie protokolliert eine Bank, was ihre Agenten entscheiden, wie rekonstruiert sie eine Entscheidung im Nachhinein, und wie hält sie einen Agenten an? Welche Autonomiestufe ein Agent überhaupt bekommt, behandelt ein eigener Beitrag unserer Serie.

Was der Rechtsrahmen verlangt

Für Hochrisiko-KI verlangt der AI Act automatische Protokolle und die Möglichkeit, das System anzuhalten; DORA verlangt Protokollierung für alle IKT-Systeme einer Bank. Beides zusammen beschreibt, was ein Orchestration-Layer technisch können muss.

Hochrisiko-KI-Systeme müssen Ereignisse über ihre gesamte Lebensdauer automatisch protokollieren können (AI Act, Art. 12). Menschen müssen eingreifen oder das System „durch eine Stopp-Taste oder ein ähnliches Verfahren“ in einem sicheren Zustand anhalten können (AI Act, Art. 14). Betreiber bewahren die Protokolle mindestens sechs Monate auf (AI Act, Art. 26). Für eigenständige Hochrisiko-Systeme wie die Kreditwürdigkeitsprüfung gelten diese Pflichten nach dem Digital Omnibus ab dem 2. Dezember 2027 (Europäisches Parlament).

Die meisten Marketing- und Serviceagenten sind kein Hochrisiko-System. Für sie greift trotzdem DORA: Die technischen Regulierungsstandards verlangen festgelegte Ereignisse und Aufbewahrungsfristen, Schutz der Protokolle gegen Manipulation und Löschung, eine Erkennung ausgefallener Protokollierung und synchronisierte Systemuhren (Delegierte Verordnung (EU) 2024/1774, Art. 12).

Protokollieren: Was je Agentenschritt festgehalten wird

Ein brauchbares Protokoll hält nicht nur das Ergebnis fest, sondern alles, was nötig ist, um die Entscheidung später nachzustellen. Fünf Angaben gehören zu jedem Schritt.

1. Auslöser und Auftrag: welches Ereignis den Agenten gestartet hat und mit welchem Mandat.

2. Kontext mit Version: welche Kundendaten, Einwilligungen und Regeln der Agent gesehen hat, mit Stand und Version.

3. Modell und Anweisung: Modellversion, Systemanweisung und verwendete Werkzeuge.

4. Prüfergebnis: was die Prüferrolle geprüft hat, mit Ergebnis und Begründung.

5. Freigabe und Wirkung: wer freigegeben hat, was beim Kunden angekommen ist, und wann.

Nachvollziehen: Eine Entscheidung im Nachhinein rekonstruieren

Nachvollziehbar ist eine Entscheidung erst, wenn ein Prüfer sie mit den damaligen Daten und Versionen wiederholen kann. Eine Liste von Ereignissen allein reicht dafür nicht.

Hypothetisches Beispiel: Ein Kunde einer Genossenschaftsbank beschwert sich, dass ihm zwei Tage nach einer Kündigung seines Dispos ein Kreditangebot geschickt wurde. Die Innenrevisorin und der Leiter Marketing-Operations rufen den Vorgang im Protokoll auf. Sie sehen, dass der Agent einen Kontextstand von vor der Kündigung verwendet hat. Sie entscheiden, dass Kreditangebote künftig nur mit einem Kontext ausgespielt werden, der höchstens einen Tag alt ist, und ergänzen die Prüferregel.

Damit das funktioniert, müssen Kontext, Regeln und Modell versioniert sein. Wie Kontextobjekte mit Gültigkeit aufgebaut sind, zeigt der Beitrag über die fünf Bausteine einer AI Decision Engine.

Stoppen: Kriterien, Stufen, Vier-Augen-Prinzip

Ein Agent muss auf drei Ebenen angehalten werden können: einzelner Schritt, Anwendungsfall und gesamter Agent. Die Kriterien dafür werden vor dem Start festgelegt, nicht im Vorfall.

• Schritt: Die Prüferrolle hält eine Aktion an, wenn Einwilligung, Kontaktbudget oder Kontextalter nicht passen.

• Anwendungsfall: Ein Schwellenwert, etwa eine ungewöhnliche Beschwerdequote oder Abweichung von der Vergleichsgruppe, setzt den Fall automatisch aus.

• Agent: Eine benannte Person kann den Agenten vollständig anhalten; laufende Vorgänge gehen an Menschen über.

Aktionen mit Außenwirkung, etwa ein Angebot oder eine Konditionsänderung, gibt nach dem Vier-Augen-Prinzip eine zweite Stelle frei, bis die Bank genug Erfahrung hat. Warum ein Stopp-Schalter allein nicht genügt, beschreibt unser Beitrag Ein Kill Switch reicht nicht.

ACCELERAID protokolliert Datenzugriffe, Modellaufrufe und Änderungen exportierbar und liefert erklärbare Ergebnisse. Die Plattform läuft in einem ISO-27001-Rechenzentrum in Frankfurt oder auf Anfrage On-Premise und ist SOC-2-konform (ACCELERAID).

Fünf Punkte zum Mitnehmen

1. Ein KI-Orchestration-Layer ohne Blackbox protokolliert je Agentenschritt Auslöser, Kontext mit Version, Modell, Prüfergebnis und Freigabe.

2. Der AI Act verlangt für Hochrisiko-KI automatische Protokolle, eine Stopp-Möglichkeit und mindestens sechs Monate Aufbewahrung, für eigenständige Systeme ab dem 2. Dezember 2027.

3. DORA verlangt Protokollierung, Manipulationsschutz und synchronisierte Uhren für alle IKT-Systeme, also auch für Agenten außerhalb der Hochrisiko-Klasse.

4. Nachvollziehbar ist eine Entscheidung erst, wenn sie mit den damaligen Daten und Versionen wiederholt werden kann.

5. Stopp-Kriterien für Schritt, Anwendungsfall und Agent werden vor dem Start festgelegt; Aktionen mit Außenwirkung laufen anfangs mit Vier-Augen-Freigabe.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.