KI bei Kredit und Versicherung: Welche Scoringsysteme hochriskant sind

Kreditwürdigkeit präzise abgrenzen

Anhang III Nummer 5 Buchstabe b erfasst KI-Systeme, die zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Ermittlung ihres Kreditscores bestimmt sind. Typische Kandidaten sind Modelle, die Zahlungsausfallwahrscheinlichkeit, Annahme, Limit oder Konditionen anhand personenbezogener Merkmale bewerten. Unternehmensratings fallen nicht allein unter diesen personenbezogenen Tatbestand, können aber andere Regelungen berühren, wenn Einzelunternehmer oder persönliche Garantien faktisch natürliche Personen in den Mittelpunkt rücken.

Systeme zur Aufdeckung von Finanzbetrug sind ausdrücklich ausgenommen. Diese Ausnahme ist eng am tatsächlichen Zweck zu prüfen. Ein Modell, das zugleich Betrugssignale und allgemeine Kreditwürdigkeit in einen einheitlichen Score einfließen lässt, kann nicht pauschal als Betrugserkennung behandelt werden. Institute sollten Module, Outputs und Entscheidungswege trennen sowie dokumentieren, welche Funktion Annahme, Preis, Limit oder spätere Vertragsmaßnahmen beeinflusst.

• Natürliche Person und konkrete Score-Funktion bestimmen
• Betrugserkennung von Bonitätsbewertung technisch trennen
• Gemischte Modelle nach jedem Output und Zweck klassifizieren

Quellen: [1] [3]

Versicherungstatbestand ist bewusst begrenzt

Anhang III Nummer 5 Buchstabe c betrifft KI-Systeme zur Risikobewertung und Preisbildung bei Lebens- und Krankenversicherung für natürliche Personen. Kfz-, Sach-, Reise- oder Industrieversicherung wird nicht allein aufgrund eines KI-gestützten Scorings von diesem speziellen Tatbestand erfasst. Eine pauschale Aussage, jede Versicherungs-KI sei hochriskant, wäre daher falsch. Andere Anhang-III-Kategorien oder Produkt- und Datenschutzvorschriften können dennoch einschlägig sein.

Auch innerhalb von Leben und Gesundheit ist die Funktion genau zu beschreiben. Ein internes Tool zur Dokumentensortierung ist anders zu beurteilen als ein Modell, das Gesundheitsangaben auswertet und Prämien oder Annahme beeinflusst. Betrifft eine Anwendung Schadenbearbeitung statt Risikobewertung und Preisbildung, ist der konkrete Tatbestand erneut zu prüfen. Produktnamen, Konzernkategorien oder die bloße Verwendung sensibler Daten ersetzen diese Funktionsanalyse nicht.

• Versicherungssparte und natürliche Person festhalten
• Risikobewertung und Preisbildung von Verwaltung trennen
• Andere Rechtsregime auch außerhalb des Tatbestands prüfen

Quellen: [1] [3]

Art. 6 Absatz 3 und Profiling

Ein gelisteter Anwendungsfall kann ausnahmsweise nicht hochriskant sein, wenn kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte besteht und das System das Entscheidungsergebnis nicht wesentlich beeinflusst. In Betracht kommen enge Verfahrens- oder Vorbereitungsaufgaben, Verbesserungen abgeschlossener menschlicher Tätigkeiten oder Mustererkennung, die eine menschliche Bewertung nicht ersetzt oder beeinflusst. Für Finanzmodelle ist die faktische Gewichtung im Prozess entscheidend.

Profiling natürlicher Personen in einem gelisteten Use Case führt innerhalb dieses Rahmens stets zur Hochrisikoeinstufung. Eine angeblich bloß vorbereitende Kennzahl kann außerdem wesentlich beeinflussen, wenn Sachbearbeiter sie regelmäßig übernehmen oder Abweichungen begründen müssen. Anbieter müssen eine Ausnahmebeurteilung vor dem Inverkehrbringen oder der Inbetriebnahme dokumentieren und das System nach Artikel 49 Absatz 2 registrieren. Betreiber sollten sich diese Begründung vorlegen lassen und gegen ihre eigene Konfiguration und Verwendung prüfen.

• Fehlenden wesentlichen Einfluss anhand des Workflows belegen
• Profiling als Grenze der Ausnahme erkennen
• Anbieterbegründung gegen tatsächlichen Betrieb validieren

Quellen: [1] [2] [3]

Rollen und bestehendes Risikomanagement verbinden

Ein Finanzinstitut ist beim Einsatz eines zugekauften Systems typischerweise Betreiber. Eigenentwicklung, Auftreten unter eigenem Namen, erhebliche Zweckänderung oder wesentliche Änderung kann Anbieterstatus auslösen. Rollen sind je Modell, Version und Konzerngesellschaft zu bestimmen. Die Auslagerung an FinTech oder Cloud-Anbieter beseitigt betriebliche Pflichten nicht. Verträge brauchen Leistungsgrenzen, Datenanforderungen, Logs, Änderungsinformationen, Vorfallunterstützung und Auditmöglichkeiten.

Die Anforderungen sollten in Modellrisikomanagement, Validierung, Compliance und interne Revision integriert werden, ohne unterschiedliche Zwecke zu vermischen. Inputdaten müssen für den vorgesehenen Zweck relevant und hinreichend repräsentativ sein; menschliche Aufsicht benötigt verständliche Informationen und Eingriffsbefugnisse. Monitoring sollte Drift, Fehlerquoten, Gruppenunterschiede, Override-Muster und Beschwerden erfassen. Ein bestehender Kontrollrahmen ist hilfreich, aber kein automatischer Nachweis der Erfüllung jeder AI Act Pflicht.

• Rolle pro Modellversion und Gesellschaft festlegen
• Lieferantennachweise in Auslagerungssteuerung integrieren
• Drift, Gruppenwirkung und Overrides laufend überwachen

Quellen: [1] [2]

Folgenabschätzungen verzahnen, nicht vermischen

Betreiber der in Anhang III Nummer 5 Buchstaben b und c genannten Hochrisikosysteme müssen vor dem erstmaligen Einsatz grundsätzlich eine Grundrechte-Folgenabschätzung nach Artikel 27 durchführen. Sie hat einen eigenen Gegenstand und ist nicht mit der Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO identisch. Beide Prüfungen können organisatorisch verzahnt werden, müssen aber ihre jeweiligen Fragen beantworten. Für Kreditinstitute und Versicherungsunternehmen, die unionsrechtlichen Anforderungen an ihre interne Unternehmensführung unterliegen, lässt Artikel 27 die Integration in bestehende Folgenabschätzungen zu, ohne den gesetzlichen Inhalt entfallen zu lassen.

Die DSGVO bleibt unabhängig von der Hochrisikofrist anwendbar. Artikel 22 kann bei ausschließlich automatisierten Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung relevant sein; Transparenz, Rechtsgrundlage, Datenminimierung und Betroffenenrechte sind gesondert zu prüfen. Grundrechte- und Datenschutzprüfung sollten verwendete Daten, betroffene Gruppen, mögliche Benachteiligungen, menschliche Überprüfung und Beschwerdewege gemeinsam abbilden, ohne die Rechtsgrundlagen gleichzusetzen.

• Artikel-27- und DSGVO-Prüfung getrennt begründen
• Bestehende Finanzprozesse nur mit dokumentierter Zuordnung nutzen
• Überprüfungs- und Beschwerdewege praktisch erreichbar gestalten

Quellen: [1] [4]

Frist und Parallelrecht im Umsetzungsplan

Die spezifischen Hochrisikoanforderungen der Abschnitte 1 bis 3 des Kapitels III gelten für Anhang-III-Systeme nach dem Digital Omnibus grundsätzlich ab 2. Dezember 2027. Bis dahin sollten Institute Inventar, Klassifikationsakte, Daten-Governance, Protokollierung, menschliche Aufsicht und Lieferantennachweise aufbauen. Die Kommissionsleitlinien zur Klassifizierung sind am Stichtag noch nicht bindend final und müssen vor Veröffentlichung erneut auf ihren Status geprüft werden.

Die Frist verschiebt nicht DSGVO, Verbraucher- und Hypothekarkreditrecht, Diskriminierungsverbote oder einschlägige Aufsichtsvorgaben. Die Verbraucherkreditrichtlinie (EU) 2023/2225 und nationale Umsetzungsschritte sind im Zeitplan gesondert zu beobachten. Freigaben sollten Bedingungen und Stoppschwellen enthalten, etwa unerklärte Modelländerungen, unvertretbare Gruppenunterschiede oder fehlende Überprüfbarkeit. Ein dokumentierter Prozess unterstützt Compliance, garantiert aber weder richtige Entscheidungen noch Haftungsfreiheit.

• 2. Dezember 2027 für spezifische Hochrisikopflichten einplanen
• Parallelrecht ohne Aufschub operationalisieren
• Leitlinien und nationale Umsetzung vor Veröffentlichung aktualisieren

Quellen: [2] [3] [5]

Häufige Fragen