--- mpf: '0.7' title: Souveränität — ESFI Docs url: https://docs.esfi.eu/de/topics/sovereignty/ mpf-url: https://docs.esfi.eu/de/topics/sovereignty/index.mpf organization: European Strategy & Future Infrastructure domain: docs.esfi.eu lang: de updated: '2026-11-03' author: ESFI provenance: human source-hash: abec5fca9a84809211853f7feaafe285e73fa1c3045efc70f3b06556d1f40d46 toc: - level: 1 text: Souveränität id: souveränität - level: 2 text: Das Objekt der Souveränität ist Abhängigkeit id: das-objekt-der-souveränität-ist-abhängigkeit - level: 2 text: Kontrolle hat mehr als eine Ebene id: kontrolle-hat-mehr-als-eine-ebene - level: 2 text: Eigentum und Kontrolle sind verschieden id: eigentum-und-kontrolle-sind-verschieden - level: 2 text: Eine Liste von Alternativen ist kein Exit id: eine-liste-von-alternativen-ist-kein-exit - level: 2 text: Souveränität erfordert die Fähigkeit zu urteilen id: souveränität-erfordert-die-fähigkeit-zu-urteilen - level: 2 text: Nicht jede Evidenz sagt dasselbe id: nicht-jede-evidenz-sagt-dasselbe - level: 2 text: Souveränität ist keine Autarkie id: souveränität-ist-keine-autarkie - level: 2 text: Wie wir gemeinsam daran arbeiten id: wie-wir-gemeinsam-daran-arbeiten - level: 2 text: Wo wir vorsichtig sind id: wo-wir-vorsichtig-sind - level: 2 text: Weiterführende Literatur id: weiterführende-literatur - level: 2 text: Änderungen an dieser Position id: änderungen-an-dieser-position - level: 2 text: Auf dieser Seite id: auf-dieser-seite spec-origin: esfi.eu content-origin: docs.esfi.eu content-id: esfi:page:topics-sovereignty content-parity: html: true human-visible-source: true hidden-sections: false summary: Können Sie es ändern, wenn Sie müssen? index: true confidence: probable content-type: analysis companion-footer: ESFI — civilization infrastructure · https://esfi.eu companion-contact: mailto:hermes@esfi.eu preferred-representation: mpf companion-scope: cite: true summarize: true train: true index: true relay: true language-variants: en: https://docs.esfi.eu/topics/sovereignty/index.mpf fr: https://docs.esfi.eu/fr/topics/sovereignty/index.mpf nl: https://docs.esfi.eu/nl/topics/sovereignty/index.mpf de: https://docs.esfi.eu/de/topics/sovereignty/index.mpf hr: https://docs.esfi.eu/hr/topics/sovereignty/index.mpf mpf-id: 351333a620d94946830aea4fecad323e88806253eec60fab10554a356acc0d25 --- Sprache ✕ /de/topics/sovereignty/index.mpf[Datei öffnen ↗](/de/topics/sovereignty/index.mpf)[Spezifikation ↗](/de/standards/mpf/0.7)✕ wird geladen… # Souveränität {#souveränität} **Können Sie es ändern, wenn Sie müssen?** Viele Organisationen, mit denen wir sprechen, haben getan, was die Souveränitätsdebatte von ihnen verlangt hat. Sie haben Dienste zu europäischen Anbietern verlagert, Rechenzentren innerhalb der Union gewählt und die richtigen Klauseln in ihre Verträge aufgenommen. Und als sie etwas Wesentliches ändern mussten, stellten sie fest, dass sie es nicht konnten. Der Identitätsdienst hing weiterhin von einer externen Control Plane ab. Der Supportpfad führte durch eine andere Jurisdiktion. Die einzigen Menschen, die das System neu konfigurieren konnten, arbeiteten für den Anbieter. Dort beginnt meist die eigentliche Frage nach Souveränität. Wir verwenden Souveränität als Engineering-Begriff, nicht als Etikett. Die Frage ist nicht, ob ein Dienst eine europäische Flagge trägt. Die Frage ist, ob eine Institution die Abhängigkeiten unter einer wesentlichen Funktion sehen, verstehen kann, wer sie kontrolliert, und noch handeln kann, wenn sich eine davon ändern muss. Ein System kann in Europa gehostet sein und von Entscheidungen abhängen, die anderswo getroffen werden. Eine Komponente kann von außerhalb Europas stammen und dennoch Teil einer Architektur sein, deren Zugriff, Schlüssel, Betrieb und Ersatzpfad fest unter institutioneller Kontrolle stehen. Geografie ist Evidenz. Sie ist nicht die Antwort. Unsere Position ist enger und, wie wir meinen, nützlicher. **Souveränität ist eine operative Eigenschaft eines Systems, nicht eine Eigenschaft eines Anbieters.** Sie besteht dort, wo Abhängigkeit sichtbar genug ist, um gesteuert zu werden, begrenzt genug, um verändert zu werden, und gut genug verstanden wird, damit die Institution Aussagen darüber beurteilen kann. * * * ## Das Objekt der Souveränität ist Abhängigkeit {#das-objekt-der-souveränität-ist-abhängigkeit} Wenn Souveränität als Eigenschaft von Anbietern diskutiert wird, wird das Gespräch zu Listen: genehmigte Anbieter, bevorzugte Jurisdiktionen, zertifizierte Clouds. Listen sind für Beschaffung nützlich. Sie sagen einer Institution selten, ob sie handeln kann. Wir beginnen anderswo: bei der wesentlichen Funktion und den Abhängigkeiten darunter. Die Einheit, die wir untersuchen, ist die Beziehung zwischen einer Funktion und dem, worauf sie beruht. Die praktischen Fragen sind leicht zu stellen und oft schwer zu beantworten: - Wovon hängt diese Funktion tatsächlich ab? - Wer kann diese Abhängigkeit ändern, aussetzen oder einschränken? - Unter welcher Jurisdiktion und welchen vertraglichen Bedingungen arbeitet sie? - Welchen Teil davon kontrolliert die Institution, technisch und physisch? - Was passiert mit der Funktion, wenn sich Anbieter, Route oder Rechtslage ändern? - Kann die Abhängigkeit isoliert, ersetzt oder unter ein anderes Betriebsmodell gebracht werden? Eine Souveränitätsaussage wird erst nützlich, wenn die Antworten eine Entscheidung verändern können. Wenn nicht, ist die Aussage Dekoration. Mit einer Antwort, die viele Bewertungen vermeiden, sind wir ausdrücklich einverstanden: **unbekannt.** Wenn eine Abhängigkeit nicht durch Evidenz belegt werden kann, lassen wir sie offen und sagen das. Unbekannt ist eine akzeptable Antwort. Angenommene Kontrolle ist es nicht. ## Kontrolle hat mehr als eine Ebene {#kontrolle-hat-mehr-als-eine-ebene} Es gibt nicht eine einzige Souveränitätsebene. Eine digitale Funktion ruht auf mehreren Systemen, die unterschiedliche Eigentümer, Jurisdiktionen und Failure Modes haben können. Wir finden es nützlich, fünf Arten von Kontrolle zu unterscheiden, weil Institutionen oft eine sichern und dabei eine andere verlieren. **Physisch.** Digitale Systeme laufen auf Glasfaserrouten, Stromversorgung, Gebäuden und Routing-Knoten. Eine gut gesteuerte Anwendung auf einer Unterlage, die die Institution weder sehen noch beeinflussen kann, bleibt Entscheidungen ausgesetzt, die anderswo getroffen werden. Rechtlicher Zugang zu Infrastruktur und effektiver operativer Zugang sind nicht dasselbe: Ein Recht, Zugang zu beantragen, kann weiterhin von Verfahren abhängen, die jemand anderes kontrolliert. **Operativ.** Wer kann das System tatsächlich betreiben? Wer kann deployen, Zugriff entziehen, die Schlüssel halten, den Dienst wiederherstellen und Routing ändern? Ein Dienst kann am richtigen Ort gehostet sein und dennoch für jede wesentliche Handlung von einem externen Administrator, Identity Provider oder Managed Platform abhängen. **Rechtlich.** Standort liefert Evidenz, entscheidet aber nicht die Jurisdiktion. Rechtliche Exposition hängt von Betreiber, Eigentümer, Muttergesellschaft, Vertragspartner und dem Recht ab, das jede Beziehung regelt. Ein Domain-Suffix oder eine Büroadresse ist ein Signal, keine Schlussfolgerung. **Lieferkette.** Hardware, Firmware, Software-Updates, Package Registries und spezialisierte Wartung sind alles Kontrollpunkte. Im Juli 2024 störte ein fehlerhaftes Update eines einzigen Sicherheitsanbieters weltweit Systeme bei Fluggesellschaften, Krankenhäusern und öffentlichen Diensten, unabhängig davon, wo diese Systeme gehostet wurden. Eine Ebene zu verlagern, während darunter ein nicht untersuchter Kontrollpunkt bestehen bleibt, schafft keine Souveränität. **Information.** Institutionen hängen auch davon ab, wie ihre Informationen veröffentlicht und interpretiert werden. Wenn öffentliche Information nur über eine proprietäre Plattform oder durch Raten eines Modellanbieters verstanden werden kann, wurde ein Teil der Publikationsgrenze der Institution nach außen verschoben. Hier berührt Souveränität unsere Arbeit an [AI-Readiness](/de/topics/ai-readiness). Europäische Regulierung spiegelt diese geschichtete Sicht zunehmend wider. NIS2 verpflichtet wesentliche und wichtige Einrichtungen, die Sicherheit ihrer Lieferketten zu berücksichtigen, nicht nur die Sicherheit ihrer eigenen Systeme. Die Logik ist dieselbe: Kontrolle ist nur so stark wie die am wenigsten untersuchte Ebene unter der Funktion. ## Eigentum und Kontrolle sind verschieden {#eigentum-und-kontrolle-sind-verschieden} Es liegt nahe, Souveränität mit Eigentum gleichzusetzen. Wenn wir es besitzen, kontrollieren wir es. In der Praxis laufen beides ständig auseinander. Eine Organisation kann ihre Infrastruktur besitzen und trotzdem von einem einzelnen Anbieter für Management, einer proprietären Plattform für Konfiguration, einem externen Team für Wiederherstellung oder einer einzigen Upstream-Route für Konnektivität abhängen. Eigentum gibt einen Titel. Es gibt nicht die Fähigkeit zu handeln. Auch das Gegenteil ist wahr. Infrastruktur zu nutzen, die jemand anderem gehört, nimmt Kontrolle nicht automatisch weg. Eine geregelte Beziehung kann echte Kontrolle geben, wenn Zugriff, Autorität, Jurisdiktion, Sicherheit, Kontinuität und Exit explizit und durchsetzbar sind. Das ist wichtig, weil es einen realistischeren Weg eröffnet. Keine Institution kann jedes Kabel, jeden Server und jede Komponente besitzen, auf der sie beruht. Sie kann aber die Bedingungen definieren, unter denen eine Abhängigkeit akzeptabel ist, und sicherstellen, dass diese Bedingungen überprüfbar sind. Die Frage lautet nicht: „Wem gehört alles?“ Die Frage lautet: **Welche Rechte und Fähigkeiten machen Kontrolle für die Funktion real, die wir schützen müssen?** ## Eine Liste von Alternativen ist kein Exit {#eine-liste-von-alternativen-ist-kein-exit} Eine häufige Beruhigung in Souveränitätsdiskussionen lautet, dass Alternativen existieren. Es gibt andere Clouds, andere Anbieter, andere Produkte. Also sei die Abhängigkeit kein Problem. Eine Alternative am Markt ist kein Exit. Eine Abhängigkeit ist erst substituierbar, wenn die Institution beschreiben kann, wie die wesentliche Funktion in eine andere operative Situation wechseln würde, ohne Fähigkeit, Daten, Identität, Sicherheit oder Wiederherstellungsvermögen zu verlieren. Das bedeutet typischerweise zu verstehen: - wie Daten das System verlassen und ankommen, und in welcher Form; - wie sich Identität und Zugriff verändern; - auf welchen Protokollen und Schnittstellen die Funktion beruht; - wie Schlüssel und Zertifikate umziehen; - welche Verfahren und Fähigkeiten sich ändern müssen; - welche vertraglichen oder rechtlichen Einschränkungen gelten; - wie lange alte und neue Systeme parallel laufen müssen und wie Rollback funktioniert. Der Data Act hat begonnen, einen Teil davon für Cloud-Dienste anzugehen, indem er Verpflichtungen festlegt, die den Wechsel zwischen Anbietern erleichtern sollen. Das ist ein bedeutender Schritt. Für sich allein macht er eine konkrete Institution noch nicht wechselbereit. **Substitution ist keine Eigenschaft des Marktes. Sie ist eine Eigenschaft des deployten Systems.** Daraus folgt unser stärkster Souveränitätstest: Kann sich die Architektur bewusst verändern, ohne die Funktion zu verlieren, die sie schützen soll? ## Souveränität erfordert die Fähigkeit zu urteilen {#souveränität-erfordert-die-fähigkeit-zu-urteilen} Jede Souveränitätsbewertung beruht letztlich auf Aussagen. Ein Anbieter erklärt, wo Daten verarbeitet werden. Ein Vertrag legt fest, wer Zugriff hat. Ein Zertifikat bestätigt einen Standard. Ein Migrationsplan verspricht, dass Wechsel möglich ist. Einige dieser Aussagen sind gut belegt, andere nicht. Der Unterschied ist nur für jemanden sichtbar, der sie beurteilen kann. Deshalb behandeln wir Urteilsfähigkeit als Voraussetzung für Souveränität, nicht als optionalen Zusatz. Eine Institution, die nicht beurteilen kann, was Anbieter ihr über Kontrolle sagen, hat keine Kontrolle. Sie vertraut. Dieses Vertrauen kann gerechtfertigt sein, aber es ist etwas anderes. Urteilsfähigkeit ist hier kein Dokument und keine Checkliste. Sie ist ein Zustand, den die Institution erreichen und erhalten muss: Menschen, die die Abhängigkeiten gut genug verstehen, um die richtigen Fragen zu stellen, eine ausweichende Antwort zu erkennen und zu wissen, welche Evidenz die Sache entscheiden würde. Dasselbe gilt für die Systeme, die eine Institution verwendet. Ein Monitoring- oder Beschaffungssystem, das eine Deklaration nicht von einem verifizierten Fakt unterscheiden kann, gibt diese Verwirrung an alle weiter, die sich darauf verlassen. Hier berührt Souveränität unsere Arbeit an [Fähigkeitstransfer](/de/topics/capability-transfer). Formales Eigentum ohne die Fähigkeit, ein System zu beurteilen und zu verändern, ist eine schwache Form von Kontrolle. Jede wichtige Entscheidung läuft weiterhin durch das Verständnis eines anderen. ## Nicht jede Evidenz sagt dasselbe {#nicht-jede-evidenz-sagt-dasselbe} Eine Souveränitätsaussage zu bewerten beginnt damit, zu wissen, was jede Art von Evidenz zeigen kann und was nicht. Ein in einem Browser beobachteter Request kann zeigen, dass eine Seite einen Dritten kontaktiert. Er kann nicht zeigen, wo das Backend läuft. Ein DNS-Eintrag kann zeigen, dass ein Anbieter berechtigt ist, im Namen einer Organisation E-Mail zu versenden. Er kann nicht zeigen, dass derselbe Anbieter ihre Anwendungen hostet. Eine Anbietererklärung zeigt, was der Anbieter erklärt. Sie zeigt nicht, wovon eine konkrete Workload zu einem konkreten Zeitpunkt abhängt. Ein Eigentumsnachweis stellt rechtlichen Titel fest. Er stellt keine operative Unabhängigkeit fest. Das sind keine Schwächen der Evidenz. Es sind ihre Grenzen. Der Fehler besteht darin, Signale verschiedener Art in einen einzigen Souveränitätsscore zu mischen, der verbirgt, was jedes davon tatsächlich beweist. Wir halten sie getrennt. Ein Signal bleibt ein Signal. Unabhängige Signale, die übereinstimmen, stärken einen Befund. Eine Schlussfolgerung muss die Art der Evidenz tragen, auf der sie beruht, und die Unbekannten, die darunter verbleiben. ## Souveränität ist keine Autarkie {#souveränität-ist-keine-autarkie} Souveränität wird manchmal als Aufruf verstanden, alles intern zu bauen oder jede ausländische Abhängigkeit auszuschließen. So sehen wir es nicht, und wir glauben nicht, dass das funktionieren würde. Komplexe Infrastruktur wird durch Interdependenz gebaut. Die Aufgabe besteht darin zu wissen, welche Abhängigkeiten akzeptabel sind, welche strategisch sind, welche stärkere Evidenz brauchen, welche einen Exitpfad brauchen und welche Kontrolle auf eine Weise konzentrieren, die eine Institution nicht akzeptieren sollte. Eine gute Souveränitätsarchitektur kann externe Anbieter enthalten, auch außereuropäische. Was sie nicht enthalten kann, sind kritische Abhängigkeiten, die niemand kartiert hat, niemand steuern kann und niemand zu ersetzen weiß. Das ist der Unterschied zwischen Interdependenz und Abhängigkeit ohne Kontrolle. ## Wie wir gemeinsam daran arbeiten {#wie-wir-gemeinsam-daran-arbeiten} Unser Ansatz zur Souveränität folgt derselben Reihenfolge wie der Rest unserer Arbeit. **Die Abhängigkeit kartieren.** Bevor Alternativen vorgeschlagen werden, identifizieren wir, worauf die Funktion über physische, operative, rechtliche, Lieferketten- und Informationsebenen hinweg beruht und wo Kontrolle konzentriert ist. **Die Kontrollgrenze definieren.** Gemeinsam mit der Institution bestimmen wir, welche Abhängigkeiten akzeptabel sind, welche Bedingungen brauchen und welche für diese Funktion nicht akzeptabel sind. Diese Bedingungen werden in überprüfbaren Begriffen ausgedrückt. **Die Alternative bauen, wo die Grenze nicht akzeptabel ist.** Nicht alles auf einmal. Zuerst die strategischen Funktionen, mit einem Migrationspfad, der wirklich ausgearbeitet statt angenommen wurde. **Evidenz und Urteilsfähigkeit hinterlassen.** Die Institution soll mit einem Dossier enden, das sie pflegen kann, und mit Menschen, die die nächste Aussage selbst beurteilen können. Wir wenden dieselbe Disziplin auf uns selbst an. Die Infrastruktur, die wir betreiben, und die offenen Formate, die wir veröffentlichen, sind Teil davon, wie wir prüfen, ob diese Arbeitsweise in der Praxis hält. Wir können andere nicht glaubwürdig auffordern, ihre Abhängigkeiten sichtbar zu machen, während wir unseren eigenen operativen Stack als Blackbox behandeln. Wenn wir gemeinsam mit einem Partner eine Abhängigkeit betrachten, halten wir typischerweise diese Fragen fest: | Frage | Was sie sichtbar macht | | --- | --- | | Welche wesentliche Funktion unterstützt diese Abhängigkeit? | Warum sie überhaupt wichtig ist. | | Was genau wird benötigt: System, Betreiber, Route, Plattform, Autorität? | Das tatsächliche Objekt der Abhängigkeit. | | Woher wissen wir, dass die Beziehung besteht? | Die Art der Evidenz und ihre Grenzen. | | Wer kann sie steuern, ändern, aussetzen oder wiederherstellen? | Wo Kontrolle tatsächlich liegt. | | Welche rechtlichen Beziehungen gelten und welche sind ungeklärt? | Rechtliche Exposition. | | Was passiert mit der Funktion, wenn sie verschwindet? | Die Konsequenz des Verlusts. | | Kann sie isoliert oder ersetzt werden, und was muss mit umziehen? | Die tatsächliche Substitutionsgrenze. | | Was bleibt unverifiziert? | Die ehrliche Grenze der Bewertung. | ## Wo wir vorsichtig sind {#wo-wir-vorsichtig-sind} Wir halten uns an einige Verpflichtungen darüber, was wir behaupten. Wir nennen eine Abhängigkeit nur in dem Maß kontrolliert, in dem Evidenz Kontrolle über die betreffende Funktion stützt. Wir leiten Jurisdiktion nicht aus einem Domainnamen oder einer Hosting-Adresse ab und behandeln eine Anbietererklärung nicht als Beweis dafür, wie ein System tatsächlich läuft. Wir nennen eine Abhängigkeit nicht ersetzbar, nur weil es eine Alternative am Markt gibt. Nur ein tatsächlich ausgearbeiteter Migrationspfad verdient dieses Wort. Wir verstecken ungelöste Abhängigkeiten nicht hinter einem einzigen Score. Wo etwas unbekannt ist, sagen wir das. Und wir präsentieren Souveränität nicht als Isolation. Unser Ziel ist enger: die praktische Fähigkeit zu wissen, wo Abhängigkeit liegt, zu entscheiden, welche Abhängigkeit akzeptabel ist, und zu handeln, wenn sie es nicht ist. * * * ## Weiterführende Literatur {#weiterführende-literatur} - [Richtlinie (EU) 2022/2555 (NIS2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union. - [Verordnung (EU) 2023/2854 (Data Act)](https://eur-lex.europa.eu/eli/reg/2023/2854/oj), einschließlich Bestimmungen zum Wechsel zwischen Datenverarbeitungsdiensten. **Verwandte Themen:** [Fähigkeitstransfer](/de/topics/capability-transfer) · [Resilienz](/de/topics/resilience) · [AI-Readiness](/de/topics/ai-readiness) * * * ## Änderungen an dieser Position {#änderungen-an-dieser-position} - 24. September 2026 — Erstmals veröffentlicht. Materielle Änderungen werden hier mit Datum aufgeführt. Korrekturen an Formulierungen oder Links nicht. ## Auf dieser Seite {#auf-dieser-seite} ESFI — civilization infrastructure · https://esfi.eu