Your board is asking. Your legal team is asking. Your auditors will be asking: Should AI workloads move to sovereign cloud, or stay on AWS, Azure or GCP? European enterprises have already run this experiment — under real regulatory pressure, with real money and real consequences. Many discovered that sovereign cloud alone didn’t deliver the control they expected. The real control point turned out to be somewhere else entirely.
Europe ran this experiment first, under regulatory pressure US enterprises are only starting to feel. With DORA fully in force since January 2025, NIS2 enforcement underway across EU member states and the EU AI Act’s high-risk system provisions taking effect in August 2026, European enterprises — particularly in financial services, critical infrastructure and manufacturing — have spent two years migrating workloads, renegotiating contracts and writing sovereign cloud into board-level risk frameworks. The hyperscalers responded. AWS launched its European Sovereign Cloud in January 2026. Microsoft and Google followed with their own sovereignty offerings. The market arrived.
US enterprises are not far behind. The SEC’s cybersecurity disclosure rules, CISA’s AI security guidance, proposed state-level AI regulations and growing board-level scrutiny of AI governance are creating comparable pressures on this side of the Atlantic. If your organization runs AI workloads on behalf of EU clients, operates EU subsidiaries or simply faces the question of where sensitive AI training data and model outputs should live — you are already in this conversation. The European experience is your preview.
What has not arrived is clarity on what you actually get — and what you do not. At the European Identity and Cloud Conference in Berlin this May, the mood among practitioners had shifted measurably from previous years. The cheering for the sovereign cloud concept was over. What was happening on stage and in the corridors was a careful, sometimes uncomfortable, dissection of the gap between marketing slides and operational reality. (EIC returns to Berlin in May 2027.)
The conference agenda made the shift visible. Where previous years centered on sovereign cloud architecture and vendor selection, the 2026 program’s trending themes — as mapped in the closing session — were AI security, identity fabric, workload identity management, and crypto agility. Sovereign cloud had become assumed infrastructure. The practitioner conversation had moved to what you build on top of it, and who controls that layer.
Martin Kuppinger, distinguished analyst and co-founder of KuppingerCole, observed the same shift: “Cloud sovereignty had a much larger role at this year’s EIC, with a differentiated discussion about whether and where it is needed. There is common sense that sovereignty is not a value in its own right — the required level depends on the use case and a proper risk assessment. There is no binary model for sovereignty.”
Sovereign cloud, on the slides, looks like control. In the contracts, service matrices and AI agent deployments, it often looks more like a very expensive illusion.
The control question nobody answers clearly
When enterprises talk about sovereign cloud, they are usually thinking about data residency — where the data lives. European data center, European jurisdiction. But data residency is the beginning of the conversation, not the end.
The harder questions are about control. Who holds the encryption keys, and who can compel access to them under what legal circumstances? Who sees the metadata, the access logs, the telemetry from your workloads? When you run AI inference or model training on a sovereign cloud platform, who controls the model registry, the training data pipeline, the output logs? And when an AI agent acts autonomously on your behalf — scheduling workloads, provisioning resources, making access decisions — whose infrastructure is that agent running on, and who can observe what it does?
These are not hypothetical concerns. The CLOUD Act of 2018 gives US authorities the ability to compel US companies to produce data stored abroad, regardless of where the servers sit. European sovereign cloud offerings from US hyperscalers are structured to address this — through operational separation, European legal entities and customer-managed keys — but the structures are new, partially tested and vary significantly between providers.
Germany’s BSI has raised the stakes further. In April 2026, the agency published its Criteria Enabling Cloud Computing Autonomy (C3A): The first framework to operationalize what cloud sovereignty actually means in technical terms, including disconnect scenarios, staff residency requirements and an extraordinary provision for federal takeover of cloud operations in defense scenarios. Formally non-binding, the criteria are widely expected to become the de facto benchmark for German federal procurement — and a likely template for EU-level frameworks now in the legislative pipeline. For US CISOs, the direction of travel is clear: Regulatory definitions of cloud sovereignty are tightening, and the gap between “data in Europe” and “operationally sovereign” is only going to widen.
Identity is where sovereignty actually lives
The clearest theme at EIC 2026 was that identity — not network perimeter, not data residency — is where cloud sovereignty either holds or breaks down. The argument is becoming hard to avoid.
Jason Keenaghan, who leads identity management strategy at Thales, framed it directly: “Identity is shifting from an IT function to a regulated infrastructure. The most important question for the next decade will be: Who is in control?”
For a US CISO, this shift is very real: Identity governance is moving from pure IT plumbing to a regulated control surface that auditors, regulators and even enterprise customers in RfPs will increasingly scrutinize. The question of “who is in control” is no longer philosophical. It is contractual.
Here’s the problem. You can put your data in a Frankfurt data center with customer-managed keys. But if your identity governance is weak — if you do not know which human users, service accounts and AI agents have access to what, and under what conditions — your sovereignty posture is only as strong as your weakest identity. A compromised privileged account does not care about data residency.
This is particularly acute for AI workloads. Agentic AI systems — models that act autonomously, make API calls, provision resources, access data — are creating a new category of non-human identities that most enterprises’ IAM systems were never designed to manage. Consider a concrete example I have seen in client environments: An LLM-based deployment agent with standing access to production Kubernetes clusters. It schedules workloads, provisions resources and makes access decisions autonomously. If that agent runs on sovereign cloud infrastructure but its identity — its credentials, its permissions, its audit trail — is not properly governed, your sovereignty posture is exactly as strong as the weakest link in that agent’s access chain. If you are running similar agents in US-based cloud regions today, the same identity blind spots exist — even if you never touch a sovereign cloud region.
Sebastian Rohr, an IAM consultant and IDPro member who has spent two decades on enterprise identity architectures, distilled the requirements for governing AI agents in practice: “Every agent needs an assigned non-human identity. A solid on-behalf-of delegation model must be established. An audit trail via SIEM integration is required. No long-lived credentials, no API keys — only ephemeral credentials. Context-based authentication and fine-grained access control. Agents must be managed as real identities. And once that foundation exists: Risk-based, continuous re-authentication combined with the ability for real-time revocation. Do we have all these capabilities everywhere today? Not necessarily — but designing the architecture for it? That is entirely possible.”
For AI agents in particular, the practical question is this: Can you list every agent running in your environment, govern its entitlements and revoke access in real time? If not, you do not truly control the workload — regardless of which cloud region it runs in.
What practitioners at EIC kept coming back to is not a sovereign cloud answer. It is an identity governance answer. Sovereign cloud buys you legal protection and data residency. Identity governance gives you operational control — and increasingly, it is the layer where AI workload sovereignty actually has to be enforced.
When sovereign cloud is worth it — and when it is not
For US CISOs managing EU operations, EU subsidiaries or EU customers, the practical question is not whether sovereign cloud is philosophically correct. It is whether the additional cost and complexity deliver sufficient risk reduction for specific workloads. Most organizations I have worked with are over-applying sovereign cloud to workloads that do not need it, while under-applying it to the ones that do.
A working framework, refined across two years of European deployments. Use this as a quick triage for which workloads truly justify a sovereign cloud premium. As Kuppinger puts it: “Within an organization, varying levels of sovereignty demand for different use cases are the norm, not the exception.”
Five things European enterprises learned the hard way
Sovereign cloud does not mean the hyperscaler cannot see your metadata. Customer-managed keys protect data at rest. They do not prevent the platform from logging access patterns, API calls and resource consumption. Know what your provider logs and where those logs go. For US CISOs: This matters for any hyperscaler operating under foreign data localization requirements you may face as the regulatory landscape evolves.
Early sovereign cloud offerings had real service gaps — and exit is harder than expected. Many advanced AI/ML services were unavailable at launch; enterprises that committed early ended up running hybrid architectures more complex than anticipated. And lock-in in sovereign cloud contexts is harder to escape than standard cloud. Build exit strategy into procurement decisions before you sign.
Identity governance cannot be deferred. The enterprises that got the most value from sovereign cloud investments had already done the identity governance work — asset inventory, access classification, non-human identity management. For US CISOs facing similar AI governance and resilience requirements: This is the lesson that will hurt most if you have not done the work.
Sovereign from a hyperscaler is not the same as sovereign from a European provider. AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty and Google Sovereign Cloud are structurally different from offerings built by IONOS, Hetzner, OVHcloud or Deutsche Telekom. The former offers broader service catalogs with sovereignty controls layered on. The latter offer cleaner legal structures with narrower feature sets. Neither is universally better — and the choice should follow workload characteristics, not procurement preference.
What US CISOs should do now
If your organization has EU operations, subsidiaries or customers — or AI workloads sensitive enough that the regulatory direction in the US matters — these are decisions you will face. Three concrete steps.
1. Classify your workloads by sensitivity and regulatory exposure before you classify them by cloud type. Not everything needs sovereign cloud. But know which workloads do before a regulator, auditor or customer’s procurement team asks.
2. Audit your identity governance posture before your cloud strategy. Sovereign cloud without IAM maturity is expensive and insufficient. Governance has to happen at the identity layer, not the data center boundary.
3. Read the contracts carefully. Key management, metadata logging, law enforcement access and service continuity provisions vary significantly between providers. Legal and security need to review them together — and AI workload provisions deserve their own column.
Europe’s sovereign cloud experiment is still running. The early results suggest the regulatory pressure is real, the market response is genuine and the operational complexity is higher than the marketing suggested. AI workloads make it more complex, not less. That is not a reason to avoid sovereign cloud — it is a reason to approach it with clearer eyes than the first wave of European adopters had. Buy the jurisdiction. Then govern the identity. In that order.
Sovereign cloud buys you a jurisdiction. Identity governance buys you control. AI workloads need both, and most enterprises are buying only one.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
No Responses