Sie haben eine Ausschreibung gewonnen und sollen in einem Jahr eine Plattform für Gesundheitsdaten aufbauen. Bisher betreiben Sie Ihre Infrastruktur selbst, eine Cloud kam wegen Datenschutz, Sicherheit und Datenhoheit nie infrage. Jetzt soll die Plattform skalieren und KI nutzen, und dafür braucht es GPU-Leistung, die sich kaum selbst vorhalten lässt. Also doch Cloud? Vier Entwicklungen sprechen dafür.
1. Der rechtliche Rahmen ist klarer geworden
Seit dem Digitalgesetz von 2024 regelt § 393 SGB V den Cloud-Einsatz im Gesundheitswesen ausdrücklich. Leistungserbringer, Kranken- und Pflegekassen sowie ihre Auftragsverarbeiter dürfen Gesundheits- und Sozialdaten in der Cloud verarbeiten, wenn vier Voraussetzungen erfüllt sind:
- Die Verarbeitung findet in Deutschland, der EU, dem EWR oder der Schweiz statt, oder in einem Drittstaat mit Angemessenheitsbeschluss der EU-Kommission. Der Anbieter hat eine Niederlassung in Deutschland.
- Die technischen und organisatorischen Maßnahmen entsprechen dem Stand der Technik.
- Für die eingesetzten Cloud-Systeme liegt ein aktuelles BSI-C5-Testat vor, seit dem 1. Juli 2025 grundsätzlich vom Typ 2. Ein Typ-2-Testat prüft die Wirksamkeit der Sicherheitsmaßnahmen über einen längeren Zeitraum.
- Die im Prüfbericht des Testats genannten korrespondierenden Kriterien für Kunden sind umgesetzt. Ein Teil der Pflichten liegt damit beim Nutzer.
2. Europäische Anbieter haben aufgeholt
Digitale Souveränität steht derzeit auf jeder Konferenzfolie. Dahinter steckt eine konkrete Frage: Wer kann auf die Daten zugreifen? Unterliegt der Anbieter über seine US-Mutter dem CLOUD Act oder Section 702 des FISA, können US-Behörden die Herausgabe verlangen, auch aus einem Rechenzentrum in Frankfurt.
§ 393 SGB V lässt diese Frage offen. Auch die großen US-Anbieter können seine Anforderungen erfüllen. Wer Zugriffe von Behörden außerhalb der EU vermeiden will, muss zusätzlich auf die Eigentümerstruktur des Anbieters achten.
Genau hier haben europäische Anbieter aufgeholt. Anbieter wie Open Telekom Cloud, STACKIT oder Hetzner erfüllen die gesetzlichen Anforderungen und bieten heute Rechenleistung, Speicher, Netzwerk und GPUs für anspruchsvolle Anwendungen. Die Auswahl an verwalteten Diensten ist kleiner als bei den US-Hyperscalern. Eine Übersicht europäischer Anbieter pflegen wir laufend.
3. Der Rechenbedarf von KI ist schwer planbar
Kleinere und mittelgroße Open-Weight-Modelle lassen sich inzwischen gut selbst betreiben. Unterschätzt wird meist der Schritt vom Pilotprojekt zum Betrieb mit mehreren hundert oder tausend Nutzern: Viele gleichzeitige Anfragen brauchen ein Vielfaches an GPU-Kapazität. Und wer aus dem Alltag die führenden Chat-Modelle kennt, erwartet vom internen Werkzeug dieselbe Qualität. Konkurrenzfähige Open-Weight-Modelle wie Kimi K3, DeepSeek V4 und GLM 5.3 brauchen dafür Server mit mehreren High-End-GPUs. Gekaufte Hardware wird über mehrere Jahre abgeschrieben. Die Anforderungen der Modelle ändern sich in Monaten.
Die Cloud spielt hier ihre Stärke aus. GPU-Kapazität lässt sich mieten und an den tatsächlichen Bedarf anpassen. Oder man betreibt die Modelle gar nicht selbst und nutzt sie über eine API. Rechtlich ist ein API-Endpunkt ein Cloud-Dienst wie jeder andere, die Anforderungen aus § 393 SGB V gelten also auch hier. Dazu sollte vertraglich ausgeschlossen sein, dass Eingaben zum Training verwendet werden. Welche Anbieter das zusagen, zeigt unsere Übersicht von LLM-APIs mit EU-Endpunkt.
Eine technische Eigenschaft der Inferenz hilft dabei: Sie braucht keine dauerhafte Speicherung. Ein- und Ausgaben können im Arbeitsspeicher verarbeitet und nach der Antwort verworfen werden. Verzichtet der Anbieter vertraglich auf Protokollierung und Speicherung (Zero Data Retention), entsteht gar kein Datenbestand, der später herausgegeben werden könnte, etwa auf Grundlage des CLOUD Act. Das senkt das Risiko deutlich. Sorgfältig auswählen muss man den Anbieter trotzdem.
4. Die Einstiegshürde ist gesunken
Lange sprach der hohe Einarbeitungsaufwand gegen die Cloud. Jeder Anbieter bringt eine eigene Welt mit: Konsolen mit hunderten Diensten, eigene Begriffe, eigene Konzepte für Netzwerke, Berechtigungen und Verschlüsselung. Wer umsteigen wollte, war auf Dokumentation, Foren und Ausprobieren angewiesen.
KI-Assistenten haben das verändert. Sie führen durch jede Einstellung, erklären Best Practices und ordnen ein, welche Option zum eigenen Fall passt. Gut aufgesetzte KI-Agenten gehen einen Schritt weiter: Über Infrastructure as Code legen sie Server, Netzwerke, Berechtigungen und Sicherheitsregeln direkt an. Jede Änderung liegt als Code vor und ist prüfbar, nachvollziehbar und wiederholbar. Mit den richtigen Leitplanken, etwa automatischen Prüfungen und einer Freigabe vor jeder Änderung, ist das in der Regel sicherer als händische Konfiguration in der Konsole, in die sich leicht Fehler einschleichen.
Netzwerkarchitektur, Identitätsmanagement, Verschlüsselung, Backup, Notfallkonzepte und Compliance bleiben anspruchsvoll, gerade im Gesundheitswesen. Trotzdem braucht ein kleines Team heute deutlich weniger Zeit als vor wenigen Jahren, um eine neue Umgebung sicher aufzubauen.
Also doch Cloud?
Wer eine funktionierende Infrastruktur betreibt, hat zunächst keinen Grund zu wechseln. Die Souveränität eigener Systeme erreicht kein Cloud-Anbieter, und für gleichmäßig laufende Workloads ist eigene Hardware oft wirtschaftlicher. Ob sich ein Wechsel lohnt, zeigt erst der Blick auf den konkreten Anwendungsfall: Welche Daten werden verarbeitet, wie stark schwankt der Bedarf, welche Anforderungen kommen in den nächsten Jahren dazu, und was kosten beide Wege über die gesamte Laufzeit, einschließlich Personal, Hardware-Erneuerung und Betrieb.
Häufig ist das Ergebnis ein Mix, etwa eigene Infrastruktur für den Kern und gemietete GPU-Kapazität für KI. Für eine Plattform, die neu entsteht, skalieren muss und KI nutzen soll, spricht heute vieles für die Cloud: Der rechtliche Rahmen ist klar, europäische Anbieter erfüllen ihn, und der Einstieg ist einfacher geworden.