Was der Aufsichtsrat über Klinik-KI fragen sollte: Drei Fragen, die strukturell wirken
Klinik-Aufsichtsräte bekommen zunehmend Investitions-Vorlagen für Klinik-KI auf den Tisch — kaufmännisch sauber, technisch oft ohne strukturelles Vorwissen lesbar.

Dr. Sven Jungmann
CEO

An einem Donnerstagnachmittag liegt vor dem Aufsichtsrat einer mittelgroßen deutschen Klinik die Investitions-Vorlage für eine Klinik-KI. Investitions-Volumen, Drei-Jahres-Renditeerwartung, Risiko-Notiz, Anbieter-Auswahl, Vergabe-Verfahren — die Vorlage ist kaufmännisch sauber. Die Frage, die in der Sitzung am Tisch steht, ist nicht die kaufmännische. Eine Aufsichtsrats-Vorsitzende mit Industrie-Hintergrund liest die Vorlage seit zehn Minuten und fragt, was sich an der Software in zwölf Monaten klinisch verändert haben wird, an welchem Begleitungs-Aufwand das hängt und was im Haus bleibt, wenn die Anbieter-Partnerschaft im dritten Jahr endet. Die Vorlage trägt die Antworten auf diese Fragen formal nicht. Die strukturell wirksame Aufsichts-Lese der Klinik-KI-Investition steht nicht in der Investitions-Volumens-Diskussion — sie steht in drei anderen Fragen, deren Antwort-Pattern die Tragfähigkeit der Vorlage sichtbar machen, bevor das Volumen freigegeben ist.
Die Aufsichts-Funktion bei Klinik-IT-Investitionen ist in der deutschen und der internationalen Governance-Literatur konvergent dokumentiert. Empfehlungen des Katholischen Krankenhausverbands Deutschlands (KKVD), des Bundesverbands Deutscher Privatkliniken (BDPK) und der Deutschen Krankenhausgesellschaft (DKG) benennen die Aufsichts-Funktion als strukturelle Frage-Funktion, nicht als kaufmännische Detail-Beratung — und empfehlen für IT- und Digital-Investitionen eine Vorlagen-Form, in der Implementations-Begleitung und Exit-Bedingungen separat ausgewiesen sind. Das Trustee Center der American Hospital Association (AHA) und die Trust Governance Frameworks von NHS England spiegeln dieselbe Drei-Achsen-Logik in der US- und UK-Aufsichts-Praxis: Daten- und Architektur-Substanz, Implementations- und Begleitungs-Substanz, Exit- und Übertragbarkeits-Substanz. Die Drei-Achsen-Logik ist auch in den standard-formalen Texten anschlussfähig — der EU AI Act 2024/1689 verankert die Pflichten der Anwender:innen bei Hochrisiko-KI in Artikel 26 und das Quality Management System in Artikel 17, die deutsche Marktaufsichts-Struktur ist im Mai 2026 noch im Aufbau, der Anwendungs-Beginn der Mehrheit der Hochrisiko-Anforderungen liegt am 02.08.2026; ISO/IEC 42001:2023 setzt das in einem AI-Management-System-Standard mit explizitem Top-Management-Verantwortungs-Layer um; das Bundesamt für Sicherheit in der Informationstechnik (BSI) benennt in seinen Governance-Empfehlungen zu KI-Sicherheit dieselben Achsen aus IT-Sicherheits-Sicht. Aus der Konvergenz lässt sich ein Strukturwerk ableiten, an dem eine Aufsichts-Sitzung die Investitions-Vorlage prüfen kann, bevor das Volumen freigegeben ist.
Frage 1 — Auf welcher Datenqualitäts-Architektur ruht die Investition
Die erste Frage zielt nicht auf die Funktions-Liste der Software, sondern auf die Datenqualitäts-Architektur, auf der die Vorschläge entstehen. Die substanzielle Antwort benennt drei Punkte: aus welchen Akten-Quellen die Software ihre Eingabe zieht, wie die Konsistenz über diese Quellen gesichert wird, und wie das System mit widersprüchlichen oder unvollständigen Eingabe-Daten verfährt. Reviews 2024–2026 in npj Digital Medicine dokumentieren konvergent, dass Datenqualitäts-Lücken in der Trainings- und Inferenz-Daten-Konsistenz die häufigste strukturelle Schadens-Quelle in der Klinik-KI-Adoption sind — die Reviews aggregieren Studien unterschiedlicher Methodik, die Klassen-Aussage bleibt über die Reviewlinie hinweg stabil. Eine Antwort in der Form „die Software hat eine sehr gute Datenqualität“ ist keine Antwort; sie ist ein Antwort-Pattern. Eine substanzielle Antwort nennt die Quellen-Liste, die Konsistenz-Prüfung über Quellen, das Verhalten bei Widersprüchen — und benennt, wo die Datenqualität in der Inferenz noch nicht ausreichend ist, ohne diese Lücke als Erfolg zu rahmen. Wenn die Vorlage zu Frage 1 keine architektonische Substanz liefert, sondern eine Funktions-Folien-Liste wiederholt, hat die Aufsicht den ersten Befund.

Frage 2 — Wie wird der Übergang vom Vertrag in den Klinik-Alltag begleitet
Die zweite Frage zielt auf die Implementations-Begleitung — den Übergang vom Vertragsabschluss zum operativen Klinik-Alltag, gemessen in Personentagen und in der organisatorischen Begleitungs-Struktur. Greenhalgh und Kolleg:innen (2017) benennen im NASSS-Bezugsrahmen die Anpassung über Zeit als eigenständige Komplexitäts-Domäne; Damschroder und Kolleg:innen (2009) ordnen im CFIR-Rahmen den inneren Kontext (Klinik-interne Strukturen, Lese-Routinen, Schlüsselpersonen) als die Domäne mit der größten Adoptions-Variation. Reviews 2018–2025 in Implementation Science konvergieren auf den Befund, dass Klinik-IT-Investitionen, die in der Implementations-Begleitung unter-budgetiert sind, in der Sustainment-Phase 12 bis 24 Monate nach Go-Live überproportional scheitern. Die substanzielle Antwort auf Frage 2 nennt drei Punkte: das vertraglich vereinbarte Personentage-Volumen für die Implementations-Begleitung in den ersten 12 Monaten, die benannten Ansprechpersonen auf Anbieter- und auf Klinik-Seite, und das Format der laufenden Begleitung — Vor-Ort-Termine, regelmäßige Schalt-Termine, Eskalations-Pfade — über den Go-Live hinaus. Die Auskunft „die Schulung ist im Vertrag enthalten“ hat die Frage nicht beantwortet. Sie hat eine Trainings-Budget-Position genannt, an der die Sustainment-Phase nicht hängt.

Frage 3 — Was bleibt im Haus, wenn die Anbieter-Partnerschaft endet
Die dritte Frage zielt auf die Exit-Logik — die strukturelle Erwartung, welche Daten und Modelle in der Klinik verbleiben, falls die Partnerschaft in einem späteren Vertragsjahr endet, scheitert oder neu strukturiert wird. Glasgow und Kolleg:innen (1999) haben im RE-AIM-Rahmen die Maintenance-Achse als eigenständige Evaluations-Achse benannt — getrennt von der Erst-Adoption, die Frage, ob die Investition zwölf, achtzehn, vierundzwanzig Monate nach Go-Live noch trägt. Beiträge 2022–2026 in Health Affairs benennen die Anbieter- und Modell-Lebenszyklus-Risiken als strukturelle Aufsichts-Achse — Modell-Updates, Lizenz-Änderungen, Roadmap-Verschiebungen, Anbieter-Konsolidierungen sind in der Klinik-KI-Branche keine Ausnahme, sondern eine wiederkehrende Erwartung. Die substanzielle Antwort auf Frage 3 nennt drei Punkte: welche Daten — Trainings-Daten, Inferenz-Logs, ärztliche Freigabe-Entscheidungen, klinische Doku — bei Vertrags-Ende bei der Klinik bleiben und in welchem Format; welche Modelle und Doku-Strukturen exportierbar oder weiterverwendbar sind; welche Vertrags-Klauseln einen geordneten Übergang in eine andere Anbieter-Partnerschaft oder in eine Klinik-interne Weiterführung tragen. Eine Antwort in der Form „der Anbieter ist eine etablierte Größe und wir gehen von einer langfristigen Partnerschaft aus“ ist keine Exit-Antwort. Sie ist eine Erwartungs-Aussage. Die Aufsichts-Frage zur Exit-Logik ist gerade die Frage, was strukturell trägt, wenn die Erwartung sich nicht bewahrheitet.
“Drei Fragen — zur Datenqualitäts-Architektur, zur Implementations-Begleitung, zur Exit-Logik — verschieben die Aufsichts-Sitzung aus der Volumens-Diskussion in die strukturelle Tragfähigkeits-Diskussion.”
Was die drei Fragen teilen — und wie der Aufsichts-Hebel sitzt
Die drei Fragen teilen denselben strukturellen Mechanismus. Jede einzelne öffnet eine Achse, an der die Sitzung Substanz prüft statt Volumens-Argumente nachzulesen. Sie sind in den deutschen Verbands-Empfehlungen — KKVD, BDPK, DKG — und in der internationalen Aufsichts-Praxis — KPMG Audit Committee Institute, Roland Berger, AHA Trustee Center, NHS Trust Governance — methodisch konvergent benannt. Sie sind in den Implementation-Science-Bezugsrahmen empirisch unterfüttert: in der NASSS-Domänen-Logik, in der CFIR-Innenkontext-Variation, in der RE-AIM-Maintenance-Achse. Sie sind in den standard-formalen Anker-Texten anschlussfähig: in Artikel 17 und Artikel 26 des EU AI Act 2024/1689, in der Top-Management-Verantwortungs-Klausel von ISO/IEC 42001:2023, in den Governance-Empfehlungen des BSI. Sie sind kompatibel mit den Trägerstruktur-Variationen — kommunal, freigemeinnützig, privat, kirchlich, universitär — und ihren Aufsichts-Gremien-Formen, ob Aufsichtsrat, Beirat oder Gesellschafter-Versammlung. Die Aufsichts-Funktion bleibt dieselbe: eine Strukturkontrolle vor der Volumen-Freigabe, an drei prüfbaren Achsen.

Drei Fragen entlang dreier Achsen. Sie sind keine vollständige Theorie der Klinik-IT-Governance; sie sind die Stellen, an denen die Aufsichts-Funktion in der konkreten Investitions-Vorlage operativ wird. Liegen die drei Antworten auf einer eigenen Vorlagen-Seite vor, prüft die Sitzung strukturelle Tragfähigkeit als beobachtbares Antwort-Muster. Müssen sie erst in der Diskussion selbst gesucht werden, bekommt die Aufsicht sie meist nicht — und erlebt die Investition stattdessen 18 Monate später als Korrektur-Vorlage. Die Strukturkontrolle, die viele Aufsichtsräte für sich seit Jahren formulieren, hat eine Form, die nicht in der Aufsichtsrats-Geschäftsordnung neu geschrieben werden muss. Sie steht in drei Fragen, die jede Investitions-Vorlage tragen kann.
Der Beitrag beschreibt drei strukturell wirksame Aufsichts-Fragen für Klinik-KI-Investitionen entlang öffentlich dokumentierter Governance-Rahmen — Empfehlungen des Katholischen Krankenhausverbands Deutschlands (KKVD), des Bundesverbands Deutscher Privatkliniken (BDPK) und der Deutschen Krankenhausgesellschaft (DKG); KPMG Audit Committee Institute Materialien; Roland-Berger-Klinik-Governance-Studien; American Hospital Association (AHA) Trustee Center und NHS Trust Governance Frameworks; Implementation-Science-Bezugsrahmen Greenhalgh/NASSS 2017, Damschroder/CFIR 2009 und Glasgow/RE-AIM 1999; Reviews 2018–2026 in Implementation Science, npj Digital Medicine und Health Affairs; sowie standard-formale Anker im EU AI Act 2024/1689 (Artikel 17 Quality Management System, Artikel 26 Pflichten der Anwender:innen), in ISO/IEC 42001:2023 (AI Management System) und in den Governance-Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik (BSI). Aiomics betreibt eine Klinik-KI-Architektur, die in den drei Achsen Datenqualität, Implementations-Begleitung und Exit-Bedingungen als Architektur-Wahl gestaltet ist; der Beitrag argumentiert die drei Aufsichts-Fragen aus den allgemeinen Governance-Quellen, nicht aus Aiomics-Praxis. Er gibt keine Rechtsauslegung zu Aufsichtsrats-Pflichten, Trägerstruktur-Recht, EU-AI-Act-Anwendung, ISO-42001-Zertifizierung oder konkreter Aufbau-Organisation der Aufsicht — die Bewertung im Einzelfall bleibt Sache der Geschäftsführung, des Aufsichtsrats, der zuständigen Träger-Organe und ihrer rechtlichen Beratung.


