Where your AI requests actually get processed

Sooner or later a client asks the question in writing. Does our material leave the country. Somebody in their procurement team has a form with that box on it, and the box is now blocking your invoice. You go looking for the answer in the tools you actually use, and you find that your subscription does not mention a country anywhere, that the vendor’s privacy page talks about retention rather than geography, and that the one page which does talk about geography splits the answer into two halves that do not agree with each other.

This guide is the short version of what those pages say, in the words the vendors themselves use, plus the part nobody puts in the marketing: what region pinning costs, which models you lose when you do it, and what you can put in a contract without lying. It is not legal advice and it is not a compliance programme. If you process health records, payment data or anything under a named regime, you need a lawyer and a signed data processing agreement, not a web guide. This is for the freelancer or the small team who has been handed a procurement form and needs to give an honest answer this week.

The map of where AI can run is drawn by export policy, not by engineering

Start with the thing that surprises people. Whether a model can run in a given country is often a question of American export law rather than of data centres or fibre.

On 10 July 2026, the US Bureau of Industry and Security removed the United Arab Emirates from Export Administration Regulations Country Groups D:3 and D:4 and reclassified it as Country Group A:5, which gives “the UAE Government and approved commercial entities” eligibility for “license-free exports, reexports, and in-country transfers under License Exception Strategic Trade Authorization (STA)” [1]. The same announcement says that, consistent with the US-UAE Artificial Intelligence Cooperation framework signed in May 2025, Commerce is “approving the UAE Government and certain companies to receive advanced computing items in the UAE license-free, including AI chips and servers”, conditioned on the UAE keeping “the commitment to make matching investments in U.S. AI digital infrastructure buildout” [1].

That is a paperwork change, and it moved a country onto the menu. You can see the effect on the other end of the pipe, in a vendor’s own region table, which is where the rest of this guide lives.

The same force works in reverse and is easier to spot. Anthropic publishes a flat list of the countries where its API can be used, and the list runs from Albania to Zimbabwe with entries for Bahrain, Oman, Qatar, Saudi Arabia and the United Arab Emirates, with no entry for China and none for Russia, and with Ukraine qualified as “Ukraine (except Crimea, Donetsk, and Luhansk regions)” [6]. Nothing technical explains that shape. It is a sanctions and export map with a docs page wrapped around it, and it can change on an announcement rather than on a release note.

Residency is a paid tier, not a setting in your subscription

Every residency control described in vendor documentation lives in a developer or cloud console, configured per project or per deployment [2][5]. OpenAI describes data residency as “a project configuration option that allow you to configure the location of infrastructure OpenAI uses to provide services”, and tells you to “contact our sales team to see if you’re eligible” [2]. Microsoft describes the equivalent as a deployment type you pick when you deploy a model, which determines “where your data is processed (global, data zone, or Azure geography)” [5].

There are conditions on top of the sale. To use OpenAI data residency with any region other than the United States, “you must be approved for abuse monitoring controls, and execute a Modified Retention amendment”, and “selecting the United Arab Emirates region requires additional approval” [2]. Image support in every residency region other than the United States, Europe included, “requires approval for enhanced Zero Data Retention or enhanced Modified Abuse Monitoring”, and the European region as a whole requires “Zero Data Retention, Modified Abuse Monitoring, Eyes Off, or Safety Retention” [2].

The practical reading for a small operator is blunt. If your stack is a monthly chat subscription and a browser tab, you have no geography control, and the truthful answer on the procurement form is that you do not offer one. Getting one means moving that workload onto an API or cloud tier, applying for it, and signing something.

Stored in a country and processed in a country are two different promises

This is the split that makes vendor pages read as if they contradict themselves. They do not. They are answering two questions and only labelling one of them clearly.

Google states the storage half plainly: “Data stored at rest in the customer selected location remains at rest in that location, independent of the … endpoint called by that customer’s request” [3]. Then it defines the other half separately. “ML processing is the method by which data is processed such that it produces model weights (tuning & training) or applies the model to the data for model inference”, and “the geographic location of this processing is determined by your choice of endpoint” [3]. Pick a global endpoint and you get the honest warning: global endpoints “route and process data anywhere globally, without restricting it to a specific geographic region”, and “they don’t provide regional isolation or data residency guarantees” [3].

Microsoft draws the same line in one paragraph. “Data stored at rest remains in the designated Azure geography. However, inferencing data is processed as follows: Global types: May be processed in any Azure region” [5]. Data zone deployments process prompts and responses only within the specified data zone, which is the United States, the European Union or Asia Pacific, and geography deployments process within the chosen geography, though prompts “might be processed between regions within that geography for operational purposes” [5].

OpenAI puts the split in a table, and the table is the clearest number in this whole guide. Ten regions are listed. All ten support regional storage. Three support regional processing: the United States, Europe (EEA and Switzerland), and the United Arab Emirates [2]. For Australia, Canada, Japan, India, Singapore, South Korea and the United Kingdom, storage is in-region and processing is not, and OpenAI says so directly: “if your selected Region does not support regional processing, as identified below, OpenAI may also process and temporarily store Customer Content outside of the Region to deliver the services” [2].

Read that list once more with the first section in mind. The United Kingdom, a country with no export control problem at all, gets storage only. The United Arab Emirates, which was in Country Group D:3 until July 2026 [1], is one of three places on earth where OpenAI will run inference in-region [2]. The map is political before it is technical.

The global option is the default, and it is the cheap one

Nobody prices sovereignty as a feature you get for free.

On AWS, cross-region inference profiles come in two shapes. A geographic profile routes “within the geography” such as US, EU or APAC. A global profile routes “worldwide” and carries “approximately 10% savings”, which AWS recommends when you want “cost savings without geographic restrictions” [4]. There is a second detail in the small print that catches people who assume their account settings protect them: “cross-Region inference can route requests to AWS Regions that are not manually enabled in your AWS account. Manual Region enablement is not required for cross-Region inference to function” [4].

On Azure, Global Standard “launches first when a new model releases, has the lowest price, and offers the broadest region coverage”, and Microsoft advises moving off it “only when you have a specific reason, such as data residency, reserved throughput, or asynchronous batch processing” [5].

On OpenAI, the arrow points the other way and costs the same 10%. Data residency endpoints “are charged a 10% uplift” for models released on or after 5 March 2026 that are eligible for data residency [2].

So the cost of an in-region answer is roughly a tenth of your model spend, either as an uplift you pay or as a discount you decline. On a small operator’s bill that is usually tens of dollars a month, which is worth knowing before you tell a client it is impossible.

Pinning a region shrinks the menu of models and features

The bill is the easy part. The real cost is that the in-region menu is shorter and later than the global one, and this is the point most procurement forms never think to ask about.

Microsoft states the release order outright. “New deployment types become available in a set order: Global, then Data Zone, then geography-based. Geography-based deployment types arrive last, have no guaranteed availability date, and depend on capacity that frees up as older models retire” [5]. Choosing a country is choosing to be behind, by an interval the vendor declines to name.

The feature menu narrows too. In OpenAI’s table, regional processing in the United Arab Emirates covers chat completions, responses and embeddings, while audio, images, batches, fine-tuning, evals, realtime, web search and the code interpreter tool list their processing regions as the United States and Europe only [2]. A workflow that transcribes a call and then summarises it does not stay in one country just because the summarising half can.

Google’s residency table has the same shape of gap. For partner models, which is how Claude is offered on Google Cloud, the jurisdictions the table covers at all are the US multi-region, the EU multi-region, Belgium, the Netherlands, Singapore, Taiwan and global [3]. There is no Gulf column, no Latin American column outside the Google models table, and no African column anywhere on the page. Google also warns that its EU multi-region “strictly covers data residency within EU member states” and that “geographies outside the European Union political boundary, including the United Kingdom and Switzerland, are excluded from this endpoint” [3], which is the sort of sentence that turns a confident answer to a British client into a wrong one.

What you can put in writing, and how to check it later

Answer the procurement form with the endpoint, not with the brand. “We use ChatGPT” is not an answer. “Requests go to the EU endpoint of the Responses API, where OpenAI performs regional processing, under a project configured for the Europe region” is an answer, and it maps to a published table you can attach [2].

Say which half you are promising. If your region does storage only, write that sentence down in the client’s words before they discover it in yours. Note the carve-out too: OpenAI’s residency “does not apply to system data”, defined as “account data, metadata, and usage data that do not contain Customer Content”, including analytics, usage statistics, billing information and support requests [2].

Then give yourself a way to verify. AWS logs every cross-region call, and tells you where to look: “CloudTrail logs all cross-Region inference requests in your source Region. Look for the additionalEventData.inferenceRegion field to identify where requests were processed” [4]. That single field is the difference between a claim and evidence, and if your vendor offers nothing equivalent, downgrade the confidence of your answer.

Finally, pair geography with retention, because clients conflate them and you should not. OpenAI states that “[e]xcept for certain endpoints and features listed in our platform documentation, OpenAI may securely retain API inputs and outputs for up to 30 days to provide the services and to identify abuse. After 30 days, API inputs and outputs are removed from our systems, unless we are legally required to retain them” [7]. Note both carve-outs, because a client who reads only the headline number will not. Where a copy sits and how long it sits there are separate promises, and a form that asks only about the first one is asking half the question.

What still goes wrong

You are trusting a table. Nothing on a residency page lets you independently confirm that a packet went where the page says it went, and the one verification hook cited here is a log the same vendor writes [4]. That is better than nothing and it is not proof. Treat the contract as the real control and the documentation as a description of it.

The tables also move faster than your contracts do. Google’s residency page was last updated on 2 September 2026, two days before this guide was checked [3]. A country entered the advanced-computing map in July 2026 on the strength of a framework signed in May 2025 and a set of investment commitments it has to keep [1], which means the same mechanism can run backwards if those conditions change. Anything you sign that names a country should name a review date as well.

The deepest limit is that residency is not sovereignty. Nothing in this guide changes who owns the model weights, who can be served a legal order, or whose export rules decide which chips sit in that in-country building. A region prefix moves the processing. It does not move the jurisdiction of the company doing the processing, and if that is what your client actually means by the question on the form, the honest move is to say so rather than to sell them a domain prefix as an answer.