Reihe · 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.
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.
Post-Market-Monitoring adressiert mögliche Verzerrungen. Akzeptanz struktureller Unsicherheit als kalkuliertes Risiko.
Priorisierung europäischer Datenbasis vor Launch. Wirtschaftliche Konsequenzen werden bewusst in Kauf genommen.
Engmaschiges Post-Market-Monitoring als Kontrollmechanismus – mit vorab definierten Abbruchkriterien.
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 klassifiziert KI-Systeme, die in der Medizintechnik eingesetzt werden, als Hochrisiko (Annex III Nr. 6) – mit Anforderungen an Daten-Governance, Transparenz und menschliche Aufsicht. 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.
Die Frage lautet nicht: Ist das regulatorisch zulässig? Die Frage lautet: Versteht das Board, was sich mit dem Update verändert?
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?
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.
Rechtliche und technische Einordnung der eigenen Teams wird akzeptiert. Update wird als Verbesserung freigegeben.
Unabhängige klinische Experten bewerten die Verhaltensänderung, bevor das Update in Betrieb geht.
Update geht in Betrieb, aber mit vorab genehmigten Abbruchkriterien und intensivierter Überwachung der geänderten Verhaltensparameter.
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.
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.
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.
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.
Annex III Nr. 5 AI Act nennt explizit KI-Systeme, die den Zugang zu wesentlichen privaten Dienstleistungen beeinflussen oder über diesen Zugang entscheiden. Die Einordnung als «minimal risk» ist möglicherweise nicht haltbar.
Das System wurde als «nützliches Tool» konzipiert. Es entscheidet. Das ist ein Unterschied – regulatorisch und governance-seitig.
DORA: Standard-Eintrag bleibt. AI Act: «minimal risk» bleibt. Operativer Aufwand entfällt. Regulatorisches Risiko bleibt.
Strukturierte Neubewertung: DORA-Kritikalität und AI-Act-Risikostufe werden methodisch und mit externer Validierung überprüft.
DORA-Kritikalität sofort anpassen. AI-Act-Klassifikation in einem strukturierten Prozess über 90 Tage klären.
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 – Annex III Nr. 5 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?
Ist das Board bereit, im Audit zu erklären, warum ein System, das Zahlungen automatisch blockiert, kein Hochrisiko-System ist?
Regulatorischer Kontext
DORA Art. 28 Abs. 3 verlangt die Klassifikation von ICT-Drittdienstleistern nach Kritikalität – die Entscheidung richtet sich nach der Ausfallwirkung auf kritische oder wesentliche Funktionen. AI Act Annex III Nr. 5 erfasst KI-Systeme zur Bewertung der Kreditwürdigkeit und des Zugangs zu wesentlichen privaten Dienstleistungen – dazu gehört nach verbreiteter Rechtsauffassung auch die automatisierte Entscheidung über die Ausführung von Zahlungen. Human Oversight ist nach AI Act Art. 26 Abs. 2 für Deployer von Hochrisiko-KI verpflichtend. Die Koinzidenz von DORA und AI Act bei demselben System ist der Kern des Dilemmas: Beide Regulierungen greifen, stellen aber unterschiedliche Anforderungen.
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 Telematicdaten: 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.
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. Das ist Proxy-Diskriminierung.
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 technische Dokumentation, die für die BaFin-Anfrage relevant ist, existiert. Sie wird vollständig übergeben.
Vor der Antwort an die BaFin wird ein unabhängiges Bias-Audit der Faktor-Korrelationen durchgeführt.
Parallel zur BaFin-Antwort wird der Oversight-Mechanismus strukturell überarbeitet: von reaktiv (Einspruch) zu proaktiv (systematische Stichprobenprüfung).
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 IDD 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 (Annex III Nr. 5) erfasst KI-Systeme zur Risikobewertung und Preisgestaltung in der Lebens- und Krankenversicherung explizit als Hochrisiko. Für Kraftfahrzeugversicherung ist die Einordnung weniger explizit, aber nach verbreiteter Rechtsauffassung ebenfalls anwendbar, wenn das System individualisierte Preisentscheidungen trifft. Die IDD (Insurance Distribution Directive) verlangt, dass Versicherungsprodukte den Interessen der Kunden entsprechen und fair gestaltet sind. Das AGG (Allgemeines Gleichbehandlungsgesetz) verbietet mittelbare Diskriminierung auch dann, wenn keine geschützten Merkmale direkt verwendet werden. Human Oversight nach AI Act Art. 26 Abs. 2 erfordert, dass die verantwortliche Person nicht nur eingreifen kann, sondern tatsächlich in der Lage ist, Entscheidungen des Systems zu verstehen und zu überprüfen.