9. März 2026

Digitale Souveränität als institutionelle Governance- und Architekturleistung

Eine strukturelle Analyse der Vertragslogik öffentlicher Hyperscaler-Rahmenverträge

Digitale Souveränität entsteht nicht durch den Abschluss eines Vertrages.
Sie entsteht durch die institutionelle Fähigkeit, die darin angelegte Macht- und Verantwortungsarchitektur im Betrieb zu steuern.

Öffentliche Verwaltungen, die Cloud-Dienste globaler Hyperscaler beziehen, treten in standardisierte Vertrags- und Servicearchitekturen ein, die auf Skalierung, technische Standardisierung und operative Autonomie des Anbieters ausgelegt sind, nicht auf hoheitliche Steuerungs- und Funktionssicherungsanforderungen. Mit Zuschlag bzw. dem Vertragsabschluss entsteht daher regelmäßig keine individuell ausgehandelte Steuerungsarchitektur, sondern es wird eine vorstrukturierte Verteilung von Änderungsbefugnissen, Haftungsrisiken und operativer Verantwortung übernommen, mit Exit-Optionen als primärem Durchsetzungsinstrument.

Der Beitrag rekonstruiert diese Verteilung anhand mehrerer realer Rahmenverträge zwischen Hyperscalern und einer europäischen Bundesverwaltung einschließlich der jeweils vertraglich einbezogenen bzw. praktisch maßgeblichen Policy- und Service-Dokumente. Die Analyse zeigt wiederkehrende Muster entlang zentraler Strukturdimensionen wie Änderungsmacht, Haftungsarchitektur, Verantwortungszuweisung im Shared-Responsibility-Modell, Exit-Fähigkeit, Audit- und Nachweisregime, Subprocessor-Governance, Datenlokation und Regulatory Change.

Der Analysekorpus umfasst Verträge mit europäischen Tochtergesellschaften amerikanischer und chinesischer Anbieter. Strukturell vergleichbar ist die Grundmechanik überall dort, wo Plattform- und Policy-Regime in global skalierenden Leistungs- und Änderungsmodellen betrieben werden; Unterschiede liegen insbesondere bei extraterritorialen Zugriffspflichten des Anbieters, regulatorischen Durchgriffsrisiken und Verhandlungsspielräumen im konkreten Beschaffungsrahmen. Anbieter und Beschaffungsrahmen werden bewusst nicht namentlich bezeichnet; die Muster sind anbieter- und länderübergreifend reproduzierbar.

Der Beitrag bewertet weder die Zweckmäßigkeit noch die Legitimität des Einsatzes von Hyperscaler-Diensten. Er beschreibt die strukturellen Bedingungen, unter denen dieser Einsatz erfolgt, benennt die Governance-Leistungen, die Verträge nicht erbringen, und leitet daraus Anforderungen an die institutionelle Vorbereitung und Steuerungsfähigkeit öffentlicher Verwaltungen ab.

1. Vertragsrealität: Dokumentenebene und operative Steuerungsebene

Die vertraglich fixierte Dokumentenebene öffentlicher Hyperscaler-Rahmenverträge ist nicht deckungsgleich mit der operativ maßgeblichen Steuerungsebene. Der Rahmenvertrag bildet den formalen Einstiegspunkt der Vertragsbeziehung. Er legt jedoch regelmäßig nicht abschließend fest, wie sich technische Ausprägung, Weiterentwicklung sowie Sicherheits- und Betriebsniveau der konkret genutzten Cloud-Dienste im Verlauf der Laufzeit entwickeln.

Die operative Leistungssteuerung ergibt sich aus einer mehrschichtigen Verweisstruktur. Neben dem Rahmenvertrag wirken insbesondere das Cloud Services Agreement (CSA), das Data Processing Agreement (DPA), Servicebeschreibungen, Security-Practice-Statements, Subprocessor-Listen sowie Portal- und Konfigurationsregime. Diese Dokumente unterscheiden sich in rechtlicher Qualität, Änderungsmechanik und Stabilitätsgrad.

Auch eine vergaberechtskonforme Einbindung auftragnehmerseitiger Bedingungen – etwa über EVB-IT-Cloud – ordnet Rangfolge und Transparenz, verschiebt jedoch nicht automatisch die plattformseitige Änderungs- und Steuerungsmacht innerhalb standardisierter Policy-Regime.

Schriftformklauseln sichern regelmäßig den Kerntext des Rahmenvertrages gegen einseitige Abweichung. Die technisch und betrieblich maßgeblichen Ebenen – insbesondere Security Practices, Servicebeschreibungen und konfigurationsbezogene Dokumentationen – unterliegen hingegen eigenständigen Aktualisierungsmechanismen. Sie können im Rahmen vertraglich vorgesehener Änderungsbefugnisse fortgeschrieben werden, ohne dass der formale Rahmenvertrag selbst angepasst wird.

Vergaberechtlich bleibt die Dogmatik der Auftragsänderung (§ 132 GWB) grundsätzlich formal unberührt, soweit die Fortschreibung innerhalb des transparent definierten Leistungs- und Änderungsrahmens erfolgt und nicht zu einer wesentlichen Umgestaltung von Leistungsgegenstand oder wirtschaftlicher Balance führt. Die laufende Anpassung erscheint dann nicht als nachträgliche Vertragsänderung, sondern als Ausübung vertraglich vorgesehener Entwicklungsklauseln, auch wenn die materielle Steuerungsmacht über diese operative Ebene faktisch beim Anbieter liegt.

Es entsteht damit eine strukturelle Trennung zwischen formaler Vertragsstabilität und operativer Veränderungsdynamik: Die beständigsten Dokumente bestimmen nicht die tägliche Leistungswirklichkeit; die steuerungsrelevanten Dokumente sind regelmäßig diejenigen mit eigener Aktualisierungslogik.

Diese Konstellation ist nicht Ausdruck individueller Verhandlungsschwäche, sondern Folge der Standardisierungslogik globaler Cloud-Plattformen. Öffentliche Beschaffungsrahmen greifen auf vorstrukturierte Vertrags- und Servicemodelle zurück, deren Änderungsregime zentral durch den Anbieter gesteuert werden.

Digitale Souveränität kann unter diesen Bedingungen nicht mit der formalen Stabilität des Rahmenvertrages gleichgesetzt werden. Maßgeblich ist vielmehr, ob die Institution die mehrstufige Verweisarchitektur organisatorisch beobachten, bewerten und steuern kann.

IT-Architektur wirkt ex ante: Sie legt Abhängigkeiten, Kontrollpunkte, Nachweisfähigkeit und Exit-Pfade fest, bevor der Zuschlag erteilt ist. Vergabe wird demgegenüber häufig ex post gedacht, sie reagiert verfahrensrechtlich auf eine Leistungsrealität, die technisch und betrieblich vielfach bereits vorentschieden ist.

Modellrahmung

Aus dieser Asymmetrie folgt der methodische Zugriff dieses Beitrags.

Vergabedesign als Governance-Engineering

Vergabedesign ist die ex-ante Gestaltung von Architektur-, Vertrags- und Betriebsregimen mit dem Ziel, Steuerungsrechte, Verantwortungszuordnung sowie Nachweis- und Exit-Fähigkeit im späteren Betrieb tatsächlich ausübbar zu halten und nicht nur formal im Vertrag zu verankern.

Dieses Modell unterscheidet zwei Ebenen, die in der Praxis häufig vermischt werden:

1. Vergaberechtliche Einbindung
   (Rangfolge, Transparenz, Einbeziehung von Verweisdokumenten, Änderungsdogmatik)
2. Plattformseitige Steuerungslogik
   (Änderungsmacht über Policy-, Service- und Konfigurationsregime)

Vergaberechtskonforme Einbindung kann Transparenz und Reaktionsrechte sichern; sie verschiebt jedoch nicht automatisch die strukturelle Änderungs- und Steuerungsmacht im Plattformregime.

Governance-Prinzip

Rahmenverträge schaffen keinen Steuerungsraum; sie definieren lediglich dessen äußere Begrenzung. Steuerung entsteht erst dort, wo die Institution die dynamischen Verweisdokumente, Konfigurationsregime und Änderungsmechanismen organisatorisch beherrscht.

Daraus folgt der Kernbefund dieses Beitrages:

• Die operative Wirklichkeit liegt in dynamischen Verweisdokumenten und Konfigurationsregimen, nicht im formal stabilen Vertragstext.
• Souveränitätsrelevant ist nicht primär der Ausgangszustand, sondern die Verteilung von Änderungsmacht über die Laufzeit.
• Haftung begrenzt typischerweise die ökonomische Exponierung des Anbieters, während die Verantwortung gegenüber Dritten – insbesondere gegenüber Aufsichtsbehörden, Betroffenen und hinsichtlich der Funktionsfähigkeit staatlicher Leistungen – strukturell bei der öffentlichen Hand verbleibt.
• Audit schafft Transparenz über definierte Compliance-Ausschnitte, begründet jedoch regelmäßig keine Gestaltungs- oder Durchgriffsrechte auf Plattform- und Betriebsarchitektur.
• Exit ist keine vertraglich „mitgelieferte“ Eigenschaft, sondern eine institutionell vorzuhaltende Fähigkeit – organisatorisch, architektonisch und personell.

Die folgende Analyse entfaltet diese Muster entlang der genannten Strukturdimensionen.

2. Strukturelle Muster

2.1 Änderungsmacht

In den analysierten Vertragsarchitekturen liegt die Befugnis zur inhaltlichen Fortentwicklung der Leistungen überwiegend beim Anbieter. Servicebeschreibungen, Security-Practice-Statements, Subprocessor-Listen sowie dokumentierte technische und organisatorische Maßnahmen werden innerhalb vertraglich vorgesehener Aktualisierungsmechanismen, regelmäßig mit vorgesehenen Ankündigungsfristen, fortgeschrieben. Maßgeblich ist dabei das anbieterdefinierte Dokumentations- und Policy-Regime.

Auf Seiten des öffentlichen Auftraggebers bestehen demgegenüber primär Reaktionsrechte. Dazu zählen Informationspflichten bei Leistungsänderungen, Widerspruchsmöglichkeiten bei neuen Subprozessoren sowie Sonderkündigungsrechte bei regulatorischen Veränderungen. Diese Instrumente setzen eine bereits angekündigte oder vollzogene Änderung voraus. Ihre praktische Wirksamkeit hängt davon ab, dass die Behörde Änderungen rechtzeitig identifiziert, bewertet und innerhalb der vorgesehenen Fristen reagiert; einzelne Vertragsgestaltungen sehen für Subprocessor-Widersprüche Fristen von lediglich zehn Tagen vor.

Reaktionsrechte sind damit governance-abhängig. Sie entfalten nur dann Wirkung, wenn Monitoring, interne Entscheidungsprozesse und Eskalationsmechanismen institutionell verlässlich etabliert sind.

Die staatliche Seite verfügt regelmäßig nicht über Mitbestimmungs- oder Zustimmungsrechte hinsichtlich der Fortentwicklung des Leistungsgegenstandes, sondern über ein Bündel reaktiver Instrumente. Die strukturelle Verteilung der Änderungsbefugnisse bleibt während der gesamten Laufzeit zugunsten des Anbieters ausgestaltet.

Für die Bewertung digitaler Souveränität ist daher nicht allein der vertragliche Ausgangszustand entscheidend. Maßgeblich ist, wer die Weiterentwicklung des Leistungsgegenstandes steuert und ob die öffentliche Hand die hierfür erforderliche Change- und Policy-Governance organisatorisch dauerhaft leisten kann.

2.2 Haftungsarchitektur

Die analysierten Hyperscaler-Rahmenverträge folgen trotz unterschiedlicher Ausgestaltung einem strukturell vergleichbaren Haftungsregime. Leistungsstörungen werden primär über Gewährleistungs- und Service-Level-Mechanismen adressiert. Nachbesserung, Ersatzleistung oder Service Credits sind regelmäßig als abschließende Rechtsbehelfe ausgestaltet. Die SLA fungiert damit nicht als Ergänzung, sondern als funktionaler Ersatz klassischer Schadensersatzinstrumente.

Darüber hinaus wird die Haftung systematisch begrenzt. Sämtliche Anbieter arbeiten mit zeitbezogenen Vergütungscaps, die an die in einem definierten Zeitraum gezahlten Entgelte anknüpfen. Indirekte Schäden, entgangener Gewinn, Reputationsfolgen und sonstige mittelbare Auswirkungen werden weitgehend ausgeschlossen. Auch Schäden aus Datenverlust oder Datenwiederherstellung sind regelmäßig nicht kompensationsfähig, sofern sie unter entsprechende Ausschlusskataloge fallen oder als mittelbare Schäden qualifiziert werden. Ökonomisch besonders relevante Schadensarten sind damit strukturell ausgeklammert.

Hinzu treten weitere Begrenzungen. Drittkomponenten, Plattform-Ökosysteme oder externe Services werden haftungsrechtlich externalisiert. IP-Freistellungen sind zwar vorgesehen, unterliegen jedoch regelmäßig der alleinigen Prozess- und Vergleichsführung des Anbieters und können im Ergebnis durch Leistungsänderung oder Vertragsbeendigung aufgelöst werden. In einzelnen Vertragsarchitekturen wird ausdrücklich klargestellt, dass Daten und Software keinen Sachschaden darstellen, wodurch deliktische Durchgriffskonstruktionen zusätzlich eingegrenzt werden.

In den zugänglichen Vertragsfassungen sind zentrale Haftungsparameter teilweise geschwärzt oder in externe Vertragsdokumente ausgelagert. Die tatsächliche staatliche Risikoexponierung erschließt sich daher nur durch eine konsolidierte Analyse sämtlicher einbezogener Vertragsbestandteile.

Unabhängig von diesen Begrenzungen verbleibt die öffentlich-rechtliche Außenverantwortung für die Rechtmäßigkeit der Datenverarbeitung, für die Funktionsfähigkeit staatlicher IT-Systeme und für mögliche Grundrechtsbeeinträchtigungen bei der Behörde. Anbietermeldungen zu Sicherheitsvorfällen erfüllen Informationspflichten, begründen jedoch kein automatisches Haftungsanerkenntnis. Vertraulichkeitsregelungen und Best-Efforts-Konstruktionen bei staatlich erzwungener Offenlegung reduzieren die Zugriffsmöglichkeiten auf den Anbieter nicht.

Die Haftungsarchitektur begrenzt damit die ökonomische Exponierung des Anbieters, ohne die regulatorische und grundrechtliche Verantwortung des Staates zu mindern. Haftungsrecht fungiert in diesem Modell nicht als Instrument staatlicher Steuerungsmacht, sondern als kalkulierter Risikorahmen innerhalb eines plattformökonomischen Geschäftsmodells.

2.3 Verantwortungsarchitektur: Shared Responsibility

Das Shared-Responsibility-Modell verteilt Verantwortlichkeiten entlang der technischen Schichten des Service-Stacks. Der Anbieter verantwortet Infrastruktur und plattformseitige Basissicherheitsmechanismen. Der Kunde verantwortet Konfiguration, Identitätsmanagement, Datenklassifikation, Zugriffspolitiken, Protokollierung sowie die fachliche Nutzung der bereitgestellten Dienste.

Diese Aufgabenteilung ist technisch plausibel. Governance-relevant wird sie durch ihre Kopplung mit der Haftungsarchitektur: Zentrale Kontrollmechanismen liegen operativ beim Kunden, während die Haftung des Anbieters regelmäßig durch Caps, Ausschlüsse wirtschaftlich wesentlicher Schadensarten und SLA-Regime begrenzt ist. Die öffentlich-rechtliche Außenverantwortung für Rechtmäßigkeit und Folgen der Datenverarbeitung verbleibt unabhängig davon bei der Behörde.

Shared Responsibility ist damit zunächst ein Plattformregime. Es beschreibt nicht, wie der öffentliche Auftraggeber seine Aufgaben organisatorisch ausgestaltet, sondern welche Aufgaben im Cloud-Betriebsmodell zwingend staatlich wahrzunehmen sind, weil sie nicht als Anbieterhaftung „zurückgespiegelt“ werden.

Die praktische Tragfähigkeit dieses Modells variiert nach Serviceebene.
Auf IaaS- und PaaS-Ebene sind zentrale Steuerungsparameter technisch konfigurierbar und überprüfbar, etwa Standortbindung, Verschlüsselung, Logging, Netzsegmentierung und Zugriffskontrollen. Hier kann die Behörde ihre Verantwortung grundsätzlich ausüben, sofern Kompetenz, Ressourcen und Prozesse vorhanden sind.
Auf SaaS-Ebene liegt die Fachlogik einschließlich wesentlicher Sicherheits- und Verarbeitungsparameter weitgehend im Verfügungsbereich des Anbieters; eigenständige Validierungsmöglichkeiten sind begrenzt und verursachen fortlaufenden Prüfaufwand.

Bei KI- und LLM-basierten Diensten verschärft sich diese Asymmetrie. Leistungsversprechen betreffen nicht nur Verfügbarkeit und Sicherheit, sondern inhaltliche Qualität und Fehlerfolgen. Die erforderliche fachliche Validierung lässt sich nicht vollständig standardisieren oder in klassische Kontrollmechanismen übersetzen. Shared Responsibility trifft hier auf Systeme, deren Outputs nicht deterministisch sind und deren Korrektheit nicht als garantierbarer Zustand beschrieben werden kann.

Wie der öffentliche Auftraggeber diese Verantwortlichkeiten organisatorisch ausübt, ist eine davon zu trennende Frage. Eine Auslagerung von Governance- und Betriebsaufgaben an spezialisierte Intermediäre kann sachgerecht sein, wenn sie die Ausübungskompetenz stärkt und die Steuerungsrechte bei der Behörde verbleiben. Kritisch wird es, wenn der Hyperscaler hinter einem Generalunternehmer oder Managed-Cloud-Bündel „verschwindet“. Dann werden Policy-Änderungen, Subprocessor-Dynamiken, Portalprozesse und Exit-Parameter nicht transparenter, sondern schwerer steuerbar. Die Behörde behält die Außenverantwortung, verliert jedoch unmittelbare Sichtbarkeit und Eingriffsfähigkeit.

Entscheidend ist daher nicht die Existenz eines Intermediärs, sondern die Transparenz- und Durchgriffsarchitektur der Leistungskette: Wer sieht Policy-Änderungen, wer bewertet sie, wer entscheidet und wer kann fristgerecht reagieren?

Wer Shared Responsibility tragfähig machen will, muss vor Vertragsabschluss zwei Fragen klären:

1. Auf welcher Serviceebene kann Verantwortung real ausgeübt werden und wo ist Steuerungsfähigkeit strukturell begrenzt.
2. Wie wird die Organisation so aufgestellt, dass Plattformdynamik kontinuierlich beobachtet, bewertet und operativ umgesetzt werden kann, ohne die Anbieterlogik hinter zusätzlichen Vertragsschichten zu verdecken.

2.4 Exit-Logik: Formales Recht und operative Fähigkeit

Alle analysierten Rahmenverträge enthalten Regelungen zur Vertragsbeendigung, zur Datenrückgabe und zu Übergangsfristen. Kündigungsrechte, Nachlaufzeiträume und Downloadoptionen sind vertraglich dokumentiert und orientieren sich regelmäßig an datenschutzrechtlichen Mindestanforderungen.

Diese Regelungen sichern eine formale Beendigungsmöglichkeit. Sie garantieren jedoch keine funktionale Wechselbarkeit.

Operative Exit-Fähigkeit bezeichnet die technische und organisatorische Fähigkeit einer Behörde, staatliche IT-Funktionen kontrolliert, zeitnah und mit vertretbarem Funktionsverlust aus einer Cloud-Umgebung herauszulösen und in eine alternative Infrastruktur zu überführen. Diese Fähigkeit ist keine geschuldete Vertragsleistung des Anbieters. Sie muss architektonisch vorbereitet, organisatorisch verankert und dauerhaft betriebsfähig gehalten werden.

Die maßgeblichen Exit-Barrieren entstehen nicht primär aus vertraglichen Kündigungsbeschränkungen, sondern aus technischen Abhängigkeiten. Proprietäre Datenbankdienste, serverlose Architekturen, anbieterspezifische KI-APIs oder tief integrierte Sicherheits- und Identitätsdienste schaffen funktionale Kopplungen, für die keine vertragliche Zusicherung einer funktionsgleichen Portabilität besteht. Datenexport ist regelmäßig möglich; die Wiederherstellung einer gleichwertigen Betriebsumgebung ist es nicht ohne Weiteres.

Mit zunehmender Nutzung cloudnativer Dienste verschiebt sich der Exit-Aufwand von einer Datenmigration zu einer Architekturtransformation. Migration wird damit nicht ausgeschlossen, aber technisch, wirtschaftlich und zeitlich anspruchsvoll. Jede Architekturentscheidung, die proprietäre Abhängigkeiten vertieft, erhöht strukturell die späteren Exit-Kosten, unabhängig von den vertraglichen Kündigungsrechten.

Im Krisenfall – etwa bei gravierenden Sicherheitsvorfällen, regulatorischen Änderungen oder einem vom Anbieter initiierten Leistungsende – entfaltet das Kündigungsrecht nur dann praktische Wirkung, wenn operative Exit-Fähigkeit zuvor aufgebaut wurde. Die rechtliche Beendigungsmöglichkeit ersetzt nicht die Fähigkeit zur Fortführung staatlicher Funktionen außerhalb der bisherigen Plattform.

2.5 Audit- und Nachweisregime

Die in den analysierten Rahmenverträgen vorgesehenen Audit- und Kontrollrechte sind strukturiert und zugleich klar begrenzt. Prüfgegenstand ist regelmäßig die Einhaltung datenschutzrechtlicher Verpflichtungen, die Umsetzung technischer und organisatorischer Maßnahmen sowie die ordnungsgemäße Verarbeitung personenbezogener Daten. DPA und ergänzende Vereinbarungen definieren Reichweite, Verfahren und Modalitäten dieser Prüfungen detailliert.

Weitergehende Aspekte – etwa Gesamtarchitektur, Resilienzkonzepte, Betriebsmodelle, Lieferkettenstrukturen oder strukturelle Abhängigkeiten – sind typischerweise nicht unmittelbarer Prüfgegenstand. Selbst dort, wo breitere Prüfungen vorgesehen sind, unterliegen sie regelmäßig verfahrensmäßigen Einschränkungen, Vorankündigungspflichten oder der Möglichkeit, standardisierte Prüfberichte des Anbieters anstelle individueller Kontrollen heranzuziehen.

Das zentrale Kontrollinstrument sind Drittprüfberichte, insbesondere SOC-Reports, ISO-Zertifizierungen oder vergleichbare Auditnachweise. Diese Berichte werden im Auftrag des Anbieters erstellt; Prüfumfang, Methodik und Wesentlichkeitsschwellen werden nicht durch die öffentliche Hand definiert. Die Behörde erhält Einsicht in standardisierte Prüfergebnisse, bestimmt jedoch nicht die Prüfarchitektur selbst.

Vertragliche Weisungs- oder Interventionsrechte für den Fall identifizierter struktureller Risiken sind regelmäßig nicht vorgesehen. Werden Defizite festgestellt, ist die vertragliche Reaktionslogik typischerweise auf Nachbesserung oder – bei fortbestehenden Mängeln – auf Kündigungsrechte ausgerichtet. Ein durchsetzbarer Anspruch auf strukturelle Anpassung des Betriebsmodells oder der Plattformarchitektur besteht nicht.

Auditrechte ermöglichen damit Transparenz über definierte Compliance-Bereiche. Sie begründen jedoch keine unmittelbare Steuerungsmacht über Architektur, Betriebsregime oder Plattformentwicklung. Kontrolle ist in diesem Modell primär prüfend, nicht gestaltend. Ihre Wirksamkeit hängt davon ab, ob identifizierte Risiken organisatorisch verarbeitet oder – im Extremfall – durch einen Anbieterwechsel adressiert werden können.

2.6 Subprocessor- und Policy-Dynamik

Die Subprocessor-Governance ist in den analysierten Verträgen formal klar ausgestaltet. Regelmäßig vorgesehen sind Informationspflichten über eingesetzte Unterauftragsverarbeiter, Listenmodelle mit Aktualisierungsvorbehalt, Ankündigungsfristen für Änderungen sowie ein Widerspruchsrecht der verantwortlichen Stelle. Teilweise wird zwischen besonders kritischen Infrastrukturleistungen und sonstigen unterstützenden Leistungen differenziert.

Die rechtliche Wirkung dieser Konstruktion liegt jedoch nicht in einem erzwingbaren Vetorecht. Übt die Behörde ihr Widerspruchsrecht aus und kommt keine einvernehmliche Lösung zustande, verbleibt typischerweise als letzte Konsequenz das Recht zur Kündigung des betroffenen Leistungsabrufs. Ein Anspruch auf Unterlassung des Subprocessor-Wechsels besteht regelmäßig nicht.

Die praktische Bedeutung des Widerspruchsrechts hängt daher von der realen Wechsel- und Exit-Fähigkeit der Behörde ab. Ohne operative Alternativen bleibt es ein formales Instrument mit begrenzter Durchsetzungskraft.

Von der Subprocessor-Governance zu unterscheiden ist die Dynamik sonstiger vertragsrelevanter Dokumente. Security Practices, technische und organisatorische Maßnahmen, Servicebeschreibungen und Portalprozesse unterliegen in den analysierten Vertragsarchitekturen regelmäßig einseitigen Aktualisierungsvorbehalten des Anbieters. Änderungen erfolgen mit Ankündigung und gegebenenfalls Fristenregelungen; eine inhaltliche Zustimmungspflicht der Behörde besteht nicht, solange vertraglich definierte Mindeststandards formal eingehalten werden.

Die Kombination aus Listenmodell bei Unterauftragsverarbeitern und einseitig fortschreibbaren Policy-Dokumenten führt zu einer strukturierten, aber anbietergetriebenen Lieferketten- und Governance-Dynamik. Die Behörde erhält Transparenz- und Reaktionsrechte, jedoch keine dauerhafte Gestaltungs- oder Genehmigungshoheit über die Weiterentwicklung von Plattform- und Sicherheitsarchitektur.

Subprocessor- und Policy-Regime sichern damit Informationszugang und Kündigungsoptionen. Die Verantwortung für Bewertung, Reaktion und gegebenenfalls Beendigung verbleibt jedoch vollständig bei der öffentlichen Hand.

2.7 Datenlokalisation und Jurisdiktionsrisiken

Alle analysierten Rahmenverträge ermöglichen die Konfiguration von Datenlokationspräferenzen. Primäre Verarbeitungsstandorte können auf bestimmte Regionen beschränkt werden. Der verfügbare Standortraum ist jedoch anbieterabhängig und regelmäßig auf definierte Rechenzentrumsregionen begrenzt; nicht sämtliche Dienste sind in allen Regionen verfügbar, und Replikations- oder Backup-Prozesse folgen teilweise eigenen Standortlogiken.

Datensouveränität ist in diesen Vertragsarchitekturen keine zugesicherte Eigenschaft, sondern das Ergebnis technischer und organisatorischer Gestaltung. Die Verträge stellen Instrumente bereit – etwa Standortkonfiguration, Verschlüsselungsoptionen, Key-Management-Modelle und Zugriffsprotokollierung. Ob und in welchem Umfang diese Instrumente genutzt werden, entscheidet sich auf Ebene der Architektur- und Konfigurationsentscheidungen der Behörde.

Für gesetzliche Herausgabeverpflichtungen des Anbieters enthalten die Verträge regelmäßig Ausnahmeklauseln. Extraterritoriale Zugriffspflichten werden nicht ausgeschlossen, sondern als rechtliche Möglichkeit anerkannt. Melde- und Abwehrpflichten strukturieren das Verfahren im Zugriffsfall, begründen jedoch keine Garantie der Zugriffverhinderung.

Technische Maßnahmen können das Risiko faktischer Offenlegung reduzieren, insbesondere Verschlüsselungsarchitekturen mit außerhalb der Anbieterinfrastruktur verwalteten kryptographischen Schlüsseln. Die Wirksamkeit solcher Maßnahmen hängt von Servicewahl, Datenkategorisierung und organisatorischer Schlüsselverwaltung ab. Ihre Umsetzung ist Teil der Infrastruktur- und Governance-Architektur, nicht das Ergebnis individueller Vertragsverhandlungen.

Konzerninterne Datenverarbeitungen sind in einzelnen Vertragsarchitekturen ausdrücklich privilegiert oder jedenfalls nicht als Vertraulichkeitsverletzung qualifiziert. Globale Subunternehmerstrukturen sind integraler Bestandteil der Betriebsmodelle. Transparenz über konzerninterne Datenflüsse ist damit vertraglich strukturiert, aber nicht vollständig durch die öffentliche Hand disponibel.

2.8 Regulatory Change

Regulatorische Veränderungen – etwa neue Datenschutzanforderungen, geänderte Geheimschutzpflichten oder neue extraterritoriale Zugriffstatbestände – betreffen die Grundlage der Cloud-Nutzung. Sie verändern nicht nur einzelne Leistungspflichten, sondern können die rechtliche Zulässigkeit oder organisatorische Tragfähigkeit des gesamten Betriebs berühren.

Die analysierten Vertragsarchitekturen sehen hierfür unterschiedliche Modelle vor. Teilweise ist vereinbart, dass die Parteien bei erheblichen Rechtsänderungen Anpassungen prüfen; vereinzelt wird eine Anpassungspflicht mit einem befristeten Sonderkündigungsrecht kombiniert, wenn die Vertragsausführung unmöglich oder wesentlich erschwert wird. In anderen Fällen beschränkt sich die Regelung auf Gesprächs- oder Kooperationspflichten. Einzelne Vertragsarchitekturen enthalten keinen ausdrücklich geregelten Mechanismus für regulatorische Veränderungen.

Gemeinsam ist diesen Modellen, dass sie regelmäßig kein spezifisches, durchsetzbares Anpassungsregime vorsehen, das dem öffentlichen Auftraggeber einen Anspruch auf strukturelle Modifikation des Leistungsmodells vermittelt. Die vertragliche Reaktionslogik bleibt im Kern kooperativ oder exit-orientiert.

Sonderkündigungsrechte sind dabei an Voraussetzungen gebunden. Die Behörde muss Rechtsentwicklungen kontinuierlich beobachten, deren Auswirkungen auf konkrete Dienste und Datenkategorien bewerten und innerhalb vertraglich definierter Fristen reagieren können. Ihre praktische Wirksamkeit setzt zudem eine tatsächlich vorhandene operative Exit-Fähigkeit voraus.

Fehlen institutionalisierte Beobachtungs- und Bewertungsstrukturen oder realistische Migrationsoptionen, bleibt das Sonderkündigungsrecht eine formale Rechtsposition ohne gesicherte operative Umsetzung.

Die Fähigkeit, auf regulatorische Veränderungen souverän zu reagieren, entsteht daher nicht primär aus der Vertragsklausel selbst, sondern aus der organisatorischen und architektonischen Vorbereitung der Behörde.

3. Kernbefund

Die analysierten Vertragsarchitekturen weisen anbieterübergreifend wiederkehrende Strukturmerkmale auf. Die materielle Änderungsmacht über operative Steuerungsdokumente liegt überwiegend beim Anbieter. Haftung ist regelmäßig begrenzt und funktional auf Gewährleistungs- und Service-Level-Mechanismen konzentriert. Audit- und Kontrollrechte zielen primär auf definierte Compliance-Bereiche. Operative Exit-Fähigkeit ist keine geschuldete Vertragsleistung, sondern Voraussetzung auf Seiten der Behörde.

Vertragsgestaltung kann Transparenz sichern, Fristen strukturieren, Informationsrechte etablieren und Eskalationsmechanismen vorsehen. Sie verändert jedoch in global standardisierten Plattformmodellen nicht grundlegend die Allokation von Änderungsmacht, Haftungsrisiken und operativer Verantwortung.

Governance-Klauseln entfalten ihre Wirkung nur, wenn sie organisatorisch unterlegt sind. Widerspruchsrechte gegenüber Subunternehmern, Sonderkündigungsrechte bei regulatorischen Veränderungen oder Stabilisierungsklauseln in Einzelabrufen bleiben formale Rechtspositionen, solange keine klar definierten Entscheidungszuständigkeiten, Bewertungsmaßstäbe und operativen Reaktionsprozesse bestehen.

Governance kann die strukturellen Eigenschaften des Plattformmodells nicht aufheben. Sie kann jedoch dessen Risiken strukturieren, begrenzen und institutionell verarbeitbar machen. Souveräne Handlungsfähigkeit entsteht in diesem Modell nicht durch Vertragsabschluss, sondern durch die Fähigkeit, vertraglich eröffnete Optionen organisatorisch wirksam zu nutzen.

4. Ex-ante-Konsequenzen

4.1 Architekturentscheidungen als Souveränitätsentscheidungen

Architekturentscheidungen in Cloud-Projekten wirken unmittelbar auf spätere Steuerungs- und Handlungsspielräume. Die Wahl proprietärer Datenbankdienste, die Nutzung nativ integrierter KI-Schnittstellen oder die Abhängigkeit von anbietereigenen Identitäts- und Berechtigungssystemen prägen strukturell die Wechsel- und Eingriffsfähigkeit. Technische Abhängigkeiten, die auf dieser Ebene begründet werden, lassen sich regelmäßig nicht durch nachgelagerte Vertragsklauseln kompensieren.

Architekturentscheidungen sollten daher eine explizite Portabilitäts- und Austauschbarkeitsbewertung enthalten. Maßgeblich ist die Frage, unter welchen Bedingungen, mit welchem Ressourcenaufwand und in welchem Zeitraum ein eingesetzter Dienst durch eine alternative Lösung ersetzt werden könnte. Erfolgt eine solche Bewertung nicht, entsteht Lock-in häufig nicht als strategische Entscheidung, sondern als Nebenprodukt technischer Optimierung.

Die Beobachtung und Bewertung von Abhängigkeiten ist keine einmalige Projektaufgabe, sondern Bestandteil des laufenden Betriebs. Bei jeder wesentlichen Architekturänderung sollte geprüft werden, ob cloud-native Bindungen zunehmen, welche Exit-Konsequenzen daraus folgen und ob diese Entwicklung bewusst akzeptiert wird. Nicht jede Abhängigkeit ist vermeidbar oder sachlich unvertretbar. Entscheidend ist jedoch, dass sie als dokumentierte und verantwortete Entscheidung erfolgt, nicht als unbeabsichtigtes Resultat technischer Bequemlichkeit.

4.2 Rollen- und Verantwortungszuordnung vor Vertragsabschluss

Das Shared-Responsibility-Modell setzt voraus, dass auf Seiten der öffentlichen Hand eindeutig festgelegt ist, wer welche Verantwortung wahrnimmt. Dazu zählen insbesondere Konfigurationskontrolle, Identitäts- und Berechtigungsmanagement, Datenklassifikation, Zugriffskontrolle, Sicherheitsüberwachung und Incident Response.

Diese Zuordnung darf nicht implizit im laufenden Betrieb entstehen. Sie sollte vor Vertragsabschluss institutionell geklärt sein, einschließlich definierter Rollen, Entscheidungsbefugnisse, Eskalationswege und angemessener Ressourcen. Fehlt eine solche Vorstrukturierung, entsteht im Krisenfall nicht nur ein technisches, sondern ein organisatorisches Risiko.

Verantwortung ist dabei von operativer Unterstützung zu unterscheiden. Aufgaben können intern oder extern wahrgenommen werden; die Letztverantwortung für Rechtmäßigkeit, Sicherheit und Funktionsfähigkeit verbleibt jedoch bei der Behörde. Die Rollenarchitektur muss daher klar zwischen Entscheidungsbefugnis, operativer Durchführung und Kontrollfunktion differenzieren.

Zur Rollenarchitektur gehört zudem die Frage der Ausübungskompetenz. Die bloße vertragliche Zuweisung von Verantwortungsbereichen ersetzt nicht die Fähigkeit, diese praktisch auszuüben. Logging-Interfaces, Backup-Funktionen, Key-Management-Systeme oder Audit-Trails entfalten nur dann Wirkung, wenn organisatorische Kompetenz, technische Expertise und ausreichende personelle Kapazitäten vorhanden sind, um diese Instrumente wirksam zu nutzen und zu überwachen.

4.3 Exit-Runbooks statt Exit-Klauseln

Das Recht auf Exit und die Fähigkeit zum Exit sind strikt zu unterscheiden. Kündigungsrechte, Datenrückgabezusagen und vertragliche Nachlauffristen sind in den analysierten Vertragsarchitekturen regelmäßig vorgesehen. Sie begründen jedoch keine operative Migrations- oder Wiederanlaufgarantie.

Operative Exit-Fähigkeit umfasst die technische und organisatorische Möglichkeit, Daten strukturiert zu extrahieren, Workloads auf alternative Infrastrukturen zu übertragen und den Betrieb kritischer Funktionen kontrolliert fortzuführen. Diese Fähigkeit entsteht nicht durch die Existenz einer Kündigungsklausel, sondern durch vorgelagerte Architektur- und Prozessentscheidungen.

Erforderlich sind dokumentierte und regelmäßig überprüfte Exit-Runbooks. Sie sollten festlegen, in welcher Reihenfolge Systeme migriert werden, in welchen Formaten Daten exportierbar sind, welche Abhängigkeiten zwischen cloud-nativen Diensten und Fachverfahren bestehen und welche Zielinfrastrukturen innerhalb welcher Zeiträume verfügbar sein müssen. Ebenso ist zu definieren, welche personellen und technischen Ressourcen im Exit-Fall aktiviert werden.

Exit-Runbooks erfüllen ihren Zweck nur, wenn sie vor Eintritt eines Krisen- oder Kündigungsfalls entwickelt und getestet werden. Wiederholte Migrations- oder Wiederherstellungsproben erhöhen die Wahrscheinlichkeit, dass ein vertraglich eröffnetes Kündigungsrecht im Bedarfsfall tatsächlich in eine funktionsfähige Alternativstruktur überführt werden kann.

4.4 Guardrails im Leistungsabruf

Rahmenvertragliche Governance-Zusagen entfalten ihre Wirkung nicht automatisch auf Ebene des einzelnen Leistungsabrufs. Sind Rahmenvertrag und Abrufsystematik als getrennte Steuerungsebenen ausgestaltet, müssen zentrale Parameter bewusst in den jeweiligen Einzelauftrag überführt werden. Dazu zählen insbesondere Datenlokationsvorgaben, Wahl des Schutzniveaus, Exit-Parameter sowie Zielwerte für Wiederanlauf- und Wiederherstellungszeiten.

Der Rahmenvertrag definiert den rechtlichen Möglichkeitsraum. Ob und mit welchen konkreten Sicherheits-, Resilienz- oder Konfigurationsparametern einzelne Dienste betrieben werden, entscheidet sich regelmäßig im Abruf und in der tatsächlichen Servicekonfiguration.

Guardrails im Leistungsabruf sind verbindliche Mindestanforderungen, die sicherstellen, dass definierte Governance- und Sicherheitsvorgaben tatsächlich implementiert und überprüfbar ausgestaltet werden. Sie strukturieren die Konfigurationsebene durch konkrete Vorgaben etwa zur Standortwahl, Verschlüsselungsarchitektur, Protokollierung, Backup-Strategie oder zu Wiederherstellungsparametern.

Resilienz entsteht in diesem Modell nicht durch den bloßen Verweis auf Zertifizierungen oder Rahmenvertragsklauseln. Sie ist das Ergebnis konkret gewählter Konfigurationen, dokumentierter Betriebsprozesse und regelmäßig durchgeführter Tests.

4.5 Policy-Change-Monitoring

Die operativ maßgeblichen Steuerungsebenen – insbesondere Security Practices, Servicebeschreibungen und Portalprozesse – unterliegen regelmäßig anbietergetriebenen Aktualisierungsmechanismen. Diese Dokumente sind nicht in gleicher Weise formal stabilisiert wie der Rahmenvertrag selbst. Änderungen erfolgen typischerweise mit Ankündigungsfristen und ohne individuelle Zustimmungspflicht der Behörde.

Um diese Dynamik institutionell zu verarbeiten, bedarf es eines strukturierten Policy-Change-Monitorings. Es handelt sich dabei nicht um eine punktuelle Vertragsprüfung, sondern um einen dauerhaft etablierten Prozess zur Beobachtung, Bewertung und Einordnung von Dokumentenänderungen.

Ein solcher Prozess sollte festlegen,

• welche Dokumente systematisch überwacht werden,
• wer für die Auswertung von Änderungsmitteilungen zuständig ist,
• nach welchen Kriterien Auswirkungen auf Sicherheit, Compliance, Resilienz oder Exit-Fähigkeit bewertet werden,
• und unter welchen Voraussetzungen eine vertiefte Risikoprüfung, Konfigurationsanpassung oder Prüfung eines Exit-Szenarios ausgelöst wird.

Diese Entscheidungsarchitektur muss vor Eintritt konkreter Änderungsfälle definiert sein. Dazu gehören klare Zuständigkeiten, Fristenregelungen, Dokumentationsanforderungen und Eskalationspfade. Ohne eine solche Struktur bleibt die vertragliche Informationspflicht des Anbieters organisatorisch folgenlos.

4.6 Dokumentations- und Nachweisarchitektur

Löschhoheit ist in den analysierten Vertragsarchitekturen keine automatisch durchgesetzte Anbieterpflicht, sondern Teil der geteilten Verantwortungsstruktur. Der Anbieter stellt technische Löschmechanismen bereit; Auslösung, Konfiguration und Dokumentation der Löschung liegen regelmäßig bei der Behörde.

Ohne eine vorab definierte Lösch-Governance – mit klaren Rollen, Prozessvorgaben und einem strukturierten Log-Retention-Konzept – ist ein belastbarer Nachweis ordnungsgemäßer Löschung gegenüber Aufsichtsbehörden oder in haftungsrechtlichen Verfahren nur eingeschränkt möglich.

Entsprechendes gilt für den Nachweis von Datenzugriffen, Konfigurationsentscheidungen, Sicherheitsereignissen und Maßnahmen der Incident Response. Beweis- und Rechenschaftspflichten in aufsichts- und haftungsrechtlichen Kontexten knüpfen an dokumentierte Prozesse und nachvollziehbare Protokolle an.

Die hierfür erforderliche Dokumentations- und Nachweisarchitektur entsteht nicht automatisch durch die Bereitstellung technischer Plattformfunktionen. Sie muss auf Seiten des öffentlichen Auftraggebers konzipiert, organisatorisch verankert, technisch implementiert und regelmäßig überprüft werden.

5. Souveränität als Organisationsleistung

Wer Hyperscaler-Rahmenverträge nutzt, bewegt sich innerhalb einer vorgegebenen Macht- und Verantwortungsarchitektur. Diese ist durch Standardisierung, Skalierbarkeit und globale Betriebslogik geprägt und lässt sich durch Individualverhandlungen nur begrenzt verändern.

Die Einbindung eines Intermediärs, Resellers oder Managed-Cloud-Anbieters verschiebt diese Plattformarchitektur nicht. In mehrstufigen Vertragsmodellen wird die anbietergetriebene Service-, Policy- und Subunternehmerstruktur in eine zusätzliche Vertragsebene eingebettet, ohne dass sich Änderungsmacht, Haftungslogik oder Jurisdiktionsstruktur grundlegend verändern. Ein Intermediär kann operative Unterstützung oder zusätzliche Governance-Strukturen bereitstellen; die aufsichts- und haftungsrechtliche Außenverantwortung für die eingesetzten Dienste verbleibt jedoch bei der öffentlichen Hand. Die Entscheidung für oder gegen eine Zwischenebene betrifft damit die Organisations- und Steuerungsarchitektur, nicht die Struktur der Plattform selbst.

Souveräne Handlungsfähigkeit setzt unter diesen Bedingungen keine vollständige Vertragskontrolle voraus, sondern institutionelle Klarheit. Erforderlich sind eine definierte Risikotoleranz, dauerhaft verankerte Kapazitäten zur Beobachtung technischer und regulatorischer Entwicklungen sowie die Fähigkeit, auf Veränderungen strukturiert zu reagieren. Dazu gehören eine kontinuierlich gepflegte Exit-Fähigkeit und eine Architektur, die Abhängigkeiten bewusst steuert, dokumentiert und regelmäßig überprüft.

Kein Rahmenvertrag ersetzt die organisatorische Fähigkeit einer Behörde, Cloud-Systeme zu konfigurieren, zu überwachen und im Bedarfsfall zu verlassen. Vertraglich bereitgestellte Instrumente – etwa Logging-Funktionen, Backup-Mechanismen, Key-Management-Optionen oder Exit-Klauseln – entfalten ihre Wirkung nur innerhalb einer funktionsfähigen Governance-Struktur.

Diese organisatorische Grundlage entsteht nicht erst im laufenden Betrieb. Leistungszuschnitt, Losbildung und die institutionelle Trennung von Steuerung und Leistungserbringung werden bereits im Vergabedesign angelegt. Architektur- und Steuerungsentscheidungen, die in dieser Phase nicht getroffen oder dokumentiert werden, lassen sich später nur mit erheblichem Aufwand korrigieren.

Souveräne Handlungsfähigkeit ist daher keine Eigenschaft des Vertrages. Sie ist das Ergebnis einer konsistenten Verbindung von Vergabedesign, Architekturentscheidung und organisatorischer Ausübungskompetenz.