Erklärbarkeit und Prüfbarkeit von KI im Finanzwesen

Von Jane Ha · Aktualisiert am 11. Oktober 2026

Erklärbarkeit und Prüfbarkeit von KI im Finanzwesen sind zwei getrennte Zusagen: Sie können sagen, warum das System ein bestimmtes Ergebnis geliefert hat (Erklärbarkeit), und Sie können im Nachhinein belegen, was das System getan hat, mit welchen Eingaben, in welcher Version und wer es geprüft hat (Prüfbarkeit). Aufsichtsbehörden, Prüfer und Kunden stützen sich jeweils auf eine andere Hälfte. Ein Kreditantragsteller will den Grund für eine Ablehnung wissen. Ein Prüfer will die Nachweiskette sehen. Ein Modellrisikoteam will beides, dazu den Beleg, dass jemand Unabhängiges das Modell hinterfragt hat.

Dieser Leitfaden richtet sich an CFOs, Leiter Rechnungswesen (Controller), Risikoverantwortliche und Finanzmanager, die KI in Kredit-, Betrugs-, Prognose-, Abschluss- oder Berichtsprozesse einbauen. Die allgemeine Definition der Technik selbst finden Sie unter Was ist erklärbare KI?. Dieser Beitrag behandelt den finanzspezifischen Teil: was erklärt werden muss, wem gegenüber und was Sie dokumentiert vorhalten müssen.

Wichtige Fakten

• Regulation B verlangt, dass eine Begründung für eine ablehnende Kreditentscheidung „konkret sein und den Hauptgrund bzw. die Hauptgründe nennen muss“, und Begründungen, die sich auf interne Standards oder einen verfehlten Schwellenwert im Credit Scoring stützen, genügen nicht (12 CFR 1002.9).
• Die interbehördliche Leitlinie zum Modellrisiko vom April 2026, SR 26-2, ersetzt SR 11-7 und dürfte vor allem für Bankengruppen mit einer Bilanzsumme von mehr als 30 Milliarden Dollar relevant sein (Federal Reserve).
• Diese Leitlinie nimmt generative und agentische KI-Modelle aus ihrem Anwendungsbereich aus, während ihre Grundsätze für traditionelle statistische Modelle und nicht generative, nicht agentische KI gelten (Anlage zu SR 26-2).
• Der EU AI Act stuft KI-Systeme, die die Kreditwürdigkeit natürlicher Personen bewerten oder deren Kredit-Score festlegen sollen, als hochriskant ein und verlangt, dass solche Systeme über ihre Lebensdauer hinweg die automatische Aufzeichnung von Ereignissen (Logs) technisch ermöglichen (Annex III, Artikel 12).
• Das NIST trennt die beiden Begriffe: Erklärbarkeit ist die Darstellung der Mechanismen, die dem Betrieb eines Systems zugrunde liegen, während Interpretierbarkeit die Bedeutung seiner Ausgabe im Kontext seines vorgesehenen Zwecks ist (NIST AI RMF 1.0).

Warum das Finanzwesen KI an einem höheren Maßstab misst

Die meisten Unternehmensbereiche kommen mit einem Modell zurecht, das funktioniert, aber nicht sagen kann, warum. Das Finanzwesen meist nicht, und zwar aus drei Gründen.

Entscheidungen bringen rechtliche Pflichten mit sich. Lehnt ein Kreditgeber einen Antragsteller ab, verlangen die US-Vorschriften einen konkreten Grund. Der Grund muss widerspiegeln, was die Entscheidung tatsächlich bestimmt hat, nicht ein allgemeines Etikett.

Zahlen fließen in Berichte ein, auf die sich Dritte verlassen. Wenn ein Modell eine Rückstellung festlegt, eine Flux-Erklärung entwirft oder Hauptbuchposten abgleicht, muss jemand dem Prüfer zeigen können, wie diese Zahl entstanden ist. Die Kontrollseite davon behandelt KI und interne Kontrollen. Dieser Beitrag widmet sich der Schicht darunter: der Dokumentation und den Aufzeichnungen, die eine Kontrolle überhaupt prüfbar machen.

Fehler sind teuer und werden spät gefunden. Eine abdriftende Prognose oder ein verzerrtes Scoring-Modell kann monatelang laufen, bevor es jemand bemerkt, und der einzige Weg, das Geschehen zu rekonstruieren, sind aufbewahrte Aufzeichnungen.

Was Aufsichtsbehörden und Prüfer tatsächlich erwarten

Die Erwartungen unterscheiden sich nach Rechtsraum und Anwendungsfall, daher lohnt es sich, sie auseinanderzuhalten.

Kreditentscheidungen (USA). Regulation B, die den Equal Credit Opportunity Act umsetzt, verpflichtet einen Kreditgeber, einem abgelehnten Antragsteller die Hauptgründe konkret mitzuteilen. Die Vorschrift räumt dem Kreditgeber 30 Tage nach Eingang eines vollständigen Antrags ein, um den Antragsteller über die getroffene Entscheidung zu informieren (12 CFR 1002.9). Die praktische Folge für KI: Wenn Ihr Modell keine Gründe liefert, für die Sie geradestehen können, haben Sie ein Compliance-Problem, wie genau das Modell auch sein mag. Nachträgliche Erklärverfahren nähern ein Modell nur an, statt es nachzubilden, daher muss das Team prüfen können, ob die Annäherung getreu ist.

Modellrisikomanagement (US-Banken). Die Leitlinie von 2011, SR 11-7, wurde durch SR 26-2 ersetzt. Diese verfolgt einen risikobasierten Ansatz und beschreibt wirksame Hinterfragung (Effective Challenge) als kritische Analyse durch objektive Fachleute, durchgeführt von Personen mit der nötigen Expertise, ausreichender Unabhängigkeit und der Stellung, Änderungen durchzusetzen. Sie hält außerdem fest, dass ein wirksames Modellinventar genügend Informationen enthält, um das Modellrisiko auf Einzel- und Gesamtebene zu verstehen, und dass angemessene Dokumentation ein wirksames Modellrisikomanagement stützt (SR 26-2). Die Leitlinie nimmt generative und agentische KI aus ihrem Anwendungsbereich aus, sagt aber zugleich, dass die eigenen Governance-Praktiken einer Bank die Kontrollen für nicht erfasste Werkzeuge leiten sollten. Wenn Sie ein kleineres Institut oder ein Finanzteam in einem Unternehmen sind, behandeln Sie sie als bewährte Vorlage und nicht als Regelwerk.

Modelle von Anbietern. Dieselbe Leitlinie sagt, zur soliden Praxis gehöre, die konzeptionelle Stimmigkeit, das Design, die Entwicklungsdaten und die Leistung eines Anbietermodells zu verstehen und seine Ergebnisse zu überwachen, auch wenn der Anbieter Code oder Daten zurückhält (SR 26-2). „Der Anbieter sagt, es sei genau“ ist keine Dokumentation.

EU. Das Credit Scoring natürlicher Personen ist nach Annex III des AI Act ein Hochrisiko-Einsatz, und Hochrisiko-Systeme müssen über ihre Lebensdauer hinweg die automatische Protokollierung technisch ermöglichen (Annex III, Artikel 12). Der Zeitplan des Gesetzes wurde geändert, und der aktuelle konsolidierte Text nennt den 2. Dezember 2027 als Anwendungsdatum für Systeme nach Annex III (Artikel 12). Rechtsteams sollten den Stand für ihre eigene Situation bestätigen, aber die technische Lehre ist in beiden Fällen dieselbe: Bauen Sie die Protokollierung jetzt ein, denn das Nachrüsten ist schwieriger.

Abschlussprüfer der Finanzberichterstattung. Externe Prüfer fragen nicht abstrakt nach Modellinterna. Sie wollen wissen, dass der KI-Schritt ein bekannter Teil eines dokumentierten Prozesses ist, für den es einen Verantwortlichen gibt, und dass jemand das Ergebnis nachweislich geprüft hat.

Erklärbarkeit nach Funktion: Was „erklärt“ in der Praxis bedeutet

„Erklärbar“ ist nicht eine einzige Sache. Die richtige Erklärung hängt davon ab, wer fragt und was auf dem Spiel steht.

Das Muster in der Tabelle ist immer dasselbe. Erklärung betrifft Treiber und Grundlage, Prüfbarkeit betrifft die Aufzeichnung. Ein Modell kann das eine ohne das andere haben: Ein einfacher regelbasierter Scorer ist leicht zu erklären, für einen Prüfer aber trotzdem nutzlos, wenn er nichts protokolliert.

Das Erklärwerkzeug und seine Grenzen

Zwei Verfahren tauchen bei komplexen Modellen ständig auf. SHAP „weist jedem Merkmal einen Wichtigkeitswert für eine bestimmte Vorhersage zu“ (Lundberg und Lee). LIME erklärt eine einzelne Vorhersage, indem es ein einfaches, interpretierbares Modell in der Umgebung dieser Vorhersage anpasst und das zugrunde liegende Modell als Blackbox behandelt (Ribeiro et al.).

Beide helfen bei der Frage „Warum dieses Ergebnis“. Keines ersetzt Governance, und das aus drei Gründen:

• Sie erklären eine Vorhersage, nicht die Eignung des Modells. Eine saubere Erklärung eines verzerrten Scores bleibt ein verzerrter Score.
• Sie sind Annäherungen. Behandeln Sie das Ergebnis als Evidenz, die zu validieren ist, nicht als tatsächliche Argumentation des Modells.
• Sie liefern von sich aus keine kundentaugliche Begründung. Jemand muss die Faktorbeiträge den Hauptgründen zuordnen, die eine Mitteilung wahrheitsgemäß nennen kann.

Bei folgenreichen Entscheidungen lohnt es sich zu testen, ob ein einfacheres Modell kaum an Genauigkeit einbüßt, denn ein Modell, das Sie direkt einsehen können, lässt sich leichter verteidigen als eines, das Sie annähern müssen.

Dokumentation, die standhält: Model Cards und Inventare

Eine Model Card ist ein kurzes Dokument, das ein Modell begleitet. Der ursprüngliche Vorschlag beschreibt Cards als Dokumentation der gemessenen Leistung unter verschiedenen Bedingungen, des vorgesehenen Einsatzkontexts und der Art der Evaluierung, damit Nutzer wissen, wo das Modell funktioniert und wo nicht (Mitchell et al.). Die Autoren konzentrieren sich auf Bild- und Sprachmodelle und sagen, die Idee gelte für jedes trainierte Modell. Für ein Finanzteam lässt sich die Idee unmittelbar übertragen. Das allgemeine Format finden Sie unter KI-Model-Cards.

Eine Finanzversion könnte Folgendes enthalten:

1. Zweck und Verantwortlicher. Welche Entscheidung oder welchen Prozess das Modell unterstützt und wer der benannte Fachverantwortliche ist.
2. Vorgesehene und ausgeschlossene Nutzung. Zum Beispiel: „bewertet unbesicherte Verbraucheranträge; nicht für Kredite an Kleinunternehmen.“
3. Daten. Trainingsquellen, Zeitfenster, bekannte Lücken und die angewandten Ausschlüsse.
4. Methode in einem Absatz. Modelltyp, wichtige Merkmale und wie Ausgaben in Entscheidungen übersetzt werden.
5. Leistung. Genauigkeitsmaße, Toleranz, Ergebnisse nach Segment und der Backtest gegen Ist-Werte.
6. Erklärmethode. Wie Gründe oder Treiber erzeugt werden und wie getreu sie nachweislich waren.
7. Grenzen und bekannte Fehlerbilder. Wo es schwach ist und was die manuelle Bearbeitung auslöst.
8. Kontrollen. Prüfer, Schwellenwerte, Rückfalllösung bei Ausfall und Änderungshistorie.
9. Validierung. Wer das Modell hinterfragt hat, wann und mit welchen Befunden.

Ergänzen Sie die Cards durch ein Inventar: eine Liste aller eingesetzten Modelle und KI-Werkzeuge mit Verantwortlichem, Zweck, Stufe und Ablageort der Card. SR 26-2 selbst hält fest, dass ein wirksames Inventar genügend Informationen enthält, um das Modellrisiko zu verstehen, und genau an diesem Maßstab sollten Sie Ihres messen. Bei Anbieterwerkzeugen bleibt die Card teilweise leer. Schreiben Sie das auf, statt es offen zu lassen, und entscheiden Sie, ob die Lücken für das Risiko vertretbar sind.

Prüfpfade: Die Aufzeichnung dessen, was tatsächlich geschah

Dokumentation sagt, was ein System tun soll. Ein Prüfpfad zeigt, was es an einem bestimmten Tag getan hat. Der Protokollierungsgrundsatz der EU-Regel ist ein guter allgemeiner Maßstab: Ereignisse über die Lebensdauer des Systems so aufzeichnen, dass Überwachung und Untersuchung möglich sind (Artikel 12). Eine vertiefte Behandlung von Prüfpfaden, wenn KI Aktionen in Systemen ausführt, finden Sie unter Prüfpfade für KI-Aktionen.

Ein brauchbarer Prüfpfad im Finanzwesen erfasst für jeden wesentlichen, von KI beeinflussten Vorgang:

• Eingabe: die Daten oder das Dokument, die das System erhalten hat, oder ein Verweis darauf
• Version: Modell, Prompt oder Regelsatz und die damals gültige Konfiguration
• Ausgabe: der erzeugte Score, Buchungssatz, Hinweis oder Text
• Erklärung: die dazu erzeugten Treiber oder Gründe
• Menschliche Aktion: wer es geprüft hat, was er geändert oder übersteuert hat und wann
• Folgeergebnis: die Entscheidung, Buchung oder Mitteilung, die darauf folgte

Die Aufbewahrung sollte zur gestützten Aufzeichnung passen. Fragen Sie Ihre Records- und Rechtsteams, wie lange Kreditakten, Buchungsbelege und Arbeitspapiere aufzubewahren sind, und stellen Sie sicher, dass die KI-Logs nicht früher gelöscht werden. Der Umgang mit diesen Logs ist ein eigenes Thema, das Datensicherheit bei KI im Finanzwesen behandelt.

So bauen Sie Erklärbarkeit und Prüfbarkeit auf, Schritt für Schritt

1. Erfassen Sie jedes Modell und jedes KI-Werkzeug im Finanzwesen. Berücksichtigen Sie auch Anbieterfunktionen, die in bestehenden Systemen eingeschaltet sind. Was Sie nicht gefunden haben, können Sie nicht dokumentieren.

   

2. Stufen Sie nach Tragweite ein. Ein Modell, das das Kreditergebnis eines Kunden oder eine Rückstellung bestimmt, gehört in eine strengere Stufe als ein Werkzeug, das eine interne Zusammenfassung entwirft.

3. Legen Sie die Erklärungsanforderung pro Stufe fest. Benennen Sie, wer eine Erklärung erhalten können muss, wie schnell und in welcher Form (Kundenmitteilung, Analystenansicht, Arbeitspapier für den Prüfer).

4. Wählen Sie Modelle mit Blick auf die Anforderung. Prüfen Sie für die oberste Stufe, ob ein transparenteres Modell fast ebenso genau ist, bevor Sie eine Blackbox akzeptieren.

5. Schreiben Sie die Model Card vor dem Go-live. Machen Sie die Freigabe zum Start davon abhängig, dass eine vollständige Card und ein benannter Verantwortlicher vorliegen.

6. Holen Sie eine unabhängige Hinterfragung ein. Jemand mit der richtigen Expertise und Unabhängigkeit prüft das Modell und seine Erklärmethode und kann Änderungen verlangen.

7. Schalten Sie die Protokollierung vom ersten Tag an ein. Erfassen Sie Eingaben, Versionen, Ausgaben, Erklärungen und menschliche Aktionen. Testen Sie, ob Sie eine einzelne Entscheidung anhand der Logs von Anfang bis Ende rekonstruieren können.

8. Führen Sie eine Rekonstruktionsübung durch. Wählen Sie zehn frühere Entscheidungen zufällig aus und lassen Sie jemanden außerhalb des Entwicklungsteams jede allein anhand der Aufzeichnungen erklären. Lücken zeigen sich schnell.

9. Überwachen und neu dokumentieren. Verfolgen Sie Genauigkeit, Drift und Übersteuerungsquoten. Aktualisieren Sie die Card und lassen Sie das Modell erneut hinterfragen, wenn sich Modell, Daten oder Einsatz ändern. Anregungen zur Überwachung finden Sie unter Genauigkeitskontrollen für KI im Finanzwesen.

Häufige Fallstricke

• Das Modell erklären, aber nicht die Entscheidung. Die globale Merkmalswichtigkeit beantwortet nicht, warum dieser Antragsteller abgelehnt oder dieser Buchungssatz markiert wurde.
• Pauschale Gründe. Den nächstliegenden Grund aus einer Checkliste zu versenden, obwohl der wahre Treiber ein anderer ist, besteht die Konkretheitsprüfung nach Regulation B nicht.
• Dem Erklärwerkzeug blind vertrauen. Nachträgliche Verfahren nähern das Verhalten nur an. Testen Sie sie an bekannten Fällen.
• Die Model Card als einmaliges PDF. Eine Card, die sich nicht ändert, wenn sich das Modell ändert, wird zu einer falschen Aufzeichnung.
• Logs ohne Versionen. Zu wissen, wie die Ausgabe lautete, nützt nichts, wenn Sie nicht erkennen können, welches Modell oder welcher Prompt sie erzeugt hat.
• Intransparenz des Anbieters standardmäßig hinnehmen. „Proprietär“ ist ein Grund, die Ergebnisse genauer zu überwachen, nicht, auf Dokumentation zu verzichten.
• Prüfung ohne Nachweis. Ein Prüfer, der freigibt, aber nicht festhält, was er geprüft hat, gibt dem Abschlussprüfer nichts zum Testen.
• Erklärbarkeit erst nach dem Start. Logs und Dokumentation nachzurüsten kostet weit mehr, als sie von Anfang an einzuplanen.

Was Sie messen sollten

• Abdeckung: Anteil der Modelle und KI-Werkzeuge mit Verantwortlichem, Stufe und aktueller Card
• Rekonstruktionsquote: Anteil der Stichprobenentscheidungen, die sich allein aus den Logs vollständig erklären lassen
• Erklärungsqualität: wie oft Prüfer oder Validierer die erzeugten Gründe als ungenau oder zu vage zurückweisen
• Übersteuerungsquote: wie oft Menschen die Ausgabe ändern und warum
• Aktualität: Zeit seit der letzten Aktualisierung jeder Card und Validierung, gemessen am Änderungsprotokoll
• Abschluss von Feststellungen: Zeit bis zur Behebung von Validierungs- und Prüfungsfeststellungen

Wie es weitergeht

Beginnen Sie mit dem Inventar und der Stufeneinteilung, schreiben Sie dann Cards für Ihre oberste Stufe und führen Sie eine Rekonstruktionsübung durch. Wenn Sie noch klären, wo KI hinpasst, bietet KI im Finanz- und Rechnungswesen den größeren Überblick.