KI-Risikomanagement im Medizinbetrieb

Die Bandbreite reicht von Systemen, die in der Radiologie Auffälligkeiten markieren und dringliche Fälle nach vorn sortieren, über Frühwarnscores auf Intensivstationen, Auswertungen in Labor und Pathologie und Dosierungsvorschläge bis zu Sprachmodellen, die Arztbriefe entwerfen oder Gespräche dokumentieren. Hinzu kommen Werkzeuge ohne direkten Patientenbezug, etwa für Dienstplanung, Bettenmanagement oder Terminsteuerung. Je näher ein System an der Diagnose- oder Therapieentscheidung arbeitet, desto unmittelbarer wirken seine Fehler auf Menschen.

Schon ein Update, das niemand bemerkt hat, eine Datenbasis, in der bestimmte Patientengruppen kaum vorkommen, oder eine verschobene Kalibrierung genügen, damit sich Befunde verändern – oft ohne dass es im Stationsalltag auffällt. Für Betreiber ist deshalb nicht die Frage entscheidend, ob ein System „intelligent“ ist, sondern welche Entscheidung es beeinflusst, wer sich auf seine Ausgaben verlässt und was geschieht, wenn es irrt oder ausfällt.

Drei Gruppen von Risiken

• Technische Risiken: Fehlklassifikationen, nachlassende Modellleistung, Angriffe auf Daten, Modell oder Schnittstellen sowie Ausfälle von Diensten.
• Organisatorische Risiken: unklare Zuständigkeiten, fehlende Schulung, ungeregelte Updates, Nutzung nicht freigegebener KI-Werkzeuge und Lücken in der Vorfallbehandlung.
• Ethische und rechtliche Risiken: Benachteiligung von Patientengruppen, mangelnde Nachvollziehbarkeit, Datenschutzverstöße und ein Vertrauensverlust zwischen Behandelnden und Behandelten.

Zwei Begriffe, die man kennen muss

Modelldrift bezeichnet den schleichenden Leistungsverlust eines Modells, weil sich Eingabedaten, Patientenpopulation, Geräte oder klinische Abläufe gegenüber den Bedingungen der Validierung verändert haben. Der Leitfaden MDCG 2025-6 empfiehlt dazu, Datensätze so zu gestalten, dass unbeabsichtigte Verzerrungen und Datensatzdrift beherrschbar bleiben und Untergruppen erkennbar werden, in denen ein Modell auch im Zeitverlauf schwächer abschneidet.

Automatisierungsbias meint die Neigung, sich auf maschinelle Ausgaben zu verlassen oder ihnen zu sehr zu vertrauen. Der AI Act verlangt, dass Aufsichtspersonen in die Lage versetzt werden, diese Neigung zu erkennen, Ausgaben richtig zu deuten, sie im Einzelfall zu übergehen und das System über eine Stopp-Funktion oder ein vergleichbares Verfahren anzuhalten.

Diese Seite fasst den Fachbeitrag „Risikomanagement für KI-Systeme im Medizinbetrieb“ aus mt|medizintechnik, Ausgabe 2.2026, zusammen, gliedert ihn neu und ergänzt ihn um Entwicklungen bis Oktober 2026, insbesondere den Digital Omnibus zum AI Act.

Der AI Act stuft medizinische KI nicht pauschal als hochriskant ein. Maßgeblich ist der Weg über die Produktgesetzgebung: Ist die KI selbst Medizinprodukt oder In-vitro-Diagnostikum beziehungsweise Sicherheitsbauteil eines solchen, und muss eine Benannte Stelle an der Konformitätsbewertung mitwirken, gilt sie als Hochrisiko-KI-System. Weil die MDR Software, die Informationen für Diagnose- oder Therapieentscheidungen liefert, in der Regel mindestens der Klasse IIa zuordnet, trifft das auf die meisten diagnostischen und therapeutischen KI-Anwendungen zu. Die Anforderungen des AI Act werden dann im bestehenden MDR-Verfahren der Benannten Stelle mitgeprüft – eine zweite Zertifizierung entsteht nicht.

Daneben nennt der AI Act einige Einsatzzwecke im Gesundheitsumfeld unmittelbar als hochriskant: die Bewertung von Notrufen und die Triage von Notfallpatienten, Entscheidungen von Behörden über den Zugang zu öffentlichen Gesundheitsleistungen sowie Risikobewertung und Preisgestaltung in der Kranken- und Lebensversicherung. Ist ein solches Triage-System zugleich ein Medizinprodukt mit Benannter Stelle, hat der Weg über die Produktgesetzgebung Vorrang.

Wie NIS2 und Datenschutz andocken

Für Kliniken, die das BSI-Gesetz als besonders wichtige oder wichtige Einrichtung erfasst, sind KI-Systeme Teil der zu schützenden IT: Ein erheblicher Sicherheitsvorfall in einem KI-Dienst ist früh zu melden – spätestens nach 24 Stunden eine Erstmeldung, nach 72 Stunden eine Meldung mit erster Bewertung und spätestens einen Monat danach eine Abschlussmeldung. Der Datenschutz verlangt für risikoreiche Verarbeitungen eine Datenschutz-Folgenabschätzung; der AI Act verpflichtet Betreiber, dafür die Informationen des Anbieters zu nutzen.

Zeitachse aus Betreibersicht

• Seit 2. Februar 2025: Verbote bestimmter KI-Praktiken; Pflicht, die KI-Kompetenz der Beschäftigten zu fördern – seit dem Omnibus ausdrücklich ohne garantiertes Kompetenzniveau.
• Seit 2. August 2026: allgemeine Anwendung des AI Act und Transparenzpflichten; Aufsicht durch das AI Office und nationale Behörden.
• Seit 11. September 2026: Meldepflichten der Hersteller nach dem Cyber Resilience Act für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle.
• Ab 2. Dezember 2027: Hochrisiko-Pflichten für direkt eingestufte Zwecke, etwa Notfall-Triage, die nicht als Medizinprodukt mit Benannter Stelle geprüft wird.
• Ab 2. August 2028: Hochrisiko-Pflichten für KI-Medizinprodukte – für Anbieter und für Betreiber. Bereits vorher in Verkehr gebrachte Systeme erfasst das nur bei wesentlichen Änderungen am Design; für Systeme, die für den Einsatz durch Behörden bestimmt sind, gilt spätestens der 2. August 2030.

Der Omnibus enthält zudem eine Öffnung, deren Ausgang noch offen ist: Die Kommission kann für Produkte mit eigenem Sektorrecht – darunter Medizinprodukte – einzelne Anforderungen des AI Act per delegiertem Rechtsakt begrenzen, soweit das Sektorrecht gleichwertigen Schutz bietet. Dafür hat sie bis zum 2. August 2027 Zeit. Für die Planung in Kliniken ändert das wenig, denn die Betreiberpflichten bleiben davon unberührt. Weiter reicht ein Vorschlag der Kommission vom Dezember 2025 zur Revision von MDR und IVDR: Er würde KI-Medizinprodukte in eine leichtere Regelungsgruppe des AI Act verschieben, sodass die KI-Anforderungen vorrangig über die MDR umgesetzt würden. Beschlossen ist das nicht; bis dahin gelten die hier genannten Stichtage.

Anbieter ist, wer ein KI-System entwickelt oder entwickeln lässt und unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt; bei Medizinprodukten ist das in aller Regel der Hersteller nach MDR. Betreiber ist, wer das System in eigener Verantwortung beruflich nutzt. Der Leitfaden MDCG 2025-6 stellt klar, dass der Betreiber nicht mit dem „Anwender“ der MDR gleichzusetzen ist: In der Klinik ist die Einrichtung Betreiber, die Ärztin am Befundplatz ist Anwenderin.

Wann die Einrichtung selbst zum Anbieter wird

• Sie bringt ein bereits in Verkehr befindliches Hochrisiko-System unter eigenem Namen oder eigener Marke heraus.
• Sie verändert ein Hochrisiko-System wesentlich, also auf eine Weise, die in der ursprünglichen Konformitätsbewertung nicht vorgesehen war und die Konformität oder den Zweck berührt.
• Sie setzt ein bisher nicht hochriskantes System – auch ein allgemeines Sprachmodell – für einen Zweck ein, der es hochriskant macht.

Nach MDCG 2025-6 ist eine neue Konformitätsbewertung bei wesentlicher Änderung auch dann nötig, wenn die Einrichtung das veränderte System nur selbst weiterverwendet. Vom Hersteller vorab festgelegte und bewertete Änderungen, etwa in einem Plan für vorbestimmte Änderungen, gelten dagegen nicht als wesentlich. Eigenentwicklungen, die eine Gesundheitseinrichtung nach den Regeln für In-house-Produkte ausschließlich intern einsetzt, sind laut Leitfaden keine Hochrisiko-KI; andere Pflichten des AI Act bleiben bestehen.

Was in den Vertrag gehört

• Angaben zur Datenherkunft, zu den Validierungspopulationen und zu bekannten Leistungsgrenzen.
• Updatepolitik mit Ankündigungsfristen, Release-Informationen und Rückfalloption.
• Zugriff auf Protokolle und Unterstützung bei Vorfallanalyse und Datenschutz-Folgenabschätzung.
• Meldewege, Reaktionszeiten und Ansprechpartner für Sicherheitsfragen.
• Sicherheitszusagen für Cloud-Komponenten und Drittbibliotheken, einschließlich Stückliste.
• Supportende und geordnete Herausgabe oder Löschung von Daten bei Vertragsende.

Ein eigenes Risikomanagementsystem im Sinne des AI Act schreibt das Gesetz nur dem Anbieter vor. Betreiber haben Überwachungs-, Aufsichts-, Daten-, Protokoll- und Meldepflichten. Ein strukturiertes Risikomanagement in der Einrichtung ist dennoch die praktische Grundlage, um diese Pflichten zu erfüllen. Die Betreibernorm IEC 80001-1 beschreibt genau diesen Ansatz für vernetzte Medizinprodukte und Gesundheitssoftware: Risikomanagement vor, während und nach der Einbindung in die Klinik-IT.

1. 1
   Vor der Beschaffung: Zweck und Einordnung

   Klinischen Nutzen, Zweckbestimmung, Rolle der Einrichtung und regulatorische Einordnung klären. Akzeptanzkriterien festlegen: Welche Fehlerraten und welche Restrisiken sind für diesen Einsatz vertretbar, und wer entscheidet darüber?

2. 2
   Vor der Inbetriebnahme: Prüfung im eigenen Umfeld

   Mit eigenen, repräsentativen Daten prüfen, ob die Leistung des Herstellers in der eigenen Population erreicht wird. Schnittstellen, Berechtigungen und Netzsegment absichern, Aufsichtspersonen benennen und schulen, Rückfallprozess festlegen.

3. 3
   Im Betrieb: Überwachung und Rückmeldung

   Leistungskennzahlen, Übersteuerungsquoten, Datenqualität und Verfügbarkeit laufend beobachten. Auffälligkeiten dokumentieren, an den Anbieter melden und bei Risiko die Nutzung aussetzen.

4. 4
   Bei Änderungen: kontrollierte Freigabe

   Jedes Modell-Update, jede neue Schnittstelle und jeder neue Einsatzbereich durchläuft Bewertung, Test, Freigabe und Dokumentation. Prüfen, ob die Änderung vorab vom Hersteller festgelegt war oder die Einrichtung in die Anbieterrolle rücken würde.

5. 5
   Bei Außerbetriebnahme: geordneter Abschied

   Ersatzprozess sicherstellen, Protokolle und Nachweise nach den Aufbewahrungsfristen sichern, Zugänge und Schnittstellen schließen, Daten beim Anbieter löschen lassen und die Erfahrungen in die nächste Beschaffung einfließen lassen.

STRIDE geht auf Loren Kohnfelder und Praerit Garg zurück, die das Schema 1999 bei Microsoft beschrieben. Es ordnet Bedrohungen sechs Kategorien zu und lässt sich gut auf ein Datenflussdiagramm anwenden: Für jede Komponente und jede Verbindung wird gefragt, welche Kategorie dort denkbar ist. Bei einem KI-Befundungssystem gehören dazu typischerweise das bildgebende Gerät (in der Radiologie „Modalität“ genannt), das Bildarchiv, der Inferenzdienst – lokal oder in der Cloud –, die Ergebnisanzeige, das Klinikinformationssystem und der Updatekanal des Herstellers.

KI-spezifische Bedrohungen

Der AI Act nennt selbst typische Angriffe auf KI: Vergiftung von Daten und Modellen, gezielt veränderte Eingaben, die ein Modell täuschen, sowie Angriffe auf die Vertraulichkeit und Ausnutzung von Modellschwächen. Für Anwendungen mit Sprachmodellen bieten die OWASP Top 10 for LLM Applications in der Fassung 2026 eine aktuelle Gliederung. Für Einrichtungen sind vor allem diese Muster relevant:

Bewährt hat sich eine Matrix mit zwei Achsen. Auf der einen steht die Wahrscheinlichkeit, gespeist aus technischen Faktoren wie Angriffsfläche und Modellrobustheit, aus organisatorischen Faktoren wie Schulungsstand und Prozessreife und aus menschlichen Faktoren wie Zeitdruck und Automatisierungsbias. Auf der anderen steht die Schwere der Folgen – medizinisch, datenschutzrechtlich, betrieblich und mit Blick auf das Vertrauen in die Einrichtung.

Bias gezielt prüfen

Verzerrungen entstehen, wenn Trainingsdaten die eigene Patientenschaft nicht abbilden oder wenn sich Abläufe und Geräte ändern. Betreiber sollten deshalb Leistungskennzahlen nicht nur insgesamt, sondern nach relevanten Untergruppen auswerten, soweit Daten und Rechtsgrundlage das zulassen. Seit dem Omnibus erlaubt der AI Act Betreibern von Hochrisiko-Systemen, zur Erkennung von Verzerrungen ausnahmsweise auch besondere Kategorien personenbezogener Daten wie Gesundheitsdaten zu verarbeiten – unter strengen Schutzauflagen und ohne dass daraus eine Pflicht folgt.

Grundrechte-Folgenabschätzung: wann sie Pflicht ist

Eine Grundrechte-Folgenabschätzung verlangt der AI Act nur für die Hochrisiko-Zwecke, die er selbst auflistet, und nur von öffentlichen Stellen und privaten Erbringern öffentlicher Dienste sowie von Betreibern, die Kreditwürdigkeit prüfen oder Lebens- und Krankenversicherungen bepreisen. Öffentliche Kliniken und private Häuser mit Versorgungsauftrag können damit etwa beim Einsatz eines Triage-Systems in der Notaufnahme betroffen sein; ist dieses zugleich ein Medizinprodukt mit Benannter Stelle, sollte wegen des Vorrangs der Produktgesetzgebung im Einzelfall geprüft werden, ob die Pflicht greift. Für KI-Medizinprodukte, die allein über die MDR hochriskant sind, gilt diese Pflicht nicht. Der Omnibus erlaubt, auf eine bereits erstellte Datenschutz-Folgenabschätzung zu verweisen.

1. 1
   Prävention

   Sicherheit beginnt bei der Auswahl: Secure by Design beim Anbieter einfordern, Validierung mit repräsentativen eigenen Testdaten durchführen, Netzsegmentierung, Mehrfaktor-Anmeldung und rollenbasierte Rechte umsetzen. Wer vor dem Echtbetrieb einen zweiten, unabhängigen Blick einholt – aus einer externen Sicherheitsprüfung oder einer Partnerklinik mit Erfahrung im selben Einsatzfeld –, findet blinde Flecken, bevor sie Patienten betreffen.

2. 2
   Erkennung

   Abweichungen früh bemerken: Leistungskennzahlen und Eingabedaten auf Drift überwachen, Protokolle auswerten, Alarme für ungewöhnliches Verhalten definieren und Übersteuerungen durch das Personal als Frühindikator nutzen. Auf Intensivstation und in der Notaufnahme zählt, wie schnell eine Auffälligkeit beim zuständigen Team ankommt.

3. 3
   Korrektur

   Wenn etwas schiefgeht: Menschen behalten an kritischen Punkten das letzte Wort und können das System anhalten. Rückfallprozesse ohne KI, die Möglichkeit zur Rückkehr auf eine frühere Modellversion, klare Eskalationswege und ein eingeübter Ablauf zur Vorfallbehandlung begrenzen den Schaden.

4. 4
   Nachweis

   Dokumentation verbindet alles: Einordnung, Risikobewertung, Testergebnisse, Freigaben, Schulungen, Übersteuerungen, Vorfälle und Korrekturen. Sie belegt die Erfüllung der Pflichten gegenüber Aufsicht und Auditoren und ist Grundlage der kontinuierlichen Verbesserung.

Melden, wenn es ernst wird

Hat die Einrichtung Grund zur Annahme, dass die Nutzung ein Risiko birgt, informiert sie unverzüglich den Anbieter oder Händler sowie die Marktüberwachungsbehörde und setzt die Nutzung aus. Bei einem schwerwiegenden Vorfall verlangt der AI Act, unverzüglich zuerst den Anbieter zu informieren. Bei KI-Medizinprodukten laufen gesundheitsbezogene Vorfälle über das Vigilanzsystem der MDR – der Hersteller meldet je nach Schwere spätestens nach 15, 10 oder 2 Tagen. In Deutschland müssen zudem Betreiber und Anwender mutmaßliche schwerwiegende Vorkommnisse unverzüglich der zuständigen Bundesoberbehörde melden, in der Regel dem BfArM. Über den AI Act zu melden sind dort nur Verletzungen grundrechtsschützender Pflichten. Parallel können Meldungen nach BSI-Gesetz und Datenschutzrecht anfallen.

Konkrete Maßnahmen im Überblick

• Inventar aller KI-Systeme mit Zweck, Einordnung, Verantwortlichen und Datenflüssen.
• Benannte Aufsichtspersonen je System mit dokumentierter Schulung und Befugnis zum Übersteuern.
• Protokollierung mit Modellversion und Nutzeraktion, Aufbewahrung mindestens sechs Monate.
• Freigabeverfahren für Updates mit Test in einer Referenzumgebung.
• Regelmäßige Sicherheitstests und KI-Red-Teaming, insbesondere bei Sprachmodellen und Agenten.
• Abgestimmte Meldematrix für Anbieter, Medizinprodukte-Vigilanz, BSI und Datenschutzaufsicht.

Viele Einrichtungen betreiben bereits ein Informationssicherheitsmanagementsystem, ein Qualitätsmanagement und ein Datenschutzmanagement. KI-Risiken lassen sich dort einhängen: als eigene Risikokategorie, mit eigenen Kontrollen und mit einer klaren Rolle für die Freigabe neuer Systeme. Welche Norm welchen Beitrag leistet, zeigt die folgende Übersicht.

Für Kliniken, die unter das BSI-Gesetz fallen, ist die Einbettung auch rechtlich naheliegend: Die geforderten Risikomanagementmaßnahmen umfassen unter anderem Vorfallbewältigung, Lieferkettensicherheit sowie Sicherheit bei Erwerb, Entwicklung und Wartung einschließlich des Umgangs mit Schwachstellen. KI-Dienste und ihre Anbieter gehören damit in das Lieferanten- und Schwachstellenmanagement des ISMS.

1. 1
   Tage 1–15: Verantwortung festlegen

   Eine verantwortliche Stelle für KI benennen, Medizintechnik, IT-Sicherheit, Datenschutz, Qualitätsmanagement und ärztliche Leitung in ein Gremium holen und die Freigabe neuer KI-Systeme an dieses Gremium binden.

2. 2
   Tage 16–30: Inventar erstellen

   Alle KI-Systeme erfassen, auch eingebettete Funktionen in Geräten und Cloud-Diensten. Für jedes System Zweck, Anbieter, Datenflüsse, Nutzergruppen und regulatorische Einordnung festhalten.

3. 3
   Tage 31–45: Risiken priorisieren

   Für die Systeme mit dem größten Patientenbezug ein Bedrohungsmodell nach STRIDE erstellen und die Auswirkungen bewerten. Ergebnis ist eine Liste der dringendsten Maßnahmen.

4. 4
   Tage 46–60: Verträge und Anbieter

   Bestehende Verträge auf Updatepolitik, Protokollzugang, Datenherkunft, Meldewege und Supportende prüfen; fehlende Zusagen nachverhandeln und Einkaufsanforderungen für künftige Beschaffungen festlegen.

5. 5
   Tage 61–75: Aufsicht und Kompetenz

   Aufsichtspersonen je System benennen, zielgruppengerechte Schulungen zu Leistungsgrenzen und Automatisierungsbias durchführen, Beschäftigte und ihre Vertretung informieren.

6. 6
   Tage 76–90: Betrieb verankern

   Überwachung und Protokollaufbewahrung einrichten, Änderungsverfahren und Meldematrix in Kraft setzen, eine Übung zur Vorfallbehandlung durchführen und den Plan für die folgenden zwölf Monate verabschieden.

Der Plan ist eine Orientierung und ersetzt keine Einzelfallprüfung. Umfang und Reihenfolge hängen von Größe, Versorgungsauftrag und KI-Bestand der Einrichtung ab.