Die häufigste Frage in deutschen Cloud-Projekten ist keine technische, sondern eine rechtliche: Dürfen unsere Daten dorthin? Google hat darauf in den letzten Jahren eine bemerkenswert konkrete Antwort aufgebaut. 5,5 Milliarden Euro fließen bis 2029 in deutsche Rechenzentren und Standorte, in München steht der erste Sovereign Cloud Hub, und das Souveränitäts-Portfolio reicht von EU-Datengrenzen bis zu komplett getrennten Umgebungen. Was davon Sie wirklich brauchen und wie Sie die Frage sauber beantworten.
Die Frage, die jedes Cloud-Projekt in Deutschland begleitet
Wer in einem deutschen Unternehmen ein Cloud-Projekt vorschlägt, kennt den Moment. Die Technik ist überzeugt, der Business Case steht, und dann meldet sich die Rechtsabteilung: Wo genau liegen die Daten? Wer kann darauf zugreifen? Was ist mit der DSGVO, was mit dem US-Recht, was sagt der Datenschutzbeauftragte?
Diese Fragen sind keine Bremserei. Sie sind berechtigt, und sie entscheiden in regulierten Branchen über die Machbarkeit des gesamten Vorhabens. Die gute Nachricht ist, dass sich die Antwortlage in den letzten zwei Jahren deutlich verbessert hat. Die Cloud-Anbieter haben verstanden, dass der europäische Markt ohne belastbare Souveränitätsangebote nicht zu gewinnen ist, und Google hat darauf besonders sichtbar reagiert.
Was Google konkret in Deutschland baut
Zahlen sagen mehr als Absichtserklärungen. Google investiert 5,5 Milliarden Euro in den Ausbau seiner deutschen Infrastruktur zwischen 2026 und 2029. Dazu gehören ein neues Rechenzentrum in Dietzenbach bei Frankfurt, der weitere Ausbau des Standorts Hanau und wachsende Büros in Berlin, Frankfurt und München. Im November 2025 hat Google zusätzlich den ersten Sovereign Cloud Hub in München eröffnet, einen Ort, an dem Kunden souveräne Cloud-Architekturen konkret testen können, bevor sie sich festlegen.
Für die Einordnung: Das ist keine Marketingfläche, sondern physische Infrastruktur auf deutschem Boden. Daten, die in der Region Frankfurt liegen, liegen in Deutschland, unterliegen europäischem Recht am Speicherort und sind mit deutscher Latenz erreichbar. Für viele Anwendungsfälle ist allein das schon die halbe Antwort auf die Eingangsfrage.
Die drei Stufen der Souveränität
Die andere Hälfte der Antwort steckt im Portfolio, und hier lohnt sich Präzision, weil der Begriff Souveränität inflationär verwendet wird. Google Cloud bietet drei Stufen an: Data Boundary, Dedicated und Air-Gapped.
Die erste Stufe, der Google Cloud Data Boundary, regelt, wo Daten gespeichert und verarbeitet werden. Sie können festlegen, dass beides ausschließlich in der EU oder in einem bestimmten Land passiert. Das deckt die Anforderung ab, die in den meisten Projekten tatsächlich gestellt wird: Datenresidenz mit vertraglicher und technischer Absicherung.
Die zweite Stufe, Google Cloud Dedicated, geht weiter. Hier wird die Cloud von einem lokalen, vertrauenswürdigen Partner betrieben. In Deutschland ist das T-Systems, eine Tochter der Deutschen Telekom. Der Betrieb, die Kontrollen und der Zugriff liegen bei einem deutschen Unternehmen, während die Technologie von Google kommt. Dieses Modell adressiert die Sorge, dass ein US-Anbieter unter Druck seiner Heimatjurisdiktion Zugriff gewähren müsste.
Die dritte Stufe, Air-Gapped, ist die vollständige Trennung. Eine eigenständige Umgebung ohne Verbindung zum öffentlichen Google-Netz, für Fälle, in denen selbst die zweite Stufe nicht genügt, etwa bei Verschlusssachen oder kritischer Infrastruktur mit höchsten Auflagen.
Der wichtigste Satz zu diesem Portfolio lautet: Die meisten Unternehmen brauchen die erste Stufe, einige die zweite, sehr wenige die dritte. Wer pauschal die höchste Stufe fordert, bezahlt für Anforderungen, die er nicht hat. Wer pauschal die niedrigste nimmt, riskiert ein böses Erwachen im Audit. Die richtige Antwort ist eine Klassifizierung der eigenen Daten, nicht ein Bauchgefühl.
Wie Sie die Frage für Ihr Unternehmen sauber beantworten
Die Eingangsfrage lautete: Dürfen wir das in die Cloud legen? Die ehrliche Antwort ist fast immer: Es kommt darauf an, welche Daten. Und genau diese Differenzierung ist der Weg aus der Blockade, in der viele Cloud-Diskussionen stecken.
Der erste Schritt ist eine Dateninventur. Welche Datenarten gibt es im Unternehmen, und welche Schutzanforderungen gelten für welche? Produktdaten und anonymisierte Telemetrie haben andere Anforderungen als Personaldaten, und die haben andere als Gesundheitsdaten oder Konstruktionsgeheimnisse. In den meisten Unternehmen zeigt diese Inventur, dass ein großer Teil der Daten problemlos in eine EU-Region kann, ein kleinerer Teil erhöhte Anforderungen hat und ein sehr kleiner Teil besondere Behandlung braucht.
Der zweite Schritt ist die Zuordnung: Datenklasse zu Souveränitätsstufe. Aus dieser Zuordnung ergibt sich die Architektur fast von selbst. Die Masse der Workloads läuft in der Frankfurter Region mit Data Boundary, die sensiblen Bereiche bekommen die passende höhere Stufe, und für den Rest gilt: bleibt vorerst, wo er ist. Cloud-Adoption ist keine Alles-oder-nichts-Entscheidung, auch wenn sie oft so diskutiert wird.
Der dritte Schritt ist die Dokumentation. Datenschutzbeauftragte und Auditoren wollen keine Versprechen, sondern nachvollziehbare Kontrollen. Die Souveränitätswerkzeuge von Google Cloud erzeugen genau diese Nachweise: wo Daten liegen, wer zugegriffen hat, welche Grenzen technisch erzwungen werden. Compliance wird damit von einer Vertrauensfrage zu einer Konfigurationsfrage, und das ist ein fundamentaler Unterschied in jeder Prüfung.
Warum das Thema gerade jetzt strategisch wird
Man könnte einwenden, dass Datenresidenz ein alter Hut ist. Was die Lage verändert hat, ist KI. Die interessantesten KI-Anwendungsfälle arbeiten mit den sensibelsten Daten: Kundenhistorien, Verträge, Konstruktionsdaten, Patientenakten. Wer KI ernsthaft nutzen will, muss die Souveränitätsfrage beantworten, sonst bleiben genau die wertvollsten Anwendungsfälle verboten.
Genau deshalb ist es bemerkenswert, dass Google seine deutschen Investitionen und sein KI-Angebot zusammen ausbaut. Die Rechenleistung für KI-Workloads entsteht in Deutschland, und die Souveränitätswerkzeuge gelten auch für die KI-Dienste. Damit wird ein Satz möglich, den viele Rechtsabteilungen bisher nicht schreiben konnten: Wir nutzen moderne KI-Modelle, und die Daten verlassen die EU nicht. Wie der Weg von der KI-Idee in den produktiven Betrieb aussieht, haben wir im Artikel über KI-Piloten in Produktion beschrieben. Die Souveränitätsfrage ist das Fundament darunter.
Ein Szenario aus der Praxis: der Weg eines Herstellers
Wie die Klassifizierung in der Realität aussieht, zeigt ein typisches Szenario. Ein Maschinenbauer will seine Wartungsdokumentation mit KI durchsuchbar machen und perspektivisch Wartungsprognosen aus Sensordaten gewinnen. Der erste Reflex der Rechtsabteilung: Konstruktionsdaten in einer US-Cloud, ausgeschlossen. Das Projekt liegt daraufhin ein halbes Jahr auf Eis.
Die Wende kommt mit der Dateninventur. Sie zeigt, dass das Vorhaben drei sehr unterschiedliche Datenklassen berührt. Die Wartungshandbücher und Serviceberichte enthalten keine Konstruktionsgeheimnisse und keine Personendaten, sie dürfen mit einer EU-Datengrenze problemlos in die Frankfurter Region. Die Sensordaten aus dem Feld sind Maschinendaten ohne Personenbezug, ebenfalls unkritisch, sobald die Kundenverträge geprüft sind. Nur die eigentlichen Konstruktionsdaten sind hochsensibel, und sie werden für den Use Case gar nicht gebraucht. Das Ergebnis: Neunzig Prozent des Projekts laufen mit der ersten Souveränitätsstufe, der sensible Rest bleibt schlicht draußen. Aus dem Grundsatzproblem wurde eine Architekturentscheidung, und das Projekt lief an.
Dieses Muster wiederholt sich in fast jedem Fall, den wir begleiten. Die pauschale Frage, ob man in die Cloud darf, ist unlösbar. Die konkrete Frage, welche Datenklasse mit welcher Stufe wohin darf, ist fast immer lösbar.
Die häufigsten Missverständnisse zur Cloud-Souveränität
Drei Missverständnisse begegnen uns dabei immer wieder. Das erste: Datenresidenz gleich Souveränität. Dass Daten in Frankfurt liegen, sagt allein noch nichts darüber, wer auf sie zugreifen kann. Deshalb gibt es die gestuften Modelle, und deshalb lohnt der genaue Blick auf Betrieb und Schlüsselverwaltung statt nur auf den Standort des Rechenzentrums.
Das zweite Missverständnis ist das Gegenteil: die Annahme, nur die eigene Serverlandschaft sei wirklich sicher. Die ehrliche Gegenfrage lautet, wer die eigenen Server patcht, überwacht und gegen Angriffe härtet, und wie sich dieses Niveau mit dem eines Anbieters vergleicht, der Sicherheit im industriellen Maßstab betreibt. Für die meisten Mittelständler fällt dieser Vergleich unbequem aus.
Das dritte Missverständnis: Souveränität sei ein einmaliges Projekt. Tatsächlich ist sie eine Eigenschaft der Architektur, die mit jeder neuen Datenquelle und jedem neuen Use Case mitgepflegt werden muss. Wer sie von Anfang an als Konfiguration und Prozess aufsetzt statt als Ausnahmegenehmigung, hat bei jedem Audit die Nachweise bereits in der Hand.
Welche Rolle Ihr Datenschutzbeauftragter dabei spielt
Ein praktischer Rat zum Schluss der Analyse: Holen Sie Ihren Datenschutzbeauftragten an den Anfang des Vorhabens, nicht an sein Ende. In vielen Projekten wird die Architektur fertig geplant und dann zur Freigabe vorgelegt. Das erzeugt genau die Konfrontation, die beide Seiten vermeiden wollen, denn jetzt kann der Datenschutz nur noch bremsen oder durchwinken.
Der bessere Weg dreht die Reihenfolge um. Der Datenschutzbeauftragte definiert mit, welche Datenklassen welche Schutzstufe brauchen, und bekommt die Souveränitätswerkzeuge gezeigt, mit denen diese Stufen technisch erzwungen werden. Aus dem Prüfer wird ein Mitgestalter, und aus der Freigabe am Ende wird eine Reihe kleiner Zustimmungen unterwegs. Nach unserer Erfahrung verändert das die Projektlaufzeit mehr als jede technische Entscheidung. Die Cloud-Frage scheitert selten an den Werkzeugen. Sie scheitert an Beteiligten, die zu spät gefragt wurden.
Der Anfang ist eine Liste, kein Projekt
Falls die Cloud-Frage in Ihrem Haus seit Jahren im Kreis diskutiert wird, ist der Ausweg unspektakulär. Sie brauchen kein Großprojekt und keinen Grundsatzbeschluss. Sie brauchen eine Liste Ihrer Datenklassen mit ihren Schutzanforderungen und eine Zuordnung zu den verfügbaren Souveränitätsstufen. Mit dieser Liste wird aus der Grundsatzdebatte eine Reihe konkreter, einzeln entscheidbarer Fragen.
Wir erstellen diese Zuordnung gemeinsam mit unseren Kunden und bauen anschließend die Architektur, die dazu passt. Unsere eigenen Systeme betreiben wir selbst auf Google Cloud, in europäischen Regionen, genauso wie die Systemlandschaften mehrerer unserer Kunden. Den Einstieg finden Sie auf unserer Google-Cloud-Seite. Alle Analysen finden Sie in unseren Google Cloud Insights.