TL;DR: Drone strikes on AWS data centers in Bahrain and the U.A.E. exposed a foundational gap in AI and cloud strategies: data sovereignty and identity sovereignty belong in architecture as core priorities from day one. Trusted AI demands sovereign-aware, resilient foundations across regions and providers. Boards and CIOs who recognize this now and act accordingly will build AI strategies that hold up under geopolitical and regulatory pressures.
For boards and CIOs, cloud and AI concerns now extend beyond uptime and encryption.
Recent strikes on AWS data centers in Bahrain and the U.A.E. generated uncertainty around:
- Where critical data lives
- Whose laws apply to it
- Who actually controls identities when a region is under stress
These questions are at the root of two increasingly important concepts: data sovereignty and identity sovereignty.
As geopolitical instability escalates, CIOs are adjusting their cloud and AI strategies. Here’s what you need to know.
Data sovereignty matters more than ever
Data is subject to the laws and governance of the jurisdiction where it’s stored and processed. But data sovereignty goes further than data residency (location alone) by tying your risk profile directly to the legal, regulatory, and geopolitical environment of that particular location.
A few dimensions matter here:
- Location and jurisdiction: Governments increasingly require that sensitive categories of data (health, finance, public sector, defense) stay within national borders or move only through certified sovereign cloud environments.
- Control and access: Sovereignty determines who can compel access to your data. Countries are tightening rules to prevent foreign governments from reaching into cloud providers’ infrastructure.
- AI and sovereignty: Regulators now treat AI training data, embeddings, and inference logs as in scope for sovereignty and privacy law, alongside raw source tables. This changes the calculus for any AI deployment.
Data sovereignty has become a strategic priority for AI, and it must be built into architecture from the start. Organizations must know where their data lives, which jurisdictions govern it, and how that intersects with AI training, inference, and logging, before they build.
In practical terms, you can’t do credible, trusted AI on top of single‑region, single‑provider, single‑point‑of‑failure data and identity architectures.
Identity sovereignty must be addressed as well
If data sovereignty is about where your data lives and which country’s laws apply to it, identity sovereignty is about who really controls your identity infrastructure, and how resilient it is when things go wrong.
Three questions expose the risk:
- Who owns your primary identity systems? For most enterprises, that means Active Directory (AD) and Entra ID. If those systems are fully dependent on a single cloud region or provider, you have effectively outsourced a single point of failure.
- How recoverable are your identities under stress? The AWS incidents showed that even highly available cloud deployments can be disrupted by physical or geopolitical events. Identity sovereignty means you can recover quickly from another location when a data center goes down.
- Can you prove who did what? In a major outage or attack, audit trails and logs may be partially unavailable. Identity sovereignty requires enough independent control and telemetry to reconstruct actions and maintain trust, even when infrastructure is under pressure.
Identity experts and vendors are increasingly framing identity as the enterprise control plane for AI and cloud, particularly as machine identities (service accounts, automation, and AI agents) now outnumber humans by an estimated 82:1. If you can’t recover that control plane, you’re not really in control of your environment.
Why the AWS incidents made data and identity sovereignty urgent
The Bahrain and U.A.E. events were a stark example of physical and geopolitical risk intersecting with cloud architecture:
- Drone strikes disrupted multiple AWS Availability Zones, impacting banking and critical services that depended on those regions.
- Many workloads were designed for regional resilience only, instead of sovereign, cross-provider resilience. Disaster recovery plans that assumed multiple AZs in only one region broke down amid crisis.
Two lessons stand out:
- Location risk is real. Where your data and infrastructure live can be affected by physical attacks, sanctions, or diplomatic tensions. Data and workloads concentrated in a single region share that region’s risk profile.
- Identity and recovery are sovereignty issues. When primary identity systems, admin tools, and backups are tightly bound to an impacted region or provider, recovery depends on factors you don’t control. That’s an identity sovereignty failure as much as an availability one.
Regulators are paying attention. At the same time, the U.S. has been explicitly pushing back on data localization measures that could fragment global cloud architectures. The net effect for enterprises is more scrutiny on where data and identity live and how they’re governed.
Why AI raises the stakes for identity and data sovereignty
AI amplifies every sovereignty risk because:
- AI centralizes value and exposure. When AI systems train on and access large amounts of data, they become a concentration point for both value and exposure. If that AI stack depends on a specific region or provider, you inherit that region’s full risk profile – that could include natural or human-made disasters.
- AI increases identity risk. AI agents and automation often operate with elevated privileges and broad data access. When identity infrastructure fails or is compromised, AI can make that failure catastrophic quickly.
- Auditability is critical for trust. Regulators and customers are asking what the AI did, who approved its access, under what policies, and based on which data. Answering those questions requires data and identity sovereignty you can trace and prove across regions and providers.
Trusted AI requires trusted foundations for data and identities. And trusted foundations require sovereignty and resilience built into the architecture from the start.
What this means for partner ecosystems
For hyperscalers, ISVs, and GSIs alike, sovereignty must be a strategic shared design priority for every joint solution going to market.
In practice, that means:
- Building multi-region and multi-cloud architectures that respect data and regulatory boundaries
- Making Entra ID, AD, and other identity control planes independently recoverable
- Keeping AI-ready data products consistent across sovereign edges without fragmenting the broader AI strategy
Focusing on platform modernization, identity security, and trusted AI-ready data supports data and identity sovereignty.
Requirements for data and identity sovereignty
Achieving data sovereignty requires visibility and control over your data estate.
You need architecture that:
- Enables discovery and classification across regions to automatically identify where sensitive data lives, how it moves between regions and clouds, and which sovereignty or residency rules apply.
- Delivers governed, reusable data products with clear lineage, policies, and access controls, so teams can safely feed AI systems and prove where the data came from and which rules apply.
- Supports hybrid and multi-cloud architectures that honor sovereignty requirements, keeping certain data in-country or on-premises, while still participating in broader AI platforms on Microsoft, Snowflake, Databricks, and AWS.
The goal is to have enough factual control and visibility to implement the policies regulators and boards require.
On the identity side, the priorities are clear:
- Independent backups and recovery with enhanced recovery capabilities for Entra ID and AD, including bring-your-own-key options, Intune backup and restore, and advanced AD disaster recovery (standby forests, phased recovery), giving organizations options when a region or provider comes under stress.
- Attack surface reduction to detect and reduce risky configurations, stale privileges, and ghost identities (including non-human accounts), making it harder for attackers to exploit identity weaknesses during or after an outage.
- Controls with strong compliance standards to align identity resilience with FedRAMP High and equivalent frameworks, helping public sector and regulated organizations meet both sovereignty and compliance obligations.
If identity is your control plane for AI and cloud, you need to own its resilience and be able to restore it under adverse conditions. That’s identity sovereignty in practical terms.
What comes next
Data sovereignty and identity sovereignty are no longer niche topics for public sector RFPs and legal teams. Sovereignty is now a mainstream concern in architecture and risk discussions.
Every AI strategy should start with sovereign-aware data architectures and independently recoverable identity control planes. You simply cannot maintain credible, trusted AI with single-region, single-provider, single-point-of-failure data and identity architectures.
Here’s how to build out your AI strategy:
- Make data sovereignty a strategic priority. Know where data lives, which laws apply, and how that intersects with AI training, inference, and logging before building.
- Treat identity sovereignty as critical infrastructure. Ensure your identity control planes are hardened, independently recoverable, and fully auditable across regions.
- Use sovereign-aware data and identity architectures. Implement multi-region and multi-cloud patterns that respect regulatory boundaries and give AI systems the governed, trustworthy foundations they require.
In a world where both data and identity are geopolitical assets, control, resilience, and trust are crucial. Those core components form the foundation of an AI strategy that can withstand the technical failures, geopolitical incidents, and regulatory pressures that are increasingly part of the landscape.
