On-Premises-KI für Klinikketten und MVZ-Träger: Wann es sich lohnt

Die Frage „Cloud oder On-Premises?" ist für Klinikketten und MVZ-Träger in den vergangenen zwei Jahren wieder lauter geworden. Das hat weniger mit Technologie zu tun als mit Realpolitik: Aufsichtsbehörden schauen genauer hin, § 75c SGB V verpflichtet Krankenhäuser zur IT-Sicherheit auf KRITIS-Niveau, und die DSGVO hat in der jüngsten Rechtsprechung (Stichwort: Schrems-Konsequenzen) auch konfigurierte EU-Hosting-Setups nicht völlig aus der Schusslinie genommen, wenn US-Mutterkonzerne im Spiel sind.

Wer als Träger oder Geschäftsführung einer Klinikkette heute über die Einführung eines KI-Telefonassistenten nachdenkt, steht damit vor einer Architekturentscheidung, die deutlich weiter reicht als die Frage „Welche KI klingt am besten?". Es geht um Datenhoheit, Auditierbarkeit und um die langfristige Verlagerung von Patientenkommunikation in IT-Systeme — eine der sensibelsten Datenkategorien überhaupt.

Was On-Premises in der Praxis bedeutet

Die Begriffe vermischen sich. Anbieter werben mit „EU-Cloud", „DSGVO-konform", „Hosting in Deutschland". Das ist nicht dasselbe wie On-Premises. Wer es genau wissen will, sollte sich vier Fragen stellen:

1. Wo läuft die Datenbank? Auf Servern, die dem Träger gehören oder von ihm angemietet sind — oder auf einer fremden Cloud-Plattform?
2. Wem gehören die LLM-Provider-Konten? Wird Azure OpenAI, Anthropic oder ein lokales Modell genutzt? Wer hat den API-Schlüssel? Wer trägt das Auftragsverarbeitungs-Risiko?
3. Wie läuft die Telefonie? Eigene SIP-Trunks beim eigenen Provider — oder ein gemeinsamer Anbieter-Trunk, über den auch andere Kunden laufen?
4. Wie sieht die Netzwerkarchitektur aus? Können die Komponenten in eine eigene DMZ oder TI-Sicherheitszone gestellt werden? Ist eine air-gapped-Variante möglich?

Eine echte On-Prem-Installation beantwortet alle vier Fragen mit „bei uns im Haus" — die Komponenten laufen auf Hardware des Trägers, die Modelle laufen entweder lokal oder auf einer dezidierten Cloud-Subscription, die Telefonie nutzt eigene SIP-Trunks, und die Architektur lässt sich vom restlichen Klinik-Netz isolieren.

KIS-Integration: Der eigentliche Hebel

Ein KI-Telefonassistent in einer Klinikkette entfaltet seinen Wert erst, wenn er mit dem Krankenhausinformationssystem (KIS) verbunden ist. Ohne Anbindung an SAP IS-H, Orbis, medatixx, x.isynet, Turbomed oder ALBIS bleibt er ein hübsches Sekretariats-Frontend ohne Substanz. Mit Anbindung wird er zum Echtzeit-Patientenkommunikationskanal — der Anrufer wird identifiziert, der Termin im Kalender des richtigen Arztes gebucht, die Vorgeschichte für die Sprechstunde aufbereitet.

Die Integration läuft über die etablierten Schnittstellen-Standards:

• HL7 v2 für klassische ADT-Meldungen (Aufnahme, Verlegung, Entlassung). Die meisten KIS-Systeme sprechen HL7 v2 nativ.
• HL7 FHIR (R4 und neuer) für die moderne, RESTful API-Welt. Die gematik schreibt FHIR für viele TI-Anwendungen vor, deshalb wird es zunehmend zum Standard.
• IHE-Profile wie XDS, XCA, PIX/PDQ — wichtig bei Trägern mit standortübergreifender Patientenakte.

Bei einer On-Prem-Installation läuft die KIS-Anbindung innerhalb des Klinik-Netzes. Es muss keine PHI durch ein Internet-Tor zu einem Cloud-Anbieter wandern. Das ist nicht nur ein DSGVO-Argument, sondern auch eines, das in IT-Sicherheits-Audits unmittelbar Punkte bringt.

Die regulatorische Kulisse: § 75c SGB V, gematik, KIM

Seit 2022 schreibt § 75c SGB V Krankenhäusern den Stand der Technik in der IT-Sicherheit vor. Verstöße werden inzwischen real geahndet, und Aufsichtsbehörden wie das BSI prüfen aktiv. Für Klinikketten heißt das: Eine KI-Telefonanlage, die patientenbezogene Daten verarbeitet, fällt unter dieses Regime — und muss entsprechend gehärtet werden.

Die zentralen Anforderungen, die eine On-Prem-Architektur mehr oder weniger automatisch löst:

• Datenhaltung in einer kontrollierten Umgebung. Eigene Server, eigenes Netz, eigene Backup-Routine.
• Audit-Trails und Protokollierung. Wer hat wann mit welcher Patientenakte gearbeitet? Bei einer Cloud-Lösung sind diese Logs beim Anbieter, bei On-Prem im Haus.
• Anbindung an die Telematikinfrastruktur (TI). Sichere Kommunikationsdienste (KIM), elektronische Heilberufsausweise (eHBA), elektronische Patientenakte (ePA). Eine On-Prem-Installation kann direkt im TI-Sicherheitszonen-Netz stehen.
• Schutz besonders schützenswerter Daten. § 203 StGB betrifft auch das ärztliche Personal — die Auslagerung der Verarbeitung an Dritte (selbst in eine EU-Cloud) ist juristisch strittig. Mit On-Prem entfällt die Diskussion.

Für eine Klinik-Kette mit zwölf Häusern haben wir in der Architektur-Beratung kürzlich folgenden Satz gehört: „Wir wollen unseren Datenschutzbeauftragten nicht erklären müssen, warum die Sprachaufnahme einer Patientin in ein Modell fließt, das jemand anderes hostet." Das fasst die Position vieler Träger gut zusammen.

Cloud vs. On-Premises: Die Entscheidungsmatrix

Die Matrix macht deutlich: On-Premises ist nicht in jedem Punkt die bessere Lösung. Cloud-Setups sind schneller live, automatisch aktuell, und für kleinere Träger mit ein bis fünf Standorten meist die richtige Wahl. Erst ab acht bis zehn Standorten kippt die Bilanz: Dann werden die Auditierungspflichten, die Integrationstiefe und die strategische Datenhoheit zu Argumenten, die schwerer wiegen als Setup-Geschwindigkeit.

Drei reale Szenarien, in denen On-Prem die richtige Wahl ist

Szenario 1: MVZ-Verbund mit 12 Standorten und gemeinsamer Patientenakte

Träger eines MVZ-Verbunds, die bereits eine zentralisierte Patientenakte (etwa über medatixx oder x.isynet im Verbund-Setup) betreiben, profitieren stark von einer On-Prem-Installation, weil die KI direkt an die existierende Architektur andocken kann. Die Telefonanlage wird zur logischen Erweiterung des KIS, nicht zu einem separaten Cloud-Silo, das aufwendig synchronisiert werden muss.

Szenario 2: Klinikkette mit eigener Rechenzentrums-Strategie

Kommunale und private Klinikketten haben in den letzten Jahren erhebliche Investitionen in eigene Rechenzentren oder dedizierte Hostings getätigt — getrieben durch KRITIS-Auflagen und die Erkenntnis, dass IT-Souveränität ein strategisches Asset ist. Wer in diese Infrastruktur investiert hat, möchte die KI-Komponenten auf derselben Schiene betreiben. Eine On-Prem-Installation passt nahtlos in eine RZ-Strategie, eine externe Cloud-Lösung wäre architektonisch ein Fremdkörper.

Szenario 3: Universitätskliniken und forschende Häuser

Universitätskliniken haben einen Sonderstatus: Sie verarbeiten Patientendaten für die Versorgung, aber auch für Forschung — letztere mit eigenen ethischen und regulatorischen Anforderungen (Ethikkommissionen, GCP, lokale Datenverarbeitungsbestimmungen). Eine On-Prem-Installation ermöglicht die saubere Trennung zwischen Versorgungs- und Forschungsdaten innerhalb derselben Plattform, was bei einer Cloud-Lösung architektonisch viel schwieriger sauber abbildbar ist.

Was vor dem Go-Live geklärt werden muss

1. KIS-Inventur. Welche Systeme sind im Verbund im Einsatz? Wie aktuell ist die HL7- bzw. FHIR-Unterstützung? Gibt es Sonderschnittstellen, die zusätzliche Integrationsarbeit bedeuten?
2. Netz-Topologie. Steht die Hardware in einer eigenen DMZ? Wie sieht die Anbindung an die TI aus? Welche Firewall-Regeln müssen erweitert werden?
3. SIP-Provider und Rufnummern. Sollen die Bestandsrufnummern beibehalten werden? Welche Portierungen sind nötig? Welche SIP-Trunks werden für die Inbound- und Outbound-Telefonie genutzt?
4. LLM-Strategie. Wird ein lokales Modell (z. B. eine quantisierte Llama-Variante) im eigenen RZ betrieben? Oder eine dedizierte Cloud-Subscription bei Azure OpenAI in einem EU-Tenant? Beides ist On-Prem-kompatibel, hat aber unterschiedliche Performance- und Kostenprofile.
5. Identity-Management. Wie loggen sich die Mitarbeitenden ein? LDAP, SAML, Active Directory? Single Sign-On mit den bestehenden eHBA-Karten?
6. Backup- und Disaster-Recovery-Strategie. Wie oft wird die PostgreSQL-Datenbank gesichert? Wo liegen die Backups? Gibt es ein zweites Rechenzentrum für DR-Szenarien?
7. Audit- und Reporting-Anforderungen. Welche Logs müssen wie lange aufbewahrt werden? Welche Auswertungen werden für die Aufsicht erwartet? Wer hat Zugriff auf welche Reports?

Diese sieben Punkte gehören in das Architektur-Gespräch vor der Vertragsunterzeichnung. Eine seriöse On-Prem-Beratung dauert meistens mehrere Sitzungen, nicht eine.

Häufige Einwände — und ihre realistische Beantwortung

„Das ist zu komplex für uns, wir haben keine eigene IT." — Stimmt für viele Einzel-MVZs, stimmt nicht für Klinikketten. Träger ab acht Standorten haben in der Regel ein eigenes IT-Team, das die On-Prem-Installation übernehmen kann, oder einen IT-Dienstleister, der genau das gewohnt ist. Die Installation selbst ist nicht radikal komplexer als ein KIS-Upgrade.

„Wir verlieren die schnellen Updates." — Teilweise wahr. On-Prem-Installationen werden in Wartungsfenstern aktualisiert, nicht kontinuierlich. In der Praxis ist das aber häufig ein Vorteil, weil Updates kontrolliert ausgerollt werden können und nicht überraschend Verhalten ändern.

„Wir brauchen die Cloud-Skalierung." — Selten. Klinikketten haben planbare Lastprofile (Sprechzeiten, Bandbreite), keine Black-Friday-Spitzen. On-Prem-Hardware lässt sich für Peak-Lasten dimensionieren, ohne dass die Skalierungs-Magie der Cloud nötig wäre.

„Das ist teurer." — Bei einem Standort: ja. Bei zwölf Standorten und 800.000 Patientenkontakten pro Jahr: in der Regel nein. Die Cloud-Kosten skalieren linear mit Volumen, On-Prem-Kosten weitgehend mit Standorten — und Standorte wachsen langsamer als Volumen.

Fazit

On-Premises ist 2026 kein Nostalgie-Argument mehr, sondern eine sehr bewusste architektonische Entscheidung. Für Klinikketten und MVZ-Träger ab acht Standorten ist sie häufig die richtige — nicht weil Cloud schlecht ist, sondern weil die Kombination aus § 75c SGB V, gematik-Anforderungen, eigener RZ-Strategie und politischem Klima die Bilanz kippt.

Der wichtigste Punkt: Die Entscheidung gehört in das Architektur-Gespräch, nicht in eine Excel-Tabelle mit Lizenzpreisen. Wer eine On-Prem-Installation einkaufen will wie eine Cloud-Subscription, hat das Modell nicht verstanden — und wer eine Cloud-Lösung einkauft, ohne die regulatorischen Konsequenzen für eine Klinikkette mit zwölf Standorten zu durchdenken, ebenfalls nicht.

Weiterführende Artikel

• KI-Telefonassistent und § 203 StGB: Was Anwaltskanzleien beachten müssen
• On-Premises AI Phone Assistants for NHS GP Federations (English)