Cloud vs. On-Premise für Klinik-KI: Was der TCO-Vergleich über fünf Jahre wirklich zeigt

In einer Strategie-Sitzung einer mittelgroßen Mischklinik im Frühjahr 2026 fasst die Geschäftsführerin die zwei Positionen am Tisch zusammen. Die IT-Leitung schlägt eine Cloud-Native-Topologie in einer EU-Region vor, mit den vertraglichen Architektur-Kontrollen, die der Datenschutz-Beauftragte vorab geprüft hat. Der Datenschutz-Beauftragte hat eine zweite Variante vorbereitet: ein eigenes Rechenzentrum mit GPU-Servern und einer offenen Sprachmodell-Variante, „weil das souveräner ist“. Auf dem Tisch liegen zwei Angebote, eine Förder-Reststrecke aus dem Krankenhauszukunftsgesetz (KHZG), und eine Frage, die in den ersten zehn Minuten formuliert wird: was das jeweils auf fünf Jahre kostet. Diese Frage ist die ehrlichere Variante der Cloud-vs-On-Premise-Diskussion. Sie ist seltener als die Sicherheits-Frage, weil sie eine Rechnung verlangt, die in vielen Häusern bisher nicht aufgesetzt wurde — und sie liefert ein Bild, das der regulatorische Reflex „Cloud verboten, On-Premise sicher“ nicht trägt.

Eine Vorab-Klärung. Souveränität ist 2026 keine reine Standort-Frage — sie ist, wie in einem früheren Stück zur Architektur-Frage ausgeführt, eine Architektur-Frage mit sieben operativen Kontroll-Stellen: Schlüsselverwaltung, Regional-Containment, Subprozessor-Pinning, Audit-Trail-Immutabilität, Datenexport-Garantien, Personalstandort-Bindung, Modell-Provenienz. Eine On-Premise-Topologie löst die Kontrollen nicht automatisch ein, eine Cloud-Native-Topologie löst sie nicht automatisch nicht ein. Beide tun es, wenn sie korrekt gebaut sind, und beide tun es nicht, wenn sie schlecht betrieben werden. Die rechtlichen Bezugsgrößen liegen daneben: der US-amerikanische CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) verpflichtet US-ansässige Cloud-Anbieter zur Datenherausgabe auf richterlichen Beschluss — unabhängig vom Speicher-Ort und davon, ob die Klinik die Verschlüsselungs-Schlüssel selbst hält. Foreign Intelligence Surveillance Act Section 702 (FISA 702) erweitert diese Reichweite. Das EuGH-Urteil Schrems II (2020) hat die transatlantische Datenübertragung neu beurteilt; das nachfolgende EU-US Data Privacy Framework bleibt rechtlich umstritten. Diese Lage ist eine komplementäre Bezugsgröße, keine ersetzbare. Die TCO-Frage ist die ökonomische Übersetzung der Architektur-Sicht — sie fragt nicht, in welchem Raum der Server steht, sondern was die Einlösung der Kontroll-Stellen über fünf Jahre kostet und welche Topologie die Disziplin trägt, ohne dass die Klinik sie einkaufen muss.

Die fünfjährige Rechnung: was in beiden Topologien tatsächlich anfällt

Deutsche Krankenhäuser geben rund 2,2 Prozent ihres Umsatzes für IT aus — laut dem Krankenhaus-IT-Monitor 2024 von Roland Berger weiterhin deutlich unter dem OECD-Mittel von etwa vier Prozent. Innerhalb dieses Budgets entfällt der größte Block — etwa 40 Prozent — auf Lizenzen und externe Dienstleister, ein knappes Drittel auf Personal, der Rest auf Hardware und Sonstiges. Die Posten, die in einer Cloud-vs-On-Premise-TCO-Rechnung gegeneinander aufgerechnet werden müssen, fallen in beiden Topologien an, aber sie verteilen sich grundlegend unterschiedlich auf Anbieter und Klinik. Die fünf Posten — Hardware, Lizenz beziehungsweise Inferenz-Verbrauch, Personal, Wartung und Compliance — sind dieselben; die Frage ist, wer sie trägt und wie sie sich über fünf Jahre entwickeln.

Erstens: Hardware. On-Premise trägt die Hardware-Investition als sichtbarsten Posten — GPU-Server in einer Konfiguration, die das gewählte Modell trägt. Reviews in npj Digital Medicine 2024–2026 berichten, dass 70-Milliarden-Parameter-Modelle in der Inferenz typischerweise mehrere High-End-GPUs der A100- oder H100-Klasse oder Nachfolge-Generationen verlangen; kleinere Sieben-bis-Dreizehn-Milliarden-Parameter-Modelle laufen auf einer einzelnen GPU, verlieren aber Genauigkeit. Die Hardware muss nach Spitzenlast dimensioniert werden, weil die Investition unabhängig vom Inferenz-Volumen erfolgt. Refresh-Zyklen fallen früher an als die Klinik-IT sie aus den Server-Plattformen anderer Workloads kennt: Reviews im Bundesgesundheitsblatt 2024–2026 benennen Hardware-Refresh-Zyklen für GPU-intensive Workloads in der Größenordnung von drei bis fünf Jahren — und identifizieren die Wartungs-Last, nicht die einmalige Hardware-Investition, als den unterschätzten Kostentreiber. Die KHZG-Förderfähigkeit endet im Auslaufzeitraum; die Anschluss-Förderlogik für den nächsten Refresh ist offen. In der Cloud entfällt die Hardware-Investition; an ihre Stelle tritt ein Inferenz-Verbrauch, der als Stunden- oder Token-Verbrauch fakturiert wird und mit dem Volumen schwankt. Über fünf Jahre summiert sich der Cloud-Verbrauch bei konstantem Volumen oft auf eine vergleichbare Größenordnung wie die On-Premise-Hardware mit Refresh — die Verteilung der Kosten über die Zeit ist die Differenz, nicht die Summe.

Zweitens: Personal. On-Premise verlangt einen Posten, der in Standard-Ausschreibungen häufig fehlt. Patches ohne Verzug, Logging-Audits, Backup-Wiederherstellungs-Proben in monatlicher Routine, immutable Audit-Trails mit kryptografischer Verkettung, Inferenz-Server-Härtung, Modell-Versions-Disziplin, Drift-Detektion, Sicherheits-Hardening — diese Disziplin verlangt dediziertes Personal in einer ML-Operations-Rolle (MLOps) sowie ein 24/7-Sicherheits-Team. Der Bundesverband Gesundheits-IT (bvitg) benennt in Stellungnahmen zur Klinik-IT-Modernisierung den MLOps-Skill-Aufbau und die GPU-Verfügbarkeit als strukturelle Engpässe in deutschen Klinik-IT-Abteilungen außerhalb der größten Universitätsklinika. Gartner-Healthcare-IT-Reports 2024–2026 identifizieren Hardware-Refresh, MLOps-Personal-Aufbau und Patch-Disziplin als die drei Kostentreiber, die On-Premise-TCO-Modelle regelmäßig unterschätzen. Cloud-seitig übernimmt der Anbieter die operative Schicht — Patch-Routine, Inferenz-Server-Härtung, GPU-Refresh — und die Klinik trägt eine schmaler dimensionierte Aufsicht, die das vertragliche Audit prüft. Personal ist auf der Cloud-Seite nicht null; es ist anders qualifiziert.

Drittens: Wartung. Software, die nicht regelmäßig auf neue Versionen mitgeführt wird, verliert in fünf Jahren ihre Relevanz und ihre Sicherheits-Patches. On-Premise trägt die Wartungs-Last selbst — Modell-Updates, Tokenizer-Verfeinerungen, Patches, Domänen-Varianten — meist nicht in der Lizenz enthalten. Cloud-seitig ist die Wartung in den Inferenz-Verbrauch eingerechnet; die Frage lautet nicht „wie viel kostet die Wartung“, sondern „wie ist sie vertraglich zugesichert“. Viertens: Compliance. Audit-Vorbereitung, Datenschutzfolgeabschätzung, Architektur-Dokumentation, Zertifizierungs-Pflege — diese Posten kommen beidseits vor, unterscheiden sich aber strukturell. McKinsey-Healthcare-Cloud-Strategy-Reports 2024 dokumentieren, dass Cloud-Compliance-Vorteile typischerweise bei mittelgroßen Häusern entstehen, weil zertifizierte Anbieter die Audit-Vorlast kommerziell tragen — Cloud Computing Compliance Criteria Catalogue (C5) des Bundesamts für Sicherheit in der Informationstechnik (BSI), ISO/IEC 27001, ISO/IEC 27018 und der Entwurf des European Cybersecurity Certification Scheme for Cloud Services (EUCS) sind als zertifizierte Bezugsgrößen verfügbar. On-Premise muss die Audit-Vorlast selbst getragen werden, einschließlich der Zertifizierungs-Pflege über fünf Jahre. Fünftens: Lizenz beziehungsweise Inferenz-Verbrauch — der Posten, der in den meisten Ausschreibungen ehrlich verglichen wird. Über fünf Jahre ist er selten der größte; die anderen vier überholen ihn in der Mehrzahl der Konstellationen.

Vier Inflexionspunkte: wo die TCO-Logik strukturell kippt

Erstens die Klinikgröße. Unter rund 250 Betten kippt die TCO-Logik fast immer cloud-favourable, weil sich die Fixkosten der On-Premise-Disziplin — 24/7-Sicherheits-Team, MLOps-Stelle, Refresh-Reserve — auf eine zu schmale Inferenz-Last verteilen. Zwischen 250 und 800 Betten variiert die Logik je nach Workload-Mischung; Häuser dieser Größe sind die Mehrzahl. Über 800 Betten und mit etablierter Universitäts-MLOps-Praxis kann On-Premise tragen — die Inkremental-Kosten für eine zusätzliche LLM-Last sind dann niedriger. Zweitens die Inferenz-Volatilität. Workloads mit stark schwankender Auslastung — saisonale Notaufnahme-Spitzen, Trauma-Zentrum-Lasten — treiben die On-Premise-TCO, weil die Hardware in den Tälern leersteht. McKinsey-Healthcare-Cloud-Strategy-Reports benennen diese Volatilitäts-Mechanik als den ökonomischen Hauptgrund, warum mittelgroße Häuser mit volatilen Workloads in der Cloud-Variante über fünf Jahre günstiger fahren. Gleichmäßige Workloads — konstante Doku-KI-Last im Reha-Haus, planbare Codier-KI-Auslastung im Akut-Haus — verschieben die Logik zurück; eine On-Premise-Dimensionierung bleibt dort näher am tatsächlichen Verbrauch.

Drittens die vorhandene GPU- und MLOps-Kompetenz. Häuser, die bereits eine GPU-Infrastruktur für Bildgebung, Genomik oder Pathologie betreiben, haben Hardware, Personal und Patch-Disziplin schon im Haus — sie können eine zusätzliche LLM-Last strukturell auf vorhandene Architektur aufsetzen. Häuser ohne diese Praxis müssen die gesamte Lernkurve aufbauen, und die Lernkurve ist ein eigener TCO-Posten, der sich nicht in der Hardware-Investition versteckt. Viertens der KRITIS-Status mit Air-Gap-Pflicht. Wo eine konkrete Bewertung nach KRITIS-Verordnung vorliegt — und nicht eine berufene Sicherheits-Intuition — ist On-Premise die Architektur-Antwort unabhängig von der TCO-Logik. Die European Union Agency for Cybersecurity (ENISA) strukturiert KI-Sicherheit in mehreren Schichten — Modell, Daten, Inferenz, Audit, Personal — und macht deutlich, dass eine Air-Gap-Topologie die Daten- und Inferenz-Schicht in spezifischen Konstellationen schließt, an Modell-Provenienz und Personal-Schicht aber nichts ändert. Wo der Air-Gap nur berufen wird, ist die On-Premise-Wahl eine architektonische Behauptung — und die TCO-Rechnung stützt sie nicht.

Damit gibt die TCO-Rechnung etwas an die Souveränitäts-Frage zurück. Wenn die eigentliche Klinik-Frage Souveränität ist und nicht „On-Premise als Selbstzweck“, verschiebt sich die Antwort zurück auf die genannten Kontroll-Stellen. Sie lassen sich in einer korrekt gebauten europäischen Cloud-Topologie vertraglich und technisch einlösen; sie lassen sich in einer korrekt betriebenen On-Premise-Topologie ebenfalls einlösen, verlangen dort aber das eigene 24/7-Sicherheits-Team und die strukturelle MLOps-Kompetenz, die in den meisten Häusern außerhalb der größten Universitätsklinika nicht aufgebaut ist. Die gematik bewertet Cloud-Nutzung im Klinik-Kontext entlang dieser Kriterien und nicht entlang einer pauschalen Cloud-vs-On-Premise-Achse — die Empfehlungen lassen zu, dass eine sauber gebaute europäische Cloud-Topologie Anforderungen erfüllt, die in einer schlecht gewarteten On-Premise-Topologie unerfüllt bleiben. Die rechtlichen Bezugsgrößen — DSGVO, EU AI Act, US CLOUD Act, FISA 702, Schrems II, EU-US Data Privacy Framework — bleiben davon unberührt; sie sind komplementäre Auswahl-Kriterien, nicht ersetzbare. Aiomics ist als Cloud-Native-Architektur in einer EU-Region gebaut, mit den genannten Kontroll-Stellen vertraglich und technisch eingelöst — eine Wahl aus der Distributed-Systems-Schule, die On-Premise nur dort als Substitut zulässt, wo eine der Inflexionspunkt-Konstellationen tatsächlich trägt.

Die fünfjährige Rechnung und die vier Inflexionspunkte sind keine vollständige Theorie der Klinik-KI-Architektur; sie sind eine pragmatische Auswahl aus Marktstudien-Aggregaten und Hardware-Ökonomie. Was sie zusammenhält, ist die Disziplin, die fünf Posten und die vier Konstellations-Stellen schriftlich nebeneinander zu legen, bevor die Hardware-Investition oder der Cloud-Vertrag steht. Der regulatorische Reflex trägt nicht; die ökonomische Verkürzung „Cloud spart Geld, weil keine Hardware“ trägt auch nicht. Die ehrlichere Frage in der Strategie-Sitzung jener Mischklinik wäre nicht die nach der jeweiligen Fünf-Jahres-Summe — sondern, in welcher Topologie die Klinik die operative Disziplin am verlässlichsten hält, ohne sie einkaufen zu müssen.