KI-Verordnung (AI Act) für Versicherer: Was fällt darunter und was nicht?

Am 2. August 2026 wird der Hauptteil der KI-Verordnung (AI Act) der EU vollständig auf Hochrisiko-KI-Systeme anwendbar. Ein Teil der Verordnung ist übrigens bereits früher in Kraft getreten: Kapitel I und II (Definitionen und die verbotenen KI-Praktiken in Artikel 5) seit dem 2. Februar 2025, sowie die Bußgeldbestimmungen, das Governance-Kapitel und die Regeln für KI-Modelle mit allgemeinem Verwendungszweck seit dem 2. August 2025. Für Versicherer lautet die relevante Frage nicht, ob der AI Act auf sie anwendbar ist (das ist er), sondern welcher Teil ihres KI-Portfolios unter welches Regime fällt. Für manche Use Cases ist das eindeutig. Für andere gerade nicht, und genau dorthin verlagert sich in den kommenden Monaten die Arbeitslast.

Der Rahmen: vier Risikostufen und Anhang III

Der AI Act (Verordnung (EU) 2024/1689) teilt KI-Systeme in vier Risikostufen ein: unannehmbar, hoch, begrenzt und minimal. Hochrisiko ist die Kategorie mit den mit Abstand meisten Pflichten. Anhang III der Verordnung zählt acht Bereiche auf, in denen KI-Systeme als Hochrisiko eingestuft werden können.

Für Versicherer ist Anhang III Kategorie 5(c) am konkretesten. Die Verordnung bezeichnet diesen Use Case als KI-Systeme für 'Risikobewertung und Preisbildung in Bezug auf natürliche Personen im Fall von Lebens- und Krankenversicherungen'. Da gibt es keinen Raum für Diskussion. Das sind Hochrisiko-Systeme. Erwägungsgrund 58 begründet dies: Diese KI kann einschneidende Folgen für den Lebensunterhalt, die Grundrechte und sogar die Gesundheit der Betroffenen haben.

Für Personenschäden, Sachversicherung und allgemeine Claims-KI ist es komplizierter. Diese Use Cases werden in Anhang III nicht explizit genannt. Ob ein bestimmtes System als Hochrisiko einzustufen ist, hängt davon ab, was das System tut, wie einschneidend der Output für den Kunden ist und wie es in der Entscheidungsfindung eingesetzt wird. Personenschaden-KI gerät schnell in den Compliance-Risikobereich, fällt aber nicht in jedem Fall ohne Diskussion darunter.

Zwei Ausnahmen, die für Versicherer relevant sind. Anhang III Kategorie 5(b) stuft KI zur Kreditwürdigkeitsprüfung als Hochrisiko ein, nimmt KI zur Betrugserkennung bei Finanzdienstleistungen aber ausdrücklich aus. Erwägungsgrund 58 fügt hinzu, dass KI-Systeme, die durch das Unionsrecht zur Betrugserkennung bei Finanzdienstleistungen und zur aufsichtsrechtlichen Berechnung der Kapitalanforderungen von Kreditinstituten und Versicherungsunternehmen vorgeschrieben sind, nicht als Hochrisiko im Sinne dieser Verordnung gelten.

Profiling: nicht das, wonach es aussieht

Eine häufig gehörte These lautet, dass Profiling durch KI automatisch eine Hochrisiko-Einstufung nach sich zieht. Das stimmt nicht. Artikel 6 Absatz 3 Unterabsatz 1 bietet gerade eine Ausnahme für manche Anhang-III-Systeme, die kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte darstellen. Absatz 3 Unterabsatz 3 fügt hinzu, dass ein System, das Profiling natürlicher Personen durchführt, ungeachtet dieser Ausnahme stets als Hochrisiko gilt.

Mit anderen Worten: Profiling macht ein System nicht aus sich heraus zum Hochrisiko-System. Es verschließt lediglich den Fluchtweg für Systeme, die ohnehin bereits unter Anhang III fallen. Für Personenschaden-KI müssen Sie also zuerst feststellen, ob der Use Case unter Anhang III fällt. Erst danach wird Profiling juristisch relevant.

Anbieter versus Betreiber: andere Pflichten, anderer Stack

Der AI Act unterscheidet zwei Rollen. Der Anbieter ('provider') entwickelt das System oder bringt es auf den Markt. Der Betreiber ('deployer') setzt es in seinem Geschäftsbetrieb ein. Viele Versicherer sind Betreiber, weil sie KI über SaaS-Pakete oder Anbieter von Betrugserkennung einkaufen.

Die schwersten Pflichten liegen beim Anbieter. Die Artikel 9 bis 15 regeln Risikomanagement, Data Governance, technische Dokumentation, Logging-Architektur, Transparenz und die Gestaltung der menschlichen Aufsicht. Ein Versicherer, der ein System einkauft, muss diesen Stack nicht selbst liefern, muss aber nachweisen können, dass sein Lieferant das getan hat.

Der Betreiber hat eigene Pflichten nach Artikel 26: Nutzung gemäß den Anweisungen, menschliche Aufsicht durch befähigte Personen, Kontrolle der Eingabedaten, soweit sie der eigenen Kontrolle unterliegen, Monitoring, Aufbewahrung der Logs (mindestens sechs Monate) und Information der Kunden, wo dies angezeigt ist.

Für Versicherer liegt hier eine wichtige Nuance. Artikel 26 Absätze 5 und 6 enthalten eine spezifische Regelung für Finanzinstitute, die Governance-Anforderungen nach dem Unionsrecht über Finanzdienstleistungen unterliegen. Für diese Betreiber gelten die Monitoring- und Log-Aufbewahrungspflichten als erfüllt, wenn sie diese Finanzdienstleistungsvorschriften einhalten. Versicherer unter Solvency II fallen grundsätzlich darunter. Das spart keine Arbeit, aber es erspart einen separaten AI-Act-Papierkrieg neben dem, was bereits läuft.

FRIA: für wen ja und für wen nicht

Artikel 27 verpflichtet zu einem Fundamental Rights Impact Assessment (FRIA) für Betreiber bestimmter Hochrisiko-Systeme. Die Pflicht trifft Betreiber, die öffentlich-rechtliche Einrichtungen sind oder private Einrichtungen, die öffentliche Dienste erbringen, sowie Betreiber von Systemen unter Anhang III Kategorie 5(b) (Kreditwürdigkeit) und 5(c) (Lebens- und Krankenversicherungen). Für andere Versicherungs-Use-Cases ist ein FRIA nicht automatisch verpflichtend. Ob sich das ändert, hängt davon ab, wie das spezifische System eingestuft wird.

Praktischer Rat: Behandeln Sie das FRIA nicht als generischen Compliance-Schritt, sondern halten Sie pro System fest, ob Artikel 27 greift. Für manche Systeme lohnt es sich, ein FRIA auch dann durchzuführen, wenn es gesetzlich nicht verpflichtend ist, weil es die eigene Risikobewertung untermauert und an die DSFA-Pflicht nach Artikel 35 DSGVO anschließt.

Das Übergangsregime des Artikels 111

Ein häufiger Fehler in Veröffentlichungen zum AI Act ist die Annahme, dass alle bestehenden KI-Systeme am 2. August 2026 auf einen Schlag unter das Hochrisiko-Regime fallen müssen. Das stimmt nicht. Artikel 111 Absatz 2 regelt, dass Hochrisiko-Systeme, die vor diesem Datum bereits in Verkehr gebracht oder in Betrieb genommen wurden, erst dann unter das Regime fallen, wenn sie nach dem 2. August 2026 'erhebliche Änderungen an ihrer Konzeption' erfahren.

Auf dem Papier verschafft das Luft. In der Praxis ist das Schein. Nahezu jedes aktiv gewartete KI-System erfährt innerhalb von ein bis zwei Jahren Änderungen, die als 'erheblich' qualifizieren: neue Trainingsdaten, Modellablösungen, erweiterte Features. Wer das im Blick hat, kann planen. Wer das nicht tut, läuft beim nächsten Upgrade gegen das Regime.

Für öffentliche Stellen gilt im Übrigen eine härtere Frist: Ihre bestehende Hochrisiko-KI muss spätestens am 2. August 2030 konform sein, auch ohne Konzeptionsänderung.

Die Bußgelder

Artikel 99 setzt drei Stufen mit Höchstbeträgen:

• Bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes für verbotene KI-Praktiken (Artikel 5).

• Bis zu 15 Millionen Euro oder 3 % für die Nichteinhaltung von Pflichten für Anbieter (Artikel 16), Betreiber (Artikel 26), Transparenzpflichten (Artikel 50) und einige weitere Bestimmungen (Artikel 99 Absatz 4).

• Bis zu 7,5 Millionen Euro oder 1 % für unrichtige oder irreführende Angaben gegenüber einer Aufsichtsbehörde (Artikel 99 Absatz 5).

Wie diese Höchstbeträge in der Praxis angewandt werden (pro Verstoß, pro System oder kumulativ), liegt bei der nationalen Aufsichtsbehörde. In den Niederlanden erhält die Autoriteit Persoonsgegevens eine zentrale Rolle, in Abstimmung mit DNB und AFM, soweit es Versicherer betrifft. Die Aufsichtspraxis ist derzeit noch nicht ausgereift. Gut zu wissen: Das Sanktionskapitel selbst ist bereits seit dem 2. August 2025 in Kraft.

Was das mit dem Anbietermarkt macht

Ende 2025 beteiligte sich fast jeder an KI-Piloten. Schnell bauen, schauen, was es bringt, erst danach über Governance nachdenken. Diese Phase ist vorbei.

Ab dem Sommer wird die Frage bei jeder Ausschreibung stets dieselbe: Können Sie heute die Einstufung dieses Systems begründen? Gibt es eine Dokumentation nach Artikel 11? Wurde Bias gemessen, und wird das weiterhin gemessen? Passt die von Ihnen angebotene Verteilung zwischen Anbieter und Betreiber zu dem, was das Gesetz verlangt? Ein Lieferant, der diese Fragen nicht innerhalb eines Tages beantworten kann, fliegt von der Shortlist. Compliance-Teams befassen sich bereits jetzt damit. Der Einkauf folgt kurz darauf.

Wo DCSolutions steht

DCSolutions baut Plattformen für Versicherer mit Erklärbarkeit und menschlicher Entscheidungsfindung als Ausgangspunkt. Konkret:

• Jeder automatisierte Schritt hat einen dokumentierten Zweck, Eingangsdaten und Grenzen.

• Entscheidungen werden auf einem Niveau protokolliert, das an die Anforderungen von Artikel 12 auf Anbieterseite anschließt, sodass der Versicherer als Betreiber auch sein eigenes Monitoring nach Artikel 26 fahren kann (oder, für Versicherer unter Solvency II, den bestehenden Governance-Stack weiter nutzen kann).

• Bearbeiter sehen, was das Modell getan hat und auf welcher Grundlage, und können jederzeit eingreifen oder überstimmen.

• Bias-Tests und Monitoring laufen kontinuierlich, nicht als jährliches Audit.

Das ist bewusst so gebaut. Nicht weil das Gesetz es erzwingt, sondern weil es die einzige Art ist, verantwortungsvoll mit dieser Arbeit umzugehen. Die Gespräche mit Compliance-Teams macht es derzeit allerdings deutlich einfacher.

Was Sie jetzt tun können

Drei Schritte, in dieser Reihenfolge.

Eins. Erstellen Sie ein Register aller KI-Systeme, die in Ihrer Versicherungskette laufen, einschließlich der Modelle, die in SaaS-Paketen Dritter mitkommen. Pro System: Use Case, erste Inbetriebnahme, Anbieter, Betreiberrolle und der Status unter Artikel 111.

Zwei. Bestimmen Sie pro System die Risikoeinstufung. Nicht 'Hochrisiko zur Sicherheit' (das bringt unnötige Pflichten), nicht 'minimal, weil unklar' (das bringt Risiko). Begründen Sie die Wahl, explizit, auf Papier.

Drei. Für Systeme, die Hochrisiko sind oder wahrscheinlich werden: Fordern Sie die Dokumentation nach Artikel 11 bei Ihrem Anbieter an, planen Sie Ihre eigenen Pflichten nach Artikel 26 ein (mit Blick auf den Solvency-II-Weg in den Absätzen 5 und 6) und prüfen Sie, ob Artikel 27 greift.

Mit Versicherern, die sich jetzt damit befassen, sprechen wir gerne. Ein Intake, ein technischer Walkthrough dazu, wie wir unsere Plattformen einstufen und begründen. Danach wissen Sie, wo Sie stehen. Vereinbaren Sie ein Gespräch über unsere Kontaktseite oben.

Quellen

• Verordnung (EU) 2024/1689 (der AI Act), insbesondere Anhang III, Artikel 6, 9-15, 26, 27, 50, 99, 111 und 113. Abrufbar über eur-lex.europa.eu/eli/reg/2024/1689/oj oder als deutsche PDF auf data.europa.eu (ELI: data.europa.eu/eli/reg/2024/1689/oj)

• Erwägungsgrund 58 (Erwägung zur Hochrisiko-Einstufung von Versicherungen) und Erwägungsgrund 96 (zum FRIA)

• AI Act Service Desk der Europäischen Kommission: ai-act-service-desk.ec.europa.eu

• EIOPA, Statement on the use of governance arrangements and risk management in the use of artificial intelligence

• artificialintelligenceact.eu (Erläuterung Artikel für Artikel)

‍