Architekturkontrollen statt Datenschutz-Theater: Wie Klinik-IT 2026 souverän bleibt

Es ist Frühjahr 2026, und in einer mittelgroßen deutschen Klinik liegt ein Anbieter-Vergleich für ein KI-System auf dem Schreibtisch der IT-Leitung. Drei Kandidaten, vier Tabellen-Spalten: Funktionsumfang, Preis, Vertrag, Datensouveränität. Die Spalte „Datensouveränität“ ist in zwei der drei Zeilen mit „Server in Deutschland“ ausgefüllt. Damit hat der Anbieter im Vergleichs-Tabellen-Sinn die Frage beantwortet — und die IT-Leitung weiß, dass damit operativ nichts beantwortet ist. Die Architektur-Frage ist eine andere als die Standort-Frage; sie verlangt sieben Antworten, von denen der Server-Standort eine ist.

Die Distributed-Systems-Literatur (Kleppmann, „Designing Data-Intensive Applications“, 2017) hat die System-Souveränität seit Jahren von der Geografie auf die Kontroll-Architektur verschoben — Schlüssel-Custody, Replikations-Topologie, Audit-Spuren, Datenfluss-Disziplin. Der Standort ist eine von mehreren Variablen, nicht die alleinige. Wer sich auf die Standort-Spalte einer Anbieter-Vergleichs-Tabelle stützt, behandelt eine Klasse von Fragen, die Sicherheits-Anforderungen 2026 so nicht stellen. Was hier folgt, ist die kompakte Architektur-Linse, in der eine Klinik-IT-Leitung KI-Anbieter prüft, bevor der Vertrag in Verhandlung geht. Sie schließt an einen früheren Beitrag zu Datensouveränität als Architektur-Frage an und vertieft die operative Prüf-Mechanik.

Sieben Kontrollen, an denen Datensouveränität entschieden wird

Erstens — Schlüsselverwaltung. Wer hält die Verschlüsselungs-Schlüssel? Im Bring-Your-Own-Key-Modell (BYOK) bleibt die Klinik in der Custody der Schlüssel. Ohne BYOK ist die Antwort auf diese Frage „der Anbieter“ — unabhängig vom Server-Standort. BYOK in Verbindung mit europäischer Datenresidenz reduziert das Datenfluss-Risiko gegenüber außereuropäischen Anbieter-Infrastrukturen; die rechtliche Exposition bleibt durch CLOUD Act und FISA 702 mit-bestimmt. Zweitens — Regional-Containment auf Architektur-Ebene. Es genügt nicht, den primären Server in Europa zu betreiben. Replikation, Backup, Failover, Logging und sekundäre Speicher-Zonen müssen ebenfalls auf die kontrollierte Region beschränkt sein. Ein US-Backup-Bucket eines deutschen Primär-Servers ist kein deutsches System mehr — der Datenfluss ist die Bezugsgröße, nicht das Adress-Schild des Primär-Knotens. Drittens — Subprozessor-Pinning. Cloud-Anbieter arbeiten mit Subprozessoren: Logging-Diensten, Monitoring-Anbietern, Identity-Providern. Eine vertragliche Pinning-Klausel zwingt den Anbieter, die Subprozessor-Liste vor Änderungen zu aktualisieren und die Klinik vorab zu informieren. Ohne Pinning kann der Anbieter den Datenfluss morgen anders führen als heute. Der C5-Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik (BSI) hält Subprozessor-Transparenz seit Jahren als Mindestanforderung an Cloud-Anbieter fest.

Viertens — Audit-Trail-Immutabilität. Logs, die der Anbieter nachträglich verändern kann, sind keine Audit-Spuren — sie sind Zustands-Berichte. Echte Audit-Trails verwenden Append-only-Strukturen mit kryptografischer Verkettung; Anbieter, die das anbieten, können es vertraglich zusichern. Anbieter, die es nicht anbieten, signalisieren strukturell, dass eine spätere Rekonstruktion ihrer Datenflüsse Mitwirkung von ihrer Seite verlangt. Fünftens — Datenexport-Garantien. Eine Klinik, die in fünf Jahren wechselt, muss den eigenen Datenbestand exportieren können — in einem nicht proprietären Format, mit dokumentierter Schema-Struktur, in einer Frist, die der Vertrag garantiert. Ohne Datenexport-Garantie verschiebt sich die Souveränitäts-Frage in die Anbieter-Bindungs-Frage. Sechstens — Personalstandort-Bindung. Wer hat administrativen Zugriff auf die Cloud-Instanz? Eine Vertragsklausel, die diesen Zugriff auf Personal in einer definierten Region beschränkt — und Sub-Beauftragungen außerhalb dieser Region ausschließt — ist eine Souveränitäts-Kontrolle, die der Standort des Servers nicht ersetzt. Siebtens — Modell-Provenienz und Vertrags-Pinning. Trainingsdaten-Politik, Modell-Updates und Versions-Stände eines KI-Anbieters müssen vertraglich an einen definierten Status fixiert sein, bevor das Modell Klinik-Daten verarbeitet. Ein Anbieter, der den Modell-Stand morgen unterschiedlich definieren kann als heute, hat keinen kontrollierten Modell-Zugang gegeben. Die ENISA-Empfehlungen zur Cloud-Sicherheit im Gesundheits-Sektor (2021) benennen die Konvergenz-Linie europäischer Aufsichts-Behörden: Schlüsselverwaltung, Datenfluss-Steuerung, Subprozessor-Transparenz und Audit-Verfahren entscheiden über Cloud-Sicherheit; geografische Datenresidenz ist eine notwendige, aber nicht hinreichende Bedingung.

Was Cloud-Native einlöst und wo informelles On-Premise verfehlt

Liest man die sieben Kontrollen zusammen, ergibt sich ein unbequemer Befund. Eine korrekt gebaute Cloud-Native-Architektur in einer EU-Region kann jede der sieben Kontrollen vertraglich und technisch einlösen: BYOK ist Standard bei seriösen europäischen Cloud-Konfigurationen; Subprozessor-Pinning ist Vertrags-Routine; Audit-Trail-Immutabilität ist im C5-Kriterienkatalog gefordert; Datenexport-Garantien sind in europäischen Cloud-Spezifikationen wie Gaia-X und im Entwurf des European Cybersecurity Certification Scheme for Cloud Services (EUCS) strukturell vorgesehen. Personalstandort-Klauseln und Modell-Provenienz-Pinning sind Vertragsvorlagen, die bei vielen seriösen Cloud-Anbietern auf Anfrage ergänzt werden — sie kosten Verhandlungs-Aufwand, sind aber technisch und juristisch umsetzbar. Ein schlecht gewartetes On-Premise-System dagegen — eines, dessen Patch-Zustand niemand verfolgt, dessen Backup-Strategie informell bleibt, dessen Audit-Spuren nur bei Bedarf zusammengesucht werden — verfehlt mehrere der sieben Kontrollen, ohne dass der Standort dem Argument zur Hilfe käme. Der Patch, der nicht eingespielt wurde, ist eine Sicherheitslücke unabhängig vom Land des Servers. Das Backup, dessen Wiederherstellungs-Probe vor 18 Monaten zuletzt geprüft wurde, ist im Ernstfall eine offene Frage — auch dann, wenn das Storage-System in der eigenen Klinik steht.

Auf den sieben Kontrollen schlägt eine korrekt gebaute Cloud das informell betriebene On-Premise verlässlich. Das ist keine Anti-On-Premise-Argumentation. Es gibt Konstellationen, in denen ein gut betriebenes On-Premise-System die richtige Antwort ist — etwa für sehr kleine Datenmengen mit definierten Schnittstellen, für hochspezialisierte Forschungs-Setups mit eigenem Sicherheits-Personal oder für gematik-relevante Komponenten in der Telematik-Infrastruktur (TI), in der die Spezifikationen den Architektur-Zuschnitt eng vorgeben. Das BSI und die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) haben in mehreren Tätigkeitsberichten Subprozessor-Transparenz, Schlüssel-Custody und Audit-Verfahren als Architektur-Voraussetzungen für Cloud-Nutzung im Gesundheits-Sektor benannt. Was die Architektur-Linse ablehnt, ist der Reflex: die Annahme, dass der Standort allein die Souveränitäts-Frage beantwortet. Die Antwort liegt in der Tabelle der sieben Kontrollen; die Standort-Spalte gehört dort hinein, als ein Detail-Beitrag zur Subprozessor- und Personalstandort-Frage. Den Standort isoliert zu führen heißt, eine Variable doppelt zu zählen, die in den sieben Kontrollen ohnehin enthalten ist.

Die sieben Kontrollen als schriftliche Anbieter-Frage

Die Architektur-Linse ergibt eine Beschaffungs-Disziplin. Vor der nächsten KI-Anbieter-Bewertung empfiehlt sich, die sieben Kontroll-Fragen schriftlich an alle Anbieter im Vergleich gehen zu lassen — nicht als Begleit-Notiz im Anhang, sondern als Hauptteil der Anbieter-Antwort. Zur Schlüssel-Custody: Ist BYOK technisch und vertraglich vorgesehen, und wenn ja, in welcher Form wird die Custody durchgesetzt? Zum Regional-Containment: Sind Replikation, Backup, Failover und Logging nachweisbar in der kontrollierten Region? Zur Subprozessor-Liste: Ist sie gepinnt, mit Vorab-Informations-Pflicht vor jeder Hinzufügung? Zur Audit-Spur: Sie ist Append-only, kryptografisch verkettet, vertraglich zugesichert? Zur Datenexport-Garantie: In welchem Format, in welcher Frist, mit welcher Schema-Struktur? Zum Personalstandort: Auf welche Region ist der administrative Zugriff beschränkt, und sind außerhalb dieser Region liegende Sub-Beauftragungen ausgeschlossen? Zur Modell-Provenienz: Sind Trainingsdaten-Politik und Modell-Stand fixiert, sind Modell-Updates an Vorab-Information gebunden?

Die Übersetzung in andere Bezugsrahmen trägt

Die Architektur-Linse trägt auch außerhalb des deutschen Aufsichts-Kontexts. Außerhalb der DSGVO-Sphäre tragen die Bezugs-Standards andere Bezeichnungen — ISO/IEC 27018 für Cloud-Datenschutz, System and Organization Controls 2 Type II (SOC 2 Type II) für Service-Organisations-Audit, der EUCS-Entwurf für europäische Cloud-Souveränität, das US-amerikanische Federal Risk and Authorization Management Program (FedRAMP) für Bundes-Cloud-Beschaffung, die Network and Information Security Directive 2 (NIS-2) für kritische Infrastruktur. Die sieben Kontrollen sind in allen diesen Bezugsrahmen strukturell vorgesehen. Eine Architektur, die in einem dieser Standards die sieben Kontrollen einlöst, übersetzt sie meist mit überschaubarem Aufwand in die übrigen. Was zwischen ihnen variiert, ist die Audit-Verfahrens-Sprache; die operative Substanz variiert weit weniger. Im deutschen TI-Kontext sind die gematik-Spezifikationen zur Cloud-Nutzung an einigen Stellen enger gefasst als die generische Architektur-Linse — Subprozessor-Transparenz, Schlüsselverwaltung und Audit-Anforderungen sind auf TI-Komponenten zugeschnitten. Wer in der TI-Anbindung arbeitet, prüft die sieben Kontrollen zusätzlich gegen den TI-spezifischen Vertrags-Bezugsrahmen.

In der Beschaffungs-Realität zeigt sich der Unterschied schnell. Eine Klinik, die ihre Anbieter-Bewertung an den Standort-Reflex koppelt, kauft regelmäßig Anbieter mit guter Geografie und schwacher Architektur — und merkt das erst, wenn die Audit-Spur eines Vorfalls nicht eindeutig zu rekonstruieren ist oder eine Datenexport-Anfrage in einer informellen Verhandlung versandet. Eine architekturzentrierte Auswahl bewertet entlang der sieben Kontrollen und behandelt den Standort als zusätzliche Spalte derselben Tabelle. Ein eigenes 24/7-Sicherheits-Team, das jeden Patch zeitnah einspielt, jede Subprozessor-Beziehung dokumentiert und immutable Audit-Spuren technisch durchsetzt, überfordert die Klinik-IT-Strukturen außerhalb der größten Universitäts-Häuser strukturell.

Bemerkenswert ist, wie häufig die Standort-Spalte in der Anbieter-Tabelle die einzige ausgefüllte Spalte bleibt — auch dann, wenn die fragenden IT-Leitungen im Gespräch die Architektur-Linse selbst beherrschen. Die Tabelle ist ein altes Werkzeug für eine alte Frage; sie führt selbst dann zur Standort-Antwort, wenn die Person, die sie ausfüllt, weiß, dass die Antwort woanders liegt. Wer die sieben Kontrollen schriftlich abfragt, baut ein anderes Werkzeug — eines, in dem die Standort-Frage kleiner wird, weil die anderen Spalten endlich Platz haben.

Aiomics ist Cloud-Native auf europäischer Infrastruktur gebaut, mit BYOK, vertraglich gepinnten Subprozessoren und einer Audit-Spur, die per Konstruktion immutable ist. Diese Wahl ist die Konsequenz einer Architektur-Schule, in der die sieben Kontrollen Standard sind und nicht Sondermeinung. Sie ersetzt keine Anbieter-Prüfung; sie ist ein Datenpunkt, an dem sich die Linse einüben lässt. Was sie für die Klinik-IT-Leitung verändert, ist nicht die Auswahl-Entscheidung, sondern die Reihenfolge der Fragen. Die Standort-Spalte rückt nach hinten; die sieben Kontroll-Spalten rücken nach vorn. In dieser Reihenfolge ergibt sich eine Anbieter-Tabelle, die die Frage tatsächlich beantwortet, die sie zu beantworten vorgibt.

Wer Souveränität als Standort-Frage führt, beantwortet im Jahr 2026 eine Frage aus dem Jahr 2010 — und übersieht die sieben Spalten, an denen sie heute entschieden wird.