Das Modellrisikomanagement verfügt über ein etabliertes Vokabular. SR 11-7, die aufsichtliche Leitlinie der Federal Reserve und des OCC aus dem Jahr 2011, hat die Disziplin auf vier Säulen gestellt: Validierung, Dokumentation, Governance und laufende Überwachung. Für eine logistische Regression, die Kreditanträge bewertet, sind diese Säulen gut verstanden. Man kann die Eingangsgrößen festhalten, das Ergebnis von Hand nachrechnen und exakt herleiten, warum eine Entscheidung so ausgefallen ist, wie sie ausgefallen ist.
Ein LLM, das Kennzahlen aus Geschäftsberichten extrahiert, verhält sich nicht so. Die Prüfer haben das bemerkt. Die häufigste Feststellung lautet heute, dass eine Governance-Lücke besteht: Institute haben ML schneller in den Betrieb gebracht, als ihre MRM-Rahmenwerke nachgezogen sind. Das Modellinventar enthält daher Einträge, für deren Prüfung der Validierungsprozess nie ausgelegt war.
Im April 2026 haben Federal Reserve, OCC und FDIC gemeinsam SR 26-2 erlassen, das SR 11-7 ablöst. Es modernisiert das Modellrisikomanagement rund um einen Wesentlichkeitsbegriff, skaliert die Tiefe der Überwachung am tatsächlichen Risiko eines Modells und verabschiedet sich von der pauschalen Erwartung einer jährlichen Neuvalidierung. Was es ausdrücklich nicht leistet: Es sagt Ihnen nicht, wie ein generatives Modell zu validieren ist. SR 26-2 nimmt generative und agentische KI ausdrücklich von seinem Anwendungsbereich aus und begründet dies damit, dass die Technologie zu neuartig und zu schnelllebig sei, um sie festzulegen. Die vier Säulen bleiben also bestehen, das Rahmenwerk um sie herum ist neuer, und der schwierigste Fall, das LLM selbst, bleibt Ihrem Ermessen überlassen. Genau um diese Lücke geht es in diesem Beitrag.
Dies ist ein methodischer Hinweis, keine Rechtsberatung. Im Folgenden geht es darum, was sich in der täglichen Arbeit tatsächlich ändert.
Ein System validieren, das nie zweimal dieselbe Antwort gibt
Die klassische Modellvalidierung stützt sich auf Reproduzierbarkeit. Dieselbe Eingabe ausführen, dieselbe Ausgabe erhalten, gegen einen unabhängigen Benchmark abgleichen. Ein nicht-deterministisches System bricht diese Annahme schon im ersten Schritt. Temperatur, Sampling und ein stilles Modell-Update des Anbieters bedeuten allesamt, dass die heutige Ausgabe nicht mehr mit der von gestern übereinstimmen muss.
Die Validierung verschiebt sich daher von der Prüfung einer einzelnen Antwort hin zur Charakterisierung einer Antwortverteilung. Wir halten ein festes Eval-Set vor, lassen es wiederholt durchlaufen und messen, wie stabil die Ausgaben sind, nicht nur, ob ein einzelner Durchlauf korrekt aussah. Bei einer Extraktionsaufgabe bedeutet das, gegen eine handannotierte Ground Truth unter Quartalsende-Bedingungen zu bewerten, mit klar benannten Fehlerbildern: halluzinierte Posten, vertauschte Zahlen, die falsche Berichtsperiode, die aus einem Dokument mit mehreren Perioden gezogen wurde. Ein einzelner bestandener Durchlauf sagt fast nichts aus. Validiert wird die Varianz über die Durchläufe hinweg.
Die Dokumentation muss bis zu den Daten und zum Prompt reichen
Bei SR 11-7 ging es in der Dokumentation um Modelllogik und Annahmen. Bei ML wandert die sensible Oberfläche nach außen, zu den Daten und zu den Anweisungen.
Zwei Artefakte, die ältere MRM-Vorlagen selten verlangt haben:
- Datenherkunft (Lineage) für das Trainings- und Retrieval-Korpus: woher jedes Dokument stammt, zu welchem Zeitpunkt es aktuell war und ob die Point-in-Time-Korrektheit gewahrt blieb, sodass das Modell nie Informationen aus der Zeit nach dem Entscheidungsdatum gesehen hat
- Versionierte Prompts und Retrieval-Konfiguration, behandelt als Modelleingaben, denn das Ändern eines Prompts verändert das Modellverhalten ebenso sicher wie das Ändern eines Koeffizienten, und ein Audit-Trail, der das auslässt, kann eine vergangene Entscheidung nicht rekonstruieren
Wenn Sie die Frage „Was genau hat diese Ausgabe im vergangenen März erzeugt?” nicht beantworten können, ist die Säule Dokumentation nicht erfüllt, ganz gleich, was die Model Card aussagt.
Drift überwachen und der Anbieter, in den man nicht hineinsehen kann
Die laufende Überwachung beobachtete früher Eingangsverteilungen und die Performance gegen realisierte Ergebnisse. Das gilt weiterhin. Drift in der zugrunde liegenden Population zeigt sich genauso wie eh und je. Neu ist, dass das Modell selbst unter Ihnen driften kann, wenn es bei einem Anbieter gehostet wird, der sich das Recht vorbehält, die Gewichte ohne Vorankündigung zu aktualisieren.
Wir behandeln das als operative Realität, die instrumentiert und nicht wegdiskutiert werden muss. Ein dauerhaftes Eval-Set läuft nach Zeitplan gegen den Live-Endpunkt, sodass eine durch eine anbieterseitige Änderung verursachte Regression als Kennzahl sichtbar wird und nicht erst Wochen später als Support-Ticket. Wo ein Anbietermodell tatsächlich intransparent ist, verlagert sich der Validierungsaufwand an die Grenze: die Eingaben belasten, die Ausgaben eingrenzen und gegen eine unabhängige Quelle abgleichen, die das Modell nie gesehen hat. Sie validieren den Wrapper und die Kontrollen rund um die Blackbox, denn die Box selbst lässt sich nicht öffnen.
Nichts davon ersetzt die Säulen von SR 11-7. Es erweitert sie auf Systeme, die probabilistisch, teilweise extern und unter Produktionslast veränderlich sind. Schwer tun sich jene Teams, die ML noch immer so validieren, als wäre es eine Tabellenkalkulation. Beginnen Sie damit, festzuhalten, was Ihr aktueller Prozess über Determinismus voraussetzt, und prüfen Sie dann jede Annahme gegen das Modell, das Sie tatsächlich betreiben.