Reihe · Board-Dilemmata
Board-Dilemmata
in regulierten Innovationsfeldern
Was diese Reihe Ihnen zeigt
Typische Dilemmata, vor denen Verwaltungsräte in regulierten Innovationsfeldern stehen – mit Handlungsoptionen und den Fragen, die das Board stellen muss, bevor es entscheidet.
„Board“ steht hier für das jeweilige strategische Leitungsorgan: Verwaltungsrat (CH), Vorstand mit Aufsichtsrats-Beteiligung (DE), Geschäftsleitung mit Beirat. Die Pflichtenkreise unterscheiden sich rechtlich; die Dilemmata gelten für jede dieser Konstellationen.
Folge 1 · Medtech
KI-Training mit einseitiger Datenbasis: Soll das Board den Launch freigeben?
Die Frage lautet nicht: Ist das erlaubt? Die Frage lautet: Ist das die Risikostruktur, die das Board freigeben will?
Ihr Unternehmen steht kurz vor der Markteinführung einer KI-gestützten intraoperativen Bildanalyse. Das System analysiert während orthopädischer Eingriffe Live-Bilddaten und gibt in Echtzeit Hinweise zur optimalen Implantatpositionierung.
Die klinische Bewertung ist abgeschlossen. Die technische Dokumentation ist vollständig. Die MDR-Konformität ist bestätigt. Die Geschäftsleitung empfiehlt den Launch.
Im technischen Bericht findet sich jedoch ein Detail, das nicht prominent im Executive Summary steht: Das Modell wurde überwiegend mit Bilddaten einer japanischen Klinikgruppe trainiert. Für die europäische Markteinführung erfolgte eine ergänzende Validierung – auf deutlich kleinerer Datengrundlage.
Regulatorisch ist das zulässig. Dokumentiert. Formal abgesichert. Aber ist es die Risikostruktur, die das Board verantworten will?
KI-Systeme lernen aus Mustern. Muster entstehen aus Daten. Daten bilden Realität nie vollständig ab. Eine überwiegend japanische Datenbasis bedeutet nicht, dass das System fehlerhaft ist – aber sie bedeutet, dass Anatomie, Demografie und klinische Variationen im europäischen Zielmarkt möglicherweise nicht in gleicher Breite abgebildet sind.
Hier geht es nicht um ein internes Analyse-Tool. Es geht um intraoperative Entscheidungsunterstützung. Hinweise, die im Operationssaal gegeben werden, beeinflussen Handlungen. Und damit Verantwortung.
Die drei Optionen des Boards
Post-Market-Monitoring adressiert mögliche Verzerrungen. Akzeptanz struktureller Unsicherheit als kalkuliertes Risiko.
- Zeitvorteil gegenüber Wettbewerbern realisiert
- Monitoring-Verpflichtungen müssen klar definiert und mit Ressourcen hinterlegt sein
- Board akzeptiert explizit, dass europäische Datenvarianz unterrepräsentiert ist
- Haftungsrisiko, wenn Verzerrungen zu klinischen Outcomes beitragen
Priorisierung europäischer Datenbasis vor Launch. Wirtschaftliche Konsequenzen werden bewusst in Kauf genommen.
- Deutlich stärkere Verteidigungsposition gegenüber Regulatoren und Haftungsansprüchen
- Verzögerung von 6–18 Monaten je nach verfügbarer Datenbasis
- Risiko: Wettbewerber besetzt den Markt mit ähnlicher oder schwächerer Datenbasis
- Erfordert aktive Kooperationsvereinbarungen mit europäischen Kliniken
Engmaschiges Post-Market-Monitoring als Kontrollmechanismus – mit vorab definierten Abbruchkriterien.
- Launch mit klar definierten Monitoring-Parametern: Welche Outcomes lösen einen Stopp aus?
- Board genehmigt nicht nur den Launch, sondern auch die Abbruchkriterien
- Operative Komplexität, aber lernfähiges System mit echter Feedback-Schleife
- Unterschied zu Option A: Das Board versteht und genehmigt die Kontrollstruktur – nicht nur den Launch
Keine dieser Optionen ist falsch. Aber jede definiert, wie Ihr Unternehmen mit Unsicherheit umgeht.
Was das Board vor der Entscheidung klären sollte
Haben wir den technischen Bericht selbst gelesen – oder nur die Executive Summary?
Verstehen wir, was «ergänzende Validierung auf kleinerer Datengrundlage» konkret bedeutet – in Zahlen?
Wissen wir, welche anatomischen oder demografischen Merkmale in der europäischen Patientenpopulation von der japanischen Trainingskohorte abweichen?
Gibt es klinische Experten, die unabhängig von der Geschäftsleitung bewertet haben, ob die Datenbasis für den europäischen Einsatz ausreichend ist?
Falls wir Option C wählen: Sind die Monitoring-Parameter und Abbruchkriterien im Board-Protokoll dokumentiert?
Bias ist selten ein isolierter Fehler. Er ist eine Folge von Designentscheidungen. Und Designentscheidungen sind – spätestens hier – Governance-Fragen.
Regulatorischer Kontext
MDR (EU) 2017/745 stellt Anforderungen an die klinische Bewertung und Post-Market-Surveillance. Der AI Act (EU) 2024/1689 kann ein solches System als Hochrisiko-KI erfassen – bei KI, die Sicherheitskomponente eines nach der MDR regulierten Medizinprodukts ist, läuft der Klassifizierungspfad über Art. 6 Abs. 1 i. V. m. Anhang I (produktbezogene Hochrisiko-KI), nicht über Anhang III. Daraus folgen Anforderungen an Daten-Governance, Transparenz und menschliche Aufsicht, sofern das Produkt einer Konformitätsbewertung durch eine dritte Stelle unterliegt. Die Systeme stehen nebeneinander: MDR beantwortet die Frage der Marktfähigkeit. Der AI Act stellt Anforderungen an die Gestaltung. Beide zusammen bestimmen, was das Board verantworten muss.
Folge 2 · Medtech
Algorithmus-Update nach Markteinführung: Soll das Board die Freigabe erteilen?
Die Frage lautet nicht: Ist das regulatorisch zulässig? Die Frage lautet: Versteht das Board, was sich mit dem Update verändert?
Fortsetzung von Folge 1: dasselbe Unternehmen, zwölf Monate später, vor der nächsten Entscheidung.
Ihr Unternehmen hat vor zwölf Monaten eine KI-gestützte intraoperative Bildanalyse erfolgreich im europäischen Markt eingeführt. Das Produkt läuft stabil. Die Performance-Zahlen sind gut. Das Marktfeedback ist positiv.
Nun liegt dem Board eine Entscheidungsvorlage vor. Die Entwicklungsabteilung hat den Algorithmus weitertrainiert. Neue Daten aus europäischen Kliniken wurden integriert. Die Genauigkeit ist nach internen Tests gestiegen. Das System empfiehlt jetzt häufiger bestimmte Implantattypen in bestimmten Konstellationen – eine Verschiebung, die technisch dokumentiert, aber klinisch noch nicht vollständig bewertet ist.
Die Frage, die auf dem Tisch liegt: Ist das ein Software-Update – oder eine wesentliche Änderung im Sinne der MDR, die eine neue Konformitätsbewertung erfordert? Die Rechtsabteilung sagt: wahrscheinlich kein wesentlicher Change. Die Entwicklungsabteilung sagt: das Modell verhält sich in bestimmten Situationen nachweislich anders als vorher.
Wenn ein Modell in bestimmten Situationen anders entscheidet als vor dem Update – ist das dann dasselbe System?
Was sich wirklich verändert hat
Das Board hat drei Informationsquellen: die Entwicklungsabteilung, die die Verbesserung erklärt, die Rechtsabteilung, die die regulatorische Einordnung vornimmt, und die Entscheidungsvorlage, die eine Freigabe empfiehlt. Was es nicht hat: eine unabhängige klinische Bewertung der Verhaltensänderung des Systems.
Das Modell empfiehlt jetzt häufiger bestimmte Implantattypen. Das ist eine Verhaltensänderung mit klinischer Wirkung – unabhängig davon, ob sie als «wesentlich» im Rechtssinne gilt. Die Frage ist nicht, ob das System besser geworden ist. Die Frage ist, ob das Board versteht, was «besser» in diesem Kontext bedeutet – und wer das aus klinischer Sicht beurteilt hat.
Die drei Optionen des Boards
Rechtliche und technische Einordnung der eigenen Teams wird akzeptiert. Update wird als Verbesserung freigegeben.
- Schnellste Option, Produktdynamik bleibt erhalten
- Board übernimmt Verantwortung auf Basis interner Beurteilung ohne externe klinische Validierung
- Risiko: Wenn das System sich bei bestimmten Patienten anders verhält, fehlt eine unabhängige Bewertungsgrundlage
- Post-Market-Surveillance muss explizit auf die Verhaltensänderung ausgerichtet sein
Unabhängige klinische Experten bewerten die Verhaltensänderung, bevor das Update in Betrieb geht.
- Stärkste Verteidigungsposition, falls das Update später in Frage gestellt wird
- Verzögerung von 4–8 Wochen, je nach Verfügbarkeit klinischer Expertise
- Sendet Signal: Das Board unterscheidet zwischen Software-Update und klinisch relevantem Modell-Change
- Empfehlenswert, wenn die Verhaltensänderung Konstellationen betrifft, die in der Trainingsphase unterrepräsentiert waren
Update geht in Betrieb, aber mit vorab genehmigten Abbruchkriterien und intensivierter Überwachung der geänderten Verhaltensparameter.
- Mittlere Option: Innovationsdynamik bleibt erhalten, Risiko wird aktiv gesteuert
- Board genehmigt explizit: das Update, die Monitoring-Parameter und den Rückrufmechanismus
- Erfordert klare Definition: Welche Outcomes lösen welche Reaktion aus?
- Dokumentation des Board-Beschlusses muss alle drei Elemente umfassen
Was das Board vor der Entscheidung klären sollte
In welchen konkreten Situationen verhält sich das Modell nach dem Update anders als vorher – und hat ein Kliniker das beurteilt?
Ist die Einschätzung «kein wesentlicher Change» durch die Rechtsabteilung eine rechtliche Bewertung oder auch eine klinische?
Erfasst die Post-Market-Surveillance explizit die Verhaltensparameter, die sich verändert haben?
Was ist der Rückrufmechanismus, wenn das Update sich als problematisch erweist – und wer löst ihn aus?
Ist dokumentiert, dass das Board die Verhaltensänderung verstanden und akzeptiert hat – nicht nur das Update?
In regulierten Innovationsfeldern endet Verantwortung nicht mit der Markteinführung. Sie beginnt dort erst richtig. Die Frage ist nicht, ob das Board dem Update zustimmt – sondern ob es versteht, wozu es zustimmt.
Regulatorischer Kontext
MDR Art. 83 verpflichtet Hersteller zu einem Post-Market-Surveillance-System, das aktiv Daten über das Verhalten des Produkts sammelt und bewertet. Der AI Act Art. 72 verlangt für Hochrisiko-KI-Systeme ein Post-Market-Monitoring-System. Beide Systeme stehen nebeneinander und können unterschiedliche Reporting-Verpflichtungen auslösen. Eine Verhaltensänderung durch ein Update, die klinisch relevant ist, aber rechtlich nicht als «wesentliche Änderung» gilt, kann trotzdem neue Meldepflichten nach MDR Art. 87 auslösen – wenn sie zu einer schwerwiegenden Fehlfunktion führt.
Folge 3 · Fintech
KI-gestützte Betrugserkennung: Was klassifiziert das Board – und was übersieht es dabei?
Die Frage lautet nicht: Ist das System zuverlässig? Die Frage lautet: Weiß das Board, welche zwei Regulierungen gleichzeitig greifen – und zieht es die richtigen Schlüsse aus beiden?
Ihr Zahlungsdienstleister hat ein KI-gestütztes Betrugserkennungssystem entwickelt, das Transaktionen in Echtzeit bewertet und automatisch blockiert, wenn der Risikowert einen definierten Schwellenwert überschreitet. Das System ist seit sechs Monaten produktiv. Die False-Positive-Rate ist niedrig. Die Betrugsverluste sind gesunken. Die Geschäftsleitung ist zufrieden.
Im Rahmen einer regulatorischen Vorbereitung kommen zwei Fragen auf den Tisch, die bisher nicht explizit adressiert wurden.
Die erste Frage: DORA-Klassifikation
Das System ist ein ICT-Drittanbieter-Dienst – ein Cloud-basiertes Modell, das über eine API angebunden ist. Als solches müsste es im ICT-Register nach DORA Art. 28 erfasst sein. Es ist erfasst – aber als «Standard»-Eintrag, nicht als kritisch oder wesentlich.
Die Frage: Ist die Betrugserkennung eine kritische Funktion im Sinne von DORA? Das System blockiert automatisch Zahlungen. Ein Ausfall für 30 Minuten würde dazu führen, dass alle Transaktionen entweder unkontrolliert durchlaufen oder vollständig gestoppt werden. Beide Szenarien sind regulatorisch und operativ problematisch.
Die zweite Frage: AI Act-Klassifikation
Das Produktteam hat das System als «minimal risk» eingestuft, weil es «nur» Transaktionen bewertet, nicht Personen. Die Rechtsabteilung hat diese Einschätzung nicht revidiert. Aber: Das System entscheidet automatisch darüber, ob eine Zahlung ausgeführt wird oder nicht. Zahlungen können Miete, Medikamente oder Gehälter betreffen. Eine automatische Blockierung hat direkte Auswirkungen auf die finanzielle Situation natürlicher Personen.
Vorsicht bei der Einordnung: Anhang III Nr. 5 AI Act erfasst im Finanzbereich die Bewertung der Kreditwürdigkeit natürlicher Personen sowie Risikobewertung/Preisbildung in der Leben- und Krankenversicherung – und nimmt KI zur Aufdeckung von Finanzbetrug ausdrücklich aus. Ein Betrugserkennungssystem ist daher nicht schon deshalb Hochrisiko-KI, weil es Zahlungen blockiert. Ebenso wenig ist die «minimal risk»-Einordnung damit belegt – das ist der eigentliche Prüfpunkt: Ist es überhaupt ein KI-System, wer ist Provider/Deployer, greift Art. 22 DSGVO, unterstützt es eine kritische DORA-Funktion?
Das System wurde als «nützliches Tool» konzipiert. Es entscheidet. Das ist ein Unterschied – regulatorisch und governance-seitig.
Die drei Optionen des Boards
DORA: Standard-Eintrag bleibt. AI Act: «minimal risk» bleibt. Operativer Aufwand entfällt. Regulatorisches Risiko bleibt.
- Keine zusätzlichen Compliance-Anforderungen kurzfristig
- Erhebliches Risiko, wenn die Klassifikationen in einem Audit in Frage gestellt werden
- DORA: fehlende Exit-Strategie für ein de-facto-kritisches System
- AI Act: ungeprüfte Klassifikation – Betrugserkennung ist regelmäßig kein Anhang-III-Hochrisiko, aber die Einstufung muss belastbar dokumentiert sein
Strukturierte Neubewertung: DORA-Kritikalität und AI-Act-Risikostufe werden methodisch und mit externer Validierung überprüft.
- Wahrscheinliches Ergebnis: DORA-Funktion als kritisch/wichtig eingestuft; AI-Act-Einordnung belastbar begründet (Betrugserkennung regelmäßig kein Anhang-III-Hochrisiko)
- Konsequenz DORA: Exit-Strategie, intensiviertes Monitoring, Vertragsanpassungen
- Konsequenz AI Act: dokumentierte Klassifikation; falls doch Hochrisiko, Konformitätsbewertung/Risikomanagement/Human Oversight – sonst Datenschutz- und Zahlungsdienste-Kontrollen
- Aufwand erheblich – aber die richtige regulatorische Position
DORA-Kritikalität sofort anpassen. AI-Act-Klassifikation in einem strukturierten Prozess über 90 Tage klären.
- Pragmatische Sequenzierung: Das dringlichere DORA-Risiko wird zuerst adressiert
- AI-Act-Klassifikation wird mit externer Rechts- und technischer Expertise bewertet
- Board beschließt und protokolliert den Übergangsplan
- Zeigt regulatorischen Behörden aktives Compliance-Management statt Ignoranz
Was das Board vor der Entscheidung klären sollte
Was passiert operativ, wenn dieses System für 30 Minuten ausfällt – und wer hat das analysiert?
Wer hat die «minimal risk»-Einordnung nach AI Act vorgenommen, und auf welcher Grundlage – Anhang III Nr. 5 und die Fraud-Detection-Ausnahme explizit geprüft?
Gibt es eine Exit-Strategie für dieses System – also: Was tun wir, wenn der API-Anbieter ausfällt oder kündigt?
Gibt es einen Human-Oversight-Mechanismus – eine Person, die automatische Blockierungen prüfen und rückgängig machen kann?
Kann das Board die AI-Act-Einordnung des Systems begründen – einschließlich der Frage, ob die Betrugserkennungs-Ausnahme greift – und die menschliche Kontrolle über automatische Blockierungen belegen?
Wenn zwei Regulierungen denselben Sachverhalt erfassen, ist die Versuchung groß, eine zu wählen – und die andere zu übersehen. Genau diese Wahl trifft das Board, ohne sie zu treffen, wenn es nicht beide explizit prüft.
Regulatorischer Kontext
Nach DORA nimmt das Finanzunternehmen selbst die Einordnung vor, ob ein ICT-Drittdienstleister eine kritische oder wichtige Funktion unterstützt (die vertraglichen Arrangements werden im Informationsregister nach Art. 28 Abs. 3 erfasst; die formale Designation kritischer IKT-Drittdienstleister/CTPP auf Unionsebene obliegt dagegen den ESAs nach Art. 31). Die Einordnung richtet sich nach der Ausfallwirkung auf kritische oder wesentliche Funktionen. AI Act Anhang III Nr. 5 erfasst im Finanzbereich die Bewertung der Kreditwürdigkeit natürlicher Personen sowie Risikobewertung und Preisbildung in der Leben-/Krankenversicherung – KI zur Betrugserkennung ist davon ausdrücklich ausgenommen. Eine automatische Zahlungsblockierung fällt daher nicht automatisch unter Anhang III; relevanter sind hier Datenschutz (Art. 22 DSGVO), Zahlungsdienste- und Verbraucherschutzrecht sowie – bei Unterstützung einer kritischen oder wichtigen Funktion – DORA. Das eigentliche Dilemma bleibt: Ein System kann außerhalb von Anhang III liegen und trotzdem eine robuste menschliche Eskalations- und Korrekturstruktur brauchen.
Folge 4 · Versicherung
KI-Underwriting und Proxy-Diskriminierung: Was antwortet das Board der Aufsicht?
Die Frage lautet nicht: Haben wir diskriminiert? Die Frage lautet: Kann das Board erklären, was das System tatsächlich entscheidet – und würde es dieser Erklärung standhalten?
Ihr Versicherungsunternehmen hat vor 18 Monaten ein KI-System für das Underwriting in der Kraftfahrzeugversicherung eingeführt. Das System berechnet individuelle Prämien auf Basis von Telematikdaten: Fahrverhalten, Tageszeit, Streckencharakteristik, Bremsverhalten. Es ist das Kernelement Ihrer Pricing-Strategie. Das Board hat die Einführung genehmigt.
Jetzt liegt eine Anfrage der BaFin auf dem Tisch. Sie verlangt Dokumentation zu drei Punkten: wie das Modell Entscheidungen trifft, ob geschützte Merkmale als Proxy-Variablen verwendet werden und welcher Human-Oversight-Mechanismus für die Pricing-Entscheidungen existiert.
Was die interne Analyse zeigt
Das Modell verwendet «Fahrzeit» als zentralen Prädiktor. Wer überwiegend zwischen 22:00 und 6:00 Uhr fährt, erhält eine höhere Risikoklassifikation und damit höhere Prämien. Diese Korrelation ist statistisch robust. Sie ist auch erklärbar: Nachtfahrten sind statistisch risikoreich.
Was die interne Analyse jedoch auch zeigt: «Fahrzeit» korreliert stark mit Beruf und Einkommensgruppe. Nachtfahrer sind überproportional in Berufsgruppen mit Schichtarbeit vertreten, die statistisch niedrigere Einkommensgruppen darstellen. Das Modell diskriminiert nicht nach Einkommen – es korreliert mit einem Merkmal, das mit Einkommen korreliert. Ob daraus rechtlich eine (mittelbare) Diskriminierung wird, steht damit aber noch nicht fest: Das AGG schützt vor Benachteiligung wegen geschützter Merkmale, nicht wegen Einkommens oder sozialer Schicht. Erst wenn «Fahrzeit» überproportional Träger eines geschützten Merkmals trifft und das nicht sachlich gerechtfertigt ist, entsteht ein Proxy-Diskriminierungsproblem.
Der Human-Oversight-Mechanismus: Ein Underwriter kann Prämienentscheidungen überprüfen, wenn ein Kunde explizit Einspruch erhebt. Das System ist so ausgelegt, dass Einsprüche in der Praxis selten sind.
Das Board hat ein System genehmigt, das es für ein Pricing-Instrument hält. Die BaFin betrachtet es möglicherweise als ein System, das strukturell benachteiligte Gruppen systematisch schlechter stellt. Beide Beschreibungen sind korrekt.
Die drei Optionen des Boards
Die technische Dokumentation, die für die BaFin-Anfrage relevant ist, existiert. Sie wird vollständig übergeben.
- Schnellste Antwort, keine operativen Änderungen
- Risiko: Die Dokumentation erklärt das Modell technisch, aber nicht die Proxy-Wirkung
- BaFin kann auf Basis der Dokumentation eine Nachfolgeanfrage oder Prüfung einleiten
- Board hat keine Kontrolle über die Narrative, die die Dokumentation erzeugt
Vor der Antwort an die BaFin wird ein unabhängiges Bias-Audit der Faktor-Korrelationen durchgeführt.
- Verzögerung der Antwort – mit BaFin abzustimmen und zu begründen
- Stärkste Verteidigungsposition: Board zeigt, dass es das Problem erkannt und proaktiv adressiert hat
- Wenn das Audit Proxy-Diskriminierung bestätigt: Board muss entscheiden, ob und wie das Modell angepasst wird
- Empfehlenswert, wenn das Board sich nicht sicher ist, ob die interne Analyse vollständig ist
Parallel zur BaFin-Antwort wird der Oversight-Mechanismus strukturell überarbeitet: von reaktiv (Einspruch) zu proaktiv (systematische Stichprobenprüfung).
- Adressiert einen der drei BaFin-Punkte direkt und konstruktiv
- Zeigt regulatorischen Willen ohne Eingeständnis eines Fehlers
- Proxy-Frage bleibt offen – muss separat adressiert werden
- Board protokolliert sowohl die Überarbeitung als auch die Begründung
Was das Board vor der Entscheidung klären sollte
Hat das Board bei der Genehmigung des Systems verstanden, welche Variablen das Modell als zentrale Prädiktoren verwendet?
Wurde die Korrelation zwischen «Fahrzeit» und sozioökonomischen Merkmalen intern analysiert – und wann?
Was ist die rechtliche Einordnung: Ist Proxy-Diskriminierung nach AGG und Versicherungsaufsichts-/Gleichbehandlungsrecht ein Verstoß, auch wenn das Modell keine geschützten Merkmale direkt verwendet?
Wer hat den Human-Oversight-Mechanismus konzipiert, und basiert er auf der Annahme, dass Kunden Einspruch erheben – oder darauf, dass das System systematisch überprüft wird?
Ist das Board bereit, gegenüber der BaFin zu erklären, wie das System Entscheidungen trifft – in eigenen Worten, nicht in der Sprache der Entwicklungsabteilung?
Die schwierigste Governance-Frage ist nicht: Was haben wir falsch gemacht? Die schwierigste Frage ist: Was haben wir genehmigt, ohne es vollständig zu verstehen?
Regulatorischer Kontext
Der AI Act (Anhang III Nr. 5) erfasst im Versicherungsbereich ausdrücklich nur Risikobewertung und Preisbildung in der Leben- und Krankenversicherung. Die Kraftfahrzeugversicherung ist davon nicht erfasst – die auf High-Risk-Pflichten (Art. 14, Art. 26 Abs. 2) gestützten Aussagen tragen für diesen Fall also nicht. Das heißt nicht, dass das System unproblematisch ist: Relevanter sind hier Versicherungsaufsichtsrecht (VAG/BaFin; die IDD betrifft primär Vertrieb und Produktaufsicht, nicht die Prämiendifferenzierung im Underwriting), für die Preisdifferenzierung die EU-Gleichbehandlungsrichtlinie 2004/113 (Unisex-Rechtsprechung), Datenschutz/Profiling und das Antidiskriminierungsrecht. Das AGG verbietet mittelbare Diskriminierung aber nur, wenn eine neutrale Regel Träger eines geschützten Merkmals (z. B. Geschlecht, Alter, Behinderung, ethnische Herkunft, Religion) besonders benachteiligt und dies nicht sachlich gerechtfertigt und verhältnismäßig ist. Eine bloße Korrelation mit Einkommen oder sozialer Schicht ist kein AGG-Verstoß. Zur AI-Act-Rolle: Weil die Kfz-Prämienbildung hier nicht als Hochrisiko-KI nach Anhang III einzustufen ist, greifen die High-Risk-Pflichten (Art. 14, Art. 26 Abs. 2) nicht. Nur falls das eingesetzte System aus anderen Gründen doch als Hochrisiko-KI zu qualifizieren wäre, träfe den Versicherer eine Doppelrolle: als Anbieter (entwickelt das System selbst) die Pflicht nach Art. 14 zur eingebauten menschlichen Aufsicht, als Betreiber (setzt es operativ ein) die Pflicht nach Art. 26 Abs. 2 zur tatsächlichen Implementierung. Dann — und nur dann — griffen beide Pflichtenkreise parallel, und die operative Aufsicht müsste die Systementscheidungen tatsächlich verstehen und überprüfen können.