Digitale Unabhängigkeit entsteht nicht durch Willensbekundungen, sondern durch Architekturentscheidungen. Dieser Beitrag zeigt, warum Datenhoheit bereits auf Infrastrukturebene beginnt – und wie BW.Tech Cloud-Strukturen bewusst souverän designt.
Kaum ein Begriff hat in den letzten Jahren eine so steile Karriere hingelegt wie „digitale Souveränität“. Er taucht in Koalitionsverträgen auf, in Strategiepapieren von Branchenverbänden, auf Konferenzbühnen zwischen Keynotes über KI und Zero Trust. Und doch bleibt er erstaunlich oft genau das: ein Begriff. Ohne Architektur dahinter.
Das Problem dabei ist nicht mangelnder politischer Wille. Das Problem ist, dass Souveränität in vielen Diskussionen als Feature verstanden wird – als etwas, das man einer bestehenden Cloud-Umgebung nachträglich hinzufügt. Ein Häkchen bei „Rechenzentrum in Deutschland“, ein Verweis auf die DSGVO, vielleicht noch ein Badge auf der Landingpage. Fertig.
Wer so denkt, verwechselt Compliance mit Kontrolle. Und genau hier wird es architektonisch relevant.
Wo Souveränität tatsächlich entsteht
Datenhoheit ist kein Zustand, den man deklariert. Sie ist das Ergebnis konkreter Designentscheidungen auf Infrastrukturebene. Das beginnt bei der Frage, wo Daten physisch liegen – und endet dort noch lange nicht. Entscheidend ist, wer Zugriff auf die Verwaltungsebene hat, welchen Rechtsräumen die Betreiberstruktur unterliegt und ob ein Unternehmen im Ernstfall tatsächlich die Kontrolle über seine eigenen Systeme behalten kann.
Ein Beispiel: Ein Unternehmen nutzt eine Public-Cloud-Lösung mit Rechenzentrumsstandort Frankfurt. Die Daten liegen physisch in Deutschland – aber der Plattformbetreiber unterliegt dem US CLOUD Act. Im Zweifel kann eine amerikanische Behörde Zugriff auf diese Daten verlangen, unabhängig davon, wo der Server steht. Der Standort allein ist also kein Garant für Souveränität. Die Betreiberstruktur ist es.
Souveränität entsteht dort, wo Infrastruktur, Betrieb und Rechtsraum zusammenfallen – und wo diese Konstellation bewusst so gestaltet wurde. Das ist keine Frage des richtigen Anbieters, sondern der richtigen Architektur.
Die vier Ebenen souveräner Cloud-Architektur
Wer digitale Souveränität ernst nimmt, muss sie auf mehreren Ebenen gleichzeitig durchdenken.
- Die erste ist die physische Ebene: Wo stehen die Systeme, wer betreibt das Rechenzentrum, und welchem Rechtsraum unterliegt der Betreiber – nicht nur der Standort?
- Die zweite ist die Betriebsebene: Wer hat administrativen Zugriff, wie sind Rollen und Berechtigungen gestaltet, und kann der Kunde im Ernstfall den Betrieb eigenständig fortführen oder übernehmen?
- Die dritte ist die Datenebene: Wo werden Daten verarbeitet, zwischengespeichert und gesichert? Werden Backups im selben Rechtsraum gehalten? Gibt es Abhängigkeiten zu Drittdiensten, die Daten in andere Jurisdiktionen spiegeln?
- Und die vierte ist die Interoperabilitätsebene: Wie stark bindet die gewählte Architektur an einen einzelnen Anbieter? Lassen sich Workloads migrieren, ohne den Betrieb zu gefährden?
Souveränität scheitert selten an der obersten Ebene. Sie scheitert an den Schichten darunter – an Abhängigkeiten, die beim Einkauf unsichtbar waren und erst beim Audit sichtbar werden.
Warum Standardlösungen das Problem nicht lösen
Die Versuchung ist groß, Souveränität über Zertifizierungen und Labels abzubilden. ISO 27001, BSI C5, „Made in Germany“ – all das sind wichtige Orientierungspunkte. Aber sie beschreiben Mindeststandards, keine Architektur.
Ein Unternehmen kann vollständig ISO-27001-zertifiziert sein und trotzdem in einer Infrastruktur arbeiten, die es im Krisenfall handlungsunfähig macht – etwa weil sämtliche Verwaltungszugänge über einen Hyperscaler laufen, dessen Geschäftsbedingungen sich über Nacht ändern können. Compliance und Kontrolle sind nicht dasselbe. Compliance fragt: Erfüllen wir die Anforderungen? Kontrolle fragt: Können wir selbst entscheiden?
Das bedeutet nicht, dass Public-Cloud-Dienste grundsätzlich problematisch sind. Microsoft 365, große Virtualisierungsplattformen, spezialisierte SaaS-Lösungen – sie alle haben ihren Platz in einer modernen IT-Architektur. Entscheidend ist, dass ihr Einsatz eine bewusste Designentscheidung ist und kein Standardreflex. Dass klar definiert ist, welche Daten und Prozesse dort liegen dürfen und welche nicht. Und dass es für die geschäftskritischen Bereiche eine Infrastruktur gibt, die nicht von den Geschäftsentscheidungen Dritter abhängt.
Wie BW.Tech diesen Ansatz umsetzt
Bei BW.Tech nennen wir das „Cloud by Design“ – und meinen damit genau dieses Prinzip: Cloud-Strukturen nicht aus dem Katalog nehmen, sondern um den konkreten Anwendungsfall herum bauen. Inhabergeführt seit 2008, mit eigenem Hochverfügbarkeits-Rechenzentrum in Deutschland und einem Technologieportfolio, das bewusst herstellerunabhängig aufgestellt ist, können wir für jeden Kunden die Architektur empfehlen, die tatsächlich passt – nicht die, die das höchste Partnervolumen bringt.
Das klingt selbstverständlich. In einer Branche, die stark von Lizenzmodellen und Reselling geprägt ist, ist es das aber nicht.
Die Frage, die sich jedes Unternehmen stellen sollte
Digitale Souveränität ist kein Projekt mit Enddatum. Sie ist (oder sollte es zumindest sein!) eine dauerhafte Haltung, die sich in jeder Architekturentscheidung widerspiegelt: in der Wahl des Betreibers, im Design der Zugriffsschichten, in der Frage, ob Interoperabilität mitgedacht oder nachgerüstet wird.
Die politische Debatte wird weitergehen. Neue Regularien werden kommen, bestehende werden verschärft. Aber ob ein Unternehmen dann souverän handlungsfähig ist, entscheidet sich nicht im Moment der Regulierung. Es entscheidet sich heute – auf der Ebene der Infrastruktur.
Die Frage, die sich Unternehmen daher stellen sollten, ist nicht, ob sie sich mit digitaler Souveränität beschäftigen sollten. Die Frage ist, ob die eigene Cloud-Architektur sie bereits ermöglicht.
