AI‑Modell‑Governance im Alltag: Wie MaRisk, EBA, EGIM und BCBS 239 den AI‑Act für Hochrisiko‑AI vorstrukturieren

Banken stehen heute vor einer doppelten Herausforderung: Das Modellportfolio wächst – von IRB‑, Marktpreis‑ und Stresstest‑Modellen bis hin zu AI‑gestützten Kredit‑Scorings und Fraud‑Erkennung – und gleichzeitig verdichten sich die aufsichtsrechtlichen Anforderungen. MaRisk, EBA‑Leitlinien, EGIM und BCBS 239 sind längst etabliert, der EU‑AI‑Act kommt als zusätzliche Schicht obenauf. Was lange getrennt betrachtet wurde, gehört inzwischen zusammen: Modelle, Daten, Governance und Verantwortung. Dieser Beitrag zeigt, wie Institute eine Brücke von den bestehenden Rahmenwerken hin zum AI‑Act schlagen können – und warum es sinnvoll ist, Hochrisiko‑AI nicht als Sonderwelt, sondern als integralen Teil der Modell‑Governance zu behandeln.

Das Wichtigste in Kürze

Bestehende Regelwerke (MaRisk, EBA‑Guidelines, EGIM) definieren bereits zentrale Elemente der Modell‑Governance: Modellinventar, Rollen, unabhängige Validierung, Dokumentation und Einbettung in Entscheidungsprozesse.

BCBS 239 und MaRisk AT 4.3.4 liefern das Daten‑Fundament, auf dem wesentliche interne Risiko‑Modelle – und damit auch AI‑Modelle – aufsetzen: Datenqualität, Aggregierbarkeit, Transparenz und klare Verantwortlichkeiten.

Der EU‑AI‑Act ergänzt diese etablierten Rahmenwerke um AI‑spezifische Anforderungen, insbesondere für Hochrisiko‑AI‑Systeme (z.B. Kreditscoring natürlicher Personen): lebenszyklusbezogenes Risikomanagement, Daten‑Governance, Human Oversight, Genauigkeit/Robustheit/Cybersicherheit, Qualitätsmanagement und Konformitätsbewertung.

Institute, die ihre Modell‑ und Daten‑Governance bereits entlang von MaRisk/EBA/EGIM und BCBS 239 aufgebaut haben, können einen Großteil der AI‑Act‑Pflichten in bestehenden Strukturen verankern – mit gezielten Erweiterungen statt einem kompletten Neubau. Gleichzeitig zwingt der AI‑Act zu neuen inhaltlichen Fähigkeiten, etwa bei Fairness‑Messung, Bias‑Analytik, Grundrechts‑Bewertung und technischer Dokumentation.

Ausgangspunkt: Vieles ist schon da

Wer heute auf MaRisk AT 4.3.5 blickt, erkennt viele Elemente wieder, die der AI‑Act für Hochrisiko‑AI fordert. Modelle müssen regelmäßig validiert, auf Genauigkeit, Stabilität und Konsistenz geprüft, in ihren Annahmen verstanden und in ihrer Verwendung gesteuert werden. Der AI‑Act verschiebt hier weniger die Grundlogik, sondern macht aus dem allgemeinen Modellrisiko‑Gedanken ein lebenszyklusbezogenes Risikomanagement speziell für AI‑Systeme: Aus „regelmäßige Validierung“ wird ein durchgängiger Prozess, der von der Konzeption über das Training bis zum laufenden Monitoring reicht; aus „Dokumentation“ werden technische Dossiers und Logs, die auch für Konformitätsbewertungen taugen.

Ähnlich verhält es sich mit den EBA‑Guidelines für Loan Origination & Monitoring. Sie verlangen schon heute, dass Institute die eingesetzten Bewertungs‑ und Scoring‑Modelle verstehen, dokumentieren und überwachen – mit besonderem Augenmerk auf Nachvollziehbarkeit und Interpretierbarkeit. Der AI‑Act setzt hier an, aber erweitert den Fokus: Wo EBA‑LOM vor allem auf die sachgerechte Nutzung im Kreditprozess schaut, rückt der AI‑Act zusätzlich die Qualität der Trainings‑, Validierungs‑ und Testdaten in den Vordergrund und fordert explizit Verfahren zur Bias‑Reduktion. Die Linie verläuft also nicht „früher keine Regeln, jetzt AI‑Act“, sondern eher „bisher Modell‑Governance im Kreditprozess, jetzt zusätzlich Daten‑ und Fairness‑Governance für AI“. Für viele Institute ist genau dieser Fairness‑ und Grundrechts‑Fokus fachlich neu – organisatorisch lässt er sich aber gut an bestehende Validierungs‑ und Compliance‑Strukturen andocken.

Modelle, Daten, Governance – im Zusammenspiel mit dem AI‑Act

Modell‑Governance: MaRisk/EGIM trifft Art. 9, 11, 14, 15

Wenn MaRisk AT 4.3.5 vorschreibt, dass Modelle in einem Inventar geführt, mit klaren Rollen versehen und regelmäßig validiert werden, dann steckt darin bereits der Keim für ein AI‑Risikomanagement nach Art. 9 AI‑Act. Anstatt ein völlig neues AI‑Register zu erfinden, können Institute ihr bestehendes Modellinventar um Kennzeichnungen für AI‑Modelle und Hochrisiko‑AI ergänzen. Auf Model‑Owner, Validator und unabhängige Überprüfung baut der AI‑Act quasi auf, wenn er Human‑Oversight‑Konzepte und technische Robustheitsanforderungen fordert: die gleiche Governance‑Linie, nur mit einem feineren Pinsel für AI.

Umgekehrt zwingt der AI‑Act die Institute, einige MaRisk‑Themen zu schärfen. Human Oversight nach Art. 14 ist mehr als ein vages „Sachbearbeiter kann eingreifen“. Es verlangt klare Regeln, wann Eingriffe erforderlich sind, wie Overrides dokumentiert werden und wie sichergestellt wird, dass Menschen Modellergebnisse tatsächlich verstehen. Die abstrakte Vorgabe aus MaRisk, Modellergebnisse „sachgerecht“ zu verwenden, wird damit zu einem konkreten Design‑Thema: Welche Informationen, Erklärungen und Warnhinweise braucht ein Nutzer, um ein AI‑Scoring kompetent beurteilen zu können – und wie stellen wir sicher, dass diese Informationen tatsächlich genutzt werden?

EGIM unterstützt diesen Schulterschluss. Der Guide verlangt ein vollständiges Modellinventar, unabhängige Validierung, risikoorientierte Prüfzyklen und eine Einbettung in Entscheidungs‑ und Limitstrukturen. Genau diese Struktur lässt sich nutzen, um AI‑Act‑Kontrollen zu verankern: Das etablierte Freigabe‑ und Change‑Verfahren wird um AI‑spezifische Prüffragen ergänzt, Validierungsberichte nehmen AI‑Risiken explizit auf, und die Rollenverteilung der Three Lines of Defence wird für AI‑Systeme konkretisiert. Die „neue“ Konformitätsbewertung des AI‑Acts muss nicht neben dem EGIM‑Prozess stehen, sondern kann in ihn eingebettet werden – erfordert aber zusätzlich technische Dossiers und Evidenz, die viele Häuser in dieser Tiefe bisher nicht vorhalten.

Daten‑Fundament: BCBS 239/AT 4.3.4 und Art. 10 im Dialog

Auf der Datenseite ist das Zusammenspiel ähnlich deutlich. BCBS 239 und MaRisk AT 4.3.4 bestehen darauf, dass Risikodaten genau, vollständig, rechtzeitig und aggregierbar sind – mit klaren Verantwortlichkeiten und Prozessen. Der AI‑Act knüpft daran an, verlagert den Schwerpunkt aber auf die Datensätze, mit denen AI‑Systeme trainiert und getestet werden. Repräsentativität, Eignung für den vorgesehenen Zweck und Bias‑Reduktion ergänzen die klassische Datenqualitäts‑Trias.

In der Praxis bedeutet das: Wo BCBS 239 Data Lineage über Risikoberichte hinweg fordert, braucht der AI‑Act eine Art „Lineage nach innen“– von der Quelle über die Vorverarbeitung bis zur Einbringung in Trainings‑ und Testdatensätze. Die gleiche Datenplattform, die heute LCR‑ oder IRB‑Reports speist, kann auch AI‑Trainingsdaten liefern. Der Unterschied: Für AI müssen nicht nur Vollständigkeit und Konsistenz nachweisbar sein, sondern auch, warum bestimmte Gruppen wie oft im Trainingsdatensatz vorkommen, welche Fairness‑Metriken verwendet werden und welche Maßnahmen gegen Verzerrungen ergriffen wurden. Das ist mehr ein neuer Blick auf bekannte Daten als ein völlig neuer Datenhaushalt – aber es verlangt neue analytische Fähigkeiten im Data‑Science‑ und Risk‑Team.

Hochrisiko‑AI in der Kreditvergabe: Ein Spezialfall, der ins etablierte Framework passt

Kaum ein Beispiel zeigt das Zusammenspiel besser als ein AI‑basiertes Kreditscoring für natürliche Personen. Aus Sicht des AI‑Acts ist der Fall klar: Der Einsatz zur Bewertung der Kreditwürdigkeit natürlicher Personen macht das System zu einer Hochrisiko‑AI. Die Konsequenz: Risikomanagement, Daten‑Governance, Human Oversight, Dokumentation, Logging, Qualitätsmanagement und Konformitätsbewertung sind Pflicht. Gleichzeitig stellt sich die Frage, wie die Rollen im AI‑Act (z.B. Provider vs. Deployer des Systems) mit den bankinternen Rollen (Modellverantwortliche, IT, Fachbereich) zusammenspielen – auch das muss im Governance‑Setup explizit geklärt werden.

Aus Sicht der bestehenden Aufsichtsrahmen ist das Scoring jedoch zunächst einfach ein Modell. Es muss im Modellinventar stehen, MaRisk‑konforme Rollen haben, validiert und im Regelbetrieb überwacht werden. Die EBA‑Guidelines on Loan Origination & Monitoring verlangen, dass Fachbereiche Methodik, Daten und Leistungsfähigkeit verstehen und dokumentieren, und dass Entscheidungen auf Basis dieses Modells nachvollziehbar sind. EGIM und interne Governance‑Leitlinien verteilen Verantwortung entlang der Three Lines of Defence, die Interne Revision schaut darauf, ob all das auch gelebt wird.

Spannend wird es im Zusammenspiel der Anforderungen: Wenn MaRisk und EBA LOM fordern, dass ein Scoring‑Modell fachlich nachvollziehbar und methodisch valide ist, dann verlangt der AI‑Act zusätzlich, dass diese Nachvollziehbarkeit auch aus technischer Sicht dokumentiert wird – etwa in Form von Modellkarten, Erklärungen der Feature‑Nutzung und Grenzen des Systems. Wo BCBS 239 und AT 4.3.4 sicherstellen, dass die Daten für das Scoring korrekt, vollständig und gut aggregierbar sind, verlangt Art. 10 AI‑Act darüber hinaus den Nachweis, dass Trainings‑ und Testdaten repräsentativ sind und keine systematischen Benachteiligungen bestimmter Gruppen verschärfen. Die bisherige Praxis, dass Sachbearbeiter kritische Scorings „mit gesundem Menschenverstand“ prüfen, wird durch Art. 14 in ein formales Human‑Oversight‑Konzept überführt: mit klaren Override‑Regeln, Eskalationspfaden und Dokumentationspflichten.

Am Ende bleibt das Kreditscoring organisatorisch „nur ein weiteres Modell“ – aber eben eines, dass eine zusätzliche AI‑Act‑Schicht trägt. Genau diese Perspektive hilft, Aufwand zu begrenzen: Statt ein neues Governance‑Gebäude zu bauen, wird ein etabliertes Stockwerk um AI‑Räume erweitert. Allerdings ist diese Erweiterung kein reines „Paperwork‑Upgrade“: Sie bringt neue Prüfobjekte (Fairness, Grundrechte, erklärbare Entscheidungen) in das Validierungs‑ und Kontrolluniversum.

Vom Rahmenwerk zur Praxis: Ein integrierter Ansatz

Für die Umsetzung im Institut lohnt es, von der Modell‑Governance her zu denken und den AI‑Act systematisch aufzusetzen, statt umgekehrt.

Ein erster Schritt besteht darin, den Modellbegriff so zu schärfen, dass alle AI‑/ML‑Verfahren mit Entscheidungs‑ oder Score‑Charakter erfasst sind. Im Modellinventar werden AI‑Modelle und Hochrisiko‑AI gekennzeichnet, nicht separat geführt. Die existierenden Anforderungen aus MaRisk, EBA und EGIM bilden die Basis; AI‑Act‑Kontrollen werden als zusätzliche Attribute, Prüfpunkte und Dokumente integriert. So wird zum Beispiel der Validierungsbericht um AI‑spezifische Abschnitte ergänzt, die Risikoanalyse um AI‑Risikokategorien und die Model‑Use‑Policy um Human‑Oversight‑Regeln und Verantwortlichkeiten entlang Provider/Deployer‑Rollen.

Auf der Datenseite werden die BCBS‑239‑Strukturen gezielt genutzt: Wo bereits Data‑Quality‑Kontrollen, Data Lineage und Data‑Governance‑Gremien existieren, lassen sich AI‑Anforderungen andocken. Trainings‑, Validierungs‑ und Testdaten werden als spezielle Nutzung der bestehenden Datenlandschaft behandelt, mit zusätzlichen Kriterien für Repräsentativität, Fairness und Dokumentation der Vorverarbeitung. So bleibt die Verantwortung für Daten in denselben Händen, statt dass ein paralleles „AI‑Daten‑Team“ entsteht – gleichzeitig müssen Data‑Owner und Risk‑Funktionen lernen, Fairness‑ und Bias‑Metriken genauso selbstverständlich zu diskutieren wie heute Ausreißer, Vollständigkeit und Plausibilitäten.

Bei der Kreditvergabe laufen alle Linien zusammenlaufen: MaRisk, EBA‑LOM, EGIM, BCBS 239 und AI‑Act treffen sich in einem Use Case mit hoher Relevanz für Aufsicht, Kunden und Reputation. Wer hier ein AI‑Kreditscoring im bestehenden Rahmenwerk hochrisikofähig macht, schafft Blaupausen für weitere Anwendungsfälle – von Collection über Frühwarnsysteme bis hin zu Pricing‑Modellen.

Ein Framework, eine Sprache, zusätzliche Kontrollen

Der AI‑Act zwingt Banken nicht dazu, ihre Modell‑Governance neu zu erfinden. Im Gegenteil: Er baut auf dem auf, was MaRisk, EBA‑Leitlinien, EGIM und BCBS 239 in den letzten Jahren etabliert haben – ein klares Verständnis von Modellen, Daten und Governance. Wer diesen Ausgangspunkt ernst nimmt, kann Hochrisiko‑AI in das bestehende Rahmenwerk integrieren, statt eine parallele AI‑Welt zu schaffen.

Genauso wichtig ist aber die Ehrlichkeit in der internen Kommunikation: Der AI‑Act ist kein reines Formalien‑Upgrade, sondern bringt neue inhaltliche Anforderungen mit sich – von Fairness‑Analysen und Grundrechts‑Risiken über Human‑Oversight‑Design bis hin zu technischen Dossiers und Konformitätsbewertungen. Strategisch heißt das: „One Framework for all Models – mit AI‑Erweiterung“. Operativ bedeutet es, Modellinventar, Validierung, Daten‑Governance und Gremienstrukturen gezielt um AI‑Act‑Kontrollen zu ergänzen und neue Kompetenzen in Risk, Data und Fachbereichen aufzubauen.

Institute, die diese Brücke konsequent und realistisch bauen, reduzieren Doppelarbeit, schaffen Klarheit im Modellportfolio und sind besser aufgestellt, um neue AI‑Use‑Cases sicher und compliant in die Fläche zu bringen – ohne den zusätzlichen Aufwand zu unterschätzen, den der AI‑Act inhaltlich tatsächlich bedeutet.

Wenn Sie die Auswirkungen auf Ihre Modelle oder konkrete AI-Anwendungen vertiefen möchten, können Sie gerne einen Gesprächstermin vereinbaren, um die nächsten Umsetzungsschritte zu besprechen.