Shadow AI in der Klinik: Wenn Mitarbeitende selbst KI nutzen

Eine IT-Leitung eines kommunalen Krankenhauses mit 320 Betten in Westfalen sieht in den Web-Proxy-Logs einer Routine-Auswertung Anfang 2026 wiederkehrende Aufrufe aus den Stations-Subnetzen — chat.openai.com, gemini.google.com, ein halbes Dutzend kleinerer KI-Endpunkte. Die Aufrufe verteilen sich über drei Schichten und summieren sich auf knapp viertausend Sitzungen pro Quartal. Eine offiziell freigegebene KI-Anwendung gibt es im Haus nicht; die Bedarfs-Anfrage zur Doku-Unterstützung steht seit zwei Jahren in der Investitions-Liste. Die Frage ist nicht, ob die Mitarbeitenden sich falsch verhalten. Die Frage ist, welche Architektur-Lücke diese Aufrufe markieren — und in welcher Reihenfolge sie geschlossen wird, ohne die operative Last für das Personal zu erhöhen.

Das Phänomen trägt seit etwa 2023 einen eigenen Namen: Shadow AI — die KI-bezogene Variante einer älteren Erscheinung, die in der Informationssicherheits-Forschung als Shadow IT seit etwa 2014 beschrieben ist. Der Microsoft Work Trend Index 2024 findet branchenübergreifend bei 75 Prozent der befragten 31.000 Wissensarbeiter:innen eine Nutzung generativer KI am Arbeitsplatz; davon bringen 78 Prozent ihre eigenen Werkzeuge mit (BYOAI — Bring Your Own AI), häufig ohne Genehmigung der eigenen Organisation. Bitkom-Erhebungen unter deutschen Unternehmen zeigen über mehrere Befragungs-Wellen einen wachsenden Anteil von Beschäftigten in vergleichbarer Größenordnung. Die Auftrags-Studien sind beide selbst-deklariert und enthalten keine separate Healthcare-Auswertung; in den Branchen-Aggregaten taucht der Sektor als BYOAI-aktiv auf, ohne eigene Mengen-Daten. Konvergent über drei Quellen-Klassen — Anbieter-Studie, Branchen-Verband, Beratungs-Forschung — bleibt das Ausmaß: die KI-Variante übertrifft mengenmäßig die klassische Shadow-IT-Größenordnung der Vor-2022-Jahre.

Drei Risiko-Klassen, die nicht in dieselbe Schublade gehören

Erstens: der Datenabfluss-Vektor. Eine ärztliche Fachkraft kopiert einen Aufnahmebefund in einen Konsumenten-KI-Browser-Tab, um eine Vorlage für einen Arzt-Brief erzeugen zu lassen. Eine pflegerische Fachkraft fotografiert eine handschriftliche Akten-Notiz und schickt sie an eine Foto-zu-Text-Anwendung auf dem Privathandy. Die BSI-Lageberichte ordnen diese Klasse als wachsendes Risiko in deutschen Organisationen ein und benennen drei wiederkehrende Wirkungs-Kanten: Inhalte verlassen den klinischen Datenraum in Verarbeitungs-Kontexte, mit denen kein Vertrag besteht; die eigenen Sicherheits-Logs verlieren an Aussage-Kraft, weil ein wesentlicher Teil der Inhalts-Bewegung nicht protokolliert wird; und die Angriffs-Oberfläche verlagert sich in private Konsumenten-Konten, deren Zwei-Faktor-Disziplin und Wiederherstellungs-Wege ausserhalb des Klinik-Verantwortungs-Bereichs liegen. Das ist die Klasse, die in Vorfall-Berichten am häufigsten erscheint.

Zweitens: der Compliance-Vektor. Die Datenschutz-Grundverordnung stuft Gesundheitsdaten in Art. 9 als besondere Kategorie ein; Art. 6 verlangt eine Rechtsgrundlage, Art. 32 geeignete technische und organisatorische Maßnahmen, Art. 33 die Meldung einer Datenschutz-Verletzung an die Aufsicht innerhalb von 72 Stunden, sofern ein Risiko für betroffene Personen besteht. Die Verordnung (EU) 2024/1689 — der AI Act — nennt KI-Systeme im Bereich der medizinischen Versorgung als Hochrisiko-Klasse, sofern sie als Sicherheitskomponente eines Produkts dienen oder selbst Medizinprodukt sind; für nicht-Hochrisiko-Anwendungen gelten die Transparenz-Pflichten nach Art. 50. Die Bundesärztekammer benennt seit 2023 die ärztliche Schweigepflicht nach § 203 StGB und das Berufsgeheimnis nach § 9 MBO-Ä als zusätzliche Schicht — dieselbe Verordnung, dieselbe Bestimmung, ein anderer Bezugs-Raum. Eine Konsumenten-KI-Sitzung mit Patienten-Bezug erfüllt regelmäßig keine dieser Verarbeitungs-Voraussetzungen — kein Auftrags-Verarbeitungs-Vertrag, keine Datenschutz-Folgenabschätzung, kein Verfahrens-Verzeichnis. Was diese Schichten im Einzelfall verlangen, beurteilen die Klinik-Datenschutz-Beauftragten und die rechtliche Beratung; die operative Beobachtung ist, dass die Voraussetzungen typischerweise nicht hergestellt sind.

Drittens: der Qualitäts-Vektor. Eine in einer Konsumenten-KI-Sitzung erzeugte Aussage trägt keine Provenienz-Nachverfolgung. Sie tritt in den klinischen Inhalts-Strom ein — als Vorlage für einen Brief, als Übersetzung einer fremdsprachigen Anamnese, als Stichpunkt-Liste für eine Visite — und ist später nicht mehr von einer korrekt rückverfolgbaren Aussage zu unterscheiden. Halluzinationen, Modell-Unkenntnis der konkreten Klinik-Standards und versionsabhängige Modell-Verhaltens-Drift bleiben in diesem Strom unsichtbar, weil die Eingangs-Spur fehlt. Die ENISA-Threat-Landscape-Reports für den Gesundheitssektor ordnen diese Klasse in die Kategorie der Daten-bezogenen Bedrohungen ein und benennen die Asymmetrie: ein Datenabfluss ist nach einem Vorfall in den Logs sichtbar; eine fehlerhaft maskierte Modell-Aussage ist es regelmäßig nicht. Die drei Risiko-Klassen verlangen unterschiedliche Antworten — Datenabfluss adressiert Trennungs- und Vertrags-Eigenschaften, Compliance adressiert Verfahrens-Eigenschaften, Qualität adressiert Provenienz-Eigenschaften. Wer sie in eine einzige Sicherheits-Maßnahme zusammenzieht, verfehlt zwei der drei Hebel.

Architektur-Eigenschaften, die die drei Klassen abräumen

Vier Architektur-Eigenschaften kehren in den konvergenten Empfehlungs-Linien — BSI-Lagebericht, ENISA-Threat-Landscape, Microsoft Work Trend Index, Gartner-Adoption-Forschung — als Eindämmungs-Schicht wieder. Erstens: eine offiziell bereitgestellte Klinik-KI-Anwendung mit Auftrags-Verarbeitungs-Vertrag, dokumentierter Datenschutz-Folgenabschätzung und Verfahrens-Verzeichnis — die Compliance-Voraussetzungen, die eine Konsumenten-KI-Sitzung nicht erfüllt, werden in der offiziellen Bereitstellung erfüllt. Zweitens: Provenienz pro Aussage. Jede Modell-Antwort, die in die klinische Inhalts-Spur eintritt, trägt die Eingabe, die Modell-Version und den Zeitstempel — die Eigenschaft, die den Qualitäts-Vektor adressiert. Haag und Eckhardt (2017) sowie Mallmann et al. (2018) ordnen die Treiber im Healthcare-Kontext: knappe Zeit-Budgets, fehlende Anpassung offizieller Werkzeuge an die Stations-Wege, langsame Bereitstellungs-Zyklen. Die Sicht der Mitarbeitenden ist überwiegend pragmatisch, nicht oppositionell. Die qualitativen Stichproben sind klein; die Treiber-Beschreibung wiederholt sich aber über mehr als ein Jahrzehnt mit hoher Konvergenz.

Drittens: Audit-Fähigkeit. Eine offiziell bereitgestellte Klinik-KI führt vollständige Aufruf-Logs mit Eingabe-Kontext, Modell-Version und Antwort. Die Logs sind Forensik nach einem Vorfall und Eingabe für laufende Anomalie-Erkennung — eine ungewöhnliche Eingabe-Klasse fällt dort auf, lange bevor sie Wirkung zeigt. Die Audit-Eigenschaft ist nicht an einen Standort gebunden; sie ist an Vertrag und Architektur gebunden. Eine cloud-native, eine hybride und eine on-premise Bereitstellung können sie alle herstellen, sofern der Anbieter vertraglich verpflichtet ist und die Logs technisch in der Klinik-Hand bleiben. Die Trennung zur Shadow AI verläuft an der Audit-Linie, nicht an der Geographie. Viertens: kuratierte Eingabe-Schichten — Daten-Klassen-Trennung am Eingang, sodass das Modell strukturell nicht mit Inhalten konfrontiert wird, die nicht für seine Verarbeitung vorgesehen sind. Diese vier Eigenschaften adressieren die drei Risiko-Klassen ohne Verbots-Schleife.

Was nicht in dieselbe Tabelle gehört

Eine Stelle, die in der Klinik-IT-Diskussion regelmäßig in eins gesetzt wird, gehört explizit getrennt: AI Act und Datenschutz-Grundverordnung sind unterschiedliche Verordnungen mit unterschiedlichen Bezugs-Räumen. Der AI Act regelt KI-Systeme in Klassen mit risiko-bezogenen Pflichten; die Datenschutz-Grundverordnung regelt Verarbeitungen personenbezogener Daten unabhängig vom Werkzeug. Eine Shadow-AI-Sitzung kann beide gleichzeitig berühren — der Bezug ist unterschiedlich. Dieselbe Trennung gilt zwischen Bundesamt für Sicherheit in der Informationstechnik (BSI) und Europäischer Agentur für Cybersicherheit (ENISA): das BSI ist eine deutsche Bundesoberbehörde mit nationaler Zuständigkeit; die ENISA ist eine europäische Agentur mit koordinierender Rolle. Die Empfehlungs-Linien beider sind konvergent in der Substanz, ihre Rechtsgrundlagen sind es nicht. Wer beide in eine Empfehlung zusammenzieht, gewinnt rhetorische Knappheit und verliert die Möglichkeit, eine Anbieter-Antwort an der jeweils zuständigen Bezugs-Stelle zu prüfen.

Eine IT-Leitung, die das Phänomen aus den eigenen Logs ablesen kann, kennt die Stelle, an der die Diskussion regelmäßig gegen eine Zeit-Schwelle läuft. Die Mitarbeitenden warten nicht auf das nächste Quartals-Investitionskomitee; sie haben die Aufgabe heute. Eine Sperre ohne offizielle Lösung verlegt das Problem in die Geräte, in denen die IT-Leitung es nicht mehr sieht. Eine offizielle Lösung mit den vier genannten Architektur-Eigenschaften verlegt es in einen Raum, in dem es prüfbar ist. Die Wahl steht nicht zwischen Nutzung und Nicht-Nutzung. Sie steht zwischen einer Nutzung, die in den eigenen Logs erscheint, und einer, die es nicht tut.