Souveränität beginnt am Ausschalter
Ein Button auf einer Folie ist kein Ausschalter
Im April 2026 vergab die Europäische Kommission einen Auftrag über 180 Millionen EUR für souveräne Cloud-Dienste an vier Anbieter, die die Organe, Einrichtungen und Agenturen der Union versorgen. Die Ausschreibung lief über das dynamische Beschaffungssystem Cloud III. Als die Kommission das Ergebnis erläuterte, erläuterte sie auch das Instrument dahinter: ein Rahmenwerk für Cloud-Souveränität mit einer Sicherheitsstufe für die Wirksamkeit der Souveränität und einer Gesamtbewertung, die sich aus 48 Kriterien in acht Kategorien zusammensetzt, darunter strategische, rechtliche und gerichtliche Aspekte, Daten und KI, Betrieb, Lieferkette, Technologie, Sicherheit und Compliance sowie ökologische Nachhaltigkeit.
Das ist ein interessanteres Ereignis, als das Adjektiv souverän normalerweise vermuten lässt. Eine Ausschreibung muss aus einem politischen Wort Fragen machen, die sich mit einer Vergabeakte beantworten lassen. Wer kann auf die Daten zugreifen? Wer kann die Plattform betreiben? Was passiert, wenn ein Anbieter den Eigentümer wechselt, wenn sich ein Gesetz ändert, wenn ein Dienst eingestellt wird oder wenn eine Einrichtung entscheidet, dass die Vereinbarung nicht mehr passt? Das Rahmenwerk der Kommission beantwortet diese Fragen nicht für jeden Käufer. Es tut etwas Nützlicheres: Es räumt ein, dass sie in denselben Raum gehören.
Die Versuchung besteht darin, Souveränität als einen Ort zu behandeln. Stellt man die Server nach Europa, unterschreibt man mit einer europäischen Tochtergesellschaft, unterstellt man den Vertrag europäischem Recht, scheint das Problem gelöst. Jeder dieser Schritte kann wichtig sein. Keiner von ihnen ist die ganze Eigenschaft. Ein System kann physisch in der Nähe der Menschen sein, die es bedient, während seine entscheidenden Schlüssel, technischen Abhängigkeiten, Betriebsbefugnisse und rechtlichen Risiken woanders liegen. Eine europäische Adresse kann wahr sein und trotzdem eine unvollständige Antwort bleiben.
Es gibt einen Test, der die Lücke sichtbar macht. Man fragt, was passiert, wenn die Organisation aufhören muss. Nicht weil Aufhören wünschenswert ist und nicht weil ein dramatisches Scheitern erwartet wird, sondern weil ernsthafte Institutionen in der Lage sein müssen, den Kurs zu ändern. Kann eine befugte Person den Dienst aussetzen? Kann die Organisation den Zustand prüfen, der beendet werden soll? Kann sie Beweise sichern? Kann sie die Arbeitslast verlagern? Kann ein anderes Team die Aufgabe übernehmen, ohne dass der erste Anbieter unverzichtbar bleiben muss? Wenn die Antwort vage ist, ist die Souveränitätsbehauptung immer noch ein Werbeprospekt.
Deshalb beginnt Souveränität am Ausschalter. Der Schalter ist kein theatralischer roter Knopf. Er ist eine Kette aus Befugnissen, Zugriffen, Wissen, Ausrüstung, Verträgen und Alternativen. Er muss an einem ruhigen Dienstag funktionieren, bevor jemand eine Pressemitteilung vorbereitet hat. Der Rest dieses Artikels folgt dieser Kette durch Cloud-Infrastruktur, europäische Politik und die unglamouröse Technik des Ausstiegs.
Fünf Wörter, die oft so tun, als wären sie austauschbar
Eigentum ist der erste Hochstapler. Es sagt uns, wer die Anteile hält, den Vorstand ernennt und den wirtschaftlichen Nutzen erhält. Eigentum kann für Souveränität wichtig sein, besonders wenn der Eigentümer geistiges Eigentum, Investitionsentscheidungen oder die langfristige Ausrichtung des Unternehmens kontrolliert. Es ist nicht dasselbe wie operative Kontrolle. Eine lokal geführte Organisation kann von einer ausländischen Betriebsplattform abhängen. Ein öffentlich geführter Dienst kann praktisch keine Möglichkeit haben, die Software zu ändern, die ihn betreibt. Eine Tochtergesellschaft kann in einem Land eingetragen sein, während ihre entscheidenden Genehmigungen woanders erteilt werden.
Standort ist der zweite. Datenresidenz beantwortet eine geografische Frage: Wo werden bestimmte Daten, Systeme oder Einrichtungen im Rahmen der Vereinbarung gespeichert oder verarbeitet? Diese Antwort kann die Einhaltung gesetzlicher Vorschriften, die Planung der Widerstandsfähigkeit oder ein vernünftiges Latenzbudget unterstützen. Sie beantwortet nicht, wer die Umgebung verwalten kann, welches Gesetz einen Anbieter zwingen kann, welche Subunternehmer in die Kette gelangen können oder was passiert, wenn ein Betreiber außerhalb des Standorts die privilegierten Zugangsdaten besitzt.
Die Gerichtsbarkeit ist der dritte Punkt. Sie betrifft die Rechtsordnung, die eine Organisation, ihre Infrastruktur oder ihre Daten erreichen kann. Ein Vertrag kann ein anwendbares Recht wählen, aber er kann andere rechtliche Befugnisse nicht zum Verschwinden bringen. Ein Dienst kann von einer europäischen Einrichtung aus erbracht werden und dennoch einen Anbieter betreffen, der anderswo Verpflichtungen unterliegt. Es geht nicht darum, jeden grenzüberschreitenden Dienst für unzulässig zu erklären. Es geht darum, aufzuhören, eine Markierung auf der Karte als rechtliche Analyse zu behandeln.
Die Betriebsbefugnis ist der vierte Punkt. Sie ist die praktische Fähigkeit, ein System dazu zu bringen, etwas zu tun oder damit aufzuhören: eine Freigabe zu erteilen, einen Schlüssel zu rotieren, ein Netzwerk zu isolieren, ein Backup wiederherzustellen, eine Richtlinie zu ändern, einen Administrator zu entfernen oder die Verantwortung an ein anderes Team zu übertragen. Die Betriebsbefugnis kann delegiert werden. Wenn sie delegiert wird, muss die Delegation sichtbar, begrenzt und umkehrbar sein. Andernfalls gibt der Vertrag dem Kunden eine nominelle Kontrolle, während der Anbieter die einzigen Personen und Schnittstellen behält, die sie tatsächlich ausüben können.
Der Ausstieg ist der fünfte Punkt. Er ist die Fähigkeit, eine Vereinbarung zu beenden und die notwendige Funktion anderswo oder auf Infrastruktur fortzusetzen, die die Organisation kontrolliert. Ausstieg bedeutet nicht nur, eine Datenbank herunterzuladen. Er kann Konfiguration, Identitäten, Verschlüsselungsschlüssel, Modelle, Container, Prüfprotokolle, Warteschlangen, Integrationen, Lizenzen, Betriebsverfahren und das Wissen umfassen, einen funktionierenden Dienst wieder aufzubauen. Ein Versprechen, dass Daten exportiert werden können, ist kein Versprechen, dass ein Dienst wieder aufgenommen werden kann.
Diese Begriffe gehören zusammen, sollten aber nicht vermischt werden. Eigentum ohne Betriebsbefugnis ist ein Eigentumstitel ohne Schlüssel. Standort ohne Gerichtsbarkeit ist eine Straßenadresse ohne eine Karte der rechtlichen Reichweite. Betriebsbefugnis ohne Ausstieg ist eine Fernbedienung, die an einer Maschine hängt, die niemand sonst reparieren kann. Souveränität ist die Beziehung zwischen allen fünf, geprüft in dem Moment, in dem Bequemlichkeit nicht mehr entscheidet.
Der Ausschalter-Test
Ein brauchbarer Ausschalter-Test beginnt mit einer bewusst unspektakulären Anweisung: Stoppen Sie dieses System an einer definierten Grenze, auf eine definierte Weise, unter einer identifizierten Autorität. „Dieses System“ muss konkret sein. Ist es ein Dienst, ein Mandant, ein Verarbeitungsauftrag, ein Datenfluss, ein Administratorkonto, ein Modell-Endpunkt oder eine gesamte operative Fähigkeit? Ein Anbieter kann in der Lage sein, einen Endpunkt zu deaktivieren, während die Daten, Kopien und privilegierten Pfade anderswo weiterlaufen. Ein Kunde kann in der Lage sein, einen Vertrag zu kündigen, und dabei feststellen, dass der einzige verfügbare Export eine Sammlung von Datensätzen ohne brauchbare Konfiguration ist.
Fragen Sie zuerst, wer den Stopp anordnen darf. Die Antwort sollte eine Rolle sein, nicht das Gedächtnis einer Person. Eine Rolle kann zugewiesen, geprüft und geändert werden. Sie sollte einen klaren Auslöser, einen Eskalationsweg und eine Aufzeichnung der Entscheidung haben. In einer öffentlichen Einrichtung kann die Autorität zwischen Diensteigentümern, Sicherheit, rechtlicher Verantwortung und einem Bereitschaftsdienst aufgeteilt sein. Die Aufteilung ist kein Mangel. Sie wird zu einem Mangel, wenn alle annehmen, dass jemand anderes handeln kann.
Fragen Sie dann, welche Anmeldedaten oder welcher Mechanismus den Stopp tatsächlich ausführt. Ein dokumentiertes Verfahren, das mit „Kontaktieren Sie den Support“ endet, ist ein Eskalationsweg, kein Ausschalter. Support kann für eine kontrollierte Migration angemessen sein, aber ein kritischer Dienst benötigt auch eine lokale oder unabhängig kontrollierte Möglichkeit, das System in einen sicheren Zustand zu versetzen. Das bedeutet nicht, dass jeder Kunde einen physischen Netzschalter haben sollte. Es bedeutet, dass die Organisation die Grenze ihrer eigenen Autorität, die Autorität des Anbieters und den Punkt kennen muss, an dem eine externe Reaktion erforderlich ist.
Als Nächstes stellt sich die Frage, was nach dem Stopp übrig bleibt. Ein sicherer Stopp kann Protokolle bewahren, Beweise für einen festgelegten Zeitraum aufbewahren, Sitzungen beenden, Zugangsdaten widerrufen, neue Schreibvorgänge verhindern und eine schreibgeschützte Kopie für Untersuchungen bereithalten. Er kann aber auch einen gefährlichen Zustand erzeugen, wenn ein abhängiger Prozess weiterhin Daten an einen Dienst sendet, der nicht mehr überwacht wird. Eine Komponente zu stoppen ist nicht dasselbe wie die Fähigkeit zu stoppen. Die Abhängigkeitskarte ist wichtiger als die Farbe des Knopfes.
Schließlich stellt sich die Frage, ob die Organisation die Funktion wieder aufnehmen kann, ohne standardmäßig in dieselbe Abhängigkeit zurückzukehren. Ein Dienst kann für eine kurze Eindämmungsmaßnahme gestoppt und dann neu gestartet werden. Das ist sinnvoll. Souveränität erfordert jedoch auch einen zweiten Weg: einen vorbereiteten Pfad zu einem anderen Anbieter, eine lokale Umgebung, einen bekannten manuellen Prozess oder einen bewusst reduzierten Dienst. Die Alternative kann langsamer oder weniger elegant sein. Sie darf nicht nur als Satz in einem Risikoregister existieren.
Der Ausschalter-Test besteht daher aus fünf Teilen: Befugnis, Mechanismus, Beweise, Abhängigkeit und Alternative. Er ist ein institutioneller Test, kein Produktmerkmal. Ein Anbieter kann hervorragende Werkzeuge bereitstellen und dennoch durchfallen, wenn der Kunde sie nicht nutzen kann. Ein Kunde kann einen Vertrag besitzen und dennoch durchfallen, wenn niemand das Verfahren geübt hat. Eine Organisation, die den Test geprobt hat, kann Schwächen früh entdecken, wenn sie noch Beschaffungs- und Ingenieursprobleme sind und keine öffentlichen Notfälle.
Kontrolle ist ein Stapel, kein Aufkleber
Stellen Sie sich ein System als einen Stapel von Räumen vor. Ganz unten liegt die physische Ebene: Gebäude, Strom, Kühlung, Netzwerkpfade und Hardware. Darüber liegen die technischen Ebenen: Firmware, Betriebssysteme, Virtualisierung, Speicher, Datenbanken, Identität und Anwendungscode. Darüber liegen die betrieblichen Ebenen: Menschen, Verfahren, Überwachung, Vorfallreaktion und Release-Management. Daneben verläuft eine rechtliche und wirtschaftliche Ebene: Eigentum, Verträge, Lizenzen, Zuständigkeit, Finanzierung und die Möglichkeit, eine Alternative zu erwerben.
Die Stapel-Metapher ist nicht die Behauptung, dass alle Systeme fünf saubere Stockwerke haben. Sie ist eine Möglichkeit, eine präzisere Frage zu stellen als „Ist das souverän?“. Die Kontrolle kann in einem Raum stark und in einem anderen schwach sein. Eine Institution kann das Recht haben, eine Anwendung zu prüfen, ohne Einblick in den physischen Verwaltungspfad zu haben. Sie kann Verschlüsselungsschlüssel besitzen, aber nicht in der Lage sein, die Hardware zu ersetzen, die den Schlüsseldienst am Leben hält. Sie kann eine vertragliche Ausstiegsklausel haben und dennoch operativ von einem Team abhängig sein, das nur der Anbieter beschäftigt.
Es ist keine Tugend, so zu tun, als müsste jede Ebene auf dieselbe Weise europäisch sein. Die digitale Wirtschaft Europas hängt von internationalen Lieferketten, Forschung, Standards und Märkten ab. Strategische Autonomie ist keine Fantasie völliger Selbstversorgung. Die politische Definition der Europäischen Kommission selbst spricht von der Fähigkeit, unabhängig zu handeln und gleichzeitig die Abhängigkeit von Anbietern außerhalb der EU zu verringern. Unabhängig zu handeln kann bedeuten, eine glaubwürdige Wahl zu haben, nicht jedes Bauteil hinter einem nationalen Zaun selbst herzustellen.
The practical distinction is between dependence that is visible and bounded, and dependence that is mistaken for control. A buyer can decide that a particular processor, software component or external service is acceptable. The decision should include the reason, the compensating measures, the replacement route and the authority to revisit it. A dependency that is recorded can be governed. A dependency hidden behind a European label will be discovered only when the label stops opening doors.
The stack also explains why a sovereignty score needs more than ownership. The Commission’s 2026 framework places strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability criteria beside one another. A list like this does not magically produce a sovereign service. It does acknowledge that control is distributed. That is already a better starting point than a single badge.
For engineers, the stack invites a dependency inventory. For procurement teams, it invites questions about subcontractors, keys, formats, interfaces, support and migration. For lawyers, it invites a map of legal reach that follows the provider and the infrastructure rather than the marketing name. For leaders, it makes a quiet point: the most expensive dependency is often the one that everyone thought had already been dealt with.
Location is useful, and insufficient
A data centre is a real place. Its walls affect physical security, energy use, network latency, labour arrangements and the resilience of a service. A residency requirement can prevent some transfers and can make an audit more concrete. It can also be a sensible expression of a public body’s legal and political responsibility. There is no need to sneer at geography to make the control point.
The mistake is asking geography to answer all the other questions. A server in Rotterdam does not, by itself, tell a buyer who has administrative access. A storage bucket in Milan does not say which telemetry is copied to a support system. A European subsidiary does not disclose the jurisdiction of the group that supplies its control plane. The location of a building and the reach of an organisation are related facts, not interchangeable facts.
The Data Act makes part of this distinction explicit. Article 28 requires providers of data processing services to make available the jurisdiction to which the infrastructure used for a service is subject, together with a general description of measures concerning international governmental access to or transfer of non-personal data where that could conflict with Union or Member State law. The requirement is valuable because it turns a vague assurance into information a customer can put in a file. It is not a guarantee that no authority will ever ask for access, and it is not a replacement for a customer’s own legal and technical assessment.
Location also changes over time. A provider can move a workload, add a subcontractor, introduce a support path, change a control-plane design or alter its ownership. A residency statement that was accurate on the day of signature can become stale. Sovereignty therefore needs a change signal: who is notified, which change triggers review, and who can pause the service while the review happens? Without that signal, a location claim is a snapshot masquerading as a property.
Stellen Sie sich eine hypothetische europäische Forschungseinrichtung vor, deren primärer Datensatz innerhalb der Union verbleiben muss. Diese Anforderung kann erfüllt sein, während ein Support-Workflow Diagnosematerial in ein Drittland sendet, während ein herstellerkontrollierter Identitätsdienst den Cluster verwaltet oder während ein proprietäres Format einen Anbieterwechsel unmöglich macht. Keine dieser Möglichkeiten wird als Tatsache über eine benannte Organisation behauptet. Sie sind der Grund, warum eine Standortkontrolle mit einer Zugriffskarte, einer Rechtsraumkarte und einer Ausstiegsprobe verbunden werden sollte.
Die ehrlichere Aussage ist einfach: Der Standort kann eine Klasse von Risiken reduzieren. Er kann nicht das gesamte Souveränitätsargument tragen. Ein Gebäude ist eine Ebene. Kontrolle ist der Stapel.
Rechtsraum ist keine Fußnote
Der Rechtsraum kommt immer dann ins Gespräch, wenn ein Versprechen auf eine Macht trifft. Ein Vertrag kann festlegen, wo Streitigkeiten verhandelt werden und welches Recht die Beziehung regelt. Das ist wichtig für Vorhersehbarkeit und Durchsetzung. Es bedeutet nicht, dass ein Anbieter, sein Mutterunternehmen, seine Mitarbeiter oder seine Infrastruktur für jedes andere Rechtssystem unsichtbar sind. Die Frage für einen Käufer ist nicht, ob ein Rechtsraum benannt werden kann. Es ist die Frage, welche rechtlichen Wege die beteiligten Personen, Systeme und Daten erreichen können und was der Anbieter tun müsste, wenn diese Wege genutzt würden.
Dies ist kein Argument dafür, jede ausländische Verbindung als verboten zu behandeln. Es ist ein Argument dafür, die Nationalitätsabkürzung durch eine dokumentierte Analyse zu ersetzen. Ein Anbieter kann ein europäisches Unternehmen sein, europäische Betriebsabläufe haben und eine Lieferkette, die mehrere Grenzen überschreitet. Ein Käufer kann diese Regelung akzeptieren, weil der Dienst belastbar ist, die Zugriffskontrollen stark sind, die relevanten Daten begrenzt sind und eine Alternative bereitsteht. Die Entscheidung ist vertretbar, wenn die Abhängigkeit und das Restrisiko sichtbar sind.
Auch das Wort Kontrolle braucht hier Sorgfalt. Ein Anbieter kann sagen, dass der Kunde seine Daten kontrolliert, weil der Kunde die Berechtigungen wählt. Das kann innerhalb des Dienstes zutreffen. Es bedeutet nicht automatisch, dass der Kunde den Anbieter, den Wartungspfad der Plattform oder die rechtliche Reaktion auf eine externe Anordnung kontrolliert. Das Wort sollte präzisiert werden: Kontrolle des Zugriffs, Kontrolle der Schlüssel, Kontrolle der Konfiguration, Kontrolle des Betriebs oder Kontrolle der Geschäftsentscheidung. Präzision ist weniger dramatisch als ein Souveränitätslogo, aber sie übersteht eine Prüfung besser.
Der Rahmen der Kommission stellt rechtliche und rechtsraumbezogene Fragen neben operative und lieferkettenbezogene Fragen. Diese Anordnung ist von Bedeutung. Rechtliche Gefährdung lässt sich nicht auf einen Absatz in einem Vertrag reduzieren, und technische Kontrolle lässt sich nicht auf ein Diagramm reduzieren. Wenn ein System eine öffentliche Funktion unterstützen soll, benötigt die Einrichtung genügend Belege, um zu erklären, wie es funktioniert und welche Behörden es beeinflussen können. Die Belege können unvollständig sein. Sie sollten nicht erfunden sein.
Eine praktische Rechtsraumdatei sollte die juristischen Einheiten in der Dienstkette, den Standort und die Rolle der relevanten Infrastruktur, die Zugriffswege für Anbietermitarbeiter und Subunternehmer, die vom Anbieter offengelegten maßgeblichen und anwendbaren Gesetze sowie das Benachrichtigungs- und Reaktionsverfahren für behördliche Anfragen identifizieren. Sie sollte auch festhalten, was der Kunde tun wird, wenn sich die Antworten ändern. Dieser letzte Satz ist der Punkt, an dem Souveränität beginnt, operativ statt beschreibend zu werden.
Das Beschaffungsexperiment der Kommission
Die Beschaffung der Sovereign-Cloud durch die Kommission ist nützlich, weil sie das Wort beobachtbar macht. Die öffentliche Erklärung besagt, dass vier Anbieter für einen Vertrag über 180 Millionen EUR für Einrichtungen der Union ausgewählt wurden. Sie beschreibt zwei komplementäre Maßnahmen: eine Sovereignty Effectiveness Assurance Level mit Schwellenwerten für Datensouveränität, technologische Autonomie und volle Souveränität sowie eine Gesamtbewertung auf der Grundlage von 48 definierten Kriterien, die in acht Kategorien gruppiert sind.
In dieser Formulierung steckt eine kleine, aber wichtige Disziplin. Das Framework ist ein Bewertungsinstrument. Es macht aus einem Anbieter nicht durch bloße Erklärung ein souveränes Objekt. Eine Bewertung kann Abwägungen sichtbar machen, einem Käufer helfen, Angebote zu vergleichen, und eine Grundlage dafür schaffen, warum ein Zuschlag erteilt wurde. Sie kann aber auch ausgespielt werden oder veralten, wenn niemand die zugrunde liegenden Nachweise prüft. Die vernünftige Frage ist nicht, ob das Framework die endgültige Antwort ist. Sie lautet vielmehr, ob die Kriterien dem Kontakt mit der Praxis standhalten.
Nehmen wir die Kategorie der operativen Souveränität. Sie sollte Fragen aufwerfen wie: Wer kann eine Netzroute ändern, wer kann einen Schlüssel rotieren, wer kann ein Vorfallprotokoll lesen, wie schnell kann ein Kunde eine Funktion übernehmen und welche Aktionen erfordern die Beteiligung des Anbieters? Das sind keine abstrakten Eigenschaften. Sie lassen sich in einer kontrollierten Übung demonstrieren. Wenn die Übung unmöglich ist, weil der Anbieter den relevanten Zustand nicht offenlegen kann oder weil der Kunde nicht befugt ist, sie anzustoßen, dann ist diese Schwäche Teil der Bewertung und kein lästiges Detail, das in einem Anhang verschwinden sollte.
Dasselbe gilt für die Kategorien Lieferkette und Technologie. Ein Käufer muss keinen unmöglichen Reinheitstest verlangen. Er muss aber wissen, welche Abhängigkeiten wesentlich sind, welche ersetzt werden können, welche vertraglich oder technisch bindend sind und wie eine Unterbrechung aussehen würde. „Wir haben ein europäisches Support-Team“ und „wir können diese Funktion fortführen, wenn eine kritische vorgelagerte Komponente nicht verfügbar ist“ sind unterschiedliche Aussagen. Die erste betrifft Menschen. Die zweite betrifft Resilienz und Wahlfreiheit.
Das öffentliche Beschaffungswesen ist für diese Arbeit besonders gut geeignet, weil eine Ausschreibung Nachweise verlangen kann, bevor ein Dienst zur Standardlösung wird. Eine Ausschreibung kann ein portables Format, ein aktuelles Abhängigkeitsregister, ein Verfahren zur Änderungsmitteilung, eine Ausstiegsprobe und eine Berechtigungsmatrix verlangen. Sie kann Antworten bewerten und einen Dienst ablehnen, der diese Nachweise nicht erbringen kann. Sie kann auch für die Fähigkeit bezahlen, die Alternative aufrechtzuerhalten, denn ein Ausstieg, der nur in einem ruhenden Dokument existiert, verfällt.
Die Veröffentlichung der Kommission präsentiert ihr Framework als Maßstab für öffentliche und private Organisationen. Das ist eine Einladung, keine Empfehlung, dass jede Organisation jede Gewichtung übernehmen sollte. Ein kleiner Dienst und eine kontinentweite Plattform haben unterschiedliche Risiken. Die Methode, die es wert ist, übernommen zu werden, ist die Gewohnheit, Souveränität in Kriterien, Nachweise und Schwellenwerte zu zerlegen. Das Beschaffungswesen kann Nein sagen. Das ist eine der wenigen Befugnisse, die nach der Bereitstellung schwächer wird.
Ausstieg ist eine technische Eigenschaft
Cloud-Verträge beschreiben den Ausstieg oft, als wäre er ein höflicher Schlussabsatz. Der Data Act behandelt ihn als Prozess. Artikel 23 verpflichtet Anbieter von Datenverarbeitungsdiensten, Hindernisse zu beseitigen, die einen Kunden daran hindern, einen Vertrag zu kündigen, einen neuen Vertrag abzuschließen, exportierbare Daten und digitale Assets zu portieren, gegebenenfalls funktionale Gleichwertigkeit zu erreichen oder Dienste zu entbündeln, soweit technisch machbar. Die Artikel 25 bis 30 legen dann Vertrags-, Informations-, Kooperations-, Entgelt- und technische Pflichten fest.
Die Details sind ungewöhnlich praxisnah. Im Regelfall muss ein Vertrag eine maximale Kündigungsfrist von zwei Monaten und eine verbindliche Übergangsfrist von höchstens 30 Kalendertagen vorsehen, während der der Anbieter den Dienst fortführt und die Kontinuität unterstützt. Macht der Anbieter geltend, dass die 30-Tage-Frist technisch nicht machbar ist, muss er den Kunden innerhalb von 14 Arbeitstagen benachrichtigen, diese Behauptung begründen und eine alternative Übergangsfrist von höchstens sieben Monaten angeben. Dem Kunden wird eine Abruffrist von mindestens 30 Kalendertagen nach der Übergangsfrist eingeräumt, und der Vertrag muss die Löschung nach einem erfolgreichen Wechsel regeln.
Artikel 29 gibt auch die Richtung für Wechselentgelte vor. Ab dem 12. Januar 2027 dürfen Anbieter für den Wechselvorgang keine Wechselentgelte mehr erheben. Während der Übergangszeit dürfen ermäßigte Entgelte nur innerhalb der in der Verordnung festgelegten Grenzen erhoben werden, und Interessenten müssen über mögliche Gebühren und Sanktionen informiert werden. Artikel 30 befasst sich mit offenen Schnittstellen, Interoperabilitätsspezifikationen und maschinenlesbarem Export. Dabei handelt es sich nicht um nebensächliche Details. Sie sind die Bausteine, aus denen ein Ersatzdienst zusammengesetzt werden muss.
Ein gesetzlicher Anspruch ist nicht dasselbe wie ein eingeübter Weg. Ein Kunde kann einen konformen Export erhalten und dennoch nicht über die Personen, Werkzeuge oder Zeit verfügen, um den Dienst wiederherzustellen. Daten können portabel sein, während die Bedeutung einer Kennung es nicht ist. Ein Modell kann kopiert werden, während sein Evaluierungssatz, seine Prompt-Richtlinie, seine Zugriffsregeln und sein Überwachungsverlauf zurückbleiben. Ein Container kann verschoben werden, während die Annahmen zu Identität und Schlüsselverwaltung verhindern, dass er startet. Das Gesetz verbessert die Grundlage. Die Technik entscheidet, ob jemand darüber gehen kann.
Deshalb sollte der Ausstieg in Schichten getestet werden. Beginnen Sie mit einer Stichprobe exportierbarer Daten und rekonstruieren Sie diese in einer separaten Umgebung. Stellen Sie dann die Identitäten und Berechtigungen mit dem Prinzip der geringsten Rechte wieder her. Bauen Sie den Dienst aus dokumentierter Konfiguration wieder auf, nicht aus dem Gedächtnis einer Ingenieurin oder eines Ingenieurs. Spielen Sie repräsentative Arbeitslasten erneut ab und vergleichen Sie die Ergebnisse, einschließlich der Fälle, die fehlschlagen sollten. Prüfen Sie, ob Prüfprotokolle ihre Bedeutung behalten. Wiederholen Sie die Übung nach einer wesentlichen Änderung. Wenn die Übung einen nicht offengelegten Eingriff des Anbieters erfordert, dokumentieren Sie diese Abhängigkeit, anstatt die Übung als unabhängig zu bezeichnen.
Der Begriff funktionale Gleichwertigkeit verdient ebenfalls Zurückhaltung. Der Data Act definiert ihn anhand eines materiell vergleichbaren Ergebnisses für gemeinsame Funktionen im selben Diensttyp. Er verspricht nicht, dass zwei Anbieter identische Architekturen, Preise, Leistungen oder Unterstützung haben. Ein Käufer sollte festlegen, was gleichwertig bleiben muss, was vorübergehend abweichen darf und was sich ändern darf. Ein Ausstiegsweg, der jeden Komfort erhält, kann unmöglich sein. Ein Ausstiegsweg, der die öffentliche Funktion erhält, kann ausreichen, sofern die Einrichtung diesen Kompromiss im Voraus gewählt hat.
Der Ausschalter gehört einer Einrichtung
Es ist verlockend, den Ausschalter in einer Produktdemo zu platzieren. Drücken Sie ein Bedienelement, beobachten Sie, wie eine grüne Anzeige grau wird, und nennen Sie das System beherrschbar. Echte Autorität ist sperriger. Sie sitzt in einer Einrichtung mit Stellenbeschreibungen, Delegationen, Urlaub, konkurrierenden Prioritäten und Menschen, die möglicherweise nicht wissen, dass sie die Person sind, von der erwartet wird zu handeln.
Das bedeutet nicht, dass jede Mitarbeiterin und jeder Mitarbeiter jedes System stoppen können sollte. Es bedeutet, dass die Autorität gestaltet sein sollte. Die Diensteigentümerin oder der Diensteigentümer entscheidet, wofür die Funktion da ist. Die Sicherheit kann einen Eindämmungsauslöser identifizieren. Rechts- und Datenschutzteams können Beschränkungen für Beweise und Zugriff identifizieren. Der Betrieb kann das Verfahren ausführen. Die Führung kann einen Konflikt zwischen Kontinuität und Rückzug lösen. Die Rollen können in einer kleinen Organisation zusammengefasst werden, aber die Entscheidungen müssen dennoch explizit sein.
Stellen Sie sich einen hypothetischen regionalen öffentlichen Dienst vor, der eine gehostete Plattform zur Bearbeitung von Anträgen nutzt. Niemand muss sich eine Ausfallgeschichte ausdenken, um die Governance-Frage zu erkennen. Wenn ein Anbieter einen kritischen Zugriffspfad ändert, wer prüft das? Wenn das Monitoring ein unerklärliches Verhalten zeigt, wer darf neue Einreichungen pausieren? Wenn der Vertrag gekündigt wird, wem gehört der Export, wer verifiziert, dass er vollständig ist, und wer entscheidet, ob ein manueller Prozess sicher genug ist, um zu laufen, während ein Ersatz aufgebaut wird? Eine Richtlinie, die die Rollen benennt, bevor der Druck entsteht, ist nützlicher als ein Versprechen nach einem Vorfall, die Koordination zu verbessern.
Dieselbe Disziplin gilt für automatisierte Systeme. Eine KI-Komponente kann gestoppt werden, während der umgebende Workflow weiterhin Entscheidungen aus zwischengespeicherten Ausgaben, Fallback-Regeln oder menschlichen Annahmen produziert. Die Organisation muss daher die Einheit der Autorität definieren. Bezieht sich der Ausschalter auf das Modell, den Entscheidungsdienst, die Warteschlange, den Veröffentlichungsschritt oder den gesamten Prozess? Ein enger Schalter kann sicherer sein als eine vollständige Abschaltung, aber nur, wenn seine Grenze bekannt und seine Wirkung beobachtbar ist.
Evidenz ist Teil des institutionellen Schalters. Eine Stopp-Aktion sollte einen Datensatz hinterlassen, wer gehandelt hat, unter welcher Autorität, zu welcher Zeit, mit welchem beobachteten Zustand und mit welchem nächsten Schritt. Der Datensatz ist keine bürokratische Dekoration. Er ermöglicht es der Organisation, eine bewusste Eindämmungsmaßnahme von einer stillen Verschlechterung zu unterscheiden, und ermöglicht es einem Ersatzteam, zu verstehen, was es übernommen hat. Dies ist derselbe Grund, aus dem der Data Act Anbieter auffordert, Informationen über Formate, Verfahren und Einschränkungen zu geben. Ein System, das seinen Zustand nicht beschreiben kann, kann nicht verantwortungsvoll übertragen werden.
Es gibt auch einen Punkt der Menschenwürde. Wenn Organisationen sagen, dass ein Anbieter unverzichtbar ist, meinen sie oft, dass eine kleine Anzahl von Menschen die Vereinbarung versteht. Das ist eine Wissensabhängigkeit, keine Tatsache der Natur. Dokumentation, Schulung, gepaarte Betriebsabläufe und regelmäßige Übungen können Autorität weniger persönlich und dauerhafter machen. Das Ergebnis mag weniger magisch aussehen. Es ist in der Regel widerstandsfähiger.
Eine Souveränitätsdatei, die eine Besprechung übersteht
Eine Souveränitätsdatei sollte etwas sein, das eine Beschaffungsbeauftragte, ein Ingenieur, eine Juristin und eine verantwortliche Führungskraft alle lesen können, ohne das Dokument in vier verschiedene private Sprachen zu übersetzen. Sie sollte kein 100-seitiges Assurance-Paket sein, das jede Frage beantwortet, außer der, die eine Entscheidungsträgerin gerade stellen will. Eine kompakte Datei kann auf tiefere Evidenz verweisen und gleichzeitig die Kontrollgrenze sichtbar machen.
Beginnen Sie mit der Dienstdefinition. Benennen Sie die Funktion, die Daten, die Nutzerinnen und Nutzer, die unterstützten Entscheidungen oder Aktionen, die akzeptable Unterbrechung und die Folgen einer unsicheren Fortsetzung. Markieren Sie, was kritisch und was lediglich bequem ist. Dies verhindert, dass die Organisation Souveränität für ein Dashboard aushandelt, während sie den Identitätsdienst übersieht, der es jedem ermöglicht, darauf zuzugreifen.
Dann erfassen Sie die Kontrollkarte. Identifizieren Sie für jede wesentliche Komponente, wer sie besitzt, wer sie betreibt, wer sie einsehen kann, wer sie ändern kann, wer sie stoppen kann und wer sie ersetzen kann. Verwenden Sie die tatsächlichen Entitäts- und Rollennamen aus dem Vertrag und dem Betriebsmodell. Wenn ein Feld „Anbieter“ oder „Kunde“ ohne benannte Verantwortung lautet, ist das eine Einladung, eine weitere Frage zu stellen.
Erfassen Sie als Nächstes die rechtliche und gerichtliche Karte. Schließen Sie die Vertragsparteien, relevante Anbieterentitäten, im Rahmen der Vereinbarung offengelegte Infrastruktur-Jurisdiktionen, anwendbare Subunternehmer, Zugriffswege und Benachrichtigungsverfahren ein. Geben Sie an, wo die Evidenz aktuell ist und wann sie überprüft werden muss. Eine Karte mit einem Datum ist ehrlicher als ein immergrüner Assurance-Satz.
The exit section should contain an inventory, not just an intention. List exportable data, digital assets, configuration, identities, keys, logs, models, evaluation material, licences and the dependencies that cannot be moved. For each item, name its format, owner, retrieval method, validation test and retention or erasure rule. If an item is not exportable, say why and describe the substitute. The point is not to punish a provider for having protected trade secrets. The point is to prevent the customer’s working capability from being confused with the provider’s internal machinery.
Finally, attach an exercise record. It should show the date, scope, participants, assumptions, observed gaps, corrective actions and the next review trigger. A small sample exit can be more informative than a large theoretical plan. The exercise can reveal that a format is technically available but slow to interpret, that a key is portable but not usable by the alternative environment, or that an authority exists on paper but is not reachable outside office hours. Those are solvable discoveries. They are far kinder than surprises.
The file should also contain a refusal condition. What evidence would make the organisation decline the service, delay deployment or limit the data it sends? This is where sovereignty becomes a procurement choice rather than a wish. A buyer does not need to reject every dependency. It needs to know which dependency would make the service unacceptable and who has the authority to say so.
What sovereignty costs, and what dependence costs
Sovereignty is not free. Controlled keys require people and procedures. Portable formats can limit the convenience of a proprietary feature. Redundant capacity costs money before it is needed. An alternative provider may be less polished. A local operating path may be slower. A public institution that insists on evidence can receive fewer bids and spend longer deciding. These are real costs, and hiding them under a flag is no more honest than hiding dependence under a discount.
The relevant comparison is not sovereignty against a frictionless world. It is a deliberate cost against an unpriced dependency. A service that is cheap to adopt may be expensive to inspect, expensive to migrate, or impossible to suspend without public consequences. A provider that is technically excellent may still create a concentration risk if the customer cannot change a critical interface. A locally controlled path may cost more today and preserve the ability to choose tomorrow. Neither choice is automatically correct. The institution should be able to explain which cost it accepted.
ENISA’s cloud risk assessment is old enough to have outlived several fashionable architectures. That is part of its usefulness. Its framing treats cloud computing as a business and technology model with benefits and risks, including lock-in and legal exposure, and recommends assessing those risks rather than assuming that the cloud is either liberation or danger. The same temperament is needed for sovereignty. The question is not whether an arrangement is pure. It is whether its dependencies are known, bounded and replaceable enough for the function at stake.
Redundancy is often misunderstood as owning two identical copies. Sometimes the better alternative is a different implementation, a manual fallback or a reduced service that preserves the most important public function. The choice depends on the consequences of interruption. A research workload may tolerate a delayed run. A public information service may need a static publication path. A safety-related workflow may need a human gate and a tested procedure rather than a second identical endpoint. Sovereignty is the ability to choose the fallback before the primary system chooses it for you.
Es gibt auch soziale Kosten. Wenn nur wenige Menschen ein System bedienen können, hat sich die Organisation eine Abhängigkeit von deren Erinnerung eingehandelt. Wenn das öffentliche Beschaffungswesen jede Abweichung vom Bestand als unverantwortlich behandelt, lehrt es den Markt, dass Ausstieg nur Theater ist. Wenn Institutionen Alternativen nur bis zum Abschluss der ersten Ausschreibung fördern, schaffen sie eine Vorführung statt Kapazität. Für Betriebswissen, Interoperabilität und Wartung zu zahlen, ist weniger aufregend, als eine Plattform anzukündigen. Es ist auch der Weg, auf dem Entscheidungen den zweiten Haushaltszyklus überleben.
Unsere kleine Fußnote
Bei Dweve vertritt unser öffentlicher Bericht The Sovereignty Illusion ein verwandtes Argument über fünf praktische Türen: Eigentum, Technologie, Kapital, Infrastruktur und rechtliche Risiken. Der Bericht ist unsere eigene Analyse, kein rechtlicher Standard und kein Ersatz für den Beschaffungsrahmen der Kommission oder den Data Act. Sein Wert liegt hier schlicht in der Gewohnheit, die er fördert: Wenn jemand sagt, ein System sei souverän, sollte man fragen, welche Tür die Kontrolle trägt und welche Tür offen bleibt. Das ist der Maßstab, auf dem wir unsere eigene Arbeit gern diskutieren, nach den Belegen und vor dem Verkaufsgespräch.
Der Test findet vor dem Notfall statt
Der aufschlussreichste Moment für Souveränität ist selten der Start. Starts sind voller vorbereiteter Diagramme, benannter Teams und günstiger Umstände. Der aufschlussreiche Moment ist ein Kurswechsel: Ein Vertrag muss beendet werden, ein Anbieter muss herausgefordert werden, eine rechtliche Reichweite muss überprüft werden, eine Abhängigkeit muss ersetzt werden, oder ein Betreiber muss eine Funktion stoppen, bevor alle Fakten bequem sind.
Deshalb ist der Ausschalter ein besserer Ausgangspunkt als die Flagge. Er verlangt Autorität statt Atmosphäre. Er fragt, was die Organisation prüfen kann, nicht, was der Anbieter versprechen kann. Er fragt, ob Daten und digitale Vermögenswerte bewegt werden können, ob die Funktion fortgeführt werden kann und ob die Belege den Wechsel überstehen. Er verwandelt Souveränität in eine Reihe einübbarer Handlungen.
Der Rahmen der Europäischen Kommission für 2026 zeigt, dass öffentliche Beschaffung diese Handlungen lesbar machen kann. Der Data Act zeigt, dass Wechsel- und Zuständigkeitsinformationen Pflichten statt Gefälligkeiten sein können. Die Risikoarbeit der ENISA erinnert uns daran, dass Lock-in und rechtliche Risiken keine neuen Überraschungen sind, selbst wenn die Architektur ihren Namen ändert. Keine dieser Quellen sagt, dass Europa ohne Abhängigkeiten auskommen kann. Sie bieten etwas Ernsthafteres: einen Weg zu entscheiden, welche Abhängigkeiten akzeptabel sind und was geschieht, wenn sie es nicht sind.
Eine europäische Institution muss nicht jeden Chip besitzen, jedes Betriebssystem schreiben oder jeden Dienst bauen, um mit Souveränität zu handeln. Sie muss eine glaubwürdige Fähigkeit behalten, die Vereinbarung zu verstehen, Grenzen zu setzen, die Bedingungen zu ändern, den unsicheren Weg zu stoppen und die wesentliche Funktion fortzuführen. Manchmal bedeutet das, einen europäischen Anbieter zu wählen. Manchmal bedeutet es eine offene Schnittstelle, einen getrennten Schlüsselinhaber, einen zweiten Betreiber, einen manuellen Weg oder einen kleineren Dienst. Die Antwort gehört zum Risiko und zur öffentlichen Verantwortung, nicht zu einem Slogan.
Vor der nächsten Ankündigung einer souveränen Cloud sollten fünf einfache Fragen gestellt werden. Wer kann das stoppen? Wer kann sehen, was geschehen ist? Wer kann es ändern? Wohin kann es bewegt werden? Was kann es ersetzen? Wenn die Antworten schriftlich vorliegen, getestet und verantwortet werden, könnte das Wort Souveränität nützliche Arbeit leisten. Wenn die Antworten bei einem Logo und einer Adresse enden, hat das System seinen Ausschalter noch nicht gefunden.
Quellen
- Sovereign Cloud Framework erklärt, Europäische Kommission, Generaldirektion Digitale Dienste.
- Stärkung der digitalen Souveränität Europas, Europäische Kommission, Gestaltung der digitalen Zukunft Europas.
- Verordnung (EU) 2023/2854 (Datengesetz), EUR-Lex, insbesondere Kapitel VI zum Wechsel zwischen Datenverarbeitungsdiensten.
- Cloud Computing Risk Assessment, Agentur der Europäischen Union für Cybersicherheit.
- The Sovereignty Illusion, Dweve.