Die Governance-Landschaft für KI in Biotech und Medtech
Ein Universitätsklinikum mit 600 Betten nimmt ein Modell zur Sepsis-Vorhersage in Betrieb. Es durchsucht elektronische Patientenakten alle 15 Minuten und markiert Patienten, deren Zustand sich wahrscheinlich verschlechtert. Klinisch sieht das nach einem Erfolg aus. Juristisch hat es gerade vier sich überlappende Regulierungsregime gleichzeitig ausgelöst. Wird eines davon übersehen, ist der Einsatz nicht nur riskant, sondern möglicherweise illegal.
Diese Lektion kartiert diese Landschaft und zeigt Ihnen, wie Sie ein Governance-Betriebsmodell aufbauen, das klare Verantwortlichkeiten vor dem Go-live zuweist.
Die vier Regime, die auf ein Modell treffen
Unser Sepsis-Modell wird nicht durch „KI-Regulierung“ geregelt. Es wird geregelt durch einen Stapel von Regimen, die größtenteils für andere Zwecke geschrieben wurden und nun gleichzeitig gelten.
1. FDA (US-Medizinprodukterecht)
Wenn Software dazu bestimmt ist, Krankheiten zu diagnostizieren, zu behandeln oder vorherzusagen, kann die US Food and Drug Administration (FDA) sie als Software as a Medical Device (SaMD) regulieren: Software, die eine medizinische Funktion erfüllt, ohne Teil eines Hardware-Geräts zu sein.
Ein Tool zur Sepsis-Vorhersage, das klinische Entscheidungen steuert, benötigt wahrscheinlich eine FDA-Clearance oder -Zulassung. Die FDA hat bereits hunderte KI-gestützte Geräte autorisiert; sie veröffentlicht die laufende Liste der AI/ML-enabled medical devices öffentlich. Das zentrale Anliegen der FDA bei KI ist die Frage locked vs. adaptive: Ein Modell, das sich im Feld selbst neu trainiert, ändert sein Verhalten. Deshalb hat die FDA den Predetermined Change Control Plan (PCCP) eingeführt, eine vorab autorisierte Beschreibung, wie ein Modell aktualisiert werden darf, ohne eine neue Einreichung.
2. HIPAA (US-Datenschutz für Gesundheitsdaten)
Der Health Insurance Portability and Accountability Act (HIPAA) regelt Protected Health Information (PHI): identifizierbare Patientendaten. Ihr Modell nimmt alle 15 Minuten PHI auf. Das bedeutet:
- Ein Business Associate Agreement (BAA) mit jedem Anbieter, der die Daten berührt.
- Datennutzung nach dem Minimum-necessary-Prinzip und Audit-Logging.
- Regeln dazu, ob PHI zum Nachtrainieren des Modells verwendet werden darf (oft nicht, ohne De-Identifizierung oder Einwilligung).
3. EU AI Act (Einstufung als Hochrisiko)
Wenn dieses Krankenhaus in der EU tätig ist oder EU-Patienten versorgt, gilt der EU AI Act (Verordnung 2024/1689, mit stufenweisem Inkrafttreten bis 2026 und 2027). KI, die als Medizinprodukt oder als Sicherheitskomponente eines solchen eingesetzt wird, gilt als hochriskant. Zu den Hochrisiko-Pflichten gehören:
- Ein Risikomanagementsystem über den gesamten Modell-Lebenszyklus.
- Data GovernanceData GovernanceData Governance umfasst die Regeln, Rollen und Prozesse, die sicherstellen, dass Daten in einer Organisation korrekt, sicher, klar definiert und verantwortungsvoll genutzt werden.Vollständige Definition ansehen → und Bias-Prüfungen der Trainingsdaten.
- Menschliche Aufsicht („human-in-the-loop“).
- Technische Dokumentation und Post-Market-Monitoring.
- Registrierung in einer EU-Datenbank.
Beachten Sie die Schichtung: Dasselbe Tool ist ein Medizinprodukt nach EU-Recht (MDR) *und* hochriskant nach dem AI Act. Sie erfüllen beides, nicht eines.
4. GxP (Good-Practice-Qualitätsstandards)
GxP ist die Kurzform für „good practice“-Qualitätsvorschriften (GLP, GCP, GMP), die in Pharma und Diagnostik verwendet werden. Relevant ist hier oft GAMP 5 (Good Automated Manufacturing Practice), das Framework zur Validierung computergestützter Systeme. Sein Kernprinzip: Validierung. Sie müssen dokumentieren, dass das System reproduzierbar das tut, was Sie behaupten, mit 21 CFR Part 11-Kontrollen für elektronische Aufzeichnungen und Signaturen (Audit Trails, Zugriffskontrolle, Datenintegrität).
Warum das schwierig ist: Die Regime sprechen nicht miteinander
Jedes Regime hat einen anderen Owner, ein anderes Vokabular und einen anderen Auslöser. Die FDA interessiert sich für den *intended use*. HIPAA interessiert sich für *Daten*. Der AI Act interessiert sich für *Risikostufe und Aufsicht*. GxP interessiert sich für *validierte, auditierbare Systeme*.
Der Failure Mode ist nicht eine große Lücke. Es sind kleine verwaiste Pflichten, für die sich kein Team verantwortlich fühlt.
| Frage | Wer oft annimmt, es sei nicht seine Aufgabe |
|---|---|
| Ist Nachtrainieren auf PHI erlaubt? | Data Science denkt Legal; Legal denkt IT |
| Wer unterzeichnet den FDA-PCCP? | Regulatory Affairs vs. klinische Leitung |
| Wer überwacht Model Drift nach dem Launch? | Jeder nimmt an, dass es jemand anderes tut |
| Wo werden die Validierungsnachweise gespeichert? | Quality vs. Anbieter |
Das Governance-Betriebsmodell aufbauen
Die Lösung ist eine explizite Ownership-Map im RACI-Stil (Responsible, Accountable, Consulted, Informed), die an jedes Regime gebunden ist. Eine funktionierende Struktur:
AI Governance Committee (accountable). Cross-funktional: Regulatory Affairs, Quality, Legal/Privacy, Clinical, Data Science, IT Security. Es besitzt die Go/No-go-Entscheidung.
Benannte Owner pro Pflicht:
- Regulatory Affairs besitzt FDA-Klassifizierung, Einreichung und den PCCP.
- Privacy Officer besitzt HIPAA, das BAA und die De-Identifizierungsregeln.
- Quality besitzt GxP-Validierung und 21 CFR Part 11 Audit Trails.
- AI Act Lead (oft Regulatory oder eine dedizierte Compliance-Rolle) besitzt Hochrisiko-Dokumentation, Bias-Tests und das Design der menschlichen Aufsicht.
- Klinische Leitung besitzt die Definition des intended use und den Human-in-the-loop-Workflow.
- MLOps/Data Science besitzt Drift-Monitoring und Model Cards.
Das nützlichste einzelne Artefakt ist ein Eintrag im Model Registry, der all dies an eine Modellversion bindet.
model: sepsis_predictor
version: 2.3.0
intended_use: "Early sepsis risk flag, adult inpatient, decision-support only"
fda_status: 510k_cleared # oder: exempt / pending
fda_pccp: true # adaptive Updates vorab autorisiert
data: PHI (HIPAA); BAA_signed: true; retrain_on_PHI: false
eu_ai_act_class: high_risk
human_oversight: clinician_confirms_before_action
gxp_validation: GAMP5_complete; part11_audit_trail: enabled
owners:
regulatory: name
privacy: name
quality: name
monitoring:
drift_metric: AUROC
alert_threshold: 0.05_drop
review_cadence: monthlyWenn ein Feld leer oder „unknown“ ist, deployen Sie nicht.
Die KI-spezifischen Risiken, die die Checkliste erfassen muss
Regulierungen sind die Untergrenze. Die Modellrisiken sind das, was Patienten tatsächlich schadet.
Dataset Shift / Drift. Das Modell wurde auf der Population eines Krankenhauses trainiert. Ein neuer Patientenmix, ein gewechselter Labordienstleister oder eine geänderte Kodierpraxis verschlechtert die Genauigkeit unbemerkt. Das ist das klassische Versagen von in Betrieb genommener klinischer KI: Die Performance sieht beim Launch gut aus und zerfällt dann still.
Bias über Subgruppen. Aggregierte Genauigkeit verdeckt Lücken in Subgruppen. Ein Sepsis-Modell kann etwa bei Patienten mit dunkleren Hauttönen schlechter abschneiden, wenn die Inputs zur Sauerstoffsättigung systematisch verzerrt sind, ein dokumentiertes Problem der Pulsoximetrie. Der AI Act verlangt diese Prüfung ausdrücklich.
Automation Bias. Kliniker vertrauen dem Score zu stark und hören auf mitzudenken. Menschliche Aufsicht funktioniert nur, wenn der Workflow das Übersteuern einfach macht und erwartet.
Alert Fatigue. Zu viele False Positives, und das Personal ignoriert alle Alerts, auch die richtigen. Das ist ein realer, gemessener Schaden, keine UX-Spitzfindigkeit.
🎬 [VIDEO: "Real-world evidence for AI in healthcare" - youtube.com - Überblick darüber, wie eingesetzte klinische KI-Modelle driften und warum Post-Market-Monitoring wichtig ist]
Wissenscheck
1. Warum argumentiert die Lektion, dass ein Modell zur Sepsis-Vorhersage nicht einfach durch „KI-Regulierung“ geregelt wird?
2. Welches zentrale regulatorische Anliegen soll der Predetermined Change Control Plan (PCCP) der FDA adressieren?
3. Ein Krankenhaus setzt ein Tool ein, das nur Abrechnungscodes zusammenfasst und nie Diagnose oder Behandlung beeinflusst. Warum könnte dies nach dem SaMD-Konzept außerhalb der FDA-Medizinprodukteregulierung liegen, das Sepsis-Modell aber nicht?
4. Wählen Sie ALLE richtigen Antworten dazu, warum das Sepsis-Modell HIPAA-Pflichten auslöst.
Wählen Sie alle richtigen Antworten aus.
5. Wählen Sie ALLE richtigen Antworten zum Zweck des Aufbaus eines Governance-Betriebsmodells vor dem Go-live.
Wählen Sie alle richtigen Antworten aus.
GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen → vor dem Deployment: die Go-live-Checkliste
Bevor das Modell einen echten Patienten berührt, führen Sie diese Prüfungen durch. Jede ist einem Regime und einem Owner zugeordnet.
- Intended-use-Statement fixiert und auf die FDA-Klassifizierung abgestimmt. (Regulatory)
- Validierungsdossier vollständig: Performance auf einem Hold-out-Set, das *dieses* Krankenhaus abbildet, plus Subgruppen-Aufschlüsselungen. (Quality + Data Science)
- Bias-Report über Alter, Geschlecht, Ethnie und klinisch relevante Subgruppen. (Data Science, gemäß AI Act)
- PHI-Handling abgezeichnet: BAA vorhanden, Regeln zum Nachtrainieren explizit, Audit Trail aktiv. (Privacy + Quality)
- Menschliche Aufsicht designt und getestet: Kann ein Kliniker die Begründung sehen und ohne Friktion übersteuern? (Clinical)
- Monitoring-Plan aktiv: Drift-Metrik, Schwellenwert, Alert-Routing und ein Rollback-Plan *vor* dem Launch. (MLOpsMLOpsMachine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.Vollständige Definition ansehen →)
- Change Control: wie Updates genehmigt werden, gebunden an den PCCP, falls adaptiv. (Regulatory + Quality)
Ein durchgerechnetes Beispiel: Ist ein Drift-Alert gerechtfertigt?
Angenommen, die Validierungs-AUROC (Area Under the ROC Curve, ein Genauigkeitsmaß von 0 bis 1) lag bei 0,82. Ihre Governance-Regel: untersuchen, wenn sie um mehr als 0,05 fällt.
Nach drei Monaten meldet das Monitoring AUROC 0,76.
Rückgang = 0,82, 0,76 = 0,06, was den Schwellenwert von 0,05 überschreitet.
MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßnahme: Review auslösen, den benannten MLOps-Owner informieren und gemäß Rollback-Plan eine Pause erwägen. Keine Debatte darüber, *ob* gehandelt wird, weil Schwellenwert und Owner vor dem Launch definiert waren. Das ist Governance, die ihren Job macht.
(Diese Zahlen sind illustrativ, nicht von einem bestimmten Produkt.)
Die Entwicklungsrichtung für 2026
Erwarten Sie Konvergenzdruck, keine Vereinfachung. Die FDA erweitert ihr AI/ML-Device-Framework und die Nutzung des PCCP weiter. Die Hochrisiko-Pflichten des EU AI Act treten stufenweise bis 2026-2027 in Kraft. Regulierer erwarten zunehmend Lifecycle-Governance, nicht eine einmalige Zulassung. Der Wettbewerbsvorteil geht an Organisationen, die Governance als operative Fähigkeit behandeln, nicht als juristische Formalität.
Key Takeaways
- Ein klinisches KI-Modell löst vier Regime gleichzeitig aus (FDA, HIPAA, EU AI Act Hochrisiko, GxP). Compliance heißt, alle zu erfüllen, nicht eines auszuwählen.
- Das echte Risiko sind verwaiste Pflichten. Lösen Sie es mit einem benannten Owner pro Pflicht und einem einzigen Model-Registry-Eintrag, der alles an eine Modellversion bindet.
- Regulierungen sind die Untergrenze; Drift, Bias, Automation Bias und Alert Fatigue sind das, was Patienten schadet. Ihre Go-live-Checkliste muss jedes davon prüfen.
- Definieren Sie Drift-Schwellenwerte, Rollback-Pläne und Owner vor dem Launch, damit die Reaktion automatisch erfolgt und keine Debatte ist. Ein AUROC-Rückgang von 0,06 über eine 0,05-Regel hinaus löst Handeln aus, kein Meeting nötig.
- Governance ist 2026 eine Lifecycle-Fähigkeit, keine einmalige Zulassung. Bauen Sie das Betriebsmodell einmal und nutzen Sie es für jedes Modell wieder, das Sie deployen.
*Diese Lektion dient der Weiterbildung und ist keine juristische, medizinische oder regulatorische Beratung.*