Die KI-Governance-Checkliste für den Finanzbereich, die Prüfer und Aufsichtsbehörden 2026 anlegen werden

Eine Governance-Checkliste vor dem Produktivgang für Finanzverantwortliche: das neue Modellrisiko-Rahmenwerk, die Lücken zu ISO 42001 und LLM-spezifische Kontrollen erfassen, bevor eine KI das Hauptbuch berührt.

Ein Bankenprüfer sitzt Ihrem Leiter Modellrisiko gegenüber und stellt eine einzige Frage: “Zeigen Sie mir, wie diese KI zu der Zahl gelangt ist, die Sie in das Kreditvotum geschrieben haben.” Lautet die ehrliche Antwort “das Modell hat sie geschrieben”, haben Sie ein Problem, das auch die umfangreichste Richtliniendokumentation nicht überdecken kann. Genau diesen Moment, der sich 2026 in Prüfungsräumen und aufsichtlichen Prüfungen immer wieder wiederholen wird, soll diese Checkliste überstehen helfen.

Die Modellrisiko-Aufsicht wurde für eine andere Art von Modell geschaffen. SR 11-7, die Modellrisiko-Leitlinie der Federal Reserve von 2011, prägt das Fachgebiet seit über einem Jahrzehnt: Governance, unabhängige Validierung und Kontrollen über den gesamten Modelllebenszyklus. Sie setzt ein Modell voraus, dessen Logik Sie prüfen und dessen Ergebnisse Sie reproduzieren können. Generative und agentische KI fügen sich schlecht in diesen Rahmen, und kein maßgeschneidertes Nachfolge-Regelwerk hat sie ersetzt. Das ist keine Entwarnung. Aufsicht und Interne Revision wenden die Modellrisiko-Erwartungen bereits analog auf LLM-gestützte Werkzeuge an. Das heißt: Sie tragen die Pflichten, ohne den Komfort einer Leitlinie zu genießen, die für die tatsächlich eingesetzte Technologie geschrieben wurde.

Das ist also die unbequeme Zwischenlage. Der alte Standard ist weg, der neue erklärt ausdrücklich, dass er genau das Werkzeug nicht abdeckt, das Sie tatsächlich eingeführt haben, und Ihr Prüfer erwartet von Ihnen dennoch, dass Sie dafür einstehen. Eine Checkliste ist der Weg, diese Lücke zu schließen, bevor ein anderer sie für Sie aufreißt.

Warum eine Checkliste mehr leistet als eine Richtlinie

Richtlinien beschreiben Absichten. Checklisten erzwingen Entscheidungen. Dieser Unterschied ist entscheidend, denn die meisten Fehlschläge beim KI-Einsatz im Finanzbereich sind keine Fehlschläge der Absicht; es sind Lücken, deren Schließung niemandem zugewiesen wurde. Ein Governance-Ausschuss, der eine zweiseitige KI-Richtlinie unterzeichnet, fühlt sich geschützt. Ein Governance-Ausschuss, der vor dem Produktivgang dreißig konkrete Fragen schriftlich beantworten muss, findet die Lücken, solange sie noch günstig zu schließen sind.

Die nachstehenden Fragen lehnen sich strukturell an ISO/IEC 42001 an, den Standard für KI-Managementsysteme, der sich zur faktischen Referenz für KI-Governance in regulierten Branchen entwickelt hat. Er ist freiwillig und zertifizierbar, nicht verpflichtend, doch sein Grundgerüst – KI-Risikobewertung, Folgenabschätzung von Systemen, Lebenszyklus-Management und Steuerung von Drittparteien – deckt sich sauber mit dem, was Prüfer heute hinterfragen. Nutzen Sie ihn als Gerüst, nicht als Heilige Schrift.

Die Fragen, die Ihr Ausschuss vor dem Produktivgang beantworten muss

Bestandsaufnahme und Verantwortlichkeit

Beginnen Sie mit dem langweiligen Teil, denn beim langweiligen Teil setzen Prüfungen an. Können Sie ein vollständiges Verzeichnis jedes KI-Systems vorlegen, das mit Finanzdaten in Berührung kommt – einschließlich der Schatten-Werkzeuge, in die ein Controller letzten Monat Quartalszahlen hineinkopiert hat? Wer ist für jedes einzelne der benannte, verantwortliche Eigentümer – eine Person, keine Abteilung? Welche Entscheidung stützt jedes System, und was ist das schlimmste plausible Ergebnis, wenn seine Ausgabe falsch ist? Können Sie den Eigentümer nicht benennen, haben Sie keine Governance; Sie haben eine Lieferantenbeziehung.

Datenherkunft und die Abstimmungsfrage

Hier ist die Frage, die echte Bereitschaft von Theater trennt: Lässt sich jede Zahl, die die KI erzeugt, auf eine abgestimmte Quelle zurückverfolgen, die mit dem Hauptbuch übereinstimmt? Nicht “zitiert das Modell ein Dokument”, sondern “stimmt die Zahl mit den Büchern überein”. Die meisten LLM-Finanzwerkzeuge rufen Text ab und lassen das Modell darauf rechnen. Genau dort lauern die stillen Fehler: ein vertauschter Quotient, eine als Jahreswert gelesene Quartalszahl, ein Vorzeichenwechsel bei einem Mittelabfluss.

Das ist die architektonische Wegscheide. Wenn Ihre KI Zahlen selbst berechnet, validieren Sie ein probabilistisches System, das auf dieselbe Frage unterschiedliche Antworten gibt. Wenn Ihre KI aus einem abgestimmten Modell abruft und die Rechnung durch eine deterministische Engine laufen lässt, validieren Sie eine Berechnung – etwas, das ein Controller bereits abzuzeichnen weiß. Wir führen das ausführlicher aus in Single Source of Truth versus Sufficient Versions of Truth, doch für die Checkliste ist der Test schnörkellos: Greifen Sie eine beliebige von der KI erzeugte Zahl heraus und bitten Sie das Team, sie bis zur Quelle zurückzuverfolgen. Gelingt das nicht vor Ihren Augen, wird es auch einem Prüfer nicht gelingen.

Validierung, wenn Sie nicht in das Modell hineinschauen können

SR 11-7 ging davon aus, dass Sie die Logik eines Modells einsehen können. Bei einem Lieferanten-LLM können Sie das nicht; die Gewichte sind eine Blackbox, und sie verändern sich nach dem Zeitplan des Anbieters unter Ihnen weg. Die Checklistenfrage lautet daher: Wie validieren Sie ein System, das Sie nicht öffnen können? Die Antwort ist die ergebnisbasierte Validierung – das System gegen eine Menge bekannt-korrekter Finanzantworten zu testen und dabei die Genauigkeit auf Feldebene, die Konsistenz bei wiederholten Abfragen und die Nachvollziehbarkeit jedes Ergebnisses zu messen. Die Mechanik dahinter behandeln wir in Sie können die Gewichte nicht validieren. Ihr Ausschuss sollte die geforderte Genauigkeitsschwelle benennen können, ebenso, wie häufig das System auf Drift erneut getestet wird und wer die Ergebnisse prüft. “Der Anbieter sagt, es sei genau” ist kein Validierungsbefund.

LLM-spezifische Risiken, die das alte Rahmenwerk nie benannt hat

SR 11-7 wurde für statistische Modelle geschrieben und schweigt deshalb zu den Fehlermodi, die LLMs tatsächlich treffen. Prompt Injection, bei der feindseliger Text in einem Dokument das Verhalten des Modells steuert. Abrufverzerrung, bei der das System die falschen Stützzahlen heranzieht und daraus selbstbewusst Schlüsse zieht. Nicht-Determinismus, bei dem derselbe Prompt am Dienstag eine andere Zahl liefert als am Montag. Ihre Checkliste braucht für jedes davon eine ausdrückliche Zeile: Was ist die Angriffsfläche, welche Kontrolle mindert das Risiko, und wie würden Sie es im Produktivbetrieb erkennen? Prompt Injection und Abrufverzerrung schlüsselt diese Punkte auf. Erwähnt Ihr Governance-Paket sie nicht, wurde es für eine frühere Ära geschrieben.

Menschliche Aufsicht, die real ist, nicht nominell

Prüfer haben gelernt, eine Aufsicht zu erkennen, die nur auf dem Papier existiert – den “geprüft und freigegeben”-Stempel auf einer Ausgabe, die niemand tatsächlich überprüfen konnte. Wirksame Aufsicht setzt voraus, dass ein Mensch die Ausgabe deuten, die Herkunft jeder Zahl nachvollziehen und sie überschreiben kann. Möglich ist das nur, wenn die Zahlen bis zur Quelle nachvollziehbar sind. Ein Prüfer, der auf einen selbstbewussten Absatz KI-generierten Kommentars starrt, ohne Rückbezug zum Hauptbuch, beaufsichtigt nichts; er unterzeichnet mit. Bauen Sie die Checkliste so, dass die Aufsicht prüfbar ist: Kann der Prüfer jede Zahl anklicken und ihre Herkunft sehen?

Protokollierung, Aufbewahrung und der Wiederholungstest

Die letzte Frage ist die, die Prüfer zuletzt stellen und die ihnen am meisten bedeutet: Können Sie, wenn wir in neun Monaten wiederkommen, rekonstruieren, was dieses System getan hat und warum? Das bedeutet eine automatische Protokollierung von Eingaben, Ausgaben, den abgerufenen Zahlen und den durchgeführten Berechnungen, aufbewahrt lange genug, um Ihren Revisions- und Aufsichtszyklus abzudecken. Der Goldstandard ist die Wiederholbarkeit: dieselben Eingaben erneut durch das System zu führen und dieselbe Zahl auf demselben nachvollziehbaren Pfad zu erhalten. Deterministische Systeme bestehen diesen Test. Reine LLM-Systeme schaffen das in der Regel nicht – und das ist der stille Grund, warum so viele KI-Pilotprojekte im Finanzbereich nie am Modellrisiko-Ausschuss vorbeikommen.

Die ehrlichen Grenzen

Eine Checkliste macht ein System nicht sicher; sie macht die Risiken eines Systems sichtbar und zugewiesen. Sie fängt keinen neuartigen Angriff ab, den noch niemand bedacht hat, und sie kann kein Modell validieren, dessen Anbieter sich weigert, Ergebnistests zu unterstützen. Sie kostet auch etwas Reales: Jede Frage, die Sie hinzufügen, ist Arbeit, die jemand vor dem Start erledigen muss statt nach einem Vorfall. Genau dieser Abwägung wegen lohnt sie sich. Die Institute, die 2026 ins Straucheln geraten, sind nicht jene mit zu vielen Kontrollen am Anfang des Lebenszyklus; es sind jene, die während einer Prüfung entdecken, dass die Kontrollen nie vorhanden waren.

Der rote Faden durch jede der obigen Fragen ist derselbe: Nachvollziehbarkeit bis zu einer abgestimmten Quelle. Governance, Validierung, Aufsicht, Protokollierung – alles bricht in sich zusammen, wenn die zugrunde liegenden Zahlen nicht auf die Bücher zurückgeführt werden können. Das ist kein Richtlinienproblem, aus dem Sie sich herausschreiben können. Es ist eine Architekturentscheidung, die Sie treffen, bevor das erste Modell live geht.

Wenn Ihre KI eine Zahl heute nicht bis zu einem abgestimmten Hauptbuch zurückverfolgen kann, sehen Sie den Unterschied am schnellsten, indem Sie eine dabei beobachten. Demo buchen – und bringen Sie die Zahl mit, die ein Prüfer am wenigsten hinterfragen sollte.