In-Kingdom ≠ sovereign: data residency myths in 2026

The confusion that costs Gulf governments unsound contracts

As Annota8’s founder I’ve sat with Gulf government clients and with US-side procurement, and I see the same confusion repeat. A technical team at a Gulf ministry writes an RFP with the clause: “Data residency in-Kingdom, NDMO certification, PDPL compliance.” A global vendor responds: “We provide a Riyadh region, all our certifications are in order.” The deal closes. The risk that emerges — illustratively — is the conflict-of-laws scenario: a US federal court can, under the CLOUD Act, order a US-incorporated cloud provider to disclose customer data the provider holds outside the United States, including data in the provider’s in-Kingdom region⁴. That is the legal mechanism worth understanding.

The legal question becomes: does the provider comply with the US court order, or does it comply with the Gulf country’s local data-protection policy? Under the CLOUD Act, the provider’s legal obligation runs to the US order. The Gulf government and the customer may have a procedural path to object, but that path is not automatic, and the parties affected may not always be notified⁵.

The CLOUD Act has been the operative US statute since 2018 — the conflict-of-laws risk it creates for non-US customers is a documented legal-practice topic, not a one-off hypothetical. The details below.

What the US CLOUD Act actually says

The “Clarifying Lawful Overseas Use of Data Act” was enacted in March 2018 as an amendment to the original Stored Communications Act of 1986⁴. The operative statutory text, codified at 18 U.S.C. § 2713, is one paragraph:

“A […] provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider’s possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States.”⁶

Operational translation: any US company that owns or controls data — wherever in the world the data sits — is obligated to hand it over to US authorities on a valid court order. The geographic location of the server does not change anything.

AWS is an Amazon subsidiary — US. Microsoft Azure — US. Google Cloud — US. Oracle Cloud — US. All subject to the CLOUD Act on their global data, including their in-Kingdom regions.

The 2018 amendment was passed after Microsoft Corp. v. United States (the “Microsoft Ireland case”), which reached the US Supreme Court. Microsoft had refused to hand over emails stored in Ireland; Congress passed the CLOUD Act to close the gap, and the case was vacated and dismissed as moot⁷.

The Saudi legal frame on the other side

On the other side, Saudi Arabia holds:

• Personal Data Protection Law (PDPL) — Royal Decree M/19, 2021, fully in force since September 2024, administered by SDAIA⁸. Defaults to in-Kingdom residency for personal data with narrow exceptions.
• National Data Management Office (NDMO) — within SDAIA. Issues the National Data Classification with four levels: Public, Restricted, Secret, Top Secret⁹. Each level has different cloud-deployment controls.
• The SDAIA AI Ethics Principles (2023) and the Generative AI Guidelines (January 2024), updated through 2024-2025¹⁰.

The Saudi frame says: data classified “Secret” or “Top Secret” must remain on sovereign infrastructure — and “sovereign” here does not just mean “in-Kingdom.”

What makes infrastructure actually “sovereign”

Synthesising across the European frameworks (Gaia-X), the French SecNumCloud standard, and the direction Saudi Arabia is taking, true sovereignty plausibly requires at least five layers (this enumeration is the author’s working framework, not a quote from any single regulator):

Layer 1 — Physical residency. Servers and data sit inside national borders. This is what AWS Riyadh and Microsoft Azure UAE North provide.

Layer 2 — Jurisdiction. The operating legal entity is subject to national law only, not foreign law. This is where global-provider regions fail — because the parent entity is American, the whole company sits under the CLOUD Act.

Layer 3 — Ownership. Majority (or full) equity in the operating entity sits with national citizens or national entities. This reduces the surface area for foreign legal pressure.

Layer 4 — Workforce. Who has access to the servers and the data? If AWS’s American or Indian staff hold admin access to the Saudi region, even with the boxes physically in Riyadh, the layer is broken. Real sovereignty requires day-to-day operations performed by security-cleared national citizens.

Layer 5 — Encryption and key custody. Encryption keys must live in an HSM inside the Kingdom, under customer control, such that if a CLOUD Act order lands at AWS, the company can truthfully say: “We hold the ciphertext; we do not hold the keys.”

Together the five layers produce “sovereign.” Layer 1 alone produces “in-Kingdom.” The gap is large.

Where the global cloud offers fail, precisely

I will go through four vendors candidly, based on their public documentation as of 2026:

AWS Saudi Arabia Region (announced March 2024, planned 2026 general availability¹): physical residency — sound. Jurisdiction — the operating provider is a US-incorporated entity, so the CLOUD Act test applies. Ownership — same. Workforce — mixed. Encryption supports KMS with HSM; for AWS-managed KMS keys the provider holds key custody, so reviewers should look at the customer-owned BYOK / external-key-store options when the workload requires that the provider not be able to compel access. AWS announced its “AWS European Sovereign Cloud” in October 2023, expanded it through 2024-2025, and reached general availability in early 2026; no equivalent for Saudi Arabia has been announced¹¹.

Microsoft Azure UAE North & UAE Central, plus the announced KSA region (partial availability)²: same structural starting point — Microsoft is US-incorporated. The G42 partnership in the UAE introduced an intermediary operating layer that some reviewers treat as more sovereign-friendly than a vanilla hyperscaler region; Microsoft’s $1.5 billion equity investment in G42 (April 2024, with a Microsoft board seat) is publicly reported, and the sovereignty implications are an active topic in legal-practice writing¹².

Google Cloud Doha (opened 22 May 2023³): same structure. Alphabet Inc. is American.

Oracle Cloud KSA (Jeddah region launched 2020; Riyadh region launched 2024 — two public-cloud regions in the Kingdom): same structure. Oracle is American¹³.

The vendors that approach real sovereignty are local providers: STC Cloud, NourNet, Salam Cloud — Saudi-domiciled entities with majority Saudi ownership, subject only to Saudi law, with Saudi workforce¹⁴. Mobily Cloud is Saudi-domiciled but its largest shareholder is Etisalat UAE (now part of e&), so its corporate-parentage profile differs from the others; UAE parentage does not import CLOUD Act exposure, but the “Saudi entities with Saudi ownership” framing does not cleanly apply¹⁵. The remaining gap with AWS is service maturity — and that gap is closing fast.

What this means for AI training and RAG deployments

The sharpest applications of the in-Kingdom vs. sovereign distinction show up in three AI use cases:

First — foundation model (FM) training data. If you are training a Saudi LLM on classified government data, the checkpoints, gradients, and embeddings themselves carry traces of the source data. Training on AWS in-Kingdom means the claim “the model is sovereign” is compromised — because a US-incorporated provider potentially has the ability to surrender checkpoints under a CLOUD Act order⁴.

Second — RAG corpora. Any government RAG deployment carries classified documents inside a vector store. If the vector DB is on a managed vector service typically deployed on AWS or GCP infrastructure (which inherits CLOUD Act exposure), or even on RDS inside AWS Riyadh, the deployment is non-sovereign.

Third — operational user data. Citizens using government apps leave traces in logs. In many enterprise AI architectures, application logs typically feed eval and model-improvement pipelines; if equivalent patterns are present in a Saudi government deployment and they run on non-sovereign infrastructure, citizens are exposed to potential unlawful disclosure.

Seven questions a government buyer must ask the vendor

A checklist for procurement teams in Saudi (and Gulf) government bodies evaluating an AI or cloud vendor:

1. Under which jurisdiction is the operating legal entity registered for this service in Saudi Arabia? Is it a branch, a subsidiary with an independent Saudi commercial registration, or a joint venture under MISA?
2. Who holds majority ownership in the operating entity? Saudi nationals or a foreign parent?
3. Can our data — even encrypted — be subject to a foreign court order through the parent entity? Yes/no answers only, no marketing language.
4. Who has admin access to the Saudi region? What are the nationalities of the root operators? What is their security-clearance level?
5. Where are the encryption keys held? Can you surrender the data without the keys? Who actually owns the keys — me (the customer) or you?
6. When a foreign court order arrives demanding Saudi data, what is your process? Do you notify me? Do you notify SDAIA? Do you contest it legally?
7. Is your service NDMO-certified? For which data-classification levels (Public, Restricted, Secret, Top Secret)?

A vendor that cannot answer these seven questions clearly, in writing, in a formal proposal, is not qualified for anything above the Public level.

How Annota8 is approaching this

We don’t sell cloud. Our approach is to build training data and RAG corpora for Saudi and Gulf government engagements on infrastructure that is actually sovereign — STC, NourNet, Salam, or government-owned data centers. Our annotation workflow is designed so MENA-resident operators work over a locked VPN into the customer’s sovereign environment, with zero data egress from the customer’s region. Our DPA template is aligned with PDPL considerations, our workflow is designed to respect NDMO classifications, and our architecture choices avoid routing through CLOUD-Act-subject cloud providers for in-scope data. See /compliance/pdpl and the government sovereign-AI page at /solutions/government-sovereign-ai.

References