Editionsgeschichte
LesenKontrolle lässt sich nicht versprechen · Ausgabe 2
SHA-256: 8bdde32db151914a62fe9b98ca954e843754260b01dbb3370c855ab5cfe0743c
Ein Anbieter kann versprechen, Ihre Daten nicht herauszugeben. Er kann dieses Versprechen in einen Vertrag schreiben. Er kann in Ihrem Land ein Rechenzentrum bauen, eine lokale Geschäftsleitung einsetzen und seinen Dienst souverän nennen.
Dann fragt jemand, was geschieht, wenn eine andere Regierung eine rechtmässige Anordnung erlässt.
Am 10. Juni 2025 wurde Anton Carniaux, Direktor für öffentliche Angelegenheiten und Recht bei Microsoft in Frankreich, vor einer Untersuchungskommission des französischen Senats gefragt, ob er garantieren könne, dass Daten, die Microsoft über das öffentliche Beschaffungswesen Frankreichs anvertraut wurden, niemals ohne ausdrückliche Zustimmung der französischen Behörden an amerikanische Behörden gehen würden.
Seine Antwort war kurz: **«Non, je ne peux pas le garantir.»** Er fügte an, nach Darstellung von Microsoft sei eine solche Übermittlung in den besprochenen Fällen nicht vorgekommen. [^1]
Die Antwort bewies nicht, dass Microsoft Daten herausgegeben hatte. Sie zeigte, wo eine Garantie endet.
Hier wird das Wort *souverän* interessant.
**Hängt eine Fähigkeit von der Erlaubnis eines anderen ab, kann sie geschützt, reguliert oder widerstandsfähig sein. Wo ihre Unabhängigkeit aufhört, muss trotzdem erst festgestellt werden.**
## 1. Eine ehrliche Antwort im falschen Moment
An der Anhörung vom 10. Juni beschrieb Anton Carniaux, wie Microsoft Anordnungen prüft und anficht. Er bestritt, dass Microsoft die Cloud-Dienste des Internationalen Strafgerichtshofs abgeschaltet habe. Das Protokoll ist als Aussage zu lesen, nicht als Beweis für eine behauptete umfassendere Abschaltung. [^1]
Als man ihn bat zu garantieren, dass Daten bei einer gültigen amerikanischen Anordnung nie ohne Zustimmung der französischen Behörden herausgegeben würden, verweigerte er eine Garantie, die er nicht hätte halten können.
Das ist kein Eingeständnis einer früheren Übermittlung. Es beweist auch nicht, dass jedes Produkt und jede Konfiguration von Microsoft gleich exponiert ist.
Es ist die Begegnung zweier Sprachen.
Die eine ist die Sprache des Marketings: Der Dienst ist sicher, lokal, regelkonform, widerstandsfähig, souverän.
Die andere ist die Sprache der Hoheitsgewalt: Eine bestimmte Regierung kann gegen eine bestimmte juristische Person ein bestimmtes Rechtsinstrument einsetzen, und diese Person muss unter Umständen handeln.
Das amerikanische Gesetz ist ungewöhnlich deutlich. Titel 18, Abschnitt 2713, eingefügt durch den CLOUD Act, regelt Herausgabepflichten für Material, das sich im Besitz, im Gewahrsam oder unter der Kontrolle eines erfassten Anbieters befindet, gleichgültig, ob es innerhalb oder ausserhalb der Vereinigten Staaten liegt. [^2]
Das Gesetz sagt nicht, dass jeder Server in Europa amerikanischen Behörden automatisch offensteht. Ebenso wenig verschwinden die damit verbundenen amerikanischen Rechtspflichten, nur weil ein Server auf europäischem Boden steht.
Die endgültigen Leitlinien des Europäischen Datenschutzausschusses vom Juni 2025 zu Artikel 48 DSGVO behandeln gesondert, unter welchen Bedingungen Organisationen Ersuchen von Behörden aus Drittstaaten rechtmässig beantworten dürfen. Genau wegen dieser rechtlichen Schnittstelle lässt sich Rechtshoheit nicht auf eine Stecknadel auf der Landkarte reduzieren. [^3]
Die praktische Frage lautet weder «Vertrauen wir den Amerikanern?» noch «Vertrauen wir den Europäern?».
Sie lautet: **Wer hat durchsetzbare Rechte oder praktische Möglichkeiten, etwas geschehen zu lassen, und was hält ihn davon ab?**
## 2. Ein Versprechen kann etwas wert sein, ohne absolut zu sein
Eine ernsthafte Analyse muss fair beschreiben, was Microsoft tatsächlich gebaut und zugesagt hat.
Im April 2025 kündigte Microsoft fünf digitale Zusagen an Europa an, darunter eine europäische Steuerung des Betriebs, zusätzliche Kapazität, Verpflichtungen zum Datenschutz und das Versprechen, Anordnungen zur Aussetzung des europäischen Cloud-Betriebs anzufechten. Laut dem Zwischenbericht von 2026 steht die Zusage zur Widerstandsfähigkeit inzwischen in Verträgen mit europäischen Regierungen und der Kommission. Das sind gewichtige geschäftliche und rechtliche Bestimmungen, nicht nichts. [^4][^5]
Microsoft beschreibt zudem eine EU Data Boundary für bestimmte Unternehmensdienste. Die eigene Dokumentation erklärt, dass die Zusage festgelegte Datenkategorien und Dienste umfasst und dass es begrenzte Fälle gibt, in denen Informationen trotzdem ausserhalb der geografischen Grenze übertragen oder aus der Ferne eingesehen werden können. Diese Feinheit gehört neben die Schlagzeile. [^6]
Und im Februar 2026 gab Microsoft die weltweite Verfügbarkeit von Azure Local disconnected operations und Microsoft 365 Local im getrennten Betrieb bekannt, mit lokalen KI-Modellen für ausgewählte Kunden. Eine wirklich vom Netz getrennte Architektur kann das Betriebsrisiko einer äusseren Abschaltung verändern. Es ist intellektuell nicht vertretbar, eine abgeschottete Installation so zu behandeln, als sei sie zwangsläufig dasselbe wie weltweit verwaltete SaaS. [^7][^8]
Eine Käuferin sollte deshalb mindestens drei technische Lagen unterscheiden:
- **Verbundene Public Cloud.** Verwaltete Infrastruktur mit lokaler Datenhaltung und zusätzlichen Kontrollen; die Abhängigkeit vom übrigen Cloud-Betrieb des Anbieters bleibt.
- **Lokal oder von einem Partner betriebener Dienst.** Andere vertragliche und organisatorische Grenzen; die darunterliegende Steuerungsebene, Lizenzen, Patches und Zugriffswege müssen genau geprüft werden.
- **Vom Netz getrennte private Installation.** Bestimmte Arbeitslasten können ohne Cloud-Verbindung eher weiterlaufen; Softwareberechtigungen, Nachschub an Updates, Ersatzteile, Support und langfristige Wartung müssen trotzdem getestet werden.
Das sind erklärende Kategorien, keine Einstufung und keine unabhängige Zertifizierung einzelner Microsoft-Produkte.
Die pauschale Aussage, Microsoft könne nie souveräne Fähigkeiten liefern, wäre ebenso leichtfertig wie die Behauptung, jeder Microsoft-Dienst mit europäischem Rechenzentrum sei souverän.
Entscheidend ist, *welche Kontrolle, unter welchen Bedingungen, wie lange*.
## 3. Der Moment, in dem Europa das Wort nicht mehr eindimensional behandelte
Am 17. April 2026 gab die Europäische Kommission vier Zuschläge für souveräne Cloud-Dienste bekannt, die Einrichtungen der Union im Rahmen eines Vertragswerks von bis zu 180 Millionen Euro über sechs Jahre nutzen können. Zum Zug kamen eine Partnerschaft von Post Telecom, OVHcloud und CleverCloud, STACKIT, Scaleway sowie ein von Proximus geführtes Konsortium mit S3NS, Clarence und Mistral, das auch Technik nutzt, die von Google Cloud abgeleitet ist. [^9]
Der Entscheid ist nützlich, weil er zwei bequeme Erzählungen durchkreuzt.
Europa hat nicht beschlossen, dass Souveränität erreicht ist, sobald jede amerikanische Technik ausgeschlossen ist. Es hat ebenso wenig beschlossen, dass eine europäische Postadresse genügt.
Die Kommission wandte einen Cloud Sovereignty Framework an. Im Juni 2026 erläuterte sie, dass dieses Regelwerk 48 festgelegte Kriterien in acht Souveränitätszielen zusammenfasst: strategisch; rechtlich und hoheitlich; Daten und KI; betrieblich; Lieferkette; technologisch; Sicherheit und Compliance; ökologische Nachhaltigkeit. [^10]
Der Ansatz unterscheidet zudem Sovereignty Effectiveness Assurance Levels, kurz SEAL. Die Kommission beschreibt SEAL-2 als Datensouveränität, SEAL-3 als höhere Stufe technologischer Autonomie oder Widerstandsfähigkeit und SEAL-4 als volle Souveränität nach ihren Definitionen. Für die Ausschreibung von 2026 war mindestens SEAL-2 verlangt; die drei Angebote mit vorwiegend europäischer Technik erreichten SEAL-3, das Konsortium mit Google-Cloud-Technik SEAL-2, so die Kommission. [^9]
<figure>
<img src="/api/media/field-notes/control-cannot-be-promised-f01-de-1b285df3d15185b576479e72e4b316ec991f59150249658d3940100f9e5332ba.webp" alt="Drei Karten. SEAL-2, Datensouveränität: Mindeststufe der Ausschreibung 2026; Konsortium unter Führung von Proximus mit Diensten von S3NS auf Google-Cloud-Technik. SEAL-3, technologische Autonomie: drei Zuschläge, Konsortium um Post Telecom, STACKIT und Scaleway. SEAL-4, volle Souveränität: höchste Stufe; kein Zuschlag gemeldet." />
<figcaption>Abbildung 1. Souveränität wird zum Beschaffungskriterium. Die Sovereignty Effectiveness Assurance Levels (SEAL) nach Definition der Europäischen Kommission und die vier Zuschläge für souveräne Cloud-Dienste vom April 2026: SEAL-2 war das Minimum; drei Zuschläge erreichten SEAL-3; ein SEAL-4-Zuschlag ist nicht gemeldet. Stufen laut Kommission, keine eigene Prüfung des Autors. Quelle: Europäische Kommission, 17. April und 1. Juni 2026.</figcaption>
</figure>
Diese Entwicklung ist wichtig. Beschaffungsstellen haben nun ein ausdrückliches Vokabular, Abstufungen und ein dokumentiertes Verfahren, um Belege zu verlangen.
Doch hier liegt die Unterscheidung, an der ich festhalten will: Ein Beschaffungsrahmen misst einen Anbieter an festgelegten Kriterien. Er beweist nicht, dass jedes Szenario jenseits dieser Kriterien ausgeschlossen ist, und auch nicht, dass eine heutige Bewertung nach einer Übernahme, einer neuen Regulierung oder einem Umbau der Plattform nicht veraltet.
Eine Punktzahl hilft beim Entscheiden.
Sie treibt die Abhängigkeit nicht aus.
## 4. Das fehlende Wort heisst *Beleg*
Wir wissen bereits, dass Eigentum, Ausstiegsfähigkeit und betriebliche Widerstandskraft zählen. Meine früheren Bände *The Sovereignty Gap*, *Open Is Not Sovereign* und *The Exit Test* nähern sich diesen Fragen aus verschiedenen Richtungen. [^11][^12][^13]
Dieser Essay fragt enger und vielleicht unbequemer.
Wie soll eine Kundin die Souveränitätsversprechen eines Anbieters prüfen, bevor sie ihm kritische Systeme anvertraut?
Ich schlage drei Schritte vor. Sie gelten für europäische, schweizerische und amerikanische, für öffentliche und private Anbieter gleichermassen.
### Versprechen
Schreiben Sie das Versprechen als beobachtbare Aussage auf, mit Geltungsbereich und Dauer. Nicht «unsere Cloud ist souverän». Sondern: «Für diese Dienstversion und diese Datenkategorie werden alle Schlüssel, die zum Lesen von Kundendaten nötig sind, unter ausschliesslicher Verwaltung der Kundin erzeugt und aufbewahrt, ohne ständigen Zugriff des Anbieters.» Das Beispiel ist eine Frage, die zu prüfen ist, keine Aussage über einen bestimmten Anbieter.
Ein anderes Versprechen kann Rechtshoheit, Betrieb, Zugang zum Quellcode, Firmware, Identität, Netzwerk oder die Befugnisse von Unterauftragnehmern betreffen. Wer das alles unter ein einziges Eigenschaftswort packt, macht eine sinnvolle Prüfung unmöglich.
### Kontrolle
Halten Sie fest, wer die versprochene Grenze aufheben kann.
Wer kann einen Schlüssel wechseln oder wiederherstellen? Wer kann die Steuerungsebene verändern? Wer kann ein Abonnement oder eine Lizenz sperren? Wer kann die Identitätsverwaltung abschalten? Wer kann notwendige Updates verweigern? Wer kann eine Übermittlung erzwingen? Wer kontrolliert die Konzernstruktur einer nominell lokalen Betriebsgesellschaft?
Dass ein Anbieter etwas *üblicherweise nicht tut*, heisst nicht, dass er es *nicht tun kann*.
Und dass er es *tun kann*, bedeutet noch keinen Missbrauch. Es markiert eine Grenze der Befugnisse, die gegen das Bedrohungsmodell abzuwägen ist.
### Beleg
Verlangen Sie den stärksten Beleg, der dem Risiko angemessen ist.
Manche Belege sind Dokumente: Gesetze, Eigentumsnachweise, Verzeichnisse der Unterauftragsverarbeiter, Vertragsbedingungen, der Umfang unabhängiger Audits, Architekturbeschreibungen und veröffentlichte Einschränkungen.
Manche müssen technisch sein: unabhängig verwahrte Schlüssel, das Verhalten des Dienstes im getrennten Betrieb, Wiederherstellungsverfahren, signierte Artefakte, Prüfprotokolle für die Kundin, bezeugte Umschaltübungen und die Überprüfung der Grenzen administrativer Zugriffe.
Manche müssen organisatorisch sein: benannte Entscheidungsbefugte, Verlängerungsrechte, getrennte Administratoren, dokumentierte Eskalation, bezifferte Kontinuitätspläne und Prüfzyklen.
Das ist keine einzelne Checkliste, die für jeden Dienst passt. Es ist die Forderung, jeder versprochenen Eigenschaft ein Mittel gegenüberzustellen, mit dem man sie widerlegen könnte.
<figure>
<img src="/api/media/field-notes/control-cannot-be-promised-f02-de-dd308dbd07e3fbf8e489040114361af7594628ab3dd69b348edfa0ac5b310c4d.webp" alt="Drei verbundene Karten. 01 Versprechen: eine begrenzte, widerlegbare Aussage (welcher Dienst, welche Daten, welche Zeit und Bedingungen). 02 Kontrolle: wer das Versprechen aufheben kann (zugreifen, ändern, erzwingen, widerrufen, abschalten). 03 Beleg: Nachweis ohne Wohlwollen (Tests, Recht, Aufzeichnungen, Schlüssel, unabhängige Zeugen)." />
<figcaption>Abbildung 2. Versprechen, Kontrolle, Beleg. Die eigene Prüfmethode des Autors: ein begrenztes Versprechen, die Instanz, die es aufheben kann, und ein Nachweis, der ohne das Wohlwollen des Anbieters trägt. Zu wiederholen, wenn sich Verträge, Technik, Betreiber oder Rechtsordnungen ändern. Redaktionelle Methode, keine SEAL-Zertifizierung der EU und kein Rechtsgutachten.</figcaption>
</figure>
Der Massstab der Methode ist absichtlich unbequem: Wenn der Anbieter morgen nicht mehr mitwirkte, welche Belege könnten die Kundin oder eine unabhängige Prüfstelle dann noch verwenden?
Diese Frage ist keine Anschuldigung. Sie ist eine Anforderung an die Architektur.
## 5. Der Beleg muss veränderte Umstände überstehen
Man denke an das Dokumentensystem eines Spitals, die E-Mail-Plattform einer Gemeinde oder die Steuerung einer Industrieanlage.
Ein Anbieter kann ehrlich vorhaben, einen Dienst über Jahrzehnte zu betreiben. Eine Regierung kann ehrlich vorhaben, nie eine Unterbrechung anzuordnen. Ein technisches Team kann ehrlich vorhaben, seine Schnittstellen nie inkompatibel zu ändern.
Keine dieser Absichten ist eine Garantie für die Zukunft.
Eine Institution muss wissen, welche Eigenschaften sie unabhängig durchsetzen kann und welche weiterhin von geschäftlicher und politischer Kontinuität abhängen.
Der Unterschied lässt sich in fünf Fragen für die Beschaffung fassen:
**Wo?** Welche Daten und Verarbeitungsfunktionen liegen physisch wo, und wohin wandern Ausnahmen, Supportwege und Metadaten?
**Wer?** Welche Stellen können über die betroffenen Schichten gesellschaftsrechtliche, rechtliche oder technische Befugnisse ausüben?
**Wie?** Welche tatsächlichen Mechanismen ziehen die Grenze – von der Kundin gehaltene Schlüssel, getrennte Steuerungsebenen, unabhängige Identität, Trennung vom Netz, Zugang zum Quellcode oder durchsetzbare Governance?
**Belegen Sie es.** Welche Nachweise lassen sich einsehen, von wem, wie oft, mit welchen Zugriffsrechten und mit welchen Einschränkungen?
**Was ändert sich?** Welche Annahmen fallen, wenn der Anbieter übernommen, sanktioniert, abgeschnitten, gezwungen wird, in Konkurs geht oder ein Produkt schlicht nicht mehr liefert?
<figure>
<img src="/api/media/field-notes/control-cannot-be-promised-f03-de-7f34f7b08536195ceb9fa60bb1fb9a20dc0281369e79f74f095e66a5efed92f4.webp" alt="Sechs Karten in zwei Reihen: 01 Standort, wo Daten und Arbeitslasten liegen; 02 Rechtshoheit, welche Gesetze Handlungen erzwingen können; 03 Betrieb, wer verwalten oder abschalten kann; 04 Schlüssel, wer tatsächlich entschlüsseln kann; 05 Technik, welche Lieferanten den Stack tragen; 06 Kontinuität, was unabhängig weiterläuft." />
<figcaption>Abbildung 3. Ein Standort ist keine Steuerungsebene. Sechs Eigenschaften, die innerhalb eines einzigen «souveränen» Angebots verschieden ausfallen können: Standort, Rechtshoheit, Betrieb, Schlüssel, Technik, Kontinuität. Redaktionelle Einteilung; die Eigenschaften sind nicht austauschbar, kein Anbieter wird bewertet.</figcaption>
</figure>
Diese Fragen setzen keine Vorliebe für lokale Anbieter voraus. Ein fähiger ausländischer Anbieter kann ein bestimmtes Bedrohungsmodell besser erfüllen als ein unreifes einheimisches Angebot. Geografie darf schwache Sicherheit nicht verdecken, und Souveränität ist nicht mit Spitzenleistung in jeder technischen Hinsicht zu verwechseln.
Umgekehrt gilt dasselbe: Bessere Funktionen, Zuverlässigkeit, Compliance-Zertifikate oder tiefe Preise beantworten die Frage der Unabhängigkeit nicht.
Die Leitlinien des NIST zum Lieferkettenrisiko behandeln die Probleme der Sichtbarkeit und Kontrolle, die entstehen, wenn Systeme von Organisationen jenseits ihres Betreibers abhängen. Sie bieten eine nützliche Disziplin, zertifizieren aber kein bestimmtes Versprechen einer souveränen Cloud. [^14]
## 6. Rechte zählen; Proben auch
Der Data Act der EU enthält Massnahmen, die vertragliche, technische und kommerzielle Hürden beim Wechsel zwischen Datenverarbeitungsdiensten abbauen sollen. Er sieht vor, dass Wechselentgelte ab dem 12. Januar 2027 entfallen, vorbehaltlich seiner Bedingungen und Ausnahmen. [^15]
DORA gilt für bestimmte Finanzunternehmen. Die Verordnung verlangt Ausstiegsstrategien für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen, sowie angemessene Tests und regelmässige Überprüfung. Sie gilt nicht unterschiedslos für jede europäische Organisation. [^16]
Weder ein Recht auf Wechsel noch eine Vertragsklausel macht ein System auf einen Schlag übertragbar. Diesem Problem bin ich in *The Exit Test* ausführlich nachgegangen. [^11]
Neu ist hier: **Der Beleg für die versprochene Kontrolle sollte während der ganzen Lieferbeziehung vorhanden sein** und nicht erst in der Notlage zum ersten Mal beschafft werden.
Für einen kritischen Dienst sollte die Beschaffung festlegen:
- ein versioniertes Verzeichnis der Souveränitätsversprechen und ihrer Grenzen;
- für jedes Versprechen und jeden Beleg eine verantwortliche Person;
- die Umstände, unter denen ein Versprechen neu zu beurteilen ist;
- unabhängige Prüfungen oder bezeugte Übungen, dem Risiko angemessen;
- einen dokumentierten Umgang mit Unbekanntem und mit Ausnahmen; und
- einen Beschluss auf Ebene der Geschäftsleitung, welche Abhängigkeiten bewusst in Kauf genommen wurden.
Das ist ein Vorschlag für gute Governance, keine Behauptung, das europäische Recht schreibe diese sechs Punkte überall wörtlich vor.
Eine robuste Organisation kann nicht souveräne Bestandteile bewusst in Kauf nehmen. Das Versagen liegt nicht immer in der Abhängigkeit. Manchmal liegt es darin, nicht zu wissen, **welche Art von Abhängigkeit man eingekauft hat**.
## 7. Weder Fahnen noch Zynismus
Die Debatte über Souveränität birgt eine politische Gefahr.
Eine Fahne kann die technische Analyse ersetzen. Ein Betreiber kann seinen Sitz in Europa haben und doch von Software, Schlüsseln, Identität, Firmware oder Kapital abhängen, die anderswo kontrolliert werden. Ein Cloud-Produkt kann lokal betrieben werden, während wichtige Fähigkeiten von einem äusseren Lieferanten abhängen.
Ebenso gefährlich ist es aber, jede vertragliche und technische Verbesserung als Öffentlichkeitsarbeit abzutun. Eine vom Netz getrennte Arbeitslast, ein lokal kontrollierter Schlüssel oder eine wirklich unabhängige Betriebsorganisation können echte Risiken verringern. Solche Schutzmassnahmen mögen unvollständig sein und sich trotzdem lohnen.
Wir sollten auch nicht aus einer Frage der amerikanischen Rechtshoheit die Annahme machen, europäische Staaten erzwängen nie eine Herausgabe. Auch europäische Anbieter unterstehen dem Recht. Es geht nicht darum, ein Land zu finden, das angeblich keine Macht über Daten hat. Es geht darum, die einschlägigen rechtmässigen Zugriffswege, Rechtskonflikte, Schutzmechanismen und die Kontrolle der Kundin im konkreten Fall zu bestimmen.
Die stärkste Sprache in einer Ausschreibung beginnt nicht mit der Nationalität eines Anbieters.
Sie beginnt mit der Frage, was ein System überstehen soll.
Ein multinationales Beratungsunternehmen, das Marketingunterlagen verschiebt, hat ein Bedrohungsmodell. Ein nationales Notfallkommunikationssystem hat ein anderes. Ein Archiv mit besonders schützenswerten Personendaten vielleicht wieder ein anderes.
Sie müssen nicht alle dieselbe Stufe von Souveränität kaufen. Aber sie müssen wissen, welche Stufe sie beanspruchen.
## 8. Was überlebt den Anbieter?
Das Versprechen eines Anbieters kann ernst gemeint und in seinem Rahmen rechtlich durchsetzbar sein. Ein Vertrag kann Anreize verändern. Ein unabhängiges Audit kann die Sicherheit erhöhen. Eine Bewertung in der Beschaffung kann Alternativen vergleichbar machen. Nichts davon ist wegzuwerfen.
Der Fehler besteht darin, eines davon für die endgültige Antwort zu halten.
Wenn wir es mit digitaler Souveränität ernst meinen, müssen die Belege stark genug sein, um einen Streit über das Etikett zu überstehen.
Fragen Sie die Architektin, was noch funktioniert, wenn die Verbindung wegfällt.
Fragen Sie den Juristen, was geschieht, wenn zwei Rechtsordnungen sich widersprechen.
Fragen Sie den Betrieb, wer die administrative Befugnis hat.
Fragen Sie das Sicherheitsteam, was sich unabhängig prüfen lässt.
Fragen Sie die Einkäuferin, welches Ausfallszenario es rechtfertigte, für diese Kontrollen zu bezahlen.
Und bitten Sie alle fünf, dasselbe klar umgrenzte Versprechen zu unterschreiben.
Dann beginnt das Eigenschaftswort etwas zu bedeuten.
Ein Anbieter kann Widerstandsfähigkeit versprechen. Er kann versprechen, gegen eine Anordnung zu kämpfen. Er kann versprechen, die Infrastruktur zu unterhalten. Solche Versprechen können viel wert sein.
Doch die folgenreichsten Eigenschaften der Souveränität sind keine Versprechen, die man bewundert. Es sind **Grenzen, die man nachweist**.
**Kontrolle lässt sich nicht herbeiversprechen. Man muss sie zeigen.**
## Methode und Grenzen
Stand der Recherche: 14. Oktober 2026. Nur öffentliche Quellen: Für diesen Essay gab es keinen Zugang zu einem Kundenkonto eines Anbieters, zu Verträgen, zur Prüfung von Schlüsseln, zu einer Übung im getrennten Betrieb oder zu einem unabhängigen SEAL-Test.
- Die Aussage vor dem Senat betrifft einen möglichen rechtlichen Zwang und die von Microsoft beschriebenen Verfahren; sie ist **kein** Beleg für eine tatsächliche unerlaubte Übermittlung zulasten der besprochenen Kunden.
- Die Anhörung im französischen Senat fand laut Primärprotokoll am **10. Juni 2025** statt; manche Sekundärberichte nennen ein anderes Datum. Massgeblich ist das Primärprotokoll.
- Die rechtliche Exposition unter dem CLOUD Act hängt von der jeweiligen Gesellschaft, der Architektur, den Zugriffsrechten und den Umständen ab; eine unabhängig betriebene, vollständig vom Netz getrennte Installation ist nicht automatisch wie ein gewöhnlicher Hyperscale-Clouddienst zu behandeln.
- Die veröffentlichten SEAL-Einstufungen der Kommission beruhen auf ihrer eigenen Methode und sind keine unabhängigen Feldtests für diesen Essay.
- Die EU-Institutionen und die Schweiz haben unterschiedliche Rechts- und Beschaffungsordnungen; der EU-Rahmen kann eine Schweizer Analyse anregen, ist aber nicht automatisch Schweizer Recht.
- «Versprechen, Kontrolle, Beleg» ist ein eigener redaktioneller Rahmen, kein anerkannter Zertifizierungsstandard und kein Ersatz für Beratung in Beschaffung, Recht oder Sicherheit.
## Quellen
[^1]: Sénat (Frankreich), Untersuchungskommission zum öffentlichen Beschaffungswesen, Anhörung von Anton Carniaux und Pierre Lagarde (Microsoft France), 10. Juni 2025. [Compte rendu de la semaine du 9 juin 2025](https://www.senat.fr/compte-rendu-commissions/20250609/ce_commande_publique.html). Aussage unter Eid: «Non, je ne peux pas le garantir, mais, encore une fois, cela ne s’est encore jamais produit.» Im selben Protokoll bestreitet er, dass Microsoft die Dienste des IStGH abgeschaltet habe. Kein Beleg für eine tatsächliche Übermittlung.
[^2]: United States Code, Titel 18, §2713, eingefügt durch den CLOUD Act (Pub. L. 115–141), 23. März 2018. [18 U.S.C. 2713 – Required preservation and disclosure of communications and records](https://www.govinfo.gov/content/pkg/USCODE-2024-title18/html/USCODE-2024-title18-partI-chap121-sec2713.htm). Besitz, Gewahrsam oder Kontrolle, unabhängig vom Speicherort; Rechtsweg und konkrete Umstände bleiben massgeblich.
[^3]: Europäischer Datenschutzausschuss, 5. Juni 2025 (endgültige Fassung 2.1). [Guidelines 02/2024 on Article 48 GDPR](https://www.edpb.europa.eu/documents/guideline/guidelines-022024-on-article-48-gdpr_en). Wie Organisationen auf Ersuchen von Behörden aus Drittstaaten antworten dürfen; kein pauschales Verbot.
[^4]: Brad Smith, Microsoft, 30. April 2025. [Microsoft announces new European digital commitments](https://blogs.microsoft.com/on-the-issues/2025/04/30/european-digital-commitments/). Fünf Zusagen, darunter die Digital Resilience Commitment, Anordnungen zur Aussetzung oder Einstellung des Cloud-Betriebs in Europa anzufechten. Ein Versprechen, kein erprobtes Ergebnis.
[^5]: Microsoft, 29. April 2026. [One year on: Progress on our European digital commitments](https://blogs.microsoft.com/on-the-issues/2026/04/29/one-year-on-progress-on-our-european-digital-commitments/). Gibt an, die Digital Resilience Commitment sei in Verträgen mit europäischen Regierungen und der Europäischen Kommission rechtlich bindend. Eigene Angabe des Unternehmens.
[^6]: Microsoft Learn, geprüft am 14. Oktober 2026. [What is the EU Data Boundary?](https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn/) und [Continuing data transfers that apply to all EU Data Boundary Services](https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-transfers-for-all-services). Geltungsbereich und dokumentierte Ausnahmen, darunter Fernzugriff durch Personal ausserhalb der Grenze; je nach Dienst verschieden und veränderlich.
[^7]: Microsoft Learn, geprüft am 14. Oktober 2026. [What is Microsoft Sovereign Cloud?](https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/microsoft-sovereign-cloud). Beschreibung des Anbieters von Sovereign Public Cloud, Sovereign Private Cloud und National Partner Clouds; im Einzelfall zu prüfen.
[^8]: Douglas Phillips, Microsoft, 24. Februar 2026. [Microsoft Sovereign Cloud adds governance, productivity and support for large AI models securely running even when completely disconnected](https://blogs.microsoft.com/blog/2026/02/24/microsoft-sovereign-cloud-adds-governance-productivity-and-support-for-large-ai-models-securely-running-even-when-completely-disconnected/). Azure Local disconnected operations und Microsoft 365 Local disconnected «now available worldwide»; grosse Modelle auf Foundry Local für ausgewählte Kunden. Ankündigung des Anbieters, kein unabhängiger Test.
[^9]: Europäische Kommission, GD Digitale Dienste, 17. April 2026. [Commission advances cloud sovereignty through strategic procurement](https://commission.europa.eu/news-and-media/news/commission-advances-cloud-sovereignty-through-strategic-procurement-2026-04-17_en). Vier Zuschläge, bis zu 180 Millionen Euro über sechs Jahre (Obergrenze, keine Ausgaben), Minimum SEAL-2, drei Zuschläge auf SEAL-3, Proximus/S3NS auf SEAL-2. Bewertung der Kommission selbst.
[^10]: Europäische Kommission, GD Digitale Dienste, 1. Juni 2026. [Sovereign Cloud Framework explained](https://commission.europa.eu/news-and-media/news/sovereign-cloud-framework-explained-2026-06-01_en). 48 Kriterien in acht Zielen, zwei sich ergänzende Bewertungen (SEAL und Gesamtwert). Eine Beschaffungsmethode, keine allgemeine Zertifizierung.
[^11]: Thierry Gilgen, The Library, Vol. 22, 10. August 2026. [The Exit Test](https://www.thierry-gilgen-ict.ch/field-notes/the-exit-test). Ob eine Institution aussteigen, wiederherstellen und weiterarbeiten kann.
[^12]: Thierry Gilgen, The Library, Vol. 65, 9. Oktober 2026. [The Sovereignty Gap](https://www.thierry-gilgen-ict.ch/field-notes/the-sovereignty-gap). Die öffentliche Infrastruktur Schweizer Parteien; keine Bewertung von Microsoft oder der EU-Beschaffung.
[^13]: Thierry Gilgen, The Library, Vol. 36, 27. August 2026. [Open Is Not Sovereign](https://www.thierry-gilgen-ict.ch/field-notes/open-is-not-sovereign). Offene und lokale Technik kann trotzdem äussere Abhängigkeiten mitbringen.
[^14]: NIST, SP 800-161 Rev. 1 (Update 1). [Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final). Allgemeine Praxis zum Lieferkettenrisiko; zertifiziert keinen Anbieter.
[^15]: Verordnung (EU) 2023/2854 (Data Act), Kapitel VI und Artikel 29. [Regulation (EU) 2023/2854](https://eur-lex.europa.eu/eli/reg/2023/2854/oj). Keine Wechselentgelte ab dem 12. Januar 2027; Geltungsbereich und Ausnahmen beachten. Geprüft am 14. Oktober 2026: Der hängige Digital-Omnibus-Vorschlag ändert Artikel 29 nicht.
[^16]: Verordnung (EU) 2022/2554 (DORA), Artikel 28 Absatz 8. [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj). Ausstiegsstrategien nur für erfasste Finanzunternehmen.