Digitale Souveränität ist 2026 vom politischen Schlagwort zum Verkaufsargument geworden. Mitte Januar hat Amazon Web Services die AWS European Sovereign Cloud in Brandenburg in Betrieb genommen, eine eigene, vollständig in der EU betriebene Partition mit getrennter Abrechnung in Euro, eigenem Personal und einer separaten Rechtsperson nach deutschem Recht. Wenige Wochen später zog Microsoft mit „Microsoft 365 Local“ nach und erlaubte seitdem, Dienste wie Exchange und SharePoint auf kundeneigener Hardware zu betreiben, abgekoppelt von der öffentlichen Cloud. Beide Angebote tragen dasselbe Etikett, und es ist ein gewichtiges: souverän.

Ich halte dieses Etikett für irreführend. Nicht, weil die technischen und organisatorischen Maßnahmen wertlos wären, im Gegenteil, sie sind beachtlich. Sondern weil sie ausgerechnet die eine Ebene unberührt lassen, auf die es bei Souveränität ankommt. Wer verstehen will, warum eine in Brandenburg betriebene Cloud rechtlich weiterhin in den Vereinigten Staaten hängt, muss zunächst sauber auseinanderhalten, was „souverän“ überhaupt bedeuten kann. Genau diese Unterscheidung trifft in der Debatte kaum jemand, und ohne sie reden die Beteiligten aneinander vorbei.

Was heißt hier souverän?

Souveränität in der Cloud zerfällt in drei Ebenen, die regelmäßig durcheinander geraten. Die erste ist die Datenresidenz, also die Frage, wo Daten physisch liegen. Die zweite ist die operative Autonomie, also die Frage, wer ein System betreibt, wartet und im Zweifel darauf zugreifen kann. Die dritte ist die rechtliche Souveränität, also die Frage, wessen Recht im Konfliktfall greift und wer einem Anbieter Anordnungen erteilen darf, denen dieser folgen muss.

Diese drei Ebenen sind nicht gleichwertig, und das ist der entscheidende Punkt. Datenresidenz und operative Autonomie lassen sich vertraglich und technisch herstellen, und genau das tun die neuen Angebote mit großem Aufwand. Die rechtliche Ebene aber entzieht sich solchen Maßnahmen, denn sie hängt nicht am Standort der Server, sondern an der Jurisdiktion, der das Mutterunternehmen untersteht.

Ein einfaches Gedankenexperiment macht den Unterschied greifbar. Stellen Sie sich vor, sämtliche Daten lägen in einem Rechenzentrum in Brandenburg, betrieben von Personen mit Wohnsitz in der EU, verschlüsselt und vertraglich abgesichert. Solange der Konzern, dem dieser Betrieb gehört, einer fremden Rechtsordnung untersteht, kann diese Rechtsordnung ihn zu einer Handlung zwingen, und kein Server-Standort ändert daran etwas. Datenresidenz ist eine Frage der Geografie, Souveränität eine Frage der Macht.

Dieser Bedeutungskern ist nicht zufällig. Souveränität bedeutet seit jeher die höchste Entscheidungsgewalt, also die Frage, wer am Ende das letzte Wort hat. Übertragen auf die Cloud heißt das: Souverän ist nicht, wessen Daten in der EU liegen, sondern wer im Streitfall bestimmen kann, was mit ihnen geschieht. Alles andere ist Komfort, nicht Kontrolle.

Die neuen Angebote im Jahr 2026

Die AWS European Sovereign Cloud ist technisch beeindruckend, das will ich nicht kleinreden. Sie läuft als eigene Partition mit einer eigenen Region, vollständig getrennt von den übrigen AWS-Regionen, mit eigenem Identitäts- und Abrechnungssystem in Euro und einem ausschließlich von Personen mit Wohnsitz in der EU besetzten Betrieb. Für Zertifizierung und digitale Signaturen hat Amazon sogar eine separate Gesellschaft nach deutschem Recht gegründet. Einen regionenübergreifenden Datenverkehr zu anderen AWS-Partitionen gibt es nicht, selbst Metadaten verbleiben in der EU-Infrastruktur.

Schon im Detail zeigt sich allerdings, wie heikel die Materie ist. Amazon legt das Kriterium des Wohnsitzes in der EU an, das BSI hingegen bevorzugt die Staatsangehörigkeit, und für staatliche Aufträge und kritische Infrastruktur kann dieser Unterschied erheblich sein. Eine scheinbar technische Detailfrage entscheidet darüber, wie weit die Autonomie tatsächlich reicht.

Microsoft verfolgt mit „Microsoft 365 Local“ einen anderen Weg. Statt einer abgeschotteten Cloud-Region verlagert das Angebot die sensibelsten Dienste, etwa Exchange und SharePoint, zurück auf Hardware im Haus der Kundin oder des Kunden, getrennt von der öffentlichen Cloud. Das ist im Kern eine Rückkehr zum Betrieb im eigenen Haus, neu verpackt als Souveränitätslösung.

Beide Wege adressieren reale Anforderungen, und für viele Anwendungsfälle reichen sie aus. Datenresidenz, operative Trennung und nachvollziehbare Zugriffskontrolle sind keine Kleinigkeiten. Das Problem beginnt erst dort, wo diese Maßnahmen als vollständige Souveränität verkauft werden, obwohl sie die rechtliche Ebene gar nicht berühren.

Der ungelöste Kern: CLOUD Act und FISA

Der CLOUD Act von 2018 verpflichtet US-Unternehmen, herausverlangte Daten herauszugeben, unabhängig davon, wo auf der Welt diese gespeichert sind. Hinzu kommen FISA Section 702 und die Executive Order 12333, die US-Nachrichtendiensten erlauben, Daten von Nicht-US-Bürgerinnen und -Bürgern im Ausland zu erheben, ohne dass Betroffene in Europa über wirksame Rechtsbehelfe verfügen. Diese Gesetze wirken extraterritorial, und das ist kein Randdetail, sondern der Kern des Problems.

Neu ist dieser Konflikt nicht. Bereits 2020 erklärte der Europäische Gerichtshof im Urteil Schrems II das Datenschutzabkommen Privacy Shield für ungültig, gerade weil die US-Überwachungsgesetze europäischen Betroffenen kein gleichwertiges Schutzniveau bieten. Die aktuelle Welle souveräner Cloud-Angebote ist im Grunde die Antwort der Industrie auf diese seit Jahren ungelöste Spannung, und sie verschiebt das Problem eher, als dass sie es beseitigt.

Eine Tochtergesellschaft nach deutschem Recht ändert daran wenig, solange die US-Muttergesellschaft die Kontrolle behält. Genau diese Konstruktion ist juristisch ungetestet. Was geschieht, wenn eine US-Behörde den Mutterkonzern anweist, seine europäische Tochter zu einer bestimmten Handlung zu veranlassen? Eine belastbare Antwort darauf gibt es bislang nicht, sie müsste vor Gericht erst erstritten werden, und bis dahin bleibt sie eine offene Flanke.

Wie wenig sich das durch Technik auflösen lässt, hat Microsoft selbst eingeräumt. Vor dem französischen Senat konnte das Unternehmen 2025 nicht garantieren, dass europäische Daten niemals an US-Behörden gelangen. Das ist keine Marketingfrage und keine Frage des guten Willens, sondern eine Frage der Jurisdiktion, und sie lässt sich mit noch so vielen Rechenzentren in der EU nicht beantworten.

Es gibt eine ernstzunehmende Gegenposition, und ich will sie nicht übergehen. Der Zugriff sei praktisch selten, heißt es, Vertrauenswürdigkeit schlage Herkunftsland, und für viele Unternehmen reichten rechtlich belastbare vertragliche Zusagen vollkommen aus. Für unkritische Arbeitslasten mag das zutreffen. Für die öffentliche Verwaltung, für kritische Infrastruktur und für besonders schützenswerte Daten überzeugt es mich nicht, denn Souveränität bemisst sich nicht an der Häufigkeit eines Zugriffs, sondern an der Frage, wer ihn im Ernstfall verhindern kann.

Ein Etikett für die falsche Ebene

Damit lässt sich präzise benennen, was an dem Wort „souverän“ stört. Es beschreibt die ersten beiden Ebenen, Datenresidenz und Betrieb, und schweigt über die dritte, die rechtliche Kontrolle. Das Etikett ist nicht gelogen, aber es ist auf eine Weise unvollständig, die das Wesentliche verdeckt, und diese Lücke ist kein Zufall.

Bemerkenswert ist nämlich, wer das Etikett vergibt: ausgerechnet jene Anbieter, deren Abhängigkeit es auflösen soll. Eine Untersuchung von 17 Anbietern entlang von 31 Kriterien kommt zu dem Schluss, dass sich keiner als klarer Souveränitätssieger bezeichnen lässt. US-Konzerne kaschieren strukturelle Jurisdiktionsrisiken mit EU-Tochtergesellschaften, und auch europäische Anbieter haben Schwächen in Kryptografie und Lieferkette. Branchenverbände wie CISPE haben dafür den Begriff Sovereignty Washing geprägt.

Dieses Muster ist nicht neu, und es lohnt sich, es zu erkennen. Ich habe an anderer Stelle beschrieben, wie Konzerne den Begriff Open Source vereinnahmen und ihn für ihre Zwecke umdeuten. Bei der souveränen Cloud geschieht dasselbe mit einem anderen Begriff: Ein Wort, das ursprünglich Unabhängigkeit bedeutete, wird zum Produktnamen für ein Angebot, das die Abhängigkeit gerade nicht beseitigt. Wer einen Begriff besetzt, kontrolliert die Debatte, und genau darum geht es.

Für die Käuferin und den Käufer hat das konkrete Folgen. Wer ein als souverän etikettiertes Produkt erwirbt, kauft womöglich Datenresidenz und glaubt, Unabhängigkeit erworben zu haben. Die Differenz zwischen beidem fällt erst auf, wenn es zu spät ist, nämlich im Konfliktfall, auf den das Etikett gerade nicht vorbereitet ist.

Die Regulierung erkennt das Problem

Auch die Politik hat verstanden, dass „souverän“ messbar werden muss, statt ein freies Versprechen zu bleiben. Anfang Juni 2026 hat die EU-Kommission den Cloud and AI Development Act vorgeschlagen, das erste EU-Gesetz, das sich gezielt an Cloud-Dienste und Künstliche Intelligenz richtet. Es ist eine Reaktion auf eine schlichte Zahl: Rund zwei Drittel des europäischen Cloud-Markts entfallen auf drei US-Konzerne, und diese Abhängigkeit gilt zunehmend als strategisches Risiko.

Im Kern steht ein Cloud Sovereignty Framework mit mehreren Stufen, an denen sich die öffentliche Hand bei der Beschaffung orientieren soll. Diese Stufen treffen exakt die Unterscheidung, um die es hier geht. Die unterste verlangt nur, dass Daten in der EU verarbeitet werden. Erst die höheren Stufen fordern Unabhängigkeit von Drittstaaten und Transparenz über die Software-Lieferkette, und die oberste verlangt Eigentum und Kontrolle aus der EU heraus, bis hin zur Staatsangehörigkeit des Personals und zur Freiheit von jeder Einflussnahme durch Drittstaaten.

Mit anderen Worten: Erst die oberste Stufe bezeichnet das, was „souverän“ im Wortsinn bedeutet, während die unterste kaum mehr als Datenresidenz verlangt. Eine ähnliche Linie verfolgt das BSI mit einem eigenen Kriterienkatalog dafür, wann eine Cloud wirklich souverän ist. Dass es solcher Kataloge überhaupt bedarf, ist das eigentliche Eingeständnis: Wäre das Etikett verlässlich, müsste niemand erst definieren, woran sich echte Souveränität erkennen lässt.

Der Cloud and AI Development Act steht dabei nicht allein, sondern ist Teil eines größeren Pakets, mit dem die EU ihre digitale Abhängigkeit verringern will. Dazu gehören eigens ausgewiesene Zonen für den beschleunigten Bau von Rechenzentren, mit denen sich die europäische Rechenkapazität in wenigen Jahren vervielfachen soll. Europäische Anbieter halten heute nur rund 15 Prozent des Markts, und gerade über die öffentliche Beschaffung könnten sie an Boden gewinnen, sofern die höheren Souveränitätsstufen dort tatsächlich verlangt werden.

Regulierung allein schafft allerdings keine Alternative, und das ist ihre Grenze. Sie kann beschreiben, was fehlt, sie kann über die Beschaffung Nachfrage lenken und Anbieter zu Transparenz zwingen. Bauen aber muss die Alternative jemand anderes, und genau hier verschiebt sich die Verantwortung von der Politik zurück zu denen, die Software entwerfen und betreiben.

Kontrolle über den Stack

Wer Souveränität ernst meint, sollte sie als das behandeln, was sie ist: keine Eigenschaft, die man kauft, sondern ein Maß an Kontrolle, das man sich erarbeitet. Die entscheidende Frage lautet nicht, wo die Server stehen, sondern wer im Ernstfall den Betrieb übernehmen kann und wer den Stack tatsächlich beherrscht, von der Hardware über die Plattform bis zu den Daten.

Diese Kontrolle hat mehrere Voraussetzungen, und keine davon ist allein hinreichend. Offene Standards und Open-Source-Software sind eine notwendige Grundlage, weil nur quelloffene Systeme prüfbar und übernehmbar sind. Hinreichend sind sie nicht, denn auch quelloffene Stacks hängen an Lieferketten, an Betrieb und an Finanzierung. Hinzu kommen Datenhoheit und die Fähigkeit, Dienste im Zweifel selbst zu betreiben, sowie eine Architektur, in der der konkrete Anbieter ein austauschbares Detail bleibt und kein Fundament, das sich nicht mehr herausziehen lässt.

Dabei ist Souveränität kein Alles-oder-nichts, sondern ein Spektrum, und welcher Grad nötig ist, ist eine fachliche Entscheidung. Nicht jede Arbeitslast braucht die höchste Stufe, denn ein öffentliches Marketingportal stellt andere Anforderungen als ein Fachverfahren mit Sozialdaten. Der Fehler liegt nicht darin, einen Hyperscaler zu nutzen, sondern darin, diese Wahl gar nicht erst zu treffen und alles unbesehen dorthin zu verlagern. Wer hingegen pro System bewusst entscheidet, welcher Grad an Kontrolle angemessen ist, betreibt Souveränität als Entwurfsdisziplin statt als Einkauf.

Selbst dort, wo volle Souveränität nicht erreichbar ist, gibt es eine Rückfalllinie, nämlich Resilienz: kundenseitig kontrollierte Verschlüsselung, Datenportabilität und technische Umkehrbarkeit als Schutz gegen extraterritorialen Zugriff. Das sind genau die Forderungen, die europäische Anbieter erheben, und sie sind pragmatischer als die Maximalforderung nach vollständiger Unabhängigkeit. Sie verlegen den Schwerpunkt von der Herkunft des Anbieters auf die tatsächliche Verfügungsgewalt über die eigenen Daten.

Diese Haltung ist im Kern nichts Neues, sondern ein altes Prinzip guten Entwurfs. Die Bindung an einen Anbieter ist Kopplung, und gute Architektur hält die Kopplung bewusst gering. Der Unterschied ist nur, dass die Kopplung an einen Hyperscaler selten als Entwurfsentscheidung wahrgenommen wird. Sie wird geerbt statt gewählt, und genau darin liegt das eigentliche Souveränitätsproblem, lange bevor ein Gesetz oder ein Etikett ins Spiel kommen.

Europa beginnt diese Lehre zu ziehen. Initiativen wie der EuroStack zielen auf eine offene, gemeinsame Infrastruktur, und in der öffentlichen Verwaltung laufen reale Migrationen weg von proprietären Plattformen, von Schleswig-Holstein bis Frankreich. Ob daraus eine tragfähige Alternative erwächst, ist offen, und ehrlicherweise ist dieser Weg mühsamer und teurer als das Anklicken eines als souverän etikettierten Angebots.

Genau deshalb ist die Begriffsklärung mehr als Wortklauberei. Solange „souverän“ ein Etikett bleibt, das die rechtliche Ebene ausspart, kauft man Datenresidenz und nennt sie Unabhängigkeit. Souveränität entsteht nicht durch ein Wort auf einem Datenblatt, sondern durch die Kontrolle über den eigenen Stack, und diese Kontrolle muss man wollen, bevor man sie haben kann.

(rme)