Die Governance-Landschaft für KI in Biotech und Medtech
# 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, bei denen eine Verschlechterung wahrscheinlich ist. 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 potenziell 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 unterliegt nicht der „KI-Regulierung“. Es unterliegt einem Stapel von Regimen, die größtenteils für andere Zwecke geschrieben wurden und nun gleichzeitig greifen.
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, braucht wahrscheinlich eine FDA-Clearance oder -Zulassung. Die FDA hat bereits Hunderte KI-gestützte Geräte autorisiert; sie veröffentlicht die laufende Liste der KI/ML-gestützten Medizinprodukte öffentlich. Das zentrale Anliegen der FDA bei KI ist die Frage locked vs. adaptive: Ein Modell, das sich im Feld selbst nachtrainiert, verändert sein Verhalten. Daher hat die FDA den Predetermined Change Control Plan (PCCP) eingeführt, eine vorab autorisierte Beschreibung, wie ein Modell ohne neue Einreichung aktualisiert werden darf.
2. HIPAA (US-Gesundheitsdatenschutz)
Der Health Insurance Portability and Accountability Act (HIPAA) regelt Protected Health Information (PHI): identifizierbare Patientendaten. Ihr Modell verarbeitet alle 15 Minuten PHI. 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-Identifikation oder Einwilligung).
3. EU AI Act (Hochrisiko-Einstufung)
Wenn dieses Krankenhaus in der EU tätig ist oder EU-Patienten versorgt, gilt der EU AI Act (Verordnung 2024/1689, gestaffelte Einführung bis 2026 und 2027). KI, die als Medizinprodukt oder als Sicherheitsbauteil eines solchen eingesetzt wird, ist als hochriskant eingestuft. Zu den Hochrisiko-Pflichten gehören:
- Ein Risikomanagementsystem über den gesamten Modell-Lebenszyklus.
- Data GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.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 leistet, 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 Eigner, 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 Fehlermodus 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 Sache |
|---|---|
| Ist Nachtrainieren auf PHI erlaubt? | Data Science denkt Legal; Legal denkt IT |
| Wer zeichnet den FDA-PCCP? | Regulatory Affairs vs. klinische Leitung |
| Wer überwacht Model Drift nach dem Launch? | Jeder nimmt an, jemand anderes |
| Wo sind die Validierungsnachweise abgelegt? | Quality vs. Anbieter |
Das Governance-Betriebsmodell aufbauen
Die Lösung ist eine explizite Ownership-Map im RACI-Stil (Responsible, Accountable, Consulted, Informed), gekoppelt an jedes Regime. Eine praktikable Struktur:
AI Governance Committee (accountable). Cross-funktional: Regulatory Affairs, Quality, Legal/Privacy, Klinik, Data Science, IT Security. Es verantwortet die Go/No-go-Entscheidung.
Benannte Eigner pro Pflicht:
- Regulatory Affairs verantwortet FDA-Klassifizierung, Einreichung und den PCCP.
- Privacy Officer verantwortet HIPAA, das BAA und die De-Identifikationsregeln.
- Quality verantwortet GxP-Validierung und 21 CFR Part 11-Audit-Trails.
- AI Act Lead (oft Regulatory oder eine dedizierte Compliance-Rolle) verantwortet Hochrisiko-Dokumentation, Bias-Testing und die Gestaltung der menschlichen Aufsicht.
- Klinische Leitung verantwortet die Definition des intended use und den Human-in-the-loop-Workflow.
- MLOps/Data Science verantwortet 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 ist oder „unknown“ enthält, erfolgt kein Deployment.
Die KI-spezifischen Risiken, die die Checkliste erfassen muss
Regulierung ist 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 Laboranbieter oder eine geänderte Kodierpraxis verschlechtern die Genauigkeit unbemerkt. Das ist das klassische Versagen von im Einsatz befindlicher 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 dunklerer Haut schlechter abschneiden, wenn die Inputs zur Sauerstoffsättigung systematisch verzerrt sind, ein dokumentiertes Problem der Pulsoxymetrie. Der AI Act verlangt diese Prüfung ausdrücklich.
Automation Bias. Klinikerinnen und Kliniker vertrauen dem Score zu stark und hören auf mitzudenken. Menschliche Aufsicht funktioniert nur, wenn der Workflow das Übersteuern leicht und erwartbar macht.
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 dazu, wie im Einsatz befindliche 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 der „KI-Regulierung“ unterliegt?
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, ein Governance-Betriebsmodell vor dem Go-live aufzubauen.
Wählen Sie alle richtigen Antworten aus.
Guardrails 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 Eigner zugeordnet.
1. Intended-use-Statement fixiert und auf die FDA-Klassifizierung abgestimmt. (Regulatory)
2. Validierungsdossier vollständig: Performance auf einem Held-out-Set, das *dieses* Krankenhaus widerspiegelt, plus Subgruppen-Aufschlüsselung. (Quality + Data Science)
3. Bias-Report über Alter, Geschlecht, Ethnie und klinisch relevante Subgruppen. (Data Science, gemäß AI Act)
4. PHI-Handling abgezeichnet: BAA vorhanden, Retraining-Regeln explizit, Audit Trail aktiv. (Privacy + Quality)
5. Menschliche Aufsicht gestaltet und getestet: Kann eine Klinikerin die Begründung sehen und ohne Reibung übersteuern? (Klinik)
6. Monitoring-Plan aktiv: Drift-Metrik, Schwellenwert, Alert-Routing und ein Rollback-Plan *vor* dem Launch. (MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Vollständige Definition ansehen →)
7. Change Control: wie Updates genehmigt werden, bei adaptiven Modellen an den PCCP gekoppelt. (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, das übersteigt den Schwellenwert von 0,05.
MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßnahme: Review auslösen, den benannten MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Vollständige Definition ansehen →-Eigner informieren und eine Pause gemäß Rollback-Plan erwägen. Keine Debatte darüber, *ob* gehandelt wird, weil Schwellenwert und Eigner vor dem Launch definiert wurden. Das ist Governance, die ihre Aufgabe erfüllt.
(Diese Zahlen sind illustrativ und stammen nicht aus einem konkreten Produkt.)
Die Entwicklungsrichtung für 2026
Erwarten Sie Konvergenzdruck, keine Vereinfachung. Die FDA baut ihr Framework für KI/ML-Geräte und die Nutzung des PCCP weiter aus. Die Hochrisiko-Pflichten des EU AI Act greifen stufenweise über 2026-2027. Regulierer erwarten immer stärker Lifecycle-Governance, nicht eine einmalige Zulassung. Den Wettbewerbsvorsprung haben Organisationen, die Governance als operative Fähigkeit behandeln, nicht als juristische Formalie.
Wichtigste Erkenntnisse
- 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 eigentliche Risiko sind verwaiste Pflichten. Beheben Sie das mit einem benannten Eigner pro Pflicht und einem einzigen Model-Registry-Eintrag, der alles an eine Modellversion bindet.
- Regulierung ist die Untergrenze; Drift, Bias, Automation Bias und Alert Fatigue schaden den Patienten. Ihre Go-live-Checkliste muss jedes davon prüfen.
- Definieren Sie Drift-Schwellenwerte, Rollback-Pläne und Eigner vor dem Launch, damit die Reaktion automatisch erfolgt und keine Debatte ist. Ein AUROC-Rückgang von 0,06 über einer 0,05-Regel löst Handeln aus, ohne Meeting.
- 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 rechtliche, medizinische oder regulatorische Beratung.*