Datensouveränität vs. Datenresidenz: Was das EU Cloud Sovereignty Framework tatsächlich fordert

Datenresidenz in Europa ist nicht gleich Datensouveränität. Das EU Cloud Sovereignty Framework definiert acht Ziele und eine fünfstufige SEAL-Bewertung, um den Unterschied zu verdeutlichen – und die meisten Cloud-Verträge für Unternehmen erfüllen diese Anforderungen deutlich schlechter, als es das Marketing vermuten lässt.

Im Oktober 2025 veröffentlichte die Generaldirektion für digitale Dienste der Europäischen Kommission die Version 1.2.1 des EU Cloud Sovereignty Frameworks – der erste systematische Versuch, den Begriff «Souveränität» beim Kauf von Cloud-Diensten als messbare Zielvorgabe und nicht als Marketingversprechen zu definieren. Es stützt sich auf das Trusted Cloud Referential von CIGREF, Gaia-X, Leitlinien der ENISA sowie nationale Strategien wie die französische «Cloud de Confiance» und die deutsche souveräne Cloud.

Warum «Hosted in Europe» nicht gleich Datensouveränität ist

Das am häufigsten genutzte Souveränitätsargument im Cloud-Marketing ist die Datenresidenz: Deine Daten liegen in einem europäischen Rechenzentrum. Für viele Beschaffungs-Checklisten ist das bereits der gesamte Test. Das Framework betrachtet dies bestenfalls als Teilantwort auf eines von acht Zielen.

Dieses Ziel ist SOV-3 (Daten- & KI-Souveränität) – dabei geht es darum, wo Daten gespeichert und verarbeitet werden und ob Kund:innen die tatsächliche Kontrolle darüber behalten. Ein europäisches Rechenzentrum beantwortet nur die Frage, «wo die Daten gespeichert sind». Es sagt nichts darüber aus, ob die KI-Verarbeitung in Europa bleibt oder ob der Anbieter auf diese Daten zugreifen und sie für eigene Zwecke nutzen kann.

SOV-2 (Rechtliche & jurisdiktionelle Souveränität) stellt eine andere Frage: Welches Recht gilt für den Anbieter und welche Behörden können eine Offenlegung erzwingen? Hier wird der US CLOUD Act relevant – er erlaubt es US-Behörden, ein US-Unternehmen zur Herausgabe von Daten zu zwingen, unabhängig davon, wo diese physisch gespeichert sind. Ein europäisches Rechenzentrum, das von einem Anbieter mit Hauptsitz in den USA betrieben wird, bietet keinerlei rechtliche Abschirmung. Die Daten bleiben zwar in Europa, das rechtliche Risiko jedoch nicht.

Ein konkretes Beispiel: Anfang 2025 verlor der Chefankläger des Internationalen Strafgerichtshofs (IStGH) nach einer Executive Order der USA, die Beamte des IStGH sanktionierte, den Zugriff auf seine Microsoft-E-Mails – es handelte sich um institutionelle Infrastruktur, nicht um ein privates Postfach. Microsoft bestritt, direkt gehandelt zu haben; der genaue Hergang ist umstritten. Unbestritten ist jedoch: Eine bedeutende internationale Institution in Den Haag konnte sich in dem Moment nicht mehr auf einen US-Cloud-Anbieter verlassen, als US-amerikanische politische Interessen mit ihrem eigenen Mandat kollidierten. Bis Oktober 2025 hatte der IStGH seine Microsoft-Office-Suite vollständig durch in Deutschland entwickelte Open-Source-Software ersetzt.

Die 8 Souveränitätsziele und die SEAL-Bewertungsskala

Das Framework bewertet Anbieter anhand von acht Souveränitätszielen (SOV-1 bis SOV-8): strategische Eigentumsverhältnisse, rechtliche Zuständigkeit, Daten- & KI-Kontrolle, operative Unabhängigkeit, Transparenz der Lieferkette, technologische Offenheit, Sicherheitszertifizierung und Nachhaltigkeit. Jedes Ziel wird auf dem Sovereignty Effectiveness Assurance Level (SEAL) bewertet, von SEAL-0 (keine Souveränität) bis SEAL-4 (vollständige digitale Souveränität).

Die meisten grossen Anbieter mit Hauptsitz in den USA und Rechenzentren in der EU erreichen bei der Datenresidenz etwa SEAL-2 bis SEAL-3, fallen aber bei der rechtlichen Zuständigkeit aufgrund der CLOUD-Act-Problematik auf SEAL-0 oder SEAL-1 zurück und erreichen bei der strategischen Souveränität aufgrund der nicht-europäischen Eigentumsverhältnisse SEAL-0. Gemessen an dieser Skala wirkt eine Residenzgarantie deutlich weniger beruhigend als in einer Verkaufspräsentation.

Richtig eingesetzt ist das Framework kein «Bestanden/Nicht bestanden»-Filter, sondern ein Profil: Welches SEAL-Level erreicht ein Anbieter bei welchem Ziel, und welche Ziele sind für deinen regulatorischen Kontext am wichtigsten? Behörden gewichten SOV-1 bis SOV-3 meist stark; NIS2-regulierte Betreiber ergänzen SOV-7; DORA-regulierte Finanzinstitute fügen SOV-4 als Kontinuitätsanforderung hinzu.

Die KI-Verarbeitungslücke, die die meisten Verträge übersehen

Wissenstools, Kollaborationsplattformen und Produktivitätssuiten leiten Inhalte mittlerweile standardmässig durch LLMs – für Zusammenfassungen, semantische Suche oder KI-gestütztes Schreiben. Diese Verarbeitung läuft auf einer Infrastruktur, die vom KI-Anbieter kontrolliert wird, oft eine andere Einheit als der Plattformanbieter, unter anderen Rechtsvorschriften und zu anderen Bedingungen.

SOV-3 fragt explizit, ob die KI-Dienste einer Plattform unter europäischer Kontrolle entwickelt und gesteuert werden. Zu wissen, wo die SaaS-Plattform gehostet wird, reicht nicht mehr aus – du musst auch wissen, wo die KI-Verarbeitung stattfindet, wer der Anbieter ist und ob deine Inhalte als Trainingsdaten enden können. Die meisten Verträge beantworten dies nicht klar: KI-Funktionen werden meist als Zusatzdienste per Klick akzeptiert, ohne formale Datenprüfung. Für Organisationen unter DORA, NIS2, FINMA oder öffentlichen Vorschriften, die sich auf Souveränität beziehen, wird diese Lücke zunehmend zum Prüfungsthema.

Eigentum und Portabilität: SOV-1 und SOV-4

SOV-1 (Strategische Souveränität) steht über allen anderen Fragen: Wer ist der Eigentümer des Anbieters? Der Enterprise-Cloud-Markt folgt einem bekannten Muster – ein europäischer Anbieter mit starkem Souveränitätsprofil wird von einem strategischen US-Käufer übernommen. Die Rechenzentren ziehen nicht am ersten Tag um; aber die Struktur der juristischen Person ändert sich mit Abschluss des Deals, und damit auch die rechtliche Exponierung. SEAL-4 erfordert Eigentum, Governance und Finanzierung mit Sitz in Europa – eine Tochtergesellschaft einer nicht-europäischen Muttergesellschaft kann dies unabhängig vom Serverstandort nicht erreichen.

SOV-4 (Operative Souveränität) fragt, ob du Workloads betreiben, unterstützen und migrieren kannst, ohne von der ständigen Kooperation des Anbieters abhängig zu sein. Viele Verträge bieten den Anschein von Portabilität ohne Substanz: Eine Exportfunktion, die vor der Verwendung anderswo aufwendig nachbearbeitet werden muss, oder eine Authentifizierungs- und Integrationsarchitektur, die schwer bei einem anderen Anbieter zu replizieren ist. Das Framework prüft, ob Self-Hosting oder On-Premise-Bereitstellung überhaupt möglich sind und ob die Dokumentation ausreicht, um unabhängig zu agieren.

Warum das für das Wissensmanagement so wichtig ist

Wikis und Wissensplattformen beherbergen die sensibelsten und am wenigsten ersetzbaren Inhalte einer Organisation – strategische Pläne, Sicherheitsdokumentationen, Audit-Nachweise und interne Grundsatzentscheidungen. Was sich über drei bis fünf Jahre ansammelt, ist in der Summe oft sensibler als jeder einzelne Dateispeicher. Eine erzwungene Offenlegung gemäss CLOUD Act bei einem Projekt-Tracker ist störend; bei der Plattform, die dein gesamtes institutionelles Gedächtnis enthält, ist das ein völlig anderes Risikoniveau.

Hier entsteht auch durch KI das grösste Konzentrationsrisiko. Wenn ein Wiki seinen gesamten Datenbestand für die semantische Suche indexiert – was zunehmend zum Standard wird –, durchläuft jedes Dokument die KI-Pipeline. Die Frage, wo diese Pipeline läuft und welchem Recht sie unterliegt, wird damit zur entscheidenden Souveränitätsfrage für diesen Bereich.

Sechs Fragen vor deiner nächsten Vertragsverlängerung

• Wer ist Eigentümer dieses Anbieters und würde eine nicht-europäische Übernahme unser rechtliches Risiko verändern? (SOV-1, SOV-2)

• Unterliegt der Anbieter oder ein Mutterunternehmen dem US CLOUD Act oder einer vergleichbaren Gesetzgebung? (SOV-2)

• Wo findet die KI-Verarbeitung statt, unter welcher Gerichtsbarkeit, und können unsere Inhalte für das Training verwendet werden? (SOV-3)

• Ist eine selbst gehostete oder On-Premise-Bereitstellung verfügbar, inklusive Dokumentation für den eigenständigen Betrieb? (SOV-4)

• Sind alle Unterauftragsverarbeiter dokumentiert und innerhalb der europäischen Gerichtsbarkeit ansässig? (SOV-5)

• Können wir alle unsere Daten in Standardformaten exportieren, die ohne proprietäre Tools wieder importierbar sind? (SOV-4, SOV-6)

Anbieter, die mit Dokumentation statt mit Marketing-Sprech antworten, zeigen dir, wie die Zusammenarbeit in der Praxis wirklich aussehen wird.

Phonemos: SEAL-4 bei sechs von acht Zielen

Das Framework wurde von und für die EU geschrieben. Die Schweiz ist kein Mitglied, und ein Schweizer Anbieter erfüllt nicht die Definition von SOV-1 als Anker eines europäischen Ökosystems – das sollte man offen sagen, statt zu viel zu versprechen. Aber das zugrunde liegende Anliegen ist nicht rein europäisch: Wo immer kritische Software im Besitz einer grossen geopolitischen Macht ist und deren Gesetzen unterliegt, werden deren Interessen zu einer operativen Variable in deiner Infrastruktur. Der IStGH-Vorfall verdeutlicht ein Muster, keine rein europäische Lektion.

Phonemos wird in Bern, Schweiz, entwickelt und betrieben, unter Schweizer Recht. Es sind keine US-Unternehmen an der Plattform oder deren Standardinfrastruktur beteiligt, und der CLOUD Act findet keine Anwendung. Unsere Selbsteinschätzung gemäss dem EU Cloud Sovereignty Framework ergab SEAL-4 bei sechs von acht Zielen. Für europäische Käufer ist der Nicht-EU-Status der Schweiz eine Nuance. Für Käufer überall sonst ist er oft ein entscheidender Vorteil.

Das Fazit

Datenresidenz war nie die vollständige Antwort auf Datensouveränität – sie sah auf einer Landkarte nur so aus. Frag, wem dein Anbieter gehört, welchem Recht er untersteht, wo die KI-Verarbeitung tatsächlich stattfindet und ob du gehen kannst, wenn es nötig ist. Frag vor der Verlängerung, nicht erst, wenn dich ein Vorfall dazu zwingt. Buche jetzt deine Demo!