KI im Krankenhaus — wenn KRITIS und Schweigepflicht aufeinandertreffen.
Welche regulatorischen Schichten heute über klinischen KI-Projekten liegen — und welche Architektur durch alle hindurch trägt.
In einer mittelgroßen Allgemeinpraxis stellt sich die Frage nach der KI-Architektur als rechtliche Frage. In einem Krankenhaus stellt sie sich als Schichtproblem. KRITIS-Verordnung, NIS-2-Umsetzungsgesetz, EU AI Act, Medizinprodukteverordnung, § 9b BSIG, § 203 StGB, KHZG Fördertatbestand 11, Berufsrecht — sieben Regelwerke sehen jedes Ihrer KI-Pilotprojekte durch eine eigene Brille an. Ein Architekturvorschlag, der nur einer dieser Schichten genügt, scheitert spätestens im dritten Audit.
1. Welche Regelwerke heute gleichzeitig gelten
Ein Krankenhaus mit mehr als 30.000 vollstationären Fällen pro Jahr fällt unter die BSI-KRITIS-Verordnung im Sektor Gesundheit. Damit wird das Haus zum Betreiber einer kritischen Infrastruktur — mit den Pflichten aus § 8a BSI-Gesetz: Stand-der-Technik-Maßnahmen, Nachweis alle zwei Jahre, Meldepflichten nach § 8b Abs. 4. Das deutsche NIS-2-Umsetzungsgesetz verschärft 2024/2025 die Schwellen und Pflichten zusätzlich; Krankenhäuser darunter fallen in die Kategorie wesentliche Einrichtungen.
Auf diesen Rahmen legt sich der EU AI Act. Klinische KI-Funktionen, die diagnostische oder therapeutische Vorschläge erzeugen, sind in den meisten Fällen Hochrisiko-Systeme im Sinne von Anhang III; in Verbindung mit Rule 11 der Medizinprodukteverordnung (MDR) werden sie regelmäßig zu Klasse-IIa-oder-höher-Medizinprodukten mit voller CE-Zulassungspflicht. Daneben gilt weiterhin § 203 StGB für jeden, der die Daten in der Behandlungsbeziehung erhebt, und das Berufsrecht der Ärztekammer für die eingesetzte Ärzteschaft.
Für die wirtschaftliche Steuerung kommt der Krankenhaus- zukunftsfonds dazu: Fördertatbestand 11 (Cybersicherheit) verlangt belegbare Investitionen in die Informationssicherheit, gegengeprüft durch externe Begutachtungen, mit Rückforderungsrisiko bei unzureichender Mittelverwendung. Wer in dieser Förderlinie steckt, kann sich heterogene Schatten-IT durch KI-Pilotprojekte sachlich nicht leisten.
2. Warum § 9b BSIG für die KI-Beschaffung gilt
§ 9b des BSI-Gesetzes regelt den Einsatz kritischer Komponenten in KRITIS-Infrastrukturen. Der Begriff wurde populär durch die Huawei-/ZTE-Verfügung des Bundesinnenministeriums vom 11. Juli 2024, die den Austausch chinesischer Komponenten aus den 5G-Kernnetzen bis Ende 2026 anordnete. Die Norm selbst ist sektorübergreifend: Sie verlangt vom KRITIS-Betreiber eine Vertrauenswürdigkeitserklärung des Herstellers, gibt dem BMI ein Untersagungsrecht bei begründeten Risiken und definiert Garantie-Erklärungen, die in deutsche Recht und deutsche Rechtsschutzgarantien einklagbar sein müssen.
Ob eine LLM-Inferenz, die im klinischen Diktat-Workflow läuft, eine kritische Komponente im Sinne von § 9b BSIG ist, ist nicht abschließend entschieden — aber die Argumentation ist offensichtlich: Ein Werkzeug, das ärztliche Anamnesen und Diagnose-Vorschläge in seinem Kontext führt, steht in seiner Funktion einem 5G-Kontrollserver näher als einer Office-Anwendung. Die KRITIS-Vorlagenpraxis wird das in den nächsten zwei bis drei Jahren systematisch nachziehen. Wer heute architektonisch souverän entscheidet, antizipiert eine Pflicht, die ohnehin kommt.
3. AI Act + MDR — wann eine Diagnose-Assistenz zum Medizinprodukt wird
Die Trennlinie verläuft an einer Stelle, die im Vertriebsgespräch gerne übersprungen wird. Ein reiner Ambient-Scribe, der Gesprochenes verschriftet und in eine strukturierte Notiz wandelt, kann als nicht-medizinisches Werkzeug eingestuft werden — vergleichbar mit einem Diktiergerät. Sobald der gleiche Scribe aber eigenständige ICD-Vorschläge generiert, Differentialdiagnosen ableitet oder Therapieoptionen vorschlägt, greift Rule 11 der MDR und macht aus dem Werkzeug ein Medizinprodukt der Klasse IIa oder höher.
Für die Beschaffung heißt das: Ein Werkzeug, das im Vertriebsdeck als Effizienz-Tool beworben wird, aber im Datenmodell ICD-Codes ausgibt, ist regulatorisch ein unangemeldetes Medizinprodukt. Der Anbieter ist dann nicht mehr nur in einer Vertragsbeziehung mit dem Krankenhaus — er ist in einem Verfahren mit dem BfArM. Ohne CE-Kennzeichnung und ohne Konformitätsbewertung darf das Werkzeug nicht in den Verkehr gebracht werden; die Verwendung in einer KRITIS-Einrichtung wäre regulatorisch ungedeckt.
4. Drei Beschaffungs-Konstellationen aus deutschen Kliniken
Die folgenden Muster sehen wir in nahezu jeder Klinik-Audit- Vorbereitung wieder. Sie sind nicht als Bewertung gemeint, sondern als typische Strukturen, an denen die regulatorische Reibung entsteht.
Etabliertes KIS, neue KI-Hülle
Im Haus läuft seit Jahren ein etabliertes Krankenhausinformationssystem eines deutschen oder europäischen Anbieters. Der Hersteller hat kürzlich eine KI-Komponente angekündigt: Befundung, Arztbrief-Generierung, ambulant-stationäre Überleitung. Die Komponente wird oft nicht selbst entwickelt, sondern als zugekaufter Sub-Service eingebunden — die eigentliche Modell-Inferenz läuft bei einem Drittanbieter, häufig in einer US-Cloud-Region oder über eine US-API. Aus KRITIS-Sicht ist das ein neuer Subprozessor in einem ohnehin meldepflichtigen Verarbeitungsweg. Das KIS-Vertragsdokument deckt diesen Pfad oft noch nicht ab.
Pilot-Projekt mit US-Cloud-Anbieter
Ein US-Cloud-Konzern bietet der Klinik einen Ambient-Scribe oder eine generative Befundungshilfe als geförderten Pilot an. Der Vertrag enthält eine deutsche oder europäische Cloud-Region für die Datenablage. Die Modell-Inferenz selbst läuft jedoch im Konzern-eigenen GPU-Pool, der nicht zwingend in derselben Region steht. Ohne eine ausdrückliche Vereinbarung über den Inferenz-Ort und ohne durchgehende Subprozessor-Transparenz erfüllt die Konstellation weder die § 203-Schwelle (Verschwiegenheitsverpflichtung der US-Subprozessor-Beschäftigten) noch die KRITIS-Anforderung an die Datenpfad-Dokumentation.
Wildwuchs auf Klinik-Endgeräten
Neben der offiziellen IT-Landschaft laufen auf den Endgeräten der ärztlichen Mitarbeitenden Apps, die ungesteuert eingesetzt werden — von der Übersetzung fremdsprachiger Anamnesen über die Symptom-Sortierung in einem Chat-Tool bis zur Bild-Hochladung in einer Konsumenten-KI. Diese Schatten-IT erzeugt eine technisch unbeobachtete Datenpfad-Vielfalt, die in einem KRITIS-Audit nicht haltbar ist. Die Verantwortung liegt im Haus, nicht beim einzelnen Mitarbeiter — die organisatorische Steuerung der KI-Nutzung gehört in eine schriftlich fixierte Richtlinie samt Compliance-Monitoring.
5. Die regulatorische Stack-Sicht — was eine Klinik-KI heute beherrschen muss
Ein klinisches KI-System, das durch alle Schichten trägt, muss heute mindestens diese acht Anforderungen erfüllen. Die Liste ist als Beschaffungs-Checkliste gemeint, nicht als juristisches Gutachten.
- BSI C5-Testat oder gleichwertiges Auditfür den gesamten Verarbeitungsstapel inklusive aller Subprozessoren.
- Modell-Inferenz in einem nachweisbar deutschen oder europäischen Rechenzentrum, mit vertraglich belastbarem Ausschluss des Inferenz-Routings in Drittstaaten.
- Verschwiegenheitsverpflichtung nach § 203 Abs. 3 StGB für den Anbieter und das nachweislich darauf verpflichtete Personal, ausdrücklich im AVV referenziert.
- Vollständige Subprozessor-Liste über alle Verarbeitungsstufen (Audio-OCR, Sprache-zu-Text, Modell- Inferenz, Post-Processing, Logging, Quality-Assurance) mit jeweiligem Hosting-Standort.
- Kein Training auf Klinikdaten in den Standardklauseln; explizite Opt-Out-Sicherung; bei künftigen Modellverbesserungen schriftliche Zustimmungs- pflicht.
- CE-Kennzeichnung nach MDR, sobald das System eigenständige medizinische Entscheidungs- unterstützung leistet — inklusive Konformitätsbewertungs- verfahren der zuständigen Benannten Stelle.
- AI-Act-Konformität für Hochrisiko-Systemenach Anhang III: Risikomanagement, Daten-Governance, technische Dokumentation, menschliche Aufsicht, Robustheit, Cybersecurity, Post-Market-Monitoring.
- Klinik-interne KI-Kompetenz nach Art. 4 AI Act— dokumentierte Schulung der bedienenden Ärzteschaft und der IT, idealerweise als Curriculum mit jährlicher Auffrischung.
6. Architektur-Optionen für die Klinik-IT
Variante A — Souveräne EU-Cloud im KIS-Verbund
Mehrere deutsche Cloud-Anbieter haben in den vergangenen Jahren souveräne Inferenz-Stacks aufgebaut, die in BSI-C5-zertifizierten Rechenzentren laufen und die für klinische KI relevanten Datenschutz- und Sicherheits- eigenschaften vertraglich absichern. Die Anbindung an das bestehende KIS erfolgt über standardisierte FHIR- oder HL7-Schnittstellen, mit klar konfiguriertem Datenpfad und dokumentierter Subprozessor-Kette. Diese Option ist regulatorisch belastbar und benötigt keine eigene Hardware-Investition.
Variante B — On-Premise im Rechenzentrum
Eigene GPU-Hardware im klinischen Rechenzentrum, betrieben mit offenen Inferenz-Frameworks und Open-Weight-Modellen. Die Investitionssumme liegt für eine redundante Klinik-Architektur typischerweise im mittleren bis hohen sechsstelligen Bereich, abhängig von Modellgröße und Lastprofil; die laufenden Kosten sind nach drei Jahren in der Regel günstiger als eine vergleichbare Cloud-Lizenz. Der entscheidende Vorteil: Der Datenpfad endet an der Hauswand. Mehr dazu im Selbst-Hosten-Artikel.
Variante C — Hybride Architektur mit Edge-Pseudonymisierung
In bestimmten Fällen — etwa bei extern eingekauften Forschungs-Workloads — ist ein hybrides Modell sinnvoll: Eine Edge-Komponente im Klinik-Rechenzentrum entfernt identifizierende Merkmale (Name, Geburtsdatum, Versichertennummer, freie Textstellen mit Stilometrie-Filter) aus den Datensätzen, bevor diese eine externe Cloud-Grenze überschreiten. Die externe Komponente sieht nur den medizinischen Kern. § 203 StGB greift in dieser Konstellation häufig nicht, weil das fremde Geheimnis nicht offenbart wird — die Pseudonymisierung muss allerdings forensisch nachweisbar belastbar sein.
Variante D — Gemeinsame Sovereign-Cloud im Versorgerverbund
Mehrere Häuser bündeln ihre KI-Infrastruktur in einem gemeinsam betriebenen souveränen Cloud-Verbund — vergleichbar mit den Trägerverbünden im Bereich der TI. Vorteile: Skalenkosten, Wissensteilung, gemeinsamer Audit-Aufwand. Die rechtliche Konstruktion erfordert eine ausgearbeitete AVV-Mehrparteien-Architektur und einen sauber definierten gemeinsamen Verantwortungsbereich nach Art. 26 DSGVO.
Häufige Fragen
Wir sind unter 30.000 Fällen — gilt KRITIS überhaupt für uns?
Nicht in der klassischen KRITIS-Verordnung. Das NIS-2-Umsetzungs- gesetz erweitert allerdings den Kreis der betroffenen Einrichtungen erheblich; medizinische Einrichtungen jenseits der reinen Krankenhausgrenze (z. B. größere MVZ, klinische Forschungseinrichtungen) sollten den eigenen Status individuell prüfen lassen. Unabhängig davon: Die Datenschutz- und Schweigepflichts-Schichten gelten ohnehin, KRITIS verschärft den IT-Sicherheitsrahmen nur zusätzlich.
Reicht ein BSI C5-Testat für unsere KI-Beschaffung?
C5 ist die Mindestschwelle, nicht das Ziel. Es deckt die klassische Cloud-Sicherheits-Dimension ab. Was es nicht beantwortet: Modell-Inferenz-Ort im Detail, Trainings-Daten- Verwendung, AI-Act-Hochrisiko-Pflichten, MDR-Konformität. Diese Punkte brauchen zusätzliche Nachweise, die der Anbieter spezifisch liefern muss.
Müssen wir den AI Act schon heute beachten?
Die Pflichten für Anbieter und Betreiber von Hochrisiko-Systemen treten gestaffelt zwischen August 2025 und August 2026 in Kraft. Wer 2026 oder später noch in der Beschaffungsphase ist, sollte die Pflichten ab heute vollständig einplanen — eine Nachrüstung später wäre regelmäßig teurer als die richtige Auswahl jetzt. Insbesondere die Pflicht zur dokumentierten KI-Kompetenz (Art. 4) ist bereits jetzt scharf.
Was passiert, wenn ein Anbieter sein KI-Werkzeug ohne CE-Kennzeichnung verkauft?
Das Werkzeug darf in der EU nicht in den Verkehr gebracht werden, wenn es nach MDR ein Medizinprodukt ist. Die Verantwortung liegt zunächst beim Hersteller — aber wer es dennoch einsetzt, riskiert die regulatorische Verantwortlich- keit des Anwenders nach Art. 16 MDR und im Schadensfall die persönliche Haftung der Geschäftsführung. Ein Vertriebsversprechen ersetzt keine Konformitätsbewertung.
Wie passt KHZG-Fördertatbestand 11 in das Bild?
Fördertatbestand 11 verlangt belegbare Investitionen in Cybersicherheit — und diese Belegbarkeit setzt eine kohärente Architektur voraus. Eine unkoordinierte KI-Erweiterung des KIS, die Datenpfade in nicht dokumentierte Drittstaaten erzeugt, ist mit dem Fördertatbestand schwer vereinbar und kann bei der späteren Begutachtung zu Rückforderungen führen. Wer in der Förderlinie steht, sollte KI-Architektur als Teil des Cyber-Programms denken.
Wie hoch ist der Investitionsbedarf für eine On-Premise-KI im Klinikbetrieb?
Eine redundante Inferenz-Architektur für eine mittelgroße Klinik mit voller KIS-Anbindung über FHIR/HL7 liegt typischerweise im niedrigen bis mittleren sechsstelligen Bereich. Hinzu kommen jährliche Betriebs- und Wartungskosten im fünfstelligen Bereich. Der Vergleich zur Cloud-Lizenz wird ab dem zweiten Betriebsjahr in vielen Konstellationen zugunsten der On-Premise-Variante kippen — bei deutlich besserer regulatorischer Lage.
Was tun wir mit der bestehenden Schatten-KI im Haus?
Erst inventarisieren, dann steuern. Eine interne Erhebung — gerne anonym — zeigt in den meisten Häusern eine überraschende Vielfalt an eingesetzten KI-Diensten. Dann braucht es eine schriftliche KI-Richtlinie, die klar regelt, welche Werkzeuge erlaubt sind und welche nicht, plus eine technische Steuerung über Endgeräte-Management. Ohne diese Reihenfolge wird jede Richtlinie folgenlos.
Müssen wir den Personalrat oder die Mitarbeitendenvertretung beteiligen?
Bei nahezu jeder klinischen KI-Beschaffung — ja. Mitbestimmungs- rechte nach § 87 BetrVG bzw. den landesrechtlichen Personalvertretungs- gesetzen greifen bei technischen Einrichtungen, die geeignet sind, das Verhalten oder die Leistung der Beschäftigten zu überwachen. Ambient-Scribes und KI-gestützte KIS-Module fallen in der Regel darunter. Eine frühe Einbeziehung ist nicht nur rechtlich nötig, sondern verkürzt das Projekt erfahrungsgemäß deutlich.
Zum Schluss
Die regulatorische Schichtung der Klinik-KI ist nicht der Versuch, Innovation zu bremsen. Sie ist die Antwort auf die Tatsache, dass die Patientendaten in einer Klinik zu den schutzbedürftigsten Datenkategorien gehören, die im deutschen Rechtssystem überhaupt existieren — und dass die KI-Industrie 2024 und 2025 sehr schnell sehr viel Architektur in den Markt geschoben hat, die diesem Schutzniveau nicht gerecht wird. Wer als Klinikleitung heute die Souveränitäts-Frage stellt, kauft sich keine Lizenz auf langsame Innovation — er kauft sich die Lizenz auf tragfähige Innovation.
Die gute Nachricht ist: Die Werkzeuge dafür existieren. Es gibt deutsche und europäische souveräne Cloud-Anbieter mit C5-Testat, es gibt mature Open-Weight-Modelle mit ausreichender Leistung für klinische Anwendungen, und es gibt erste Häuser, die On-Premise-Stacks erfolgreich betreiben. Was es nicht gibt, ist eine Abkürzung über die regulatorischen Schichten. Wer sie nimmt, zahlt im Audit oder im Gericht.
Vierzig Minuten — wir gehen mit Ihnen Ihre Privatabrechnungs- Schnittstelle durch und stellen sie audit-fest.