9. März 2026

Cloud als Kompromiss, Souveränität als Arbeit: Eine Strukturanalyse zu Beschaffung, Steuerung und Verantwortung

1. Einstieg: Warum „Alles aus einer Hand“ in der Cloud fast immer die falsche Antwort ist

„Alles aus einer Hand“ klingt nach Entlastung. Nach weniger Schnittstellen, weniger Abstimmung, weniger Verantwortung. In der Cloud ist es jedoch oft der schnellste Weg in Kosten-, Steuerungs- und Abhängigkeitsprobleme.

Die öffentliche Verwaltung steht bei der Digitalisierung vor einer Zwangslage, aus der es keinen perfekten Ausweg gibt:

1. nicht digitalisieren → Leistungs- und Funktionsversagen
2. alles selbst betreiben → Personal- und Kostenversagen
3. Public Cloud nutzen → Souveränitäts- und Abhängigkeitsrisiken.

Jede dieser Optionen hat strukturelle Nachteile und keine löst das Kernproblem für sich: leistungsfähig digitalisieren zu müssen, ohne die Steuerungs- und Verantwortungskette im Betrieb zu verlieren. Deshalb lautet die reale Frage längst nicht mehr, ob Cloud „ja oder nein“, sondern: Welche Funktionen geben wir ab und welche behalten wir unter eigener Kontrolle?

Genau an dieser Stelle entstehen derzeit die größten Brüche in der Praxis:

• Cloud-Kosten explodieren, obwohl „Skalierung“ versprochen war
• „Alles-aus-einer-Hand“-Vergaben enden in faktischem Lock-in
• Schatten-SaaS wächst außerhalb von Governance und Beschaffung; selten ein „Kulturproblem“, meist ist es das Ausweichverhalten, wenn Governance und Beschaffung nicht schnell genug anschlussfähige, sichere Optionen bereitstellen
• NIS-2 und der Cyber Resilience Act treffen auf Cloud-Strukturen, die dafür nicht gebaut wurden
• „Digitale Souveränität“ wird politisch beschworen, bleibt aber operativ undefiniert.

Das Grundproblem liegt nicht in fehlendem Willen zur Digitalisierung, sondern in einer fehlenden Übersetzung zwischen Marktlogik der Hyperscaler, vergaberechtlichen Strukturen und der organisatorischen Realität der Verwaltung, also dort, wo entschieden wird, wer steuert, wer verantwortet und wer im Betrieb tatsächlich die Kontrolle hat.

Und genau deshalb wirkt das Souveränitäts-Narrativ in der Praxis so oft schief: Die Programme verlangen Migration, Umbau und Geld, aber die Verantwortung bleibt persönlich, voll und ganz, auch dann, wenn die tatsächliche Kontrolle über Plattform, Lieferkette und Betrieb nur begrenzt wächst.

2. Realität: Cloud ist kein Produkt, sondern ein Betriebsmodell

Cloud ist kein Produkt, das man kauft und benutzt, sondern ein Betriebsmodell und genau hier liegt ein zentraler Denkfehler vieler Cloud-Vergaben.
Denn nicht der Rahmenvertrag macht Cloud steuerbar, sondern die Art und Weise, wie der Staat Cloud schneidet, organisiert und betreibt.

Warum diese Unterscheidung so entscheidend ist, zeigt sich schon bei der Ausgangslage.
„Nicht digitalisieren“ ist faktisch keine Option. Gleichzeitig sind eigene physische Rechenzentren kein flächendeckender Ausweg: Sie sind personalintensiv, teuer und zu langsam, um den heutigen Anforderungen gerecht zu werden. Der Staat nutzt Cloud also nicht, weil sie ideal wäre, sondern weil alle Alternativen schlechter sind.

Oder zugespitzt: Cloud ist keine Vision, sondern ein Kompromiss unter schlechten Optionen.
Ohne Cloud-ähnliche Betriebsmodelle kommt Verwaltung in der Breite kaum noch voran, mit Cloud verliert sie Kontrolle.

Die entscheidende Frage ist deshalb längst nicht mehr, ob Cloud genutzt werden soll oder nicht, sondern welche Aufgaben bewusst ausgelagert werden und wo der Staat Kontrolle behalten muss.

Vor diesem Hintergrund erklärt sich auch, warum so viel IaaS und PaaS beschafft wird. Diese Ebenen werden nicht gewählt, weil sie „modern“ sind, sondern weil der Staat digitalisieren will, ohne seine Fachlogik, Architekturverantwortung und Steuerungsfähigkeit vollständig an SaaS-Anbieter auszulagern. Kurz: SaaS kauft Funktion, IaaS und PaaS erhalten Gestaltungsmacht.

Über IaaS und PaaS entscheidet der Staat weiterhin, wie Architektur aufgebaut ist, wie Datenflüsse, Identitäts- und Berechtigungskonzepte sowie Logging funktionieren und wie Exit-Szenarien, Parallelbetrieb oder Migration gedacht werden. Das ist kein Selbstzweck, sondern bewusste Risikosteuerung.

Dabei wird jedoch häufig der Elefant im Raum übersehen: Shared Responsibility.
Cloud bedeutet nicht weniger Verantwortung, sondern anders verteilte Verantwortung. Portale, Policies, Skripte, IAM-Logiken, Logging, Compliance-Artefakte und Kostensteuerung verschwinden nicht in der Cloud, sie müssen gestaltet, betrieben und überwacht werden. Das muss jemand können. Und dauerhaft leisten.

Genau deshalb braucht es eine Governance-Schicht: Standards und Leitplanken, Landing Zones, Allow-/Block-Entscheidungen, FinOps sowie Audit- und Compliance-Nachweise, entweder intern aufgebaut oder als klar getrennte Steuerungsdienstleistung („Broker“) beschafft.

Drei Fragen sollte daher jede Cloud-Vergabe beantworten können:

• Haben wir Cloud-Kompetenz in den Bereichen IAM, Policies, Logging, Export, Backup und Geo-Settings wirklich intern?
• Wenn nein: Haben wir eine Governance-Rolle (Broker, FinOps, SecOps) sauber und getrennt beschafft?
• Wird Exit als Architektur- und Betriebsaufgabe behandelt oder lediglich als Datenexport?

Diese Kontroll- und Steuerungsschichten liegen in der Praxis überwiegend auf IaaS/PaaS-Ebene, oder müssen zumindest dort ansetzen, weil dort die Baseline (Identity, Netzwerk, Logging, Policies) definiert wird. Fehlen sie, entstehen zwangsläufig Schatten-SaaS, Kostenexplosionen und Sicherheitslücken und am Ende vor allem eines: kein Überblick.

3. Kernthese: Souveränität als Schadensbegrenzung – nicht als Versprechen

Digitale Souveränität entsteht unter den aktuellen Marktbedingungen und der Standardvertragslogik der Hyperscaler nicht im Rahmenvertrag. Sie entsteht, wenn überhaupt, in der Organisation. Und selbst dort nicht als Zustand, sondern allenfalls als Schadensbegrenzung.

Man kann es auch einfach ausdrücken: Verantwortung ohne Kontrolle ist keine Souveränität und genau diese Schere geht in vielen Cloud- und Souveränitätsprogrammen gerade auf.

Operative Souveränität kann eine nicht-souveräne Cloud beherrschbar machen, sie kann Risiken sichtbar und handhabbar halten, sie macht diese Cloud aber nicht souverän. Das ist eine unbequeme, aber notwendige Klarstellung. Organisation, Kompetenz und Governance ersetzen keine souveräne Cloud. Sie können keine „staatstypische“ Verantwortungslogik herstellen - also eine Risikoverteilung, die bei kritischen Verwaltungsleistungen nicht bei Service Credits stehenbleibt -, keine absoluten Zugriffssperren garantieren und auch keine anbietergetriebene Governance außer Kraft setzen.

Was sie jedoch leisten – und das ist der entscheidende Punkt –, ist etwas anderes: Sie entscheiden darüber, ob der Staat die Risiken einer nicht-souveränen Cloud überhaupt beherrscht oder ihnen ausgeliefert ist.

Governance ist dabei kein Allheilmittel. Sie beseitigt keine strukturellen Vertragsdefizite und löst keine Abhängigkeiten auf. Aber sie ist der einzige realistisch verfügbare Hebel, um diese Defizite handhabbar zu machen. In der Praxis bedeutet das vor allem, Risiken nicht zu verdrängen, sondern bewusst zu begrenzen: durch transparente Konfigurationen, klare Verantwortlichkeiten und überprüfbare Steuerungsmechanismen.

Operative Souveränität zeigt sich deshalb weniger in großen Versprechen als in konkreter Arbeit: in der Vermeidung von Fehlkonfigurationen bei Geo-Einstellungen, Backups, IAM, Logging oder Schlüsselmanagement; in der Kosten- und Abhängigkeitskontrolle durch FinOps und belastbare Transparenz über Nutzung und Wachstum; in der Vorbereitung von Exit-Szenarien, auch wenn diese vertraglich nicht geliefert werden, etwa durch Architekturentscheidungen, Portabilität und Parallelbetrieb; und nicht zuletzt darin, Transparenz dort herzustellen, wo Verträge sie nicht vorsehen, etwa bei Nutzung, Subdiensten sowie Sicherheits- und Compliance-Artefakten.

Das gilt übrigens genauso für die Security-Seite: SBOMs, Audits und Compliance-Artefakte schaffen Transparenz, sie helfen beim Bewerten und Nachweisen, aber sie verhindern keinen Fehlzustand. Wer „Souveränität“ ernst meint, muss neben Governance auch technische Guardrails, also Mechanismen, die bestimmte Konfigurationen gar nicht zulassen (z. B. Region- oder Logging-Policies, die technisch erzwungen werden), beschaffen und durchsetzen, also Mechanismen, die bestimmte Konfigurationen und Risiken gar nicht erst zulassen, statt sie nur im Reporting wiederzufinden.

Governance ist damit Schadensbegrenzung, nicht Souveränitätsersatz. Wer diese beiden Ebenen nicht sauber trennt, landet zwangsläufig in falschen Erwartungen, entweder an Verträge, die mehr leisten sollen, als sie können, oder an Organisationen, denen Fähigkeiten zugeschrieben werden, die sie strukturell nicht haben.

4. Leitprinzip: Trennen, wo der Markt trennt – und wo Steuerung nötig ist

Wenn Cloud nicht als Produkt, sondern als Betriebsmodell verstanden wird, folgt daraus zwangsläufig ein Leitprinzip für Beschaffung und Organisation: Es muss dort getrennt werden, wo der Markt selbst trennt und dort, wo Steuerung erforderlich ist. Das ist keine Ideologie und kein dogmatischer Architekturansatz, sondern eine pragmatische Reaktion auf reale Markt- und Risikostrukturen.

Der Cloud-Markt differenziert seine Leistungen bereits sehr klar. Auf der einen Seite stehen Infrastruktur- und Plattformleistungen (IaaS und PaaS), die stark standardisiert, API-getrieben und zumindest theoretisch austauschbar sind, gleichzeitig aber erhebliche Architektur-, Sicherheits- und Betriebsrisiken mit sich bringen.

Auf einer anderen Ebene liegen Anwendungen und Fachverfahren (SaaS), die funktional, fachnah und häufig proprietär ausgestaltet sind und unmittelbar auf Arbeitsprozesse, Datenverarbeitung und Verwaltungsrealität wirken.

Davon wiederum zu unterscheiden ist die Steuerungs- und Governance-Ebene, die nicht marktfähig ist, sondern organisationsabhängig bleibt und von interner Verantwortung, Aufsicht und Kontrolle geprägt wird.

Diese Trennung ist gelebte Realität des Marktes. Eine Ausschreibung, die diese Ebenen ignoriert oder bewusst zusammenzieht, erzeugt deshalb nicht Einfachheit, sondern baut implizit Lock-in auf. Unterschiedliche Risikoprofile, Verantwortlichkeiten und Betriebslogiken werden dann künstlich gebündelt, ohne dass sie noch sinnvoll gesteuert oder entkoppelt werden können.

Auch vergaberechtlich ist diese Differenzierung kein Problem, sondern regelmäßig sachlich geboten. Unterschiedliche Leistungsgegenstände dürfen – und müssen – getrennt betrachtet werden, schon weil sie völlig unterschiedliche Anforderungen an Eignung, Leistungsfähigkeit und Zuschlagskriterien stellen. Eine Bündelung ist nur dann zulässig, wenn sie technisch oder wirtschaftlich zwingend erforderlich ist; organisatorische Bequemlichkeit oder der Wunsch nach „weniger Schnittstellen“ reichen dafür nicht aus.

Gerade bei Cloud-Leistungen wird dieser Unterschied systematisch unterschätzt:
Infrastruktur- und Plattformleistungen (IaaS/PaaS), Fachanwendungen (SaaS) und Governance-Funktionen folgen nicht nur unterschiedlichen technischen Logiken, sondern auch unterschiedlichen vergaberechtlichen Bewertungsmaßstäben.
Sie erfordern jeweils andere Eignungsnachweise, andere Zuschlagskriterien und adressieren Risiken zu völlig unterschiedlichen Zeitpunkten, häufig erst im laufenden Betrieb.
Wer diese Ebenen bündelt, vereinfacht nicht, sondern verschiebt Risiken in eine Phase, in der sie kaum noch korrigierbar sind.

Je nachdem, ob ich Transparenz einkaufe (Auditfähigkeit) oder technische Verhinderung (Guardrails, Policy-Enforcement), sehen Zuschlagskriterien völlig anders aus und genau deshalb ist die saubere Trennung der Ebenen nicht nur Architektur, sondern Vergabelogik.

Beispiel:

• IaaS/PaaS: Eignung → Security-Betriebsfähigkeit (z. B. IAM, Logging, Incident Response), Nachweis durch Prozesse/Teams/Referenzen. Zuschlag → Guardrails, Automatisierung, Nachweisführung, FinOps-Transparenz.
• SaaS: Eignung → Fachreferenzen/Datenschutz/Integrationsfähigkeit. Zuschlag → Fachnutzen/Usability/Prozesspassung/Exit-Szenario.

Besonders wichtig ist dabei auch die saubere Trennung zwischen Steuerung und Leistungserbringung. Zwischen Governance-Funktionen und operativen Cloud-Leistungen besteht regelmäßig kein zwingender Zusammenhang, der eine gemeinsame Vergabe rechtfertigen würde. Im Gegenteil: Werden diese Funktionen gebündelt, verschwimmen Verantwortlichkeiten, und die Möglichkeit, Eignung, Qualität und Wirtschaftlichkeit differenziert zu bewerten, geht verloren.

Das bedeutet nicht, dass Cloud-Leistungen immer kleinteilig oder atomisiert vergeben werden müssen. Es bedeutet aber, dass jede Bündelung erklärungsbedürftig ist. Wer Steuerung, Betrieb und Leistungserbringung in einer Hand zusammenführt, muss darlegen können, warum diese Funktionen untrennbar zusammengehören – technisch, wirtschaftlich oder sicherheitsrelevant. Genau diese Begründung fehlt derzeit in vielen Cloud-Vergaben. Und dort, wo sie fehlt, entstehen strukturelle Abhängigkeiten, die später als „unvermeidbar“ beschrieben werden, obwohl sie vergaberechtlich und organisatorisch vermeidbar gewesen wären.

5. Modelle: Wie Cloud-Steuerung organisiert werden kann

Genau diese Differenzierung fehlt derzeit in vielen Cloud-Strategien und Vergaben. Cloud wird entweder als rein technisches Thema behandelt oder pauschal „outgesourct“, ohne sauber zu trennen, wer eigentlich steuert und mit welchen Folgen für Kosten, Abhängigkeiten und Verantwortlichkeit. Tatsächlich lassen sich drei Grundmodelle unterscheiden, die sich weniger durch Technik als durch ihre Steuerungslogik unterscheiden.

Modell A: Interne Steuerung (interner CSB)
In diesem Modell verbleibt die Steuerung der Cloud vollständig innerhalb der eigenen Organisation. Architekturentscheidungen, Kostenkontrolle, Sicherheits- und Governance-Fragen werden intern verantwortet. Das schafft maximale Transparenz und ermöglicht eine direkte Kontrolle über Nutzung, Risiken und Weiterentwicklung, ohne zusätzliche Abhängigkeit von externen Dritten.

Gleichzeitig ist dieses Modell anspruchsvoll. Es erfordert tiefe Cloud-Kompetenz, dauerhaft verfügbare personelle Ressourcen und die Fähigkeit, diese Steuerungsfunktion über Projektlaufzeiten, Haushaltsjahre und Legislaturperioden hinweg stabil aufrechtzuerhalten. Tragfähig ist dieser Ansatz vor allem für größere Ressorts, zentrale IT-Dienstleister oder Organisationen mit einer langfristig angelegten Cloud-Strategie.

Modell B: Externe Steuerung (CSB als Governance-Dienstleistung)
Hier werden Steuerungs-, Überwachungs- und Konsolidierungsaufgaben auf eine externe Einheit übertragen, während Beschaffungs- und Zuschlagsentscheidungen bewusst bei der öffentlichen Auftraggeberin verbleiben. Der externe CSB unterstützt etwa bei der Nutzungskontrolle, bei Kosten- und Compliance-Transparenz sowie bei Architektur-, Sicherheits- oder Exit-Fragen, ohne selbst über Anbieter, Preise oder Abrufe zu entscheiden.

Vergaberechtlich ist dieses Modell möglich, weil die wesentlichen Vergabeentscheidungen – Auswahl, Wertung, Zuschlag und Abruf – ausdrücklich beim öffentlichen Auftraggeber verbleiben. Der CSB erbringt eine Steuerungs- und Unterstützungsleistung, ersetzt aber keine Vergabestelle.

Steuerung ja – Beschaffung nein. Wird diese Grenze eingehalten, ist Modell B rechtmäßig, aber anspruchsvoll. Es funktioniert nur mit klaren Leitplanken, sauber definierten Rollen und einem ausgeprägten Verständnis dafür, dass Governance eine eigene Leistung ist und kein Ersatz für vergaberechtliche Verantwortung.

Modell C: „Managed Cloud“ als Bündel

Beim dritten Modell übernimmt ein externer Anbieter nicht nur den Betrieb, sondern häufig auch Steuerungsfunktionen sowie den Zugang zu Hyperscalern, etwa über Reseller- oder Unterauftragsmodelle. Organisatorisch wirkt dieser Ansatz zunächst attraktiv: geringe Einstiegshürden, schnelle Entlastung, ein zentraler Ansprechpartner.

Die Risiken liegen jedoch auf der Hand. Preis- und Kostenlogiken werden intransparent, Steuerungsmöglichkeiten verlagern sich nach außen, und Hyperscaler-AGB „wandern nach oben“ in Vertragskonstruktionen, die für die öffentliche Hand nur noch schwer durchschaubar sind.

Hinzu kommt ein weiteres, häufig unterschätztes Risiko: Ein „Managed-Cloud“-Modell setzt faktisch voraus, dass der Leistungsumfang – insbesondere im SaaS-Bereich – bereits zum Zeitpunkt der Vergabe hinreichend bestimmt ist. Genau das ist in der Verwaltung jedoch selten der Fall. Fachverfahren, Plattformen und Dienste werden oft erst schrittweise konkretisiert, weiterentwickelt oder neu priorisiert.

Wird Steuerung, Betrieb und Providerzugang frühzeitig auf einen einzigen Managed-Cloud-Anbieter gebündelt, entsteht das reale Risiko, dass spätere fachliche Anforderungen nicht oder nur zu deutlich schlechteren Konditionen abgebildet werden können, etwa weil bestimmte SaaS-Lösungen nicht mit den vorgesehenen Hyperscalern kompatibel sind oder außerhalb des Leistungsportfolios des Anbieters liegen.

Vergaberechtlich ist dieses Modell nicht per se unzulässig. Es nähert sich jedoch strukturell einem Generalunternehmer-Modell an, bei dem wesentliche Vorentscheidungen über Providerwahl, Leistungszuschnitt und technische Weiterentwicklung faktisch auf den Auftragnehmer verlagert werden.

Während diese Logik bei hinreichend bestimmten und weitgehend standardisierten Leistungsgegenständen – etwa im Bau – beherrschbar sein kann, trifft sie bei Cloud-Betriebsmodellen auf einen dynamischen (vor allem bei SaaS!), fortentwickelten Leistungsgegenstand. Genau hier beginnt das vergaberechtliche und steuerungslogische Risiko.

Das Risiko liegt nicht im Generalunternehmer-Modell per se, sondern in der Kombination aus dynamischem Leistungsgegenstand und vorgezogener Bündelentscheidung.

Souveränitäts- und steuerungslogisch ist dieses Modell deshalb der problematischste Weg: Steuerung, Leistungserbringung, Providerwahl und Weiterentwicklung fallen erneut in einer Hand zusammen. Spätere fachliche Entscheidungen werden dadurch strukturell vorgeprägt oder faktisch blockiert.

Naheliegend erscheint der Versuch, dieses Risiko durch mehrere parallele „Managed-Cloud“-Rahmenvereinbarungen abzufedern. Tatsächlich kann dies einzelne Abhängigkeiten reduzieren und die Auswahl im Einzelfall erweitern. Die grundlegenden strukturellen Probleme löst es jedoch nicht.

Denn auch bei mehreren Managed-Cloud-Anbietern bleibt die Steuerung jeweils eng mit Betrieb und Providerzugang verknüpft. Die eigentliche Governance wird nicht zurück in die Organisation geholt, sondern lediglich auf mehrere externe Akteure verteilt. Zugleich bleibt das zentrale Problem bestehen, dass fachliche Anforderungen – insbesondere im SaaS-Bereich – häufig erst im Laufe der Zeit konkretisiert werden, während technische und vertragliche Vorfestlegungen bereits getroffen sind. Je dynamischer, desto gefährlicher die Vorverlagerung von Entscheidungen.

Mehrere Rahmenvertragspartner können den Preis- und Anbieterdruck erhöhen und einzelne Sackgassen vermeiden, die Kopplung von Steuerung und Providerzugang bleibt aber bestehen. Mehr Anbieter erhöhen damit vor allem die Komplexität, nicht automatisch die Souveränität.

Ergänzung zu Modell C: Ein europäisches Gegenmodell – bewusste Trennung von Steuerung und Betrieb

Dass die beschriebenen Risiken nicht bloß theoretischer Natur sind, zeigt der Blick auf einzelne europäische Verwaltungsmodelle, die sich bewusst gegen ein klassisches „Managed-Cloud“-Bündel entschieden haben.

In diesem Ansatz werden Cloud-Steuerung und -Governance organisatorisch und vergaberechtlich strikt vom operativen Betrieb und vom Providerzugang getrennt. Eine zentrale Governance-Instanz fungiert dabei nicht als Generalunternehmer, sondern als Intermediär zwischen Verwaltungseinheiten und Public-Cloud-Anbietern. Sie stellt standardisierte Grundlagen wie Cloud-Foundations, Landing Zones, Sicherheits- und Governance-Mechanismen sowie Kosten- und Compliance-Transparenz bereit, ohne selbst fachliche Anforderungen festzulegen oder Vergabe- und Anbieterentscheidungen zu treffen.

Die Rollenverteilung ist dabei klar:

• Die jeweilige Verwaltungseinheit bleibt für fachliche Anforderungen, Abrufentscheidungen, den Betrieb ihrer Workloads sowie für Governance und Compliance verantwortlich.
• Die zentrale Governance-Instanz unterstützt durch Steuerungs-, Kontroll- und Konsolidierungsfunktionen (z. B. IAM-Anbindung, Logging, FinOps, Compliance-Transparenz), ohne Beschaffungsentscheidungen zu übernehmen.
• Die Public-Cloud-Anbieter verantworten ausschließlich den Betrieb ihrer Plattformen.

Governance und Beschaffung werden damit bewusst nicht zusammengelegt, sondern institutionell getrennt. Dieses Modell reduziert nicht Komplexität, sondern ordnet Verantwortung klar zu und erhält so operative Steuerungsfähigkeit auch unter nicht-souveränen Marktbedingungen.

Die hier skizzierte Struktur ist bewusst abstrakt gehalten. Die konkrete Ausgestaltung und die ihr zugrunde liegende vertragliche Logik eines europäischen Praxisbeispiels werde ich in einem gesonderten Beitrag aufgreifen.

6. Fazit

Cloud ist kein politisches Wunschprojekt, sondern ein Zwang, entstanden aus Personalmangel, wachsender Komplexität und dem realen Druck zur Digitalisierung.

Digitale Souveränität lässt sich unter diesen Bedingungen nicht als Label einkaufen und auch nicht vertraglich versprechen.

Sie entsteht dort, wo Gestaltung stattfindet. In der Organisation, in der Architektur, in der bewussten Trennung von Verantwortung und letztlich in der sehr konkreten Frage, wer steuert und wer lediglich Leistungen erbringt.

Governance kann dabei keine souveräne Cloud ersetzen. Aber ohne Governance wird jede Cloud unsouverän. Cloud bleibt der Kompromiss. Souveränität ist die Arbeit daran.