Security And Compliance
The Illusion of Sovereign Cloud: Why the Real Control in the AI Era Lies in Identity Governance
European companies have discovered that sovereign clouds cannot truly control AI workloads. Identity governance is the new battlefield for cloud security and compliance. This article analyzes European experiences and provides new approaches for US companies to manage AI risks.
Event Background: The Cost and Lessons of the European Sovereign Cloud Experiment
In January 2025, DORA (Digital Operational Resilience Act) took full effect in the EU; the NIS2 Directive was implemented in each member state; and high-risk AI system provisions under the EU AI Act are set to take effect in August 2026. Faced with triple regulatory pressure, European companies—especially those in finance, critical infrastructure, and manufacturing—have over the past two years massively migrated workloads, renegotiated contracts, and enshrined sovereign cloud into board-level risk frameworks.
Hyperscalers responded rapidly. AWS launched its European sovereign cloud in January 2026, with Microsoft and Google following with similar offerings. The market seemed mature.
However, at the European Identity & Cloud Conference (EIC) in Berlin in May 2026, a clear shift in sentiment among practitioners emerged. The euphoria over the sovereign cloud concept had passed. Replacing it was a cautious, even uncomfortable, dissection of the gap between marketing slides and operational reality.
Martin Kuppinger, co-founder and principal analyst at KuppingerCole, observed: "Cloud sovereignty loomed larger at EIC this year, but the discussion has fragmented into where and whether it's needed. The consensus is that sovereignty itself is not a value; the required level depends on the use case and risk assessment. There is no binary sovereignty model."
Technical Analysis: Why Sovereign Cloud Cannot Solve Control Issues
When enterprises talk about sovereign cloud, they usually think of data residency—where data is stored. European data centers, European jurisdiction. But data residency is only the beginning of the conversation, not the end.
The thornier issue concerns control: who holds the encryption keys? Who can compel access under which laws? Who can see metadata, access logs, and workload telemetry? When you run AI inference or model training on a sovereign cloud platform, who controls the model registry, training data pipeline, and output logs? When an AI agent acts autonomously—scheduling workloads, configuring resources, making access decisions—on whose architecture does that agent run? Who can observe its behavior?
These are not hypothetical concerns. The 2018 CLOUD Act gives U.S. authorities the power to compel U.S. companies to provide data stored overseas, regardless of server location. European sovereign cloud offerings from U.S. hyperscalers address this through operational separation, European legal entities, and customer-managed keys, but these structures are new, partially tested, and vary significantly between vendors.
Germany's BSI has further raised the bar.The German BSI has further raised the bar. In April 2026, it published the *Cloud Computing Autonomy Standard (C3A)*: the first framework to operationalize cloud sovereignty at the technical level, covering disconnection scenarios, employee residency requirements, and special provisions for federal takeover of cloud operations in defensive scenarios. Though formally non-binding, the standard is widely expected to become the de facto benchmark for German federal procurement and could serve as a template for an EU-level framework in the legislative pipeline. For U.S. CISOs, the direction is clear: the regulatory definition of cloud sovereignty is tightening, and the gap between "data in Europe" and "operational sovereignty" will only widen.
Where sovereignty actually resides
The most unambiguous theme of EIC 2026 was this: identity—not network boundaries or data residency—is where cloud sovereignty either succeeds or fails.
Jason Keenaghan, Head of Identity Management Strategy at Thales, put it bluntly: "Identity is transitioning from an IT function to regulated infrastructure. The most important question for the next decade is: who is in control?"
For U.S. CISOs, this shift is very real: identity governance is moving from pure IT plumbing to a regulated control plane that auditors, regulators, and even enterprise customers will scrutinize increasingly in RFPs. "Who is in control" is no longer a philosophical question—it is a contractual one.
The problem is this: You can place your data in a Frankfurt data center and use customer-managed keys, but if your identity governance is weak—you don't know which human users, service accounts, and AI agents have what access and under what conditions—your sovereignty posture is only as strong as the weakest identity. A compromised privileged account does not care about data residency.
This is especially severe for AI workloads. Autonomous AI systems—models that act independently, call APIs, provision resources, and access data—are creating a new class of non-human identities that most enterprise IAM systems were never designed to manage. Consider a concrete example I saw in a client environment: an LLM-based deployment agent that had standing access to the Kubernetes clusters it provisioned. It autonomously scheduled workloads, configured resources, and made access decisions. If that agent runs on sovereign cloud infrastructure but its identity—credentials, permissions, audit trails—is not properly governed, your sovereignty posture is exactly as strong as the weakest link in that agent's access chain. If you run a similar agent today in a U.S. cloud region, the same identity blind spot exists—even if you never touch a sovereign cloud region.Sebastian Rohr, an IAM consultant and IDPro member with two decades of experience in identity governance architecture, distills the practical requirements for governing AI agents: "Every agent needs an assigned non-human identity. A solid 'on behalf of' delegation model must be established. Audit trails need to be provided through SIEM integration. No long-term credentials or API keys—only temporary credentials. Context-based authentication and fine-grained access control. Agents must be managed as real identities. And once this foundation exists: risk-based continuous re-authentication, combined with real-time revocation capabilities. Do we have all these capabilities everywhere right now? Not necessarily—but architecting to support them? That's entirely possible."
For AI agents, the practical question is simple: Can you list every agent running in your environment, manage its permissions, and revoke access in real time? If not, you don't truly have control over the workload—regardless of which cloud region it runs in.
Enterprise Impact Analysis: Cost-Benefit Assessment of Sovereign Cloud
For US CISOs managing EU operations, EU subsidiaries, or EU customers, the practical question is not whether sovereign cloud is philosophically correct, but whether the additional cost and complexity deliver sufficient risk reduction for specific workloads. Most organizations I've worked with over-apply sovereign cloud to workloads that don't need it, while under-applying it to those that do.
The following framework, refined over two years of European deployment practice, serves as a rapid classification tool:
| Workload Type | Requires Sovereign Cloud? | Reason | |-------------------|-------------------------------|------------| | Regulated financial data, customer PII (EU residents) | Yes | Legal data residency requirements; sovereign cloud provides clear jurisdictional protection | | AI training data (containing sensitive personal information) | Depends | If data is anonymized and identity governance is in place, non-sovereign cloud may be considered; sovereign cloud provides additional legal buffer | | Internal dev/test environments (non-production) | No | Lower risk; sovereign cloud premium not worthwhile | | AI agents performing autonomous decisions (involving access control) | No, but strong identity governance is required | Sovereign cloud cannot control agent behavior; identity governance is key | | Disaster recovery/backup (non-sensitive geography) | No | Low cost-benefit ratio, unless explicit compliance requirements exist |
As Kuppinger stated: "Within an organization, different use cases have different needs for sovereignty levels—this is the norm, not the exception."
Market Competition Analysis: Responses from Cloud Providers and Identity Governance Vendors## Market Competition Analysis: Responses from Cloud Vendors and Identity Governance Providers
In the current market landscape, cloud vendors such as AWS, Azure, and Google Cloud are launching sovereign cloud products in an attempt to meet regulatory requirements. However, these products mainly address data residency and operational isolation, and do not fully solve the deeper issues of identity governance.
At the same time, the identity governance market is heating up. IAM vendors such as Thales, SailPoint, and CyberArk are beginning to include AI agent identity management in their product roadmaps. Kubernetes-native solutions like Spiffe/Spire are also gaining attention.
For enterprises, the correct strategy is not to choose one over the other: sovereign cloud and identity governance are complementary. Sovereign cloud provides legal assurance for data residency, while identity governance provides practical control at the operational level. Investing in only one may lead to risk exposure.
Industry Trend Observation: Identity Governance Becomes the New Control Plane for AI Workloads
From the agenda of EIC 2026, the trend is evident: AI security, identity fabric, workload identity management, and cryptographic agility have become hot topics. Sovereign cloud has become the default infrastructure, and conversations among practitioners have shifted to what to build on top of it and who controls that layer.
For US enterprises, the SEC's cybersecurity disclosure rules (December 2023), CISA's AI security guidelines, and various state-level AI regulatory proposals are creating pressures similar to those in Europe. If you run AI workloads for EU customers, operate an EU subsidiary, or simply face the question of where to store sensitive AI training data and model outputs — you are already part of this conversation. The European experience is your preview.
CloudTechDaily Insight
Europe's sovereign cloud experiment has revealed a key lesson: data residency does not equal operational control. When AI agents, service accounts, and automated workloads become the core of enterprise IT infrastructure, identity governance is the true control plane.
For CISOs and CIOs, this means: do not treat sovereign cloud as a governance silver bullet. It is a legal tool, not an operational tool. Real investment should be in identity governance architecture — one that can manage both human and non-human identities, support real-time revocation and risk-based continuous authentication. Otherwise, your AI workloads, regardless of which cloud region they run in, are exposed to the same risks.
Looking ahead, identity governance will become a core pillar of enterprise IT strategy, as important as AI security, compliance, and cloud architecture. Enterprises that first elevate identity governance to a board-level topic will gain true control in the AI era.
Reference trail · cloudtechdaily
cloudtechdaily frames this note through Cloud Platforms / Data Centers / Enterprise SaaS: dates, names and status changes still need checking. Cloud Platforms / Data Centers / Enterprise SaaS explains the local editorial angle; Source links should be opened before the summary is reused.