SR 11-7 trifft agentische KI: Modellrisikomanagement für KI-Agenten im Bankwesen

Seit mehr als einem Jahrzehnt prägt ein einziges Dokument das Modellrisikomanagement US-amerikanischer Banken: SR 11-7, die im April 2011 veröffentlichte Supervisory Guidance on Model Risk Management der Federal Reserve. Das OCC gab die inhaltlich gleiche Leitlinie als Bulletin 2011-12 heraus, die FDIC übernahm sie 2017. Die meisten Banken haben ihre Richtlinien, Inventare und Validierungsteams für Modellrisiken darauf ausgerichtet.

Generative KI und KI-Agenten stellen diesen Rahmen nun auf eine Weise auf die Probe, die seine Verfasser nicht vorhersehen konnten. Die gute Nachricht: SR 11-7 ist prinzipienbasiert und nicht regelbasiert formuliert, und vieles davon lässt sich gut anwenden. Die Herausforderung besteht darin zu erkennen, wo der Rahmen an seine Grenzen stößt und wo er endet.

Was SR 11-7 von Banken verlangt

SR 11-7 beruht auf drei Säulen:

• Solide Entwicklung, Implementierung und Nutzung. Modelle sollten einen klaren Zweck, ein solides Design, geeignete Daten und dokumentierte Grenzen haben und bestimmungsgemäß eingesetzt werden.
• Validierung mit wirksamer kritischer Prüfung. Modelle sollten von Personen geprüft werden, die von der Entwicklung unabhängig sind und über die Kompetenz und den Einfluss verfügen, Annahmen und Ergebnisse infrage zu stellen.
• Governance, Richtlinien und Kontrollen. Aufsichtsorgan und Geschäftsleitung legen Richtlinien fest, definieren Rollen und Verantwortlichkeiten und führen ein Inventar der eingesetzten Modelle.

Die Leitlinie definiert ein Modell zudem weit, nämlich als quantitative Methode, die Eingabedaten in Schätzungen überführt, und stellt klar, dass Modellrisiken sowohl aus Fehlern im Modell als auch aus dessen falscher Verwendung entstehen. Genau diese Breite macht sie für die heutige KI relevant.

Was als Modell gilt und wie man es einstuft

Eine klassische Kreditscorekarte ist leicht als Modell zu erkennen. Bei einem KI-Agenten ist das schwieriger. Er kombiniert typischerweise ein großes Sprachmodell, eine Reihe von Prompts und Anweisungen, den Abruf interner Dokumente, Tools, die andere Systeme aufrufen, und Geschäftsregeln, die über den nächsten Schritt entscheiden.

Wir empfehlen Banken, die Frage schichtweise statt auf einmal zu beantworten:

• Das Basismodell. Das zugrunde liegende LLM ist meist eine Komponente eines Drittanbieters. Es gehört ins Inventar, auch wenn die Bank nicht einsehen kann, wie es entwickelt wurde.
• Die konfigurierte Anwendung. Die Prompts, Abrufquellen, Parameter und Leitplanken, die aus einem allgemeinen Modell einen konkreten Anwendungsfall machen. Hier entsteht der größte Teil des bankspezifischen Risikos, und hierauf sollte sich die Validierung konzentrieren.
• Die Handlungen des Agenten. Die Tools und Systemberechtigungen, mit denen die Anwendung Datensätze ändern oder Prozesse auslösen kann. Wie wir weiter unten ausführen, braucht diese Schicht Kontrollen, für die SR 11-7 nicht konzipiert wurde.

Manche Banken werden bestimmte Anwendungen generativer KI als „Tools“ oder „Nicht-Modelle“ statt als Modelle behandeln. Bei geringem Risiko kann das vertretbar sein, doch die Entscheidung sollte dokumentiert, konsistent und derselben kritischen Prüfung unterworfen sein wie jede andere Einordnung. Undokumentierte Ausnahmen sind ein häufiger Prüfungsbefund.

Sind die KI-Anwendungen erfasst, müssen sie eingestuft werden. Die meisten Banken stufen Modelle bereits nach Wesentlichkeit ein, damit die Validierungstiefe dem Risiko entspricht. Dieselbe Logik sollte für KI gelten, allerdings müssen die Kriterien angepasst werden. Eine Anwendung generativer KI, die interne Besprechungsnotizen entwirft, und eine, die Kundenfragen zu Gebühren beantwortet, können dasselbe Basismodell nutzen und dennoch sehr unterschiedliche Risiken tragen.

Hilfreiche Kriterien für die Einstufung von KI und Agenten sind unter anderem:

• ob Ergebnisse Kunden erreichen oder sich auf Kundenergebnisse auswirken;
• ob das System handeln kann oder nur Empfehlungen gibt;
• die finanziellen, verhaltensbezogenen und Compliance-Folgen eines Fehlers;
• der Umfang menschlicher Prüfung, bevor man sich auf Ergebnisse stützt;
• die Sensibilität der Daten, auf die es zugreifen kann.

Ein Agent, der Datensätze in Kernbanken- oder Zahlungssystemen ändern kann, gehört fast schon per Definition in die höchsten Stufen, unabhängig davon, wie ausgereift sein Modell ist.

Systeme validieren, die nie zweimal dieselbe Antwort geben

Die klassische Validierung stützt sich darauf, Ergebnisse zu reproduzieren, Annahmen zu testen und mit Alternativen zu vergleichen. Große Sprachmodelle sind nicht deterministisch: Dieselbe Eingabe kann unterschiedliche Ausgaben erzeugen, und das Verhalten kann sich ändern, wenn ein Anbieter das Modell aktualisiert. Die Validierung muss sich anpassen, ohne die wirksame kritische Prüfung aufzugeben.

In der Praxis heißt das, mehrere Verfahren zu kombinieren:

• Testsets je Anwendungsfall. Kuratierte Sätze realistischer Eingaben mit erwarteten Ergebnissen, die wiederholt ausgeführt werden, um Genauigkeit und Konsistenz über viele Durchläufe statt über einen einzigen zu messen.
• Benchmarks. Der Vergleich mit einer Referenz, etwa dem bestehenden manuellen Prozess oder einem einfacheren regelbasierten Ansatz, damit die Bank beurteilen kann, ob die KI für ihren Zweck geeignet ist.
• Red-Teaming. Gezielte Versuche, das System zum Versagen zu bringen, darunter Prompt Injection, Versuche, vertrauliche Daten abzugreifen, und Eingaben, die verzerrte oder schädliche Ausgaben auslösen sollen.
• Laufende Überwachung. Da sich das Verhalten verändern kann, darf die Validierung keine Momentaufnahme sein. Die Überwachung von Ergebnisqualität, Korrekturquoten, Beschwerden und Vorfällen im Produktivbetrieb wird Teil der Validierungsnachweise.

Auch Validierer brauchen neue Kompetenzen. Wirksame kritische Prüfung erfordert Menschen, die verstehen, wie diese Systeme versagen – nicht nur statistische Modelltheorie.

Modelle von Drittanbietern und Anbieterrisiko

SR 11-7 erwartet bereits heute, dass Banken Anbietermodelle steuern, selbst wenn der Anbieter Design und Daten nicht vollständig offenlegt. Dieser Grundsatz ist nun zentral, denn die meiste generative KI in Banken beruht auf Modellen, die die Bank weder selbst entwickelt hat noch vollständig einsehen kann.

Banken sollten das Modellrisikomanagement mit dem Management von Drittparteienrisiken verzahnen, sodass sie für jeden KI-Anbieter verstehen:

• welche Dokumentation und Testnachweise der Anbieter bereitstellt;
• wie und wann der Anbieter Modelle ändert oder außer Betrieb nimmt und wie die Bank darüber informiert wird;
• wo Daten verarbeitet werden und ob sie zum Training der Modelle des Anbieters genutzt werden;
• welche vertraglichen Rechte die Bank für Prüfung, Tests und Ausstieg hat.

Wo die Transparenz des Anbieters begrenzt ist, müssen die eigenen Tests und die Überwachung der konfigurierten Anwendung durch die Bank umso mehr leisten.

Die Lücke: SR 11-7 validiert Modelle, nicht Handlungen

Das ist der wichtigste Punkt für Banken, die Agenten einsetzen. SR 11-7 befasst sich damit, ob die Ergebnisse eines Modells belastbar sind und angemessen verwendet werden. Die Leitlinie sagt einer Bank nicht, wie sie ein System kontrolliert, das selbstständig handelt: was es ändern darf, wer diese Änderungen freigibt und wie man sie rückgängig macht.

Auch ein gut validiertes Modell kann Schaden anrichten, wenn der Agent darum herum übermäßige Berechtigungen hat oder kein Freigabeschritt vorgesehen ist. Um diese Lücke zu schließen, braucht es Kontrollen aus dem operationellen Risikomanagement und den generellen IT-Kontrollen:

• Identität und Zugriff. Jeder Agent hat eine eigene Identität mit minimalen Rechten, die in Zugriffsprüfungen einbezogen wird.
• Freigaben. Schwellen für menschliche Freigaben richten sich nach dem Risiko der jeweiligen Handlung und werden nicht pauschal angewandt.
• Change Management. Änderungen an Prompts, Tools und Modellversionen durchlaufen kontrollierte Release-Prozesse – genau wie Codeänderungen.
• Protokollierung und Audit-Trails. Jede Handlung ist zurechenbar, rekonstruierbar und mit dem geänderten Datensatz verknüpft.
• Reaktion auf Vorfälle. Ein getestetes Verfahren, um einen Agenten zu stoppen und seine Handlungen rückgängig zu machen.

Die praktische Antwort besteht nicht darin, SR 11-7 so weit zu dehnen, dass es alles abdeckt, sondern klar festzulegen, welche Funktion welche Kontrolle verantwortet – damit Modellrisiko, operationelles Risiko, Technologierisiko und Geschäftsbereich jeweils ihre Rolle kennen.

Die Erwartungen der Aufsicht entwickeln sich weiter

Die Aufsichtsbehörden haben deutlich gemacht, dass bestehende Erwartungen an Modellrisiko, Drittparteienrisiko und operationelle Resilienz auch für KI gelten, und diese Erwartungen entwickeln sich weiter. Banken, die ihre bestehenden Rahmenwerke umsichtig erweitern, ihre Überlegungen dokumentieren und die Lücke zwischen Modellvalidierung und Handlungskontrollen schließen, sind gut aufgestellt – was auch immer als Nächstes kommt.

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