KI in Medizin und Gesundheitswesen: Medizinprodukt, Hochrisiko-KI oder Assistenztool?

Die Einstufung beginnt mit Zweck und Produktstatus

Gesundheitsbezug ist keine eigene Risikoklasse. Eine Software zur Terminplanung, Abrechnung, allgemeinen Wissenssuche oder Transkription wird nicht allein deshalb zu einem Hochrisikosystem, weil sie in einer Ordination oder Krankenanstalt läuft. Ausgangspunkt sind die vom Anbieter festgelegte Zweckbestimmung, die tatsächlich vorgesehene Funktion und der Einfluss des Ergebnisses auf Diagnose, Therapie, Triage oder Patientensicherheit. Erst danach lässt sich beurteilen, ob Medizinprodukterecht und die Produktlogik des AI Act zusammenwirken.

Artikel 6 Absatz 1 verlangt kumulativ, dass das KI-System selbst ein von Anhang I erfasstes Produkt oder eine Sicherheitskomponente eines solchen Produkts ist und dass das Produkt nach dem einschlägigen Unionsrecht eine Konformitätsbewertung unter Beteiligung einer dritten Stelle benötigt. Fehlt eine dieser Voraussetzungen, greift dieser konkrete Hochrisikoweg nicht. Das schließt andere Einordnungen, etwa einen in Anhang III genannten Verwendungszweck, eine verbotene Praxis oder Transparenzpflichten, nicht automatisch aus.

• Zweckbestimmung und Nutzergruppe schriftlich festhalten.
• Produktstatus nach MDR oder IVDR getrennt prüfen.
• Konformitätsweg und Beteiligung einer benannten Stelle dokumentieren.

Quellen: [1] [3] [4]

Diagnose und Therapie anders bewerten als Verwaltung

Software, die medizinische Informationen verarbeitet, um Entscheidungen für Diagnose oder Therapie zu unterstützen, kann nach MDR oder IVDR als Medizinprodukt einzuordnen sein. Für die konkrete Klasse kommt es auf die gesetzlichen Klassifizierungsregeln, den vorgesehenen medizinischen Zweck und die möglichen Folgen fehlerhafter Ergebnisse an. Ein Etikett wie klinischer Assistent ersetzt diese Prüfung nicht. Ebenso wenig genügt die Verwendung eines generativen Modells, um ohne weitere Analyse einen Medizinproduktstatus oder eine Hochrisikoeinstufung zu behaupten.

Bei Diktat, Terminvergabe, Ressourcenplanung oder Abrechnung fehlt häufig ein unmittelbarer medizinischer Zweck. Trotzdem können erhebliche Risiken entstehen, etwa durch unzulässige Verarbeitung von Gesundheitsdaten, Offenlegung von Berufsgeheimnissen, fehlerhafte Übernahme von Texten in die Dokumentation oder diskriminierende Priorisierung. Solche Anwendungen benötigen daher einen eigenen Kontrollrahmen. Nicht hochriskant nach Artikel 6 bedeutet weder rechtsfrei noch automatisch unbedenklich; es bezeichnet nur das Ergebnis einer bestimmten Klassifikationsprüfung.

• Klinische und administrative Funktionen technisch trennen.
• Outputs vor Übernahme in die Patientenakte prüfen lassen.
• Datenflüsse zu Modellanbieter und Unterauftragnehmern erfassen.

Quellen: [1] [3] [4] [6]

Sicherheitskomponente nach dem Digital Omnibus

Der Digital Omnibus präzisiert die Sicherheitskomponente. Entscheidend ist eine Funktion, deren beabsichtigter Zweck darin besteht, Risiken für Gesundheit oder Sicherheit von Personen oder Eigentum zu verhindern oder zu mindern, und deren Ausfall oder Fehlfunktion diese Schutzgüter gefährden kann. Reine Nutzerassistenz, Leistungsoptimierung, Serviceeffizienz, Komfort, Automatisierung oder nicht sicherheitsbezogene Qualitätskontrolle reichen für sich genommen nicht. Die Bezeichnung durch Vertrieb oder Projektteam ist weniger aussagekräftig als die dokumentierte Funktion im Gesamtsystem.

Für die Praxis verlangt das eine nachvollziehbare Fehlerfolgenanalyse. Das Team sollte festhalten, was bei Ausfall, falschem Positiv, falschem Negativ, verzögertem Ergebnis oder Modellwechsel geschieht und welche unabhängigen Schutzebenen bestehen. Ein menschlicher Bestätigungsschritt kann relevant sein, beseitigt die Sicherheitsfunktion aber nicht automatisch. Umgekehrt wird ein Komfortfeature nicht allein dadurch sicherheitsbezogen, dass seine Fehlfunktion theoretisch mittelbare Nachteile verursachen könnte. Architektur, Zweck und vorhersehbare Nutzung müssen gemeinsam bewertet werden.

• Fehlermodi und klinische Folgen szenariobasiert analysieren.
• Unabhängige Schutzmechanismen und Human Override nachweisen.
• Änderungen von Zweck, Modell und Schnittstellen neu bewerten.

Quellen: [1] [2]

Rollen von Krankenanstalt, Hersteller und Integrator

Eine Krankenanstalt ist beim Einsatz eines fremden Systems regelmäßig Betreiberin. Das MedTech-Unternehmen kann Anbieter des KI-Systems und zugleich Produkthersteller sein. Die Rollen folgen jedoch aus den tatsächlichen Handlungen, nicht allein aus Vertragsbezeichnungen. Wer ein System unter eigenem Namen in Verkehr bringt, seinen Zweck verändert oder eine wesentliche Änderung vornimmt, kann Anbieterpflichten übernehmen. Auch lokale Modellanpassungen, Eigenentwicklungen und eine Weitergabe an andere Einrichtungen verdienen deshalb eine gesonderte Prüfung.

In-house-Konstellationen erfordern besondere Sorgfalt. Eine interne Entwicklung kann unter medizinprodukterechtlichen Bedingungen anders behandelt werden als ein kommerziell bereitgestelltes Produkt; daraus folgt aber keine pauschale Ausnahme von Datenschutz, Qualitätsanforderungen oder dem AI Act. Einkauf, ärztliche Direktion, IT, Datenschutz, Informationssicherheit und Qualitätsmanagement sollten vor dem Pilotbetrieb ein gemeinsames Rollenblatt freigeben. Dieses sollte Verantwortliche, vorgesehene Nutzung, Änderungsbefugnisse, Supportwege und Reaktionen auf sicherheitsrelevante Ereignisse enthalten.

• Rollen je Version und Bereitstellungsszenario bestimmen.
• Rebranding, Zweckänderung und wesentliche Änderung als Eskalation auslösen.
• Vertragliche Rollenbezeichnungen mit der tatsächlichen Leistung abgleichen.

Quellen: [1] [3] [4]

Pflichtensysteme integriert, aber nicht gleichsetzen

AI Act, MDR beziehungsweise IVDR und DSGVO verfolgen unterschiedliche Regelungsziele und verwenden eigene Begriffe. Dennoch lassen sich Prozesse verbinden: Qualitätsmanagement, Risikomanagement, technische Dokumentation, klinische Bewertung, Daten-Governance, menschliche Aufsicht, Cybersicherheit, Beobachtung nach dem Inverkehrbringen und Vigilanz sollten aufeinander verweisen. Ein gemeinsames Kontrollsystem vermeidet widersprüchliche Versionen und doppelte Nachweise. Es darf aber nicht unterstellen, dass die Erfüllung einer Produktpflicht automatisch jede Anforderung des anderen Rechtsakts abdeckt.

Für Gesundheitsdaten bleiben insbesondere Rechtsgrundlage, Zweckbindung, Datenminimierung, Sicherheit und Betroffenenrechte zu prüfen. Berufs- und organisationsrechtliche Vorgaben können zusätzliche Grenzen setzen. Bei Chatbots oder synthetischen Inhalten können außerdem die seit 2. August 2026 grundsätzlich anwendbaren Transparenzpflichten des Artikels 50 relevant sein. Maßnahmen zur Unterstützung der KI-Kompetenz nach Artikel 4 betreffen das einschlägig befasste Personal bereits; sie schreiben jedoch weder eine bestimmte Standardausbildung noch ein Zertifikat für jede Person vor.

• Nachweise verknüpfen, aber Rechtsgrundlagen getrennt ausweisen.
• Klinische Validierung und Datenschutzprüfung nicht durch Anbieterwerbung ersetzen.
• Kompetenzmaßnahmen nach Funktion und Einsatzrisiko staffeln.

Quellen: [1] [2] [3] [4] [6]

Frist bis 2028 als Vorbereitungsfenster nutzen

Rechtsstand 16. September 2026: Die spezifischen Anforderungen aus Kapitel III Abschnitte 1 bis 3 für Hochrisikosysteme nach Artikel 6 Absatz 1 in Verbindung mit Anhang I gelten nach dem Digital Omnibus ab 2. August 2028. Das ist von der Frist 2. Dezember 2027 für die gelisteten Anhang-III-Verwendungszwecke zu unterscheiden. Die Verschiebung lässt bereits geltendes Medizinprodukterecht, die DSGVO, Artikel 4, einschlägige Transparenzpflichten und sonstiges Gesundheitsrecht unberührt.

Unternehmen sollten die Zeit nicht als Stillstand behandeln. Sinnvoll sind ein vollständiges Systeminventar, eine dokumentierte Produkt- und Rollenprüfung, vertragliche Informationsrechte, ein Änderungsprozess sowie eine belastbare Zuordnung vorhandener Nachweise zu künftigen Hochrisikoanforderungen. Bis 2. August 2027 soll die Kommission durch delegierte Rechtsakte bestimmen, in welchem Umfang gleichwertige sektorale Anforderungen einzelne Anforderungen des AI Act begrenzen können. Dieser künftige Schritt und mögliche Leitlinien müssen vor Veröffentlichung oder Projektfreigabe erneut geprüft werden.

• 2027 und 2028 in Roadmaps getrennt ausweisen.
• Bestehende Produktpflichten während der Übergangszeit weiter erfüllen.
• Kommissionsrechtsakte und Leitlinien vor Markteinführung erneut prüfen.

Quellen: [1] [2] [5] [3] [4]

Häufige Fragen