Definition

Gulf AI data residency: the architecture questions buyers should ask

AI data residency in the Gulf is three separate questions that buyers usually collapse into one. First, where the law actually requires data to stay. As of September 2026, and as a reading of the instruments rather than legal advice: in Saudi Arabia, the UAE and Qatar the personal-data statutes regulate cross-border transfer rather than imposing general localisation, and the hard in-country rules sit in sectoral instruments such as the Saudi government cloud policy, UAE health and banking rules, and the Qatar Central Bank's cloud regulation. Second, whether the cloud region runs the model at all: a live region in-country can host the AI platform while serving few or none of the models in-region. Third, where inference actually happens, because data at rest is not data in use, and the managed routes to frontier models from Gulf regions are mostly globally routed by design. A buyer who asks only whether there is a region in-country gets a compliant-looking architecture that quietly processes prompts on another continent.

Three questions, and only one of them is legal

Three different things get called data residency in the same sentence, and they have different answers. The first is legal: what an instrument actually obliges you to keep inside the country. The second is infrastructural: whether the cloud region you chose runs the model you want. The third is operational: where the computation on your prompt happens, which is not settled by where your database sits.

Buyers usually ask a version of the first question, accept a version of the second as the answer, and never ask the third. This page covers the GCC jurisdictions where that pattern causes the most damage: Saudi Arabia, the UAE and Qatar, with Bahrain relevant as a region rather than as a separate legal analysis.

The legal question: Which instrument binds you: the personal-data statute, a sector regulator's rulebook, a government cloud policy, or a free-zone regime. They give different answers, and the sectoral ones are the strict ones.
The region question: Whether a live region exists in the country, and separately whether that region serves the model you intend to call. As of September 2026 those are not the same fact in any Gulf country.
The inference question: Where the prompt is processed and the output produced, as distinct from where the data is stored. Vendor documentation answers this explicitly, and the answer is often not the region you selected.

Where does Gulf law actually require data to stay?

Start with what the personal-data laws do not say. Saudi Arabia's PDPL, the UAE's Federal Decree-Law 45 of 2021 and Qatar's Law 13 of 2016 all regulate cross-border transfer: conditions, safeguards, assessments. None of them contains a general requirement that personal data be kept inside the country. If your residency requirement came from a summary of one of those laws, it is probably stricter than the law.

The binding localisation rules are sectoral, and where they apply they are strict. What follows is a reading of primary instruments as of September 2026, not legal advice, and each of them should be re-verified against the sources listed below and with your own counsel before it becomes a design decision.

Saudi government data: The MCIT Cloud First Policy states that all data in both the Government Cloud and the Commercial Governmental Cloud should be located geographically inside the borders of Saudi Arabia. The PDPL, enforced by SDAIA since September 2024, instead governs transfer: standard contractual clauses, binding common rules or accredited certification, with a transfer risk assessment in defined cases, no general prior approval requirement, and no adequacy list published as at September 2026.
Qatar, which runs the other way: The MCIT Cloud First Policy P005 classifies government data from C0 to C4, works through an endorsed provider list, and keeps the C4 tier off cloud entirely. The PDPPL pushes in the opposite direction: Article 15 forbids a controller from restricting cross-border flow except where the processing would breach the law or risk serious harm, and it sits in the penalty schedule. Qatar is the Gulf jurisdiction whose data-protection statute argues against localisation rather than for it. One sectoral exception is the Qatar Central Bank, whose cloud computing regulation, in force since April 2024, requires licensed entities to process personal and financial information within Qatar only, with QCB approval before any cloud arrangement.
UAE health data: Federal Law 2 of 2019 provides that health data related to services provided inside the state may not be stored or processed outside the UAE except under a health-authority resolution, and it applies including in the free zones. The exemption instrument is Ministerial Decision 51 of 2021; we have not been able to read its operative text, so treat the exception categories as something to confirm with counsel rather than to design around.
Abu Dhabi health, which is stricter again: ADHICS V2, issued by the Department of Health in May 2024 and effective from August 2024, requires cloud hosting physically within the UAE with none of the environments, infrastructures or systems outside the country, including backup and disaster recovery, and states no exemption route. A companion control catches encrypted, anonymised and pseudonymised copies, and another prohibits offshore analytics and offshore remote support. For an Abu Dhabi health estate this is the binding constraint, not the federal law.
UAE banking and payments: The CBUAE Outsourcing Regulation for banks requires that the Master System of Record, which includes all Confidential Data, is continuously maintained and stored within the UAE. The Consumer Protection Standards extend consumer and transaction data holding to all licensed financial institutions, and the stored value facility and retail payment regulations carry comparable requirements.
The UAE's three coexisting regimes: Federal, DIFC and ADGM. The federal PDPL has been in force since January 2022 but its executive regulations have still not been issued, so the compliance clock, the penalty schedule and the adequacy list are not operative, and in June 2026 the Cabinet approved a new AI and Data Authority to absorb the federal Data Office. DIFC entities sit under DP Law 5 of 2020 and Regulation 10; ADGM under its own 2021 regulations. Free-zone entities are not under the federal PDPL. The health data law reaches them anyway.

A live region in the country does not mean the models run in it

This is where most Gulf residency architectures break, and they break quietly, because the region genuinely exists and the platform genuinely runs in it.

Azure Qatar Central in Doha is live and hosts Microsoft Foundry. As of September 2026 it serves no Azure-sold models in any deployment type: the region does not appear in Microsoft's model region tables at all, Foundry Models is marked preview there, and the Foundry Agent Service is not offered. A team that reads “Foundry is live in Doha” as “we can run a model in Doha” has mistaken the platform's presence for the model's.

AWS shows the adjacent version of the same trap. Bedrock runs in Bahrain me-south-1, and the number of models it serves In-Region from there is zero. Everything reachable from that region is reached over Bedrock's Global routing.

The footprint itself needs the same care, and all of it is dated. As of September 2026 AWS runs me-central-1 in the UAE and me-south-1 in Bahrain, with a Saudi region announced and not live. Azure runs UAE North in Dubai and Qatar Central in Doha; UAE Central in Abu Dhabi is a restricted-access disaster-recovery region with no listed products, Qatar Central has no paired region, and Saudi Arabia East is not live. Google runs me-central1 in Doha and me-central2 in Dammam, which is Dammam rather than Riyadh and worth checking against whatever your diagram says, and has no UAE region and none announced. Announced capacity is a plan; a plan is not a control.

Data at rest is not data in use

Even where a model is reachable from a Gulf region, the vendors say plainly that reachability is not residency. Their own documentation is the strongest evidence a buyer has on this, and it is worth reading in the vendors' own terms.

AWS separates the two routes in Bedrock. Of In-Region inference it says your requests never leave the Region you specify. Of Global inference it says Bedrock routes your request to a supported commercial Region worldwide, and that data may be processed in any commercial Region. In the Gulf, as of September 2026, exactly two models are In-Region: Amazon Nova Pro and Nova Lite, in me-central-1 only. Every Claude, GPT and Grok model listed in me-central-1 and me-south-1 is Global-only. There is no Middle East Geo tier, the geographies offered being US, EU, Japan and Australia. AWS also notes that input prompts and output results may be stored in the opt-in Regions for abuse detection purposes, which is storage, not merely transit.

Microsoft's own deployment-type documentation draws the same line: data stored at rest remains in the designated Azure geography, but Global deployment types may be processed in any Azure region. There is no Middle East Data Zone. In UAE North, the deployment types that are genuinely in-region cover four models as of September 2026: three text-embedding models and whisper, and no chat model. The only in-region route to a frontier chat model there is Regional Provisioned Managed, which requires purchasing committed throughput capacity. Microsoft also describes the order in which deployment types reach a region: Global first, Data Zone next, single-region last, with no guaranteed date for the last of those.

Google states it as a warning rather than a footnote: endpoints do not guarantee data residency or in-region ML processing. Its machine-learning processing residency commitments cover thirteen locations, and not one of them is in the Middle East. Assured Workloads offers a Qatar Data Boundary and a KSA Data Boundary, and Google's documentation is explicit that these pin where resources live and do not provide residency controls for data in use or data in transit.

Every figure in this section is a snapshot. Vendor model catalogues change frequently and without notice, so re-check each claim against the vendor documentation in the sources below before it turns into an architecture decision, and record the date you checked it.

What the workable architectures actually are

Six paths survive contact with the facts above: five architectures and one procurement gate. None of them is free, and the trade-off in each case belongs in front of whoever signs it off rather than in an appendix. All of the vendor and legal detail here is as of September 2026 and should be re-verified before it is relied on.

Self-host open-weight models in-region: SageMaker AI runs in both me-central-1 and me-south-1, and Azure Machine Learning runs in UAE North and Qatar Central. The constraint is accelerators rather than software: on Google Cloud, Dammam lists L4 GPUs only and Doha lists no Vertex AI accelerators at all, and Vertex AI in both is the base platform, without AutoML, model monitoring or agent runtime, which sit in Singapore. You also take on the model operations you were buying a managed service to avoid.
Buy committed capacity for an in-region managed model: On Azure UAE North, Regional Provisioned Managed is the route to a frontier chat model that stays in the region. It is a reserved-capacity purchase with a commercial commitment attached, so it belongs in the business case at the start rather than in a late architecture review.
Use the two models that are actually In-Region: On AWS in the UAE, Amazon Nova Pro and Nova Lite are the In-Region options. For workloads those models handle well, that is a real architecture. For workloads they do not, it is an honest constraint rather than something to engineer around.
A sovereign or in-country platform, with the live-versus-announced line held: Core42's sovereign public cloud on Azure in the UAE is live per its own product pages, scoped to open and confidential or sensitive tiers. Ooredoo's sovereign AI cloud in Qatar has been live since July 2025, per Ooredoo. In Saudi Arabia, AMD reports MI355X capacity live as of 31 August 2026 serving HUMAIN's customers, while the AWS and HUMAIN AI Zone is a build-out its partners plan to 2028, and Stargate UAE's first 200MW is expected rather than confirmed. Buy against what is running, on the provider's own published status rather than the press release.
Accept cross-border inference where the law permits it: For personal data outside the sectoral regimes, the transfer route is frequently lawful: Saudi transfers on standard contractual clauses or binding common rules with a transfer risk assessment where required, and Qatari law that positively discourages restricting flow. This is the option most often ruled out by assumption rather than by an instrument. Ruling it in means writing down which instrument applies to which data set, which is the work most residency requirements skip.
The procurement path, in Saudi Arabia particularly: Customers billed in Saudi Arabia buy Google Cloud through CNTXT, per Google's own Dammam region documentation, and the Dammam region holds a CST Class C licence assessed by the National Cybersecurity Authority. That is a procurement route rather than an architecture, and discovering it late costs weeks.

The questions to put to any vendor or consultancy

Every question below has a factual answer somebody can look up. A supplier who cannot answer them has not done the work, and a supplier who answers them confidently without a source has done something worse. Take the answers in writing, with the date attached, because all of them expire.

Which instrument are we complying with, by name?: Not “Gulf data residency”. The PDPL, ADHICS V2 control CS 1.2, CBUAE Article 6.1, Cloud First Policy P005: the answer should be a named clause, and it determines everything downstream.
Which model, in which region, on which deployment type?: All three together, on the vendor's own terms: In-Region or Global on Bedrock; Global, Data Zone, Regional or Regional Provisioned Managed on Azure. A model name and a region name with no deployment type is not an answer.
Is the region running the model, or only the platform?: Ask for the line in the vendor's model region table, not a confirmation that the region is live. The two questions have had different answers in Doha and in Bahrain as of September 2026.
Where is inference performed, and where are prompts and outputs retained?: Processing location and retention are separate answers. Abuse-detection retention can put prompt text in a region your architecture diagram does not show.
What happens to backups, disaster recovery, logs and support access?: The Abu Dhabi health standard names backup and disaster recovery explicitly and prohibits offshore remote support, so an in-country primary with an offshore secondary fails it. Most residency designs are broken by their second copy rather than their first.
Is this capacity running today, or announced?: With a date, a source and the name of whoever confirmed it. Sovereign AI announcements in the Gulf run several years ahead of the capacity they describe.
How would we evidence this to a regulator?: A region recorded per store, a deployment type recorded per model call, and logs that show what actually ran. If proving it depends on a supplier's recollection, it is not evidence.

Where we have had to make these decisions

We hold end-to-end technical ownership of the live production estate of a government-accredited EdTech in the Middle East. Its database was replatformed onto Postgres in Google Cloud's Doha region, me-central1, to meet Gulf data-residency requirements. That is one region decision on one estate, and it is the basis on which we describe the trade-offs above: not a survey of the market, but the set of choices we had to make, document and defend.

The separations on this page are the ones that engagement forced. Where the data sits became a store-by-store decision with a named region against each. Where the models run stayed a separate decision, taken against the vendor documentation set out above rather than against the region's marketing. What we bring to a residency question is architecture and evidence, and the discipline of checking the vendor's own words on the day the decision is made.

Sources

Related questions

Does the Saudi PDPL require data to stay in Saudi Arabia?

No. The PDPL regulates cross-border transfer rather than imposing general data localisation: transfers run on standard contractual clauses, binding common rules or accredited certification, with a transfer risk assessment in defined cases, no general prior approval requirement, and no adequacy list published as at September 2026. The in-country requirements come from elsewhere. The MCIT Cloud First Policy states that all data in both the Government Cloud and the Commercial Governmental Cloud should be located geographically inside the borders of Saudi Arabia, and sector regulators add their own. Identify which of those applies to your data before you design for the strictest reading of all of them. This is a reading of the instruments as at September 2026, not legal advice; verify against the current text and with your own counsel before it becomes a design decision.

Can we use Claude or GPT models and still meet Gulf data-residency requirements?

As of September 2026, not through the managed routes in Gulf regions as they stand. On AWS Bedrock, every Claude, GPT and Grok model listed in me-central-1 and me-south-1 is Global-only, which by AWS's own definition means the request may be processed in any commercial Region. On Azure, Global deployment types may be processed in any Azure region and there is no Middle East Data Zone. The honest options are: buy committed capacity on Azure UAE North through Regional Provisioned Managed, which keeps a frontier chat model in-region; use Amazon Nova Pro or Nova Lite, the only In-Region models in the Gulf, in me-central-1; self-host open-weight models on in-region compute; or establish that cross-border processing is lawful for that data set and document why. Re-check the model tables before deciding, because they move frequently and without notice.

Is a local cloud region enough on its own?

No, for two reasons. A region can host the AI platform and none of the models: as of September 2026 Azure Qatar Central runs Microsoft Foundry and serves no Azure-sold models in any deployment type, and AWS Bedrock in Bahrain serves none In-Region. And where a model is reachable, storage location and processing location are separate: Microsoft states that data at rest remains in the designated geography while Global deployment types may be processed in any Azure region, and Google's documentation warns that endpoints do not guarantee data residency or in-region ML processing. A region is a necessary condition for in-country storage and tells you almost nothing about inference.

What about the UAE's free zones?

Free-zone entities are not under the federal PDPL. DIFC entities sit under Data Protection Law No. 5 of 2020 with Regulation 10, in force since September 2023 and described by DIFC as the region's first data protection rule written specifically for AI processing, introducing concepts including deployers and operators, high risk processing and an autonomous systems officer. ADGM has its own 2021 regulations and no AI-specific regime. Qatar has a parallel split, with QFC entities under separate regulations modelled on the GDPR. None of this exempts you from sectoral rules: the UAE health data law applies including in the free zones. Read the current text from the DIFC Commissioner's office before relying on clause-level detail, because the drafting is what matters here.

How long does an answer to this question stay true?

Months, not years, on both halves of it. Vendor model catalogues, deployment types and region footprints change on a monthly cadence, and Microsoft's stated order of arrival means single-region deployment types land last and without a guaranteed date. The regulatory side is moving too: the UAE's federal executive regulations have still not been issued, and a new AI and Data Authority was approved by the Cabinet in June 2026. Treat any residency statement, including this page, as carrying the date it was checked, and re-verify against the primary sources before a design or a contract depends on it.

Further

Engagement file D-02 · The Middle East estate behind this page, replatformed into Google Cloud's Doha region for residency.
AI governance implementation · The engagement this is bought as, where residency is recorded per store alongside the other controls.
Production AI systems · The build this becomes: access, failure modes, evaluation and audit on a system that runs every day.

We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.

Book a 30-minute call See the engagement files

Last reviewed 1 September 2026 · 1AYM