32 · Modelleinsatz, Monitoring und Governance

Klinischer Aufhänger

Das Modell läuft, die AUC im Validierungsset war gut. Jetzt beginnt der schwierigste Teil: der Einsatz in der Realität. Patient:innenpopulationen ändern sich, Jahreszeiteneffekte, neue Behandlungsprotokolle, veränderte Dokumentationspraxis. Ein Modell, das niemand überwacht, verliert still seine Leistung, und niemand merkt es, bis Schaden entsteht. Dieses Modul zeigt, wie du ein Modell deployst, beobachtest und verantwortlich einbettest.

1 Modelle persistieren mit joblib

Ein trainiertes scikit-learn-Objekt wird mit joblib.dump als komprimierte Binärdatei gespeichert. Beim Laden muss die exakt gleiche scikit-learn-Version vorhanden sein, sonst drohen stille Deserialisierungsfehler.

Hinweis — die Codeblöcke unten sind Auszüge. Sie zeigen die entscheidenden Schritte, nicht jede Import-Zeile. Das vollständige, am Stück lauffähige Skript ist code/python.py (im Browser über den Python-Reiter oben). In Colab führst du das ganze Modul mit einer Zeile aus: !python module/32-einsatz-governance/code/python.py — siehe das in Colab öffnen.

import joblib

# Speichern
joblib.dump({"pipeline": pipe, "sklearn_version": sklearn.__version__}, "modell.joblib")

# Laden und Version prüfen
artefakt = joblib.load("modell.joblib")
assert artefakt["sklearn_version"] == sklearn.__version__, "Versionsmismatch!"
pipe_loaded = artefakt["pipeline"]

Für den Produktiveinsatz gilt: das Modell zusammen mit einer requirements.txt (inkl. Versions-Pin) einfrieren und in einem Modell-Registry (MLflow, DVC, Vertex AI) versionieren.

2 Model Card, der Steckbrief des Modells

Eine Model Card dokumentiert, was das Modell tut, für wen es gebaut wurde, wie es bewertet wurde und wo es versagt. Sie ist Pflicht für verantwortungsvolle KI und Grundlage für die regulatorische Dokumentation.

## Model Card — Klinisches Verschlechterungs-Prädiktionsmodell

**Modellname:** Klinische-Verschlechterung-v1  
**Version:** 1.0.0  
**Datum:** 2026-06  
**Verantwortlich:** [Klinik/Team, Kontakt]

### Aufgabe
Binäre Klassifikation: Vorhersage klinischer Verschlechterung innerhalb 24h
auf Basis der freitextlichen Pflege-/Arztnotizen (TF-IDF-Repräsentation der
dokumentierten Beobachtungen), nicht auf Basis strukturierter Vitalwerte oder
Laborwerte. Das Modell "liest" also Text, keine Zahlen-Tabelle.

### Trainingsdaten
Synthetischer Textdatensatz (n=500 Notizen), Aufnahmezeitraum simuliert.
Outcome: verschlechterung (0/1), ~35 % positiv (34,6 % im aktuellen Datenstand).
Kein Echtpatientendatensatz; klinischer Einsatz erfordert Validierung.

### Modellarchitektur
TF-IDF (Unigramme + Bigramme, min_df=2) + Logistische Regression (C=1.0,
class_weight=balanced). Pipeline, kein Pre-Leakage.

### Leistungsmetriken (Testset, 25 %)
- ROC-AUC: [Wert einsetzen]  
- Sensitivität @ Youden-Schwelle: [Wert]  
- Spezifität @ Youden-Schwelle: [Wert]

### Subgruppenleistung
AUC nach Geschlecht (jeweils mit 95%-Bootstrap-CI): weiblich [Wert, CI],
männlich [Wert, CI]. AUC nach Altersgruppe (Schwelle 65 Jahre): [Wert, CI].
Eine Lücke gilt erst als auffällig, wenn sich die Konfidenzintervalle
zwischen den Gruppen nicht mehr überlappen, nicht schon bei einem reinen
Punktschätzer-Unterschied.

### Einschränkungen und Risiken
- Bag-of-Words ignoriert Negation (z. B. „kein Fieber").
- Kalibrierung nicht validiert auf externen Kohorten.
- Sprache: Deutsch. Andere Dokumentationssprachen nicht unterstützt.
- Keine prospektive Validierung durchgeführt.

### Geplante Nutzung
Forschungszwecke / Pilotprojekt unter Aufsicht.  
NICHT für autonome klinische Entscheidungen ohne Human-in-the-Loop.

### Regulatorik
Klinische Entscheidungsunterstützung → MDR 2017/745: typischerweise Klasse IIa,
unter Regel 11 aber Klasse IIb/III, wenn die unterstützte Entscheidung Tod oder
irreversible Verschlechterung verursachen kann. Ein 30-Tage-Mortalitäts-CDSS ist
ein IIb/III-Kandidat. EU AI Act: Hochrisiko. (Keine Rechtsberatung; vgl. §5.)
Vor Produktiveinsatz: CE-Kennzeichnung, klinische Evaluierungsstudie, PMS-Plan.

3 Monitoring: Calibration Drift und Dataset Shift

Modelle altern. Zwei Hauptursachen:

Calibration Drift: Die ausgegebenen Wahrscheinlichkeiten stimmen nicht mehr mit der beobachteten Häufigkeit überein, weil sich die Ereignisrate in der Realität ändert.

Dataset Shift: Die Merkmalsverteilung verändert sich (Covariate Shift) oder der Zusammenhang zwischen Merkmalen und Outcome ändert sich (Concept Drift).

Wir simulieren Konzept-Drift durch gezieltes Label-Flipping: Ein wachsender Anteil der Testlabels wird invertiert. Das modelliert den Fall, in dem sich die Beziehung zwischen Textsignal und Outcome verändert, etwa weil geänderte Dokumentationspraktiken oder Therapieprotokolle die alten Signal-Tokens unzuverlässig machen.

import numpy as np

rng = np.random.default_rng(SEED)

def simulate_concept_drift(y_test, flip_rate, rng):
    """Flip flip_rate fraction of labels to simulate concept drift."""
    y_noisy = y_test.copy()
    n_flip = int(flip_rate * len(y_test))
    if n_flip > 0:
        flip_idx = rng.choice(len(y_test), size=n_flip, replace=False)
        y_noisy.iloc[flip_idx] = 1 - y_noisy.iloc[flip_idx]
    return y_noisy

for flip_rate in [0.00, 0.05, 0.10, 0.15, 0.20]:
    y_drifted = simulate_concept_drift(y_test, flip_rate, rng)
    auc = roc_auc_score(y_drifted, pipe.predict_proba(X_test)[:, 1])
    print(f"Drift {flip_rate:.0%}: AUC = {auc:.3f}")

4 Fairness: Subgruppenleistung

Ein gutes mittleres AUC kann starke Leistungsunterschiede zwischen Subgruppen verdecken. Im klinischen Kontext ist Gleichheit nach geschlecht, Altersgruppe oder Ethnizität (soweit dokumentiert) eine ethische und zunehmend regulatorische Anforderung. Bei kleinen Subgruppen ist die AUC-Schätzung aber hochvariabel — ein Bootstrap-Konfidenzintervall ist deshalb Pflicht, nicht optional, bevor eine Lücke als real gilt.

import numpy as np
from sklearn.metrics import roc_auc_score

def bootstrap_auc_ci(y, proba, n_boot=1000, seed=42):
    """95%-Bootstrap-CI für AUC durch Resampling mit Zurücklegen."""
    rng = np.random.default_rng(seed)
    y, proba = np.asarray(y), np.asarray(proba)
    boot_aucs = []
    for _ in range(n_boot):
        idx = rng.integers(0, len(y), len(y))
        if len(np.unique(y[idx])) < 2:
            continue
        boot_aucs.append(roc_auc_score(y[idx], proba[idx]))
    return np.percentile(boot_aucs, [2.5, 97.5])

for group in ["weiblich", "maennlich"]:
    mask = cohort_test["geschlecht_clean"] == group
    if mask.sum() < 10:
        continue
    y_g, p_g = y_test[mask], proba[mask]
    auc_g = roc_auc_score(y_g, p_g)
    lo, hi = bootstrap_auc_ci(y_g, p_g)
    print(f"  AUC {group}: {auc_g:.3f}  [95%-CI {lo:.3f}-{hi:.3f}]  (n={mask.sum()})")

Konkret gemessen auf dem Testsplit (n=125, Gesamt-AUC 0,849): Weiblich AUC 0,880, 95%-CI [0,787–0,952] (n=61); Männlich AUC 0,807, 95%-CI [0,689–0,909] (n=64). Der Punktschätzer-Unterschied (Δ≈0,07) sieht auf den ersten Blick nach einer Lücke aus, die Konfidenzintervalle überlappen jedoch stark. Diese Lücke ist bei n≈60 pro Gruppe statistisch nicht von Zufall zu unterscheiden — eine ehrliche Model Card würde hier "keine belastbare Evidenz für eine Geschlechter-Disparität" schreiben, nicht "Modell diskriminiert nach Geschlecht".

Praxis — Worked Example Altersgruppe: Dieselbe Analyse lässt sich auf jede andere klinisch relevante Subgruppe anwenden. Mit der Schwelle 65 Jahre (gängiger geriatrischer Cutoff) ergibt sich auf demselben Testsplit: <65 Jahre AUC 0,843, 95%-CI [0,733–0,940] (n=57); ≥65 Jahre AUC 0,842, 95%-CI [0,734–0,930] (n=68). Hier liegen die Punktschätzer praktisch identisch — noch deutlicher als bei Geschlecht kein Hinweis auf eine Alters-Disparität in diesem Modell.

5 Governance: MDR und EU AI Act

Klinische Prädiktionsmodelle sind in Europa reguliert. Zwei Rahmen sind relevant:

MDR 2017/745 (Medical Device Regulation): Ein Software-Produkt ist ein Medizinprodukt, wenn es zur Diagnose, Überwachung, Prognose oder Behandlung von Krankheiten eingesetzt wird. Klinische Entscheidungsunterstützung fällt typischerweise unter Klasse IIa (mittleres Risiko) oder Klasse IIb/III (hohes Risiko). Anforderungen: Qualitätsmanagementsystem (ISO 13485), klinische Bewertung, Post-Market Surveillance Plan, CE-Kennzeichnung, Unique Device Identifier.

EU AI Act (Regulation (EU) 2024/1689): Die Verordnung ist seit 1. August 2024 in Kraft und wird stufenweise anwendbar. Klinische KI kann insbesondere dann Hochrisiko-KI sein, wenn sie selbst ein Medizinprodukt ist, als Sicherheitskomponente eines Medizinprodukts dient oder in einem gelisteten Hochrisiko-Kontext eingesetzt wird. Die konkrete Einordnung hängt vom Verwendungszweck, vom Produktkontext und von aktueller EU-/MDCG-Leitlinie ab. Für Lernzwecke genügt hier: patient:innenrelevante Entscheidungsunterstützung niemals als „nur Software" behandeln. Typische Pflichten sind:

• Transparenz: Nutzer müssen wissen, dass sie mit einem KI-System interagieren.
• Menschliche Aufsicht: Entscheidungen müssen von qualifiziertem Personal überschaubar und übersteuerbar sein.
• Robustheit und Genauigkeit: Nachgewiesene Leistung über den gesamten Lebenszyklus.
• Konformitätsbewertung und technische Dokumentation vor Inbetriebnahme, wenn das System in den Hochrisiko-/Medizinproduktbereich fällt.

Praktische Konsequenzen für Datenwissenschafter:innen:

• Kein Deployment ohne vollständige Dokumentation (Model Card + technische Akte).
• Prospektive klinische Studie vor Produktiveinsatz.
• Monitoring-Plan mit definierten Schwellenwerten für Intervention.
• Changelog und Audit-Trail für alle Modellversionen.

6 Weitere Praxisfragen: Automation Bias, Haftung, Aufklärung

Regulatorik allein macht ein KI-System nicht sicher. Drei weitere Fragen betreffen unmittelbar den klinischen Alltag:

Automation Bias und Alert Fatigue: Klinisches Personal neigt dazu, Modellvorhersagen unkritisch zu übernehmen (Automation Bias), besonders unter Zeitdruck. Umgekehrt führt eine hohe Rate falsch-positiver Alarme dazu, dass Warnungen zunehmend ignoriert werden (Alert Fatigue), ein Modell mit vielen Fehlalarmen "verbrennt" das Vertrauen, das es eigentlich unterstützen soll. Beides untergräbt den Zweck der Entscheidungsunterstützung, in entgegengesetzte Richtungen.

Haftung: Wer haftet, wenn eine KI-gestützte Entscheidung einem Patienten schadet, die behandelnde Person, die Modellentwicklerin oder die Klinik als Betreiberin? Die Antwort ist je nach Rechtsraum unterschiedlich und rechtlich nicht abschließend geklärt; dieses Modul kann und will hier keine Rechtsberatung ersetzen. In der Praxis bleibt die behandelnde Person in aller Regel verantwortlich für die letztendliche Entscheidung (Human-in-the-Loop ist auch deshalb keine Formalität), während Hersteller- und Betreiberhaftung zusätzlich über Produkthaftungs- und Medizinprodukterecht greifen können. Vor Produktiveinsatz gehört diese Frage explizit zur Rechtsabteilung und Klinikleitung, nicht zur Data-Science-Entscheidung.

Informierte Einwilligung: Sollten Patient:innen erfahren, dass ein KI-System an ihrer Behandlungsentscheidung beteiligt war? Der EU AI Act fordert für Hochrisiko-KI grundsätzlich Transparenz gegenüber betroffenen Personen. Praktisch heißt das: Aufklärungsbögen und Behandlungsgespräche sollten benennen, dass ein unterstützendes Vorhersagemodell eingesetzt wird, in verständlicher Sprache, ohne technische Details vorauszusetzen. Wie genau (mündlich, schriftlich, im Rahmen der allgemeinen Aufnahmeaufklärung) ist institutionell und je nach Risikoklasse zu klären.

Wann du Hilfe holst. Sobald ein Modell reale Behandlungsentscheidungen beeinflusst, sind Rechtsabteilung, Datenschutz, Ethikkommission und gegebenenfalls Benannte Stelle keine Formalie, sondern Voraussetzung — spätestens bei nachgewiesenem Drift oder ungleicher Subgruppenleistung gehört die Weiternutzung gemeinsam mit diesen Stellen entschieden, nicht allein technisch.

Fallstricke und Merksätze

• Versionspinning ist Pflicht. Ein joblib-File ohne Versionsinfo ist eine Zeitbombe.
• Model Card = Ehrlichkeits-Dokument. Grenzen und Versagen klar benennen.
• AUC-Monitoring braucht Labels. Ohne Outcomes sieht man nur Covariate Shift.
• Subgruppen-AUC ist nicht optional. Mittlere Güte verdeckt systematische Ungleichheit, aber erst ein Konfidenzintervall sagt dir, ob eine gemessene Lücke real oder Rauschen ist.
• MDR + EU AI Act früh prüfen. Ob ein System ein Medizinprodukt oder Hochrisiko-KI ist, folgt aus Verwendungszweck und Einsatzkontext.
• Automation Bias, Haftung und Aufklärung mitdenken. Governance endet nicht bei der Regulatorik-Checkliste, sie betrifft, wie Menschen dem Modell im Alltag begegnen.

Selbstcheck