The most common question in German cloud projects isn't a technical one — it's a legal one: are we allowed to store our data there? Over the past few years, Google has built a remarkably concrete answer. €5.5 billion is flowing into German data centers and sites through 2029, Munich is home to the first Sovereign Cloud Hub, and the sovereignty portfolio ranges from EU data boundaries to fully air-gapped environments. Here's what you actually need — and how to answer the question properly.
The Question That Follows Every Cloud Project in Germany
Anyone who has proposed a cloud project at a German company knows the moment. The technical team is convinced, the business case is solid — and then legal raises its hand: exactly where does the data reside? Who can access it? What about the GDPR, what about US law, what does the data protection officer say?
These questions aren't obstructionism. They're legitimate, and in regulated industries they determine whether a project is feasible at all. The good news is that the answers have improved considerably over the past two years. Cloud providers have understood that the European market cannot be won without credible sovereignty offerings, and Google has responded more visibly than most.
What Google Is Actually Building in Germany
Numbers say more than statements of intent. Google is investing €5.5 billion to expand its German infrastructure between 2026 and 2029. This includes a new data center in Dietzenbach near Frankfurt, further expansion of the Hanau site, and growing offices in Berlin, Frankfurt, and Munich. In November 2025, Google also opened its first Sovereign Cloud Hub in Munich — a facility where customers can test sovereign cloud architectures hands-on before committing.
For context: this is not a marketing showroom, but physical infrastructure on German soil. Data stored in the Frankfurt region resides in Germany, is subject to European law at the point of storage, and is accessible with German-level latency. For many use cases, that alone answers half of the opening question.
The Three Tiers of Sovereignty
The other half of the answer lies in the portfolio — and precision matters here, because the term sovereignty is used loosely. Google Cloud offers three tiers: Data Boundary, Dedicated, and Air-Gapped.
The first tier, Google Cloud Data Boundary, governs where data is stored and processed. You can specify that both must occur exclusively within the EU or within a particular country. This covers the requirement that actually comes up in most projects: data residency backed by contractual and technical controls.
The second tier, Google Cloud Dedicated, goes further. Here, the cloud is operated by a local, trusted partner. In Germany, that partner is T-Systems, a subsidiary of Deutsche Telekom. Operations, controls, and access sit with a German company, while the underlying technology comes from Google. This model addresses the concern that a US provider could be compelled by its home jurisdiction to grant access.
The third tier, Air-Gapped, is full separation — a standalone environment with no connection to the public Google network, for cases where even the second tier is not sufficient, such as classified information or critical infrastructure subject to the strictest requirements.
The most important thing to understand about this portfolio: most companies need the first tier, some need the second, and very few need the third. Demanding the highest tier as a blanket policy means paying for requirements you don't have. Defaulting to the lowest tier means risking a painful audit. The right answer comes from classifying your own data — not from gut instinct.
How to Answer the Question Properly for Your Organization
The opening question was: are we allowed to put this in the cloud? The honest answer is almost always: it depends on which data. And that distinction is the way out of the deadlock where so many cloud discussions get stuck.
The first step is a data inventory. What types of data exist in the organization, and what protection requirements apply to each? Product data and anonymized telemetry have different requirements than HR data, which in turn differs from health records or proprietary design data. In most organizations, this inventory reveals that a large share of data can move to an EU region without issue, a smaller share has elevated requirements, and a very small share needs special handling.
The second step is mapping: data class to sovereignty tier. From this mapping, the architecture follows almost naturally. The bulk of workloads run in the Frankfurt region with Data Boundary, sensitive areas get the appropriate higher tier, and everything else stays where it is for now. Cloud adoption is not an all-or-nothing decision, even though it is often debated that way.
The third step is documentation. Data protection officers and auditors don't want promises — they want traceable controls. Google Cloud's sovereignty tools generate exactly these records: where data resides, who accessed it, which boundaries are technically enforced. Compliance shifts from a matter of trust to a matter of configuration, and that is a fundamental difference in any audit.
Why This Topic Is Becoming Strategically Important Right Now
One might argue that data residency is old news. What has changed the picture is AI. The most compelling AI use cases work with the most sensitive data: customer histories, contracts, engineering data, patient records. Anyone serious about using AI has to answer the sovereignty question first — otherwise the most valuable use cases remain off-limits.
That is exactly why it matters that Google is building out its German investment and its AI offering in parallel. The compute capacity for AI workloads is being created in Germany, and the sovereignty controls apply to the AI services as well. This makes a statement possible that many legal departments have not been able to put in writing until now: we are using modern AI models, and the data does not leave the EU. We described what the path from AI idea to production looks like in our article on bringing AI pilots into production. The sovereignty question is the foundation underneath.
A Real-World Scenario: One Manufacturer's Path
What classification looks like in practice is illustrated by a typical scenario. A mechanical engineering company wants to make its maintenance documentation searchable with AI and, over time, generate maintenance forecasts from sensor data. Legal's first reaction: engineering data in a US cloud — out of the question. The project is shelved for six months.
The turning point comes with the data inventory. It reveals that the initiative touches three very different data classes. The maintenance manuals and service reports contain no proprietary design information and no personal data — they can move to the Frankfurt region under an EU data boundary without any issue. The field sensor data consists of machine data with no personal reference, equally unproblematic once the customer contracts are reviewed. Only the actual engineering design data is highly sensitive — and it is not needed for this use case at all. The result: ninety percent of the project runs on the first sovereignty tier, and the sensitive remainder simply stays out. What had been a matter of principle became an architectural decision, and the project moved forward.
This pattern repeats itself in nearly every engagement we work on. The blanket question of whether cloud is permitted has no good answer. The specific question of which data class belongs at which tier and where is almost always answerable.
The Most Common Misconceptions About Cloud Sovereignty
Three misconceptions come up repeatedly. The first: data residency equals sovereignty. The fact that data sits in Frankfurt says nothing on its own about who can access it. That is why the tiered models exist, and why it is worth looking closely at operations and key management — not just at where the data center is located.
The second misconception is the opposite: the assumption that only your own server infrastructure is truly secure. The honest counter-question is who patches, monitors, and hardens your own servers — and how that compares to a provider operating security at industrial scale. For most mid-sized companies, that comparison is an uncomfortable one.
The third misconception: sovereignty is a one-time project. In reality, it is a property of the architecture that needs to be maintained with every new data source and every new use case. Organizations that treat it as configuration and process from the start — rather than as a one-off special approval — have the evidence ready in every audit.
The Role Your Data Protection Officer Plays
One practical piece of advice to close the analysis: bring your data protection officer in at the beginning of the initiative, not the end. In many projects, the architecture is fully designed and then submitted for sign-off. This creates exactly the confrontation both sides want to avoid — because at that point, the data protection function can only block or wave things through.
The better approach reverses the sequence. The data protection officer helps define which data classes require which level of protection, and is shown the sovereignty tools that technically enforce those levels. The auditor becomes a co-designer, and the final sign-off becomes a series of smaller agreements along the way. In our experience, this changes project timelines more than any technical decision. Cloud projects rarely fail because of the tools. They fail because the right people were brought in too late.
The Starting Point Is a List, Not a Project
If the cloud question has been going in circles at your organization for years, the way out is unspectacular. You don't need a major initiative or a policy resolution. You need a list of your data classes with their protection requirements, mapped to the available sovereignty tiers. With that list, the fundamental debate becomes a series of concrete, individually decidable questions.
We build this mapping together with our clients and then design the architecture that fits it. We run our own systems on Google Cloud, in European regions — just as we do for the environments of several of our clients. You can find the starting point on our Google Cloud page. All analyses are available in our Google Cloud Insights.