EU AI Act und Kreditscoring: Wann das Modell einer Bank zum Hochrisiko-System wird

Der EU AI Act (Verordnung (EU) 2024/1689) stuft KI-Systeme nicht pauschal ein, sondern über eine Liste konkreter Hochrisiko-Anwendungen in Anhang III. Für Banken ist Anhang III Nr. 5(b) der zentrale Eintrag: KI-Systeme, die dazu bestimmt sind, die Kreditwürdigkeit natürlicher Personen zu bewerten oder ihren Kredit-Score zu erstellen — mit einer einzigen Ausnahme: KI-Systeme zur Aufdeckung von Finanzbetrug ^[1]. Wer ein Modell betreibt, das über die Kreditvergabe an Privatpersonen mitentscheidet, betreibt nach dem Wortlaut ein Hochrisiko-System.

Zwei Eingrenzungen sind entscheidend. Erstens gilt 5(b) nur für natürliche Personen — die Bonitätsbewertung juristischer Personen, etwa ein Firmenkredit an eine GmbH, fällt nicht darunter. Einzelunternehmer und Selbstständige sind jedoch natürliche Personen und damit erfasst; eine Trennung nach privatem oder geschäftlichem Kreditzweck kennt der operative Text nicht. Zweitens nennt Erwägungsgrund 58 den Grund: Solche Systeme entscheiden über den Zugang natürlicher Personen zu finanziellen Ressourcen und wesentlichen Diensten wie Wohnen, Strom und Telekommunikation ^[1].

Der AI Act enthält ein Ventil: Nach Art. 6 Abs. 3 gilt ein Anhang-III-System ausnahmsweise nicht als hochriskant, wenn es kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte birgt — etwa weil es nur eine eng begrenzte Verfahrensaufgabe erfüllt oder das Ergebnis einer bereits abgeschlossenen menschlichen Tätigkeit lediglich verbessert ^[1]. Auf den ersten Blick könnte eine Bank hoffen, ein unterstützendes Scoring-Tool unter diese Ausnahme zu schieben.

Diese Hoffnung scheitert an einem Satz. Der letzte Unterabsatz von Art. 6 Abs. 3 stellt klar: Ein Anhang-III-System gilt immer als hochriskant, wenn es ein Profiling natürlicher Personen vornimmt ^[1]. Kreditscoring ist der Lehrbuchfall von Profiling — die automatisierte Bewertung persönlicher Aspekte einer natürlichen Person; der Begriff folgt über Art. 3 Nr. 52 der Definition aus Art. 4 Nr. 4 DSGVO. Damit ist die Ausnahme für praktisch jedes echte Scoring-Modell versperrt; es bleibt Hochrisiko.

Banken betreiben zwei sehr unterschiedliche Arten von Kreditmodellen, und nur eine steht klar in Anhang III. Origination-Scoring entscheidet über die Kreditvergabe an eine konkrete Person — das ist 5(b). Davon zu trennen sind IRB-Modelle (interne ratingbasierte Ansätze nach der CRR), mit denen Banken regulatorische Eigenmittelanforderungen für ihr Kreditportfolio berechnen. Die EBA hat in ihrem Folgebericht zum Einsatz von Machine Learning für IRB-Modelle (2023) die Auffassung vertreten, dass Anhang III Nr. 5(b) auf die Kreditwürdigkeitsbewertung bei der Kreditvergabe zielt und nicht unmittelbar die IRB-Modelle zur Eigenmittelberechnung erfasst ^[2].

Diese Linie ist kein Freibrief. Dieselbe EBA-Analyse weist auf mittelbare Effekte hin: Über die aufsichtliche Use-Test-Anforderung der CRR — wonach ein IRB-Modell auch im operativen Kreditgeschäft genutzt werden muss — kann ein Modell beide Welten berühren. Und 2025 hat die EBA in einer Mapping-Übung die Anforderungen des AI Act gegen das Banken- und Zahlungsrecht abgeglichen und ihre Schlussfolgerungen veröffentlicht ^[3]. Für die Praxis heißt das: Die Einstufung hängt am konkreten Verwendungszweck des Modells, nicht an seinem Namen.

Der AI Act verteilt die Pflichten über zwei Rollen. Ein Provider (Art. 3 Nr. 3) entwickelt ein KI-System oder lässt es entwickeln und bringt es unter eigenem Namen oder eigener Marke in den Verkehr. Ein Deployer (Art. 3 Nr. 4) setzt ein KI-System unter eigener Verantwortung ein. Eine Bank, die ein Scoring-System von einem Anbieter einkauft und unverändert nutzt, ist Deployer; sie trägt die Pflichten aus Art. 26 ^[1].

Entscheidend ist Art. 25: Ein Deployer wird selbst zum Provider — mit der vollen Provider-Pflichtenlast — sobald er (a) seinen Namen oder seine Marke auf ein bereits in Verkehr gebrachtes Hochrisiko-System setzt, (b) ein solches System wesentlich verändert (Art. 3 Nr. 23), sodass es hochriskant bleibt, oder (c) den Verwendungszweck eines nicht hochriskanten Systems so ändert, dass es hochriskant wird ^[1]. Für Banken ist das die kritische Weiche: Wer ein Vendor-Modell auf eigene Bestandsdaten nachtrainiert oder seine Zweckbestimmung verschiebt, wechselt von der leichten Deployer- in die schwere Provider-Rolle.

Die Provider-Pflichten (Dachnorm Art. 16) sind der anspruchsvollste Teil des AI Act. Ein Hochrisiko-System verlangt ein Risikomanagementsystem (Art. 9), Daten-Governance mit Anforderungen an Trainings-, Validierungs- und Testdaten (Art. 10), technische Dokumentation nach Anhang IV (Art. 11), automatische Protokollierung (Art. 12), Transparenz und Informationen für Deployer (Art. 13), menschliche Aufsicht by design (Art. 14) sowie Genauigkeit, Robustheit und Cybersicherheit (Art. 15) ^[1].

Hinzu kommen ein Qualitätsmanagementsystem (Art. 17) und die Konformitätskette: Konformitätsbewertung (Art. 43), EU-Konformitätserklärung (Art. 47), CE-Kennzeichnung (Art. 48) und die Registrierung des Systems in der EU-Datenbank (Art. 49; die Datenbank selbst nach Art. 71) ^[1]. Wer als Bank ein eigenes Scoring-Modell baut, übernimmt diese gesamte Kette — ein Aufwand, der sich von der Deployer-Rolle grundlegend unterscheidet.

Auch der reine Deployer ist nicht aus der Pflicht. Art. 26 verlangt: Einsatz gemäß den Anbieter-Instruktionen, Sicherstellung wirksamer menschlicher Aufsicht durch qualifizierte Personen, Verantwortung für die Eignung der Eingabedaten, soweit der Deployer sie kontrolliert, laufende Überwachung samt Meldung von Risiken und schwerwiegenden Vorfällen sowie Aufbewahrung der vom System erzeugten Protokolle für mindestens sechs Monate ^[1].

Der für Banken überraschende Punkt steht in Art. 27. Eine Grundrechte-Folgenabschätzung (Fundamental Rights Impact Assessment, FRIA) müssen vor der Inbetriebnahme nicht nur öffentliche Stellen durchführen, sondern ausdrücklich auch alle Deployer von Hochrisiko-Systemen nach Anhang III Nr. 5(b) — dem Kreditscoring-Eintrag ^[1]. Diese Pflicht ist ein eigenständiges Tatbestandsmerkmal: Sie hängt nicht davon ab, ob die Bank eine öffentliche Einrichtung ist. Eine private Geschäftsbank, die ein Scoring-System einsetzt, schuldet die FRIA — zusätzlich zur Datenschutz-Folgenabschätzung, die über Art. 22 DSGVO ohnehin im Raum steht.

Der AI Act ist am 1. August 2024 in Kraft getreten und greift gestaffelt (Art. 113). Für die Hochrisiko-Systeme aus Anhang III — und damit das Kreditscoring — ist der 2. August 2026 der maßgebliche Stichtag, an dem die Pflichten anwendbar werden ^[1]. Nur die andere Hochrisiko-Route über Anhang I — KI als Sicherheitsbauteil regulierter Produkte — folgt erst am 2. August 2027; sie betrifft das Scoring nicht.

Hier ist die Nuance, die zur Vorsicht zwingt: Die Kommission hat mit dem Digital Omnibus on AI (COM(2025) 836) vorgeschlagen, die Anhang-III-Frist auf den 2. Dezember 2027 zu verschieben. Stand Anfang Juni 2026 besteht dazu eine vorläufige politische Einigung, aber noch keine verabschiedete, im Amtsblatt veröffentlichte Verordnung ^[4]. Solange der Aufschub nicht förmlich angenommen ist, bleibt der 2. August 2026 geltendes Recht. Wer die Vorbereitung auf den vermeintlich sicheren Dezember 2027 schiebt, wettet auf einen Rechtsakt, der noch nicht beschlossen ist.

Vier Quellen-Streams entscheiden, ob eine Bank den Stichtag richtig trifft: EUR-Lex für die Verordnung selbst und — sobald er kommt — den Anwendungsakt des Digital Omnibus; Kommission und KI-Büro für Leitlinien zur Hochrisiko-Einstufung und zum FRIA-Template; die EBA für die Konkretisierung der Schnittstelle zwischen AI Act und Bankenrecht (etwa die Mapping-Note von 2025); und die nationalen Aufseher (BaFin, ACPR und andere), die jurisdiktionsspezifische Erwartungen veröffentlichen ^[3].

Genau das ist ein Horizon-Scanning-Problem. Horizon Scanner überwacht diese Quellen kontinuierlich, stuft jede Veröffentlichung nach Relevanz ein und routet sie an die zuständige Funktion — Origination-Scoring an das Kreditrisiko- und Model-Risk-Team, die FRIA-relevanten Stücke an Datenschutz und Compliance, die Provider-Pflichten an die Modellentwicklung. So wird aus einem beweglichen Rechtsrahmen eine prüfbare Spur statt einer Schlagzeile.