EU AI Act für KI-Systeme im Gesundheitswesen: Was Teams vorbereiten müssen

Der EU AI Act ist die erste horizontale Regulierung, die künstliche Intelligenz als regulierte Produktkategorie behandelt, und das Gesundheitswesen steht dabei klar im Fokus. Wenn Ihr Team klinische Entscheidungsunterstützung, Modelle für die diagnostische Bildgebung, Triage-Systeme oder patientennahe Anwendungen baut, integriert oder betreibt, sind die Pflichten alles andere als theoretisch. Sie übersetzen sich direkt in Engineering-Arbeit, Dokumentation und Prozessänderungen, die Quartale und nicht Wochen brauchen.

Dies ist ein technischer Readiness-Leitfaden und keine Rechtsberatung. Ziel ist es, Engineering-, Daten- und Produktteams verständlich zu machen, was die Verordnung in der Praxis verlangt, damit Sie den Aufwand früh abschätzen können. Für die formale Einstufung Ihrer konkreten Systeme und eine belastbare Compliance-Position sollten Sie weiterhin Regulatory- und Rechtsexperten einbeziehen. Im Folgenden geht es darum, wie Sie Ihre KI-Systeme im Gesundheitswesen in einen verteidigungsfähigen technischen Zustand bringen, bevor die Fristen greifen.

Welche KI-Systeme im Gesundheitswesen als Hochrisiko gelten können

Die Verordnung arbeitet mit einem risikobasierten Modell: verboten, Hochrisiko, begrenztes Risiko und minimales Risiko. Die meiste klinische KI landet in der Hochrisikostufe, und dorthin führen im Wesentlichen zwei Wege. Wenn Sie die Einstufung von Grund auf durcharbeiten, deckt unser Schritt-für-Schritt-Leitfaden zum Risikoframework den allgemeinen Fall ab, einschließlich der Ausnahme in Anhang III. Teams außerhalb der EU sollten beachten, dass die Verordnung auch Unternehmen außerhalb der EU erfasst, deren Systemergebnisse in der EU genutzt werden.

Der erste Weg führt über Anhang I, der Produkte umfasst, die bereits harmonisierten EU-Rechtsvorschriften unterliegen. KI, die Sicherheitsbauteil eines Medizinprodukts nach der EU-Medizinprodukteverordnung (MDR) oder der IVD-Verordnung (IVDR) ist oder selbst ein solches Produkt darstellt, gilt in der Regel als Hochrisiko, sobald eine Konformitätsbewertung durch Dritte erforderlich ist. In der Praxis trifft das auf die große Mehrheit der auf machine learning aufgebauten Software als Medizinprodukt zu, von der Radiologie-Triage über Pathologie-Klassifikatoren bis zur klinischen Entscheidungsunterstützung.

Der zweite Weg ist Anhang III, der eigenständige Hochrisiko-Anwendungsfälle auflistet. Relevante Beispiele für Health-Teams sind KI zur Notfall-Triage und zur Disposition von Rettungsdiensten sowie Systeme, die über den Anspruch auf Gesundheitsleistungen entscheiden. Eine Engine zur Patientenpriorisierung in einer Notaufnahme kann etwa als Hochrisiko gelten, auch wenn sie kein reguliertes Medizinprodukt ist.

Drei Punkte bringen Teams regelmäßig ins Stolpern. Erstens kann ein administratives oder ein Planungswerkzeug ohne Einfluss auf klinische Ergebnisse in eine niedrigere Stufe fallen, pauschale Annahmen kosten also unnötig Aufwand. Zweitens bringen KI-Modelle mit allgemeinem Verwendungszweck, auf denen Sie aufbauen, eigene Anbieterpflichten und eigene Dokumentation mit, die Sie übernehmen und prüfen müssen. Drittens zählt Ihre Rolle: Ein Anbieter, der ein System entwickelt und in Verkehr bringt, trägt deutlich schwerere Pflichten als ein Betreiber, der es einsetzt, wobei auch Betreiber echte Pflichten rund um Aufsicht, Protokollierung und bestimmungsgemäße Verwendung haben. Ordnen Sie jedes System einer Stufe und einer Rolle zu, bevor Sie den Aufwand schätzen.

Welche Pflichten technisch ins Gewicht fallen

Für Hochrisikosysteme definiert die Verordnung Anforderungen, die sich wie eine Produktqualitätsspezifikation lesen. Die mit dem direktesten Engineering-Einfluss sind: ein operatives Risikomanagementsystem, Daten- und Data-Governance-Kontrollen, technische Dokumentation, automatische Ereignisprotokollierung, Transparenz und klare Gebrauchsanweisungen, Maßnahmen zur menschlichen Aufsicht sowie ein nachgewiesenes Maß an Genauigkeit, Robustheit und Cybersicherheit, das der Zweckbestimmung angemessen ist.

Entscheidend ist, dass dies keine einmaligen Prüfpunkte sind. Sie müssen über den gesamten Lebenszyklus tragen, was bedeutet: Ihre Trainings-Pipeline, Ihr Evaluations-Harness, Ihre Deployment-Infrastruktur und Ihr Monitoring werden Teil der regulierten Fläche. Teams, die Compliance als ein am Ende erstelltes Dokument behandeln, stellen fest, dass dieses Dokument ein System beschreibt, das sie weder reproduzieren noch verteidigen können. Der praktische Schritt besteht darin, diese Anforderungen in die bereits vorhandenen Systeme zu verdrahten: Experiment-Tracking, model registry, CI und Observability-Stack. Ein fokussierter AI Readiness Audit ist meist der schnellste Weg, um zu sehen, wie weit Ihr aktuelles Tooling schon trägt und wo die echten Lücken liegen.

Risikomanagement und Dokumentation

Das Risikomanagementsystem ist als fortlaufender und iterativer Prozess gedacht: vorhersehbare Risiken für Gesundheit, Sicherheit und Grundrechte identifizieren, sie abschätzen und bewerten, Minderungsmaßnahmen ergreifen und nach Tests sowie im Live-Betrieb erneut bewerten. Für klinische KI sind die relevanten Risiken sehr konkret. Leistungsunterschiede zwischen Patienten-subgroups, stille Verschlechterung bei geänderter Bildgebungshardware oder geänderten Protokollen, Automation Bias bei Klinikern, die der Ausgabe zu sehr vertrauen, und Fehlerfälle bei seltenen, aber schwerwiegenden Erkrankungen gehören alle ins Register.

Die technische Dokumentation ist das Artefakt, das alles zusammenhält. Rechnen Sie mit einem lebenden Nachweis über Zweckbestimmung und klinischen Kontext, Systemarchitektur und Designentscheidungen, die datasets und ihre Herkunft, Trainings- und Validierungsmethodik, Evaluationsmetriken und Ergebnisse inklusive subgroup-Aufschlüsselungen, bekannte Grenzen und das Design der menschlichen Aufsicht. Es zahlt sich aus, Dokumentation als aus Quellen der Wahrheit erzeugt zu behandeln statt als handgeschriebenen Text. Von der Trainings-Pipeline ausgegebene model cards, gemeinsam mit den Daten versionierte dataset datasheets und Evaluationsberichte aus einem reproduzierbaren Harness halten die Dokumentation ehrlich und aktuell. Wenn eine Benannte Stelle oder ein Prüfer fragt, wie eine bestimmte Modellversion in einer bestimmten Kohorte abgeschnitten hat, wollen Sie aus Ihrer registry antworten und nicht aus dem Gedächtnis. Wie lange welches Artefakt aufzubewahren ist und wie sich das mit den Löschpflichten der DSGVO verträgt, behandelt Dokumentenaufbewahrung für KI-Systeme.

Data Governance

Data Governance ist der Bereich, in dem Healthcare-KI-Teams die meisten bestehenden Kontrollen haben und oft auch die meisten verborgenen Lücken. Die Verordnung verlangt, dass Trainings-, Validierungs- und Testdatensätze relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig im Hinblick auf die Zweckbestimmung sind. Sie fordert außerdem eine Untersuchung auf mögliche Verzerrungen, die der Gesundheit schaden oder zu Diskriminierung führen könnten, sowie geeignete Gegenmaßnahmen.

Technisch heißt das, für jedes dataset zu wissen, woher es stammt, wie es gelabelt wurde, welche Standorte, Geräte und Zeiträume es abbildet und wie es aufgeteilt wurde. Patientendemografie, Scanner-Hersteller, Aufnahmeprotokolle und Versorgungssettings prägen die Repräsentativität, und Lücken in einem dieser Punkte werden später zu Leistungslücken. Bias-Bewertung sollte fester Bestandteil Ihrer Validierung sein, mit Metriken über klinisch sinnvolle subgroups statt nur aggregierter Berichte. Nichts davon hebt Ihre Pflichten aus der DSGVO auf: Datenminimierung, Rechtsgrundlage und die Regeln für Gesundheitsdaten besonderer Kategorien laufen parallel und müssen mit der Dokumentation und Repräsentativität in Einklang gebracht werden, die der EU AI Act erwartet. Dieses Spannungsfeld arbeitet DSGVO versus EU AI Act auf. Versionierte datasets mit unveränderlicher Herkunft, erfasst in derselben registry wie Ihre Modelle, machen daraus statt einer forensischen Übung eine Abfrage.

Menschliche Aufsicht

Hochrisikosysteme müssen so gestaltet sein, dass Menschen sie wirksam beaufsichtigen können. Für klinische KI ist das Prinzip vertraut: Das System unterstützt eine Ärztin oder einen Arzt, es ersetzt die klinische Beurteilung nicht. Die Verordnung verlangt, dass Aufsicht eingebaut ist, dass Bedienende Fähigkeiten und Grenzen des Systems verstehen, für Automation Bias wachsam bleiben, die Ausgabe korrekt interpretieren und bei Bedarf eingreifen oder sie übersteuern können.

Technisch prägt das die Oberfläche und den workflow, nicht nur das Modell. Ausgaben brauchen kalibrierte Konfidenz und eine klare Kommunikation von Unsicherheit statt eines nackten Labels. Die klinische Fachkraft braucht genug Kontext und, wo sinnvoll, Erklärung, um ein Ergebnis gegen den Patienten vor ihr zu plausibilisieren. Es muss einen sauberen Weg geben, der Empfehlung zu widersprechen, sie zu übersteuern oder zu eskalieren, und dieser Weg sollte selbst protokolliert werden. Den human-in-the-loop-Punkt bewusst zu gestalten und zu dokumentieren, warum er dort sitzt, wo er sitzt, gehört ebenso zum Ergebnis wie die Modellgenauigkeit.

Monitoring nach dem Deployment

Mit dem Release enden die Pflichten nicht. Anbieter von Hochrisikosystemen müssen ein System zur Beobachtung nach dem Inverkehrbringen betreiben, das Leistungsdaten über die gesamte Lebensdauer aktiv erhebt und auswertet, und es bestehen Meldepflichten für schwerwiegende Vorfälle und Fehlfunktionen gegenüber Behörden innerhalb definierter Fristen. Hochrisikosysteme müssen Ereignisse zudem automatisch protokollieren, damit der Betrieb nachvollziehbar bleibt.

Speziell für KI reicht Monitoring über Verfügbarkeit weit hinaus. Sie wollen data drift erkennen, wenn eingehende Fälle von der Trainingsverteilung abweichen, und Performance-drift, wenn Ergebnisse schlechter werden, was im Gesundheitswesen oft erst sichtbar wird, wenn Wochen später die Ground Truth eintrifft. Die Leistung je subgroup sollte über die Zeit verfolgt werden und nicht nur zum Start, denn ein Modell kann aggregiert gesund wirken, während es eine Kohorte still im Stich lässt. Praktisch bedeutet das Dashboards zu Eingangsverteilungen und Vorhersagemustern, an klinisches Risiko gekoppelte Alarmschwellen, eine Feedback-Schleife, die Übersteuerungen durch Kliniker und bestätigte Ergebnisse erfasst, sowie ein Logging-Design, mit dem sich genau rekonstruieren lässt, welche Modellversion welche Ausgabe für welchen Fall erzeugt hat. Koppeln Sie das an einen klaren Prozess für Retraining und Revalidierung, damit die Verbesserung eines Modells Ihre dokumentierte Compliance-Position nicht still bricht.

Eine praktische Readiness-Checkliste

Für die Abfolge auf Programmebene über alle fünf Pflichtbereiche hinweg siehe die fünf Schritte zur Hochrisiko-Compliance. Für die klinische Evidenz selbst geht die Validierungscheckliste für medizinische KI bei analytischer und klinischer Validierung tiefer als dieser Leitfaden.

Wenn Sie jetzt starten, hält die folgende Reihenfolge die Arbeit beherrschbar:

• Inventarisieren Sie jedes KI-System und erfassen Sie je System die Zweckbestimmung, ob es ein Medizinprodukt ist oder in einem steckt, und Ihre Rolle als Anbieter oder Betreiber.
• Stufen Sie das Risiko ein, jedes System gegen Anhang I und Anhang III, und markieren Sie Unklares für die Expertenprüfung, statt zu raten.
• Bauen Sie eine Modell- und dataset-registry auf, mit unveränderlicher Versionierung und Herkunft, damit Dokumentation erzeugt statt handgeschrieben wird.
• Verankern Sie subgroup-bewusste Evaluation in Ihrem Validierungs-Harness, über die demografischen und technischen Schichten, die klinisch zählen.
• Dokumentieren Sie das Design der menschlichen Aufsicht je System, inklusive Übersteuerungs- und Eskalationspfaden und der Frage, wie Ausgaben Unsicherheit kommunizieren.
• Instrumentieren Sie das Monitoring nach dem Inverkehrbringen für data drift, Performance-drift und subgroup-Leistung, mit einem Logging, das jede Entscheidung rekonstruiert.
• Bringen Sie DSGVO- und AI-Act-Anforderungen an Gesundheitsdaten mit Ihren Governance- und Rechtsteams in Einklang, damit sich die beiden frameworks nicht widersprechen.
• Definieren Sie die Änderungskontroll-Schleife, die Dokumentation, Validierung und Vorfallmeldung synchron hält, wann immer ein Modell neu trainiert oder ersetzt wird.

Nichts davon muss auf einmal passieren, aber die Grundlagen, also Inventar, Klassifizierung und registry, sind das Nadelöhr für alles Weitere und belohnen einen frühen Start. Teams, die bereits gutes MLOps betreiben, finden viel von der Maschinerie halb fertig vor; die Arbeit besteht vor allem darin, sie prüffähig zu machen und an die konkreten Pflichten der Verordnung zu binden. Wenn Sie einen strukturierten Weg dorthin suchen: Unsere Beratung zu EU AI Act Compliance und unsere Audit-Arbeit sind genau für diesen Kontext regulierter KI in Gesundheitswesen und Fertigung gemacht.

Häufige Fragen

Ersetzt der EU AI Act MDR und IVDR für medizinische KI?

Nein, er läuft parallel. Software, die ein Medizinprodukt ist, braucht weiterhin ihre MDR- oder IVDR-Konformitätsbewertung, und der AI Act ergänzt Anforderungen an Data Governance, Dokumentation, Aufsicht und Monitoring. Planen Sie eine integrierte technische Dokumentation statt zweier paralleler Programme.

Ist klinische Entscheidungsunterstützung automatisch Hochrisiko?

Nicht automatisch, aber meistens. Der Weg führt in der Regel über Anhang I, weil Entscheidungsunterstützung, die als Medizinprodukt mit Konformitätsbewertung durch Dritte gilt, in der Hochrisikostufe landet. Rein administrative oder planende Werkzeuge oft nicht.

Haben Kliniken, die ein gekauftes System einsetzen, ebenfalls Pflichten?

Ja, wenn auch leichtere. Ein Betreiber muss das System bestimmungsgemäß verwenden, kompetente menschliche Aufsicht zuweisen, die erzeugten Logs aufbewahren und Betroffene informieren. Zudem hängen Sie von Dokumentation des Anbieters ab, also fordern Sie sie vor Vertragsschluss an, nicht während einer Prüfung.

Was hat sich 2026 durch den Omnibus für Gesundheits-KI geändert?

Die Fristen sind verschoben: eigenständige Hochrisikosysteme auf den 2. Dezember 2027 und in regulierte Produkte eingebettete KI, was die meiste Software als Medizinprodukt umfasst, auf den 2. August 2028. Die Pflichten selbst sind weitgehend unverändert, die Vorbereitung bleibt also gleich.