Der EU AI Act ist am 1. August 2024 in Kraft getreten, mit einer 24-monatigen Übergangsfrist für die Hochrisiko-Vorgaben, was den maßgeblichen Stichtag auf den 2. August 2026 legte. Dieser Termin steht inzwischen nicht mehr fest. 2026 haben die EU-Institutionen eine vorläufige Einigung zum Digital Omnibus erzielt, die die Hochrisiko-Pflichten für eigenständige Annex-III-Systeme, darunter die Kreditbewertung, auf den 2. Dezember 2027 verschiebt, vor allem weil die für die Konformitätsbewertung erforderlichen harmonisierten Normen nicht rechtzeitig vorlagen. Die Verschiebung muss noch förmlich angenommen werden, behandeln Sie den Zeitplan daher als vorbehaltlich und nicht als endgültig.
Was sich nicht verschiebt, ist der Inhalt. Ob die Pflichten im August 2026 oder im Dezember 2027 greifen, es bleiben Pflichten dazu, wie das System gebaut und betrieben wird, und die geforderten Nachweise müssen während der Entwicklung entstehen, nicht im Nachhinein zusammengetragen werden. Der zusätzliche Vorlauf ist ein Grund, die Entwicklung sauber zu machen, kein Grund zu warten.
Dies ist keine Rechtsberatung. Es ist eine Lesart des Regimes als technisches Problem, denn dort fällt der größte Teil der Arbeit tatsächlich an.
Welche Finanzsysteme in den Anwendungsbereich fallen
Die Hochrisiko-Kategorie des EU AI Act für Finanzdienstleistungen erfasst Anwendungen, die etwas Wesentliches über eine Person entscheiden. In der Praxis bedeutet das:
- Bonitätsprüfung und Kreditbewertung natürlicher Personen
- Risikobewertung und Tarifierung in der Lebens- und Krankenversicherung
- AML- und Betrugserkennungssysteme
Wenn Ihr Modell einen Score vergibt, der über einen Kredit entscheidet, eine Prämie festlegt oder eine Transaktion zur Prüfung markiert, gehen Sie von Hochrisiko-KI aus und planen Sie entsprechend. Die Einzelheiten sind entscheidend, und die Grenze zwischen ausgenommen und erfasst ist genau die Art von Frage, die man rechtlichem Rat vorlegen sollte. Für die Entwicklung behandeln Sie diese Systeme als erfasst und arbeiten Sie vom Stichtag rückwärts, der letztlich für Sie gilt.
Die Seite des Anbieters: Konformität vor dem Inverkehrbringen
Wenn Sie eines dieser Systeme bauen oder wesentlich verändern, sind Sie Anbieter, und vor dem Inverkehrbringen müssen Sie eine KI-Konformitätsbewertung durchführen, die technische Dokumentation erstellen, dort wo erforderlich die CE-Kennzeichnung anbringen und das System in der EU-Datenbank registrieren. Diese Abfolge hat unmittelbare Folgen für den Code.
Eine Konformitätsbewertung ist eine Aussage über das System, die einer Prüfung standhalten muss, was bedeutet, dass die belegenden Nachweise während der Entwicklung vorliegen müssen, statt am Ende verfasst zu werden. Das Risikomanagement zieht sich über den gesamten Lebenszyklus, also brauchen die Kontrollen und ihre Begründung eine nachvollziehbare Spur, genauso wie eine Modellvalidierungsfunktion eine Aufzeichnung dessen erwartet, was geprüft wurde und warum.
Bei den Trainingsdaten wird die Compliance der Kreditbewertung konkret. Der AI Act erwartet repräsentative und dokumentierte Daten. Für ein Scoring-Modell heißt das, die Population zu kennen, aus der jedes Merkmal gelernt wurde, und Zeitpunkt-Fehler zu erkennen, damit das Modell nicht auf Informationen trainiert wird, die zum Entscheidungszeitpunkt noch nicht existierten. Ein Lookahead im Backtest ist ein Methodikfehler. In einem Hochrisiko-System ist er zugleich eine Dokumentationslücke, die Sie erklären müssen.
Die nächste Sorge ist die mittelbare Diskriminierung. Ein Modell kann ein geschütztes Merkmal aus Postleitzahl, Beruf oder Transaktionsmustern rekonstruieren, ohne das Merkmal je direkt zu sehen. Bias-Prüfungen müssen nach diesen Stellvertretern suchen, nicht nur bestätigen, dass das geschützte Feld entfernt wurde. Das ist ein Eval-Problem: Holdout-Mengen, aufgeschlüsselt nach den Merkmalen, nach denen Sie nicht diskriminieren dürfen, regelmäßig ausgeführt und mit Ergebnissen, die aufbewahrt und nicht nur überflogen werden.
Die Seite des Betreibers: Aufsicht, die tatsächlich wirkt
Wenn Sie das System eines anderen betreiben, tragen auch Sie Pflichten: eine menschliche Aufsicht, die etwas bedeutet, Prüfungen der Daten-Governance, Überwachung im Betrieb, Schulung des Personals und Meldung schwerwiegender Vorfälle.
Das tragende Wort ist hier die menschliche Aufsicht. Wer einen Score unter Zeitdruck nur abnickt, übt sie nicht aus, und eine Aufsichtsbehörde erkennt den Unterschied. Aufsicht muss von Anfang an mitgedacht werden. Die Oberfläche zeigt der prüfenden Person, was die Entscheidung getrieben hat, das Volumen lässt Raum, tatsächlich hinzusehen, und der Weg zur Übersteuerung ist real. Überwachung im Betrieb ist nichts anderes als Drift-Erkennung. Ein Scoring-Modell verschlechtert sich, wenn sich die Population verschiebt, und Sie wollen den Alarm, bevor der Verlust kommt.
Das Logging verbindet beide Seiten. Die Meldung schwerwiegender Vorfälle und jede nachträgliche Prüfung hängen von einem Audit-Trail ab, der rekonstruiert, was das System gesehen und entschieden hat. Wird dieses Logging zu spät angeflanscht, verfehlt es meist genau die Eingaben, auf die es ankam.
Die Sanktionen geben dem Zeitplan sein Gewicht. Bei Verstößen gegen die Hochrisiko-Pflichten liegt die Obergrenze bei bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes, eine Stufe unter den 35 Millionen EUR / 7 %, die den verbotenen Praktiken nach Artikel 5 vorbehalten sind. Sie brauchen diese Zahl nicht, um die Arbeit zu rechtfertigen, auch wenn sie die Aufmerksamkeit zu bündeln pflegt.
Die praktische Lehre ist dieselbe, die wir auf jedes Finanzsystem anwenden. Nachvollziehbare Datenherkunft, repräsentative Trainingsdaten, eine belastbare Evaluation und Audit-Logging, das vom ersten Commit an existiert, sind es, die das System einer Prüfung standhalten lassen. Ein späterer Stichtag ändert nichts an dieser Arbeit. Er gibt Ihnen nur Zeit, sie ohne Abkürzungen zu erledigen, und das ist der bessere Grund, jetzt zu beginnen.