Open-Source-On-Premise-KI in der Klinik: Wo die Ausnahme wirklich liegt

Auf einem Klinik-IT-Workshop im Frühjahr 2026 fragt ein Vorstandsmitglied einer mittelgroßen Klinik die IT-Leitung: „Können wir das nicht selbst hosten?“ Hintergrund ist ein Artikel über Llama 3 und ein Hinweis aus dem Datenschutz-Büro, ein offenes Sprachmodell auf eigener Hardware sei „die souveränere Lösung“. Die IT-Leitung antwortet zurückhaltend: technisch ja, im Haus aber wahrscheinlich nicht. Diese Antwort ist 2026 für eine Mehrzahl deutscher Kliniken die richtige — und sie verträgt eine genauere Begründung, als sie im Workshop-Format meist bekommt. Open-Source-Sprachmodelle auf eigener Hardware sind reif genug für eine Reihe von Klinik-Anwendungen, sie sind aber nicht der strukturelle Default. Die Voraussetzungen, unter denen sie tatsächlich tragen, sind benennbar.

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. Der Server-Standort ist eine dieser Stellen, nicht ihre Summe. Diese Architektur-Sicht ist der Bezugspunkt für die On-Premise-Diskussion: 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.

Reifegrad und Lizenz-Klasse zuerst. Die Open-Source-Modell-Landschaft 2026 trägt mehrere Familien mit unterschiedlichem Lizenz-Profil. Meta Llama 3 ist unter einer „Community License“ verfügbar — Open-Weights, kommerzielle Nutzung mit einer Schwellen-Klausel ab 700 Millionen monatlichen aktiven Nutzer:innen; die Lizenz ist nicht nach der Definition der Open Source Initiative (OSI) zertifiziert. Mistral hat mehrere Modelle (Mistral 7B, Mixtral 8x7B, Mixtral 8x22B) unter Apache-2.0 veröffentlicht — OSI-konform, ohne Schwellen-Klausel; spätere Modelle laufen unter eingeschränkten kommerziellen Lizenzen, die Klasse ist also pro Modell zu prüfen. Europäische Initiativen wie Apertus aus dem Schweizer Verbund und Teuken-7B aus dem deutschen OpenGPT-X-Verbund zielen auf transparente Trainings-Korpora, mehrsprachige Abdeckung und offene Lizenz-Klassen; ihr Reifegrad gegenüber Llama 3 oder Mistral ist 2026 in spezifischen klinischen Aufgabenbereichen noch im Aufbau. Das Hugging-Face-Open-LLM-Leaderboard berichtet aggregierte Benchmark-Ergebnisse in standardisierten Aufgabenklassen; die Bewertungen sind ein Reifegrads-Indikator und keine direkte Klinik-Wirksamkeits-Aussage. Der Stanford-HAI-Foundation-Model-Transparency-Index ergänzt die Reifegrads-Frage um eine Transparenz-Achse, in der Open-Source-Modelle in Trainings-Daten-Dokumentation, Modell-Karten und Lizenz-Klarheit typischerweise höher abschneiden als proprietäre Modelle — eine notwendige, keine hinreichende Bedingung für operative Sicherheit.

Drei Konstellationen, in denen On-Premise-Open-Source eine fundierte Wahl ist

Erstens: KRITIS-Sektor-Anwendungen mit harter Air-Gap-Pflicht. In spezifischen Klinik-Anwendungen — Modell-Inferenz auf besonders schutzbedürftigen Patientendaten in einem Hochsicherheits-Forschungs-Setup, oder Anwendungen, die nach KRITIS-Bewertung der Klinik eine Air-Gap-Topologie verlangen — ist die fehlende externe Netzanbindung der eigentliche Architektur-Anker, nicht die Lizenz-Klasse des Modells. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) benennt in seinen KI-Sicherheits- und KRITIS-Veröffentlichungen Inferenz-Server-Härtung, Modell-Provenienz, Audit-Trails und Patch-Disziplin als Pflicht-Bestandteile, ohne eine pauschale „On-Premise = sicherer“-Aussage zu treffen. Die European Union Agency for Cybersecurity (ENISA) strukturiert KI-Sicherheit in mehreren Schichten — Modell, Daten, Inferenz, Audit, Personal — und macht damit 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 eine Air-Gap-Topologie tatsächlich verlangt ist, ist On-Premise-Open-Source mit Modell-Provenienz aus einer transparenten Familie eine fundierte Wahl. Wo sie nur berufen wird, ohne dass eine konkrete KRITIS-Bewertung sie trägt, ist sie eine architektonische Behauptung ohne Substanz.

Zweitens: Forschungs-Settings mit etabliertem Sicherheits-Personal. Universitätskliniken oder Forschungs-Institute mit einer existierenden MLOps-Praxis und einem Forschungs-Datenzentrum für interne Validierungs-Studien können Open-Source-Modelle auf eigener Hardware unter kontrollierten Bedingungen einsetzen, ohne die Wartungs-Last in einem schlecht ausgestatteten Klinik-IT-Umfeld zu reproduzieren. NEJM-AI-Reviews 2024–2026 berichten Wirksamkeits-Werte für domänenadaptierte Open-Source-LLMs in der Größenordnung 7B bis 70B Parameter, die in Aufgaben wie Doku-Zusammenfassung, Codier-Vorschlag und Triage-Hinweis die Bandbreite proprietärer Vergleichsmodelle erreichen, wenn die Adaption durchgeführt ist. Sie ist Personal-, Daten- und Zeit-intensiv; ohne sie fallen die Werte spürbar ab. Forschungs-Einheiten mit dieser Kompetenz sind 2026 an mehreren Universitätsklinika aufgebaut — sie bringen die Disziplin mit, die On-Premise-Open-Source verlangt.

Drittens: Standorte mit existierender 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 Open-Source-LLM-Inferenz strukturell auf vorhandene Architektur aufsetzen, ohne ein zweites parallel laufendes Operating-Modell aufzubauen. 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; Häuser, die diese Engpässe bereits geschlossen haben, sind die Minderheit. In dieser Minderheit ist On-Premise-Open-Source als zusätzliche Workload eine ökonomisch tragfähige Wahl. In Häusern, die die Voraussetzungen erst aufbauen müssten, führt die Frage zu den vier Kontraindikations-Konstellationen.

Vier Konstellationen, in denen On-Premise zur teuren Sackgasse wird

Die erste Kontraindikation ist das Haus ohne 24/7-Sicherheits-Team. Patches ohne Verzug, Logging-Audits, Backup-Wiederherstellungs-Proben in monatlicher Routine, immutable Audit-Trails mit kryptografischer Verkettung — diese Disziplin verlangt dediziertes Personal. Ohne dieses Personal verfehlt eine On-Premise-Architektur mehrere der genannten Kontroll-Stellen, ohne dass der Standort dem Argument zur Hilfe käme. Die zweite Kontraindikation ist die Anwendung mit hoher Modell-Update-Frequenz. Open-Source-LLMs erscheinen regelmäßig in neuen Versionen — Sicherheits-Patches, Halluzinations-Reduzierungen, Tokenizer-Verfeinerungen, Domänen-Modell-Varianten. Wer die Update-Disziplin nicht trägt, läuft mit veralteten Modellen weiter und verfehlt die Verbesserungen, an denen die Klinik teilhaben wollte. Die dritte Kontraindikation ist die Anwendung mit volatilem Inferenz-Volumen. Reviews in npj Digital Medicine 2024–2026 berichten, dass die Hardware-Last für 70B-Open-Source-Modelle typischerweise mehrere High-End-GPUs der A100-/H100-Klasse oder Nachfolge-Generationen verlangt; kleinere 7B-bis-13B-Modelle laufen auf einer einzelnen GPU, verlieren aber Genauigkeit. Hardware muss nach Spitze dimensioniert werden — Auslastungs-Lücken bedeuten teure Leerlauf-Kapazität, weil die Investition unabhängig vom Inferenz-Volumen erfolgt. Die vierte Kontraindikation ist das Haus ohne MLOps-Skill-Aufbau-Plan. Open-Source-Modelle laufen nicht selbsttätig; sie verlangen Inferenz-Server-Konfiguration, Monitoring, Drift-Detektion, Sicherheits-Hardening, Modell-Versions-Disziplin. 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 Förderfähigkeit unter dem Krankenhauszukunftsgesetz (KHZG) ist im Auslaufzeitraum begrenzt; die Anschluss-Förderlogik ist offen.

Die Architektur-Antwort: was Souveränität tatsächlich trägt

Wenn die eigentliche Klinik-Frage Souveränität ist und nicht „On-Premise als Selbstzweck“, verschiebt sich die Antwort zurück auf die sieben Kontroll-Stellen aus der Architektur-Sicht. Diese Kontrollen lassen sich in einer korrekt gebauten Cloud-Native-Architektur in einer EU-Region vertraglich und technisch einlösen; sie lassen sich in einer korrekt betriebenen On-Premise-Architektur ebenfalls einlösen, verlangen dort aber das eigene 24/7-Sicherheits-Team und die strukturelle MLOps-Kompetenz, die in den meisten deutschen 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 On-Premise-vs-Cloud-Achse — die Empfehlungen lassen zu, dass eine sauber gebaute europäische Cloud-Architektur Anforderungen erfüllt, die in einer schlecht gewarteten On-Premise-Architektur unerfüllt bleiben. Die rechtlichen Bezugsgrößen — DSGVO, EU AI Act, US CLOUD Act, Schrems II — bleiben davon unberührt; sie sind komplementäre Auswahl-Kriterien, nicht ersetzbare. Aiomics ist in dieser Topologie gebaut, mit den genannten Kontroll-Stellen vertraglich und technisch eingelöst — eine Architektur-Wahl aus der Distributed-Systems-Schule, die On-Premise nur dort als Substitut zulässt, wo eine der drei legitimen Konstellationen tatsächlich vorliegt.

Die drei legitimen Konstellationen und die vier Kontraindikationen sind keine vollständige Architektur-Theorie der Klinik-KI; sie sind eine pragmatische Auswahl aus dokumentierter Empfehlung und Hardware-Ökonomie. Was sie zusammenhält, ist die Disziplin, die Voraussetzungen vor der Architektur-Wahl zu benennen — und nicht erst dann, wenn die Hardware-Investition steht. Die eigentliche Frage ist nicht, in welchem Raum der Inferenz-Server steht. Sie lautet, ob die Klinik die Disziplin trägt, die das Modell verlangt — und in welcher Architektur diese Disziplin am verlässlichsten gehalten werden kann.