Wo der AI Act über Ihr bestehendes Modellrisikomanagement hinausgeht
Eine Einordnung der Risikocontrolling- und -validierungsfunktionen bei Banken und Versicherern. Was die prudenzielle Validierung bereits leistet — und was der AI Act zusätzlich verlangt.
„Wir haben funktionierendes Modellrisikomanagement . Ich habe aber keinen Überblick darüber, wo der AI Act darüber hinausgeht und wo er sich doppelt auswirkt.“
Diesen Satz hören wir in nahezu jedem ersten Gespräch mit einer Risikocontrolling- oder Validierungsfunktion. Er ist berechtigt. Und er lässt sich präzise beantworten — präziser, als es die meisten Übersichtsartikel zum AI Act tun, die Modellrisiko und algorithmische Fairness pauschal in einen Topf werfen.
Ihre Validierung ist nicht das Problem
Fangen wir dort an, wo Missverständnisse am ehesten entstehen: Ihre bestehende Modellvalidierung wird durch den AI Act nicht infrage gestellt. Sie ist, gemessen an dem, wofür sie entwickelt wurde, streng und ausgereift.
Für IRB-Ratingsysteme gilt die Validierung interner IRB-Ratingsysteme im Kreditrisiko, insbesondere durch etablierte quantitative Kriterien wie die Trennschärfe (z. B. über AUC oder Gini) und die Kalibrierung, also die Übereinstimmung zwischen geschätzter und tatsächlicher Ausfallwahrscheinlichkeit. Für interne Modelle im Rahmen von Solvency II ist ein regelmäßiger Validierungsprozess vorgeschrieben, der Backtesting gegen reale Daten, Stabilitätsanalysen, Sensitivitätsprüfungen zentraler Annahmen, sowie Bewertungen der Datenqualität umfasst. MaRisk AT 4.3.2 bündelt diese Anforderungen zusätzlich organisatorisch. Art. 185 CRR verlangt eine Validierung der internen Schätzungen — mit etablierten quantitativen Standardgrößen wie der Trennschärfe (typischerweise über die AUC/Gini-Statistik) und der Kalibrierung, also der Übereinstimmung von geschätzter und tatsächlich beobachteter Ausfallwahrscheinlichkeit. Für interne Modelle unter Solvency II schreiben Art. 121 (statistische Qualitätsstandards), Art. 122 (Kalibrierungsstandards) und Art. 124 (Validierungsstandards) einen regelmäßigen Validierungszyklus vor: Backtesting gegen tatsächliche Erfahrungswerte, Stabilitätsanalysen, Sensitivitätsprüfungen zentraler Annahmen, Bewertungen der Datenqualität und -vollständigkeit. MaRisk AT 4.3.2 verankert diese Anforderungen zusätzlich institutionell in der Risikocontrolling-Funktion.
Das ist die richtige Fachsprache, exakt angewendet. Der AI Act ersetzt nichts davon.
Die eigentliche Lücke: drei Fragen, die prudenzielle Validierung nie stellen musste
Prudenzielle Validierung beantwortet im Kern eine Frage: Ist das Modell statistisch zuverlässig und sind die daraus resultierenden Kapitalanforderungen angemessen? Der AI Act stellt für Hochrisiko-KI-Systeme drei zusätzliche Fragen, die mit dieser ersten Frage nicht deckungsgleich sind — weder mathematisch noch rechtlich.
Erstens: Algorithmische Fairness gegenüber geschützten Gruppen.
Ein Modell kann eine exzellente Trennschärfe und eine saubere Kalibrierung aufweisen — beides in Aggregation über das Gesamtportfolio — und trotzdem systematisch unterschiedliche Ergebnisse für geschützte Gruppen produzieren, ohne dass dahinter ein tatsächlicher Risikounterschied steht. Das ist keine hypothetische Spannung: Statistische Trennschärfe und Gruppen-Fairness sind, sobald sich Basisraten zwischen Gruppen unterscheiden, mathematisch nicht gleichzeitig in allen gängigen Definitionen erfüllbar (dazu mehr in unserem Artikel zur Chouldechova-Unmöglichkeitsaussage). Art. 10 AI Act verlangt für Hochrisiko-Systeme eine explizite Prüfung der Trainingsdaten auf Bias, der sich nachteilig auf geschützte Merkmale auswirken könnte. Ihre IRB- oder Solvency-II-Validierung prüft das nicht — sie wurde dafür nie konzipiert.
Zweitens: Transparenz gegenüber Betroffenen — nicht gegenüber der Aufsicht.
Ihre Validierungsdokumentation ist für die Risikocontrolling-Funktion, den Vorstand und die Aufsicht geschrieben. Art. 86 AI Act adressiert eine andere Partei: Jede betroffene Person, gegenüber der auf Basis eines Hochrisiko-KI-Systems eine Entscheidung mit erheblicher Wirkung getroffen wird, hat das Recht auf eine klare, verständliche Erklärung der Rolle des Systems und der wesentlichen Entscheidungselemente. Für Kreditwürdigkeitsprüfung und Risikobewertung/Prämiengestaltung in der Lebens- und Krankenversicherung — beide ausdrücklich in Anhang III, Ziffer 5(b) und 5(c) genannt — heißt das: Der Kunde, dessen Kreditantrag oder Versicherungsprämie durch das Modell beeinflusst wurde, hat einen eigenen, individuellen Anspruch. Kein bestehendes Validierungsartefakt deckt das ab, weil keines dafür geschrieben wurde.
Drittens: die Grundrechtsdimension als eigenes Risikoregister.
Art. 9 Abs. 2 lit. a AI Act verlangt für Hochrisiko-Systeme ausdrücklich die Identifikation von Risiken für „Gesundheit, Sicherheit oder Grundrechte“ — eine kategorial andere Risikokategorie als Kredit-, Markt- oder versicherungstechnisches Risiko. Und für genau Ihre Systeme wird das konkret: Art. 27 AI Act verpflichtet Betreiber von Hochrisiko-Systemen nach Anhang III Ziffer 5(b) (Kreditwürdigkeitsprüfung) und 5(c) (Risikobewertung/Prämiengestaltung Lebens-/Krankenversicherung) zu einer Grundrechte-Folgenabschätzung (Fundamental Rights Impact Assessment) vor der ersten Inbetriebnahme — unabhängig davon, ob Sie ein öffentliches oder privates Institut sind. Das ist ein eigenständiges, neues Artefakt: Betroffene Personengruppen, spezifische Schadensrisiken, menschliche Aufsichtsmaßnahmen und Beschwerdemechanismen müssen dokumentiert werden. Es gibt in der prudenziellen Validierung keine Entsprechung, aus der sich das ableiten ließe.
Die gute Nachricht: der Gesetzgeber hat Doppelarbeit mitgedacht
Das ist kein Zufall und kein Kulanzargument unsererseits — es steht so im Text. Erwägungsgrund 158 des AI Act hält ausdrücklich fest, dass es für Kreditinstitute unter Richtlinie 2013/36/EU (CRD) und für Versicherungs-/Rückversicherungsunternehmen unter Solvency II angemessen ist, die verfahrensbezogenen Pflichten zu Risikomanagement, Marktbeobachtung nach Inverkehrbringen und Dokumentation in die bestehenden Verfahren zu integrieren — mit dem ausdrücklichen Ziel, Doppelarbeit zu vermeiden. Praktisch bedeutet das: Das AI-Act-Risikomanagementsystem nach Art. 9 sollte in Ihrer bestehenden Risikocontrolling-Governance verankert werden, nicht als parallele Struktur daneben aufgebaut werden.
Auch aufsichtlich bleibt Vertrautes vertraut: Für Hochrisiko-KI-Systeme, die von aufsichtsrechtlich beaufsichtigten Finanzinstituten eingesetzt werden, ist die zuständige Marktüberwachungsbehörde nach dem AI Act dieselbe nationale Behörde, die bereits für Ihre prudenzielle Aufsicht zuständig ist. Für die meisten deutschen Häuser bleibt das also BaFin — kein neuer Ansprechpartner, keine zweite Aufsichtsbeziehung.
Was tatsächlich neu entstehen muss
Drei Artefakte lassen sich nicht aus bestehender Validierungsdokumentation ableiten, sondern müssen eigenständig aufgebaut werden:
→ Ein wiederkehrender, dokumentierter Fairness-Test über geschützte Gruppen hinweg — Gruppenfairness und individuelle Fairness, mit explizit dokumentierten Trade-off-Entscheidungen, nicht als einmalige Prüfung, sondern als fester Bestandteil des Validierungszyklus.
→ Ein operativer Prozess für individuelle Erklärungen nach Art. 86 — organisatorisch etwas anderes als technische Dokumentation für die Aufsicht, weil er auf Anfrage einzelner Betroffener reagieren muss, nicht auf eine jährliche Prüfung.
→ Die Grundrechte-Folgenabschätzung nach Art. 27 selbst, für Kreditscoring- und Lebens-/Krankenversicherungs-Pricing-Systeme, als eigenständiges Dokument vor Erstinbetriebnahme.
Das ist überschaubarer Zusatzaufwand, wenn er in die bestehende Governance integriert wird — und erheblicher Mehraufwand, wenn er parallel dazu neu aufgebaut wird.
Zur Einordnung von Vendor-Fragen
Ein Punkt, der in Erstgesprächen regelmäßig vor der inhaltlichen Frage kommt: Bias- und Fairness-Tests bedeuten in der Praxis oft, dass ein externer Dienstleister Zugriff auf sensible Portfoliodaten erhält — was die eigene MaRisk-AT-9-Auslagerungsprüfung und die DORA-Bewertung des IKT-Drittparteienrisikos auslöst, bevor überhaupt ein Test stattgefunden hat. Wir haben waveTest deshalb so gebaut, dass die Berechnung client-seitig in einem Docker-Container in Ihrer eigenen Infrastruktur läuft; nur Prüfergebnisse und Reporting verlassen das Haus. Technisch heißt das: Ihre Portfoliodaten verlassen zu keinem Zeitpunkt Ihre Systeme. Governance-seitig heißt das: eine wesentlich schlankere Auslagerungsprüfung, weil kein Drittparteienzugriff auf die zugrundeliegenden Daten entsteht.
Zum Weiterdenken
Die Frage, mit der CROs und Validierungsfunktionen tatsächlich ringen, ist selten „müssen wir das machen“ — sie ist „wo genau hört unser bestehendes Rahmenwerk auf, und wo fangen wir wirklich bei null an“. Unsere Erfahrung: Wer diese Grenze einmal präzise zieht, stellt fest, dass der Zusatzaufwand kleiner ist als befürchtet — vorausgesetzt, man dupliziert nicht versehentlich, was ohnehin schon gut funktioniert.
Wie ist bei Ihnen die Grundrechte-Folgenabschätzung nach Art. 27 aktuell verortet — bei der Risikocontrolling-Funktion, bei Compliance, oder noch nirgends?
Quellen
MaRisk (aktuelle Fassung, 29.05.2024 — Achtung: 9. Novelle aktuell in Konsultation, Frist 08.05.2026, mit teils grundlegender Neustrukturierung der Proportionalität): https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Rundschreiben/2024/rs_06_2024_MaRisk_BA.html
IRB-Validierung — Primärquelle Art. 185 CRR (EUR-Lex, Verordnung (EU) Nr. 575/2013): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32013R0575
Ergänzend die EBA-Praxisleitlinie zur Validierung (konkretisiert Trennschärfe/AUC, Kalibrierung methodisch): https://www.eba.europa.eu/sites/default/files/document_library/Publications/Reports/2023/1061495/Supervisory%20handbook%20on%20the%20validation%20of%20IRB%20rating%20systems%20revised.pdf
Solvency-II-Validierung — Art. 121, 122, 124 (EUR-Lex, Richtlinie 2009/138/EG): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32009L0138
Art. 10, Art. 9 Abs. 2 lit. a, Art. 27, Art. 86 AI Act sowie Erwägungsgrund 158 — alle aus derselben konsolidierten Quelle (EUR-Lex, Verordnung (EU) 2024/1689): https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ%3AL_202401689
EUR-Lex verlinkt nicht direkt zu einzelnen Artikeln oder Erwägungsgründen — nur zum Gesamtdokument. Für schnelles Nachschlagen einzelner Artikel im Alltag ist die von der KI-Community breit genutzte, inoffizielle, aber zuverlässige Referenzseite praktischer: https://artificialintelligenceact.eu/the-act/
Richtlinie 2013/36/EU (CRD) (EUR-Lex): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32013L0036
DORA-Bewertung des IKT-Drittparteienrisikos — Primärquelle (EUR-Lex, Verordnung (EU) 2022/2554): https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554
Die deutschsprachige BaFin/Bundesbank-Einordnung zum Übergang BAIT/VAIT → DORA: https://www.bundesbank.de/de/aufgaben/finanzaufsicht/einzelaspekte/risikomanagement/bait-dora-598580