KRITIS und Klinik-KI: Was als kritische Infrastruktur gilt und was nicht

Ein IT-Leiter eines Klinik-Verbunds mit 720 Betten an zwei Standorten in Süddeutschland liest im April 2026 die jüngste Sektorbroschüre Gesundheit des Bundesamts für Sicherheit in der Informationstechnik (BSI) und parallel die Konsultations-Materialien zum KRITIS-Dachgesetz. Sein Haus ist seit der ersten KRITIS-Stufe Betreiber kritischer Infrastruktur — die Erst-Klassifikation des Klinik-Verbunds ist abgeschlossen. Was 2026 ansteht, ist die Reklassifikation der eingeführten KI-Bausteine: die Doku-Assistenz aus 2024, das Bild-Analyse-Modul aus dem Frühjahr 2025, die für 2026 geplante Aufnahme-Triage-Komponente. Drei Komponenten, drei unterschiedliche Beitrags-Tiefen, drei unterschiedliche Architektur-Settings. Die Verbände-Stellungnahmen geben generische Hinweise; die operative Klassifikations-Frage — welche Komponente ist KRITIS-relevant, welche nicht — sitzt vor ihm wie ein leeres Raster, das er selbst füllen muss.

Die BSI-Kritisverordnung (BSI-Kritis-V) in Verbindung mit dem BSI-Gesetz regelt seit Jahren, ab welcher Schwelle ein Krankenhaus als Betreiber kritischer Infrastruktur gilt — historisch primär die jährliche stationäre Fallzahl. Oberhalb der Schwelle gelten drei Pflicht-Säulen: die Umsetzung des Stands der Technik nach §8a BSI-Gesetz mit Nachweisführung im zweijährigen Rhythmus, die Vorfall-Meldepflicht nach §8b über das Melde- und Informationsportal des BSI, und die strukturelle Vorbereitung auf Aufsichts- und Audit-Anlässe. Das KRITIS-Dachgesetz, dessen Materialien das Bundesministerium des Innern und für Heimat (BMI) im Beratungs-Hochlauf 2025–2026 begleitet, ergänzt diesen Rahmen um eine breitere Resilienz-Logik — physische und Cyber-Resilienz, Lieferketten, Identifizierung wichtiger Einrichtungen — und setzt zugleich Teile der EU-Richtlinie zur Netz- und Informationssicherheit (NIS-2) um. Krankenhäuser bleiben im Sektor Gesundheit erfasst. Die Frage in der Klinik-IT-Leitung ist nicht, ob der Verbund unter KRITIS fällt — diese Antwort liegt vor. Die Frage ist, welche Anwendungs-Komponenten als Bestandteil der kritischen Dienstleistung gewertet werden und wo die operative Last der Pflicht-Säulen ankommt.

Drei Klassifikations-Stellen für Klinik-KI

Die KRITIS-Klassifikation einer Klinik-KI-Komponente ist kein Etikett, das pauschal an die Komponente geheftet wird. Sie ist der Schnittpunkt aus drei Stellen, an denen die Komponente in die kritische Dienstleistung des Krankenhauses eingreift. Erstens — die Beitrags-Tiefe. Eine KI-Komponente, die in eine zeitkritische Versorgungs-Kette eingebunden ist (Aufnahme-Triage in Echtzeit, Bild-Analyse im Notfall-Pfad, Intensiv-Verlaufs-Vorhersage), greift in den kritischen Dienst „stationäre Versorgung“ anders ein als eine Komponente, die nachgelagerte Codier-Vorschläge oder Berichts-Entwürfe erzeugt. Die Beitrags-Tiefe entscheidet, ob die Komponente die kritische Dienstleistung tatsächlich trägt oder ob sie als ergänzende Werkstatt-Schicht außerhalb des kritischen Pfads läuft. Zweitens — die Daten- und Identitäts-Verschränkung mit dem Krankenhausinformationssystem (KIS). Eine Komponente, die im KIS-Authentifizierungs-Raum läuft, mit dem klinischen Identitäts- und Berechtigungs-Konzept des Krankenhauses verschmolzen ist und Patientendaten unmittelbar verarbeitet, ist anders eingeordnet als eine Komponente, die in einer separaten Verarbeitungs-Schicht mit anonymisierten oder pseudonymisierten Daten arbeitet und die Schnittstelle zum KIS auf wenige, klar abgegrenzte Aufrufe beschränkt. Die Verschränkungs-Tiefe entscheidet die Auditierbarkeit, die Vorfall-Schnittmenge und die Lieferketten-Sicht — drei Größen, die in der Sektorbroschüre Gesundheit, in den ENISA-Healthcare-Reports und in den Cybersicherheits-Empfehlungen der Klinik-Verbände gleichermaßen wiederkehrend benannt werden.

Drittens — die Verfügbarkeits-Kopplung an die Versorgungs-Leistung. Wenn die KI-Komponente ausfällt, was passiert mit der Versorgungs-Kette? Verzögert sich die Aufnahme? Verschiebt sich die Bildbefundung? Bricht eine Pflege-Doku-Spur ab, die für die nächste Schicht handlungs-relevant ist? Oder läuft die Versorgung ohne Verzögerung weiter, weil die KI-Komponente eine reine Komfort-Schicht oberhalb der klinischen Kern-Prozesse ist? Die Verfügbarkeits-Kopplung ist die Achse, auf die die European Union Agency for Cybersecurity (ENISA) in ihren Healthcare-Reports und das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) in seinen Resilienz-Materialien gemeinsam zeigen — als die Achse, an der sich kritische und nicht-kritische Anwendungen ohne Etikett-Diskussion unterscheiden lassen. Die drei Stellen — Beitrags-Tiefe, Daten-Identitäts-Verschränkung, Verfügbarkeits-Kopplung — sind nicht voneinander unabhängig. Eine hohe Beitrags-Tiefe ohne Verfügbarkeits-Kopplung ist selten. Eine tiefe Daten-Verschränkung ohne nennenswerten Beitrag zur kritischen Dienstleistung ist eine Architektur-Warnung. Was die drei Stellen zusammen tragen, ist eine Klassifikations-Geometrie, die das Etikett ersetzt.

Drei Pflicht-Konsequenzen, wenn die Komponente in den Rahmen fällt

Wenn eine Klinik-KI-Komponente nach den drei Klassifikations-Stellen in den KRITIS-Rahmen einbezogen wird, schließen sich drei operative Pflicht-Konsequenzen an. Erstens: die Komponente unterliegt dem Stand-der-Technik-Nachweis nach §8a BSI-Gesetz im Rahmen der zweijährigen KRITIS-Nachweisführung. In der Praxis heißt das, dass die Komponente in das hauseigene oder das durch den Anbieter mitgeführte Audit-Konzept einsortiert ist, dass Sicherheits-Tests, Konfigurations-Härtung und Modell-Inferenz-Pfad-Dokumentation vorliegen, dass die Korrespondenz-Pflichten zwischen Klinik und Anbieter benannt sind, und dass die Stand-der-Technik-Aussage über die Komponente prüffähig ist. Stellungnahmen der Deutschen Krankenhausgesellschaft (DKG) und Empfehlungen des Katholischen Krankenhausverbands Deutschlands (KKVD) benennen wiederkehrend, dass die operative Last dieses Nachweises in der Praxis bei der Klinik-IT-Leitung ankommt — auch wenn die Komponente vom Anbieter betrieben wird, weil die Korrespondenz-Pflichten der Architektur fast immer Klinik-Aufgaben sind. Zweitens: die Vorfall-Meldepflicht nach §8b BSI-Gesetz erstreckt sich auf erhebliche Sicherheits-Vorfälle, die die kritische Dienstleistung beeinträchtigen. Eine in den KRITIS-Rahmen einbezogene KI-Komponente bringt damit eine eigene Vorfall-Definitions- und Meldekette mit. Wer entscheidet, ab wann ein Modell-Drift, eine fehlerhafte Inferenz-Antwort, ein Modell-Update mit unerwarteter Wirkung oder ein Subprozessoren-Vorfall auf der Anbieter-Seite ein meldepflichtiger KRITIS-Vorfall ist? Diese Frage gehört in den Anbieter-Vertrag, in die Vorfall-Reaktions-Pläne der Klinik und in die Schulung der KI-betreuenden Rollen — nicht erst in das Vorfall-Gespräch nach Eintritt. Drittens: die Schnittstellen-Nachweise. Subprozessoren der Komponente, Lieferketten der Modell-Gewichte, Identitäts-Verwaltungs-Architektur und Audit-Logs sind Teil der KRITIS-Sicht auf die Komponente und müssen dokumentiert vorliegen. Eine Klinik, die das KRITIS-Pflicht-Bündel als Anbieter-Aufgabe versteht, missrechnet die Lastenverteilung — die operative Pflicht sitzt fast immer geteilt.

Vier strukturelle Wirkungen auf Betreibermodelle

Die KRITIS-Klassifikation entscheidet, ob die Komponente einbezogen ist. Das Betreibermodell entscheidet, wo die Pflichten-Last sitzt. Vier Modelle treten in der Klinik-Praxis auf, und sie unterscheiden sich strukturell. Modell eins, der hauseigene Betrieb der Komponente — On-Premise oder im Klinik-Rechenzentrum — verlangt höhere interne Reife: Personal mit ausreichender Sicherheits-Tiefe, Audit-Konzepte für die Komponente, redundante Infrastruktur, eigene Vorfall-Reaktion. Die Pflichten-Last sitzt komplett im Haus. Das ist tragbar, wenn die personellen und finanziellen Voraussetzungen vorhanden sind; in mittelgroßen Häusern wird der Aufwand häufig unterschätzt. Modell zwei, der hybride Betrieb mit Anbieter-Komponenten in einem teilweise externen Verbund, teilt die Pflichten-Last zwischen Krankenhaus und Anbieter. Audit-Rechte, Vorfall-Kommunikations-Pfade, Subprozessoren-Vereinbarungen und die Korrespondenz-Pflichten zwischen den Schichten müssen sauber abgegrenzt sein. In der Praxis ist die Schnittstellen-Definition die häufigste Stelle, an der die hybride Variante zu einer impliziten Vollverlagerung beider Lasten zurück ans Krankenhaus wird.

Modell drei, der Cloud-Betrieb mit BSI-attestierten Plattformen, reduziert die Plattform-Last für die Klinik — die Plattform-Sicherheits-Kontrollen werden über das BSI-C5-Testat mit definiertem Geltungsbereich attestiert. Die Anwendungs-Schicht und die Korrespondenz-Pflichten verbleiben beim Klinik-Betreiber: Identitäts-Verwaltung in der KI-Komponente, Konfigurations-Härtung, Modell-Inferenz-Pfad-Dokumentation, Subprozessoren der Anwendungs-Schicht. Die KRITIS-Pflicht-Last verschiebt sich, sie verschwindet nicht. Modell vier, der vollständig anbieter-betriebene Klinik-KI-Service, in dem das Krankenhaus die Komponente in der Anwendungs-Schicht und in Teilen der Plattform-Schicht zukauft, verändert die Subprozessoren-Lage und die Vorfall-Meldekette grundlegend. Die operative Sicherheits-Last beim Anbieter steigt; die KRITIS-Verantwortung der Klinik bleibt — sie wandert von der Eigen-Umsetzung zur Anbieter-Steuerung und Anbieter-Auswahl. In allen vier Modellen entscheidet die Architektur über die Lastenverteilung; das Etikett des Anbieters tut es nicht.

NIS-2 und das Dachgesetz erweitern den Rahmen, sie ersetzen ihn nicht

Das KRITIS-Dachgesetz und das NIS-2-Umsetzungsgesetz — die Wissenschaftlichen Dienste des Deutschen Bundestags haben den Beratungs-Hochlauf in mehreren Sachstand-Berichten ausgewertet — verschieben den Rahmen nicht in einen anderen Aggregat-Zustand, sondern erweitern ihn an drei Stellen. Erstens: die Resilienz-Logik wird breiter — physische und Cyber-Resilienz werden zusammen gedacht, was die Verfügbarkeits-Kopplungs-Achse aus der Klassifikations-Geometrie zusätzlich auflädt. Zweitens: die Lieferketten-Anforderungen werden konkreter — Subprozessoren-Sicht, Identitäts-Verwaltung in der Lieferkette, Software-Lieferanten-Risiko gehören explizit in die Bewertung. Für eine Klinik-KI-Komponente bedeutet das, dass die Subprozessoren-Tiefe — der Inferenz-Anbieter eines Sprachmodells, der Annotations-Dienst, der Identitäts-Provider — in einer früheren und sichtbareren Pflicht-Linie steht als unter der älteren Verordnungs-Mechanik. Drittens: die Identifizierung wichtiger Einrichtungen ergänzt das KRITIS-Konstrukt um eine zweite Klasse — Häuser, die nicht über die Schwellenwerte einzustufen sind, aber wegen ihrer Versorgungs-Funktion in den erweiterten Anwendungsbereich fallen. Für mittelgroße Häuser wird die Frage, ob sie unter das Dachgesetz fallen, Teil der laufenden Sicherheits-Architektur — und nicht erst Anlass nach Eintritt einer formalen Klassifikations-Mitteilung.

Die KRITIS-Klassifikation einer Klinik-KI-Komponente entsteht nicht am Etikett der Komponente und nicht an der Trägerschaft des Hauses, sondern an drei Stellen — Beitrags-Tiefe, Daten-Identitäts-Verschränkung, Verfügbarkeits-Kopplung — und das gewählte Betreibermodell entscheidet, wohin die Pflicht-Last fällt. Eine IT-Leitung, die die drei Stellen einzeln prüft und die vier Betreibermodelle gegen die Klassifikations-Geometrie liest, sortiert ihre Klinik-KI-Architektur strukturell. Die Pflichten-Last verschiebt sich dabei zwischen den Schichten; sie verschwindet in keinem Modell. Was die KRITIS-Architektur trägt, ist nicht die Etikettierung der Komponente, sondern die nachvollziehbare Sicht auf die Schnittlinie zwischen Klassifikations-Stellen und Betreibermodell.