The First Question Isn’t Which Model. It’s Which Country
A UAE tender assumed in-country AI inference was broadly available. The Jurisdiction Screen found a much narrower answer.
I recently put a United Arab Emirates public-sector tender through my Jurisdiction Screening instrument. The tender wanted project information to remain inside the UAE. It wasn’t only asking for data to be stored there. The processing was expected to happen there as well.
That is a much bigger promise than it looks.
On first reading, the requirement didn’t seem particularly unusual. Governments are quite reasonably becoming more specific about where their information goes. Plenty of cloud providers now advertise UAE regions, local data residency and sovereign services. It is easy to read all of that and conclude that in-country AI inference is broadly available too.
The tender appeared to have made that leap. It assumed that a fairly normal enterprise AI stack could be assembled while keeping the relevant processing inside the country.
Once the screen separated the individual claims, the answer became awkward. In-country inference was not completely impossible, but it was hardly available in the general way the tender seemed to assume. There were a few routes through it. Each came with restrictions, a narrower choice of models or a different architecture.
This wasn’t a minor compliance detail. It changed what could be built, which type of suppliers could bid for it and what those suppliers would have to promise.
If you're scoping a project in a country with residency rules: this screen and the other four doors are in my free field book — Take a copy.
A UAE endpoint is not UAE inference
The problem starts with the word available.
A cloud service can be available from a UAE region without every model behind that service running there. Data can be stored in the UAE while inference happens somewhere else. A provider can announce an in-country capability without having made it generally available. A consumer product, an enterprise tenant and a sovereign deployment can all have different answers.
All of those statements can be true at the same time. They are still not interchangeable.
AWS now distinguishes between In-Region, where a request does not leave the selected region, Geo, where it may move within a defined geography, and Global, where it may be routed across commercial regions without a geographic boundary. Those definitions are unusually helpful because they make the difference explicit.
When I checked the relevant Claude configurations against the current AWS model-region table, invoking them from the UAE did not give the project in-country Claude inference. The applicable route was Global.
The request could begin in the country. That did not mean the model processed it there.
Going directly to Anthropic did not solve the problem either. Anthropic’s own current explanation says that customer data is stored in the United States and that requests may be routed through infrastructure in the United States, Europe, Asia and Australia. It does not offer a UAE processing pin in that first-party service.
The detail is set out quite plainly in Anthropic’s server-location guidance, but it is easily lost once a project starts treating “available in the UAE” as a single yes-or-no field.
There were some genuine in-country options. OpenAI now offers UAE inference residency to eligible new ChatGPT Enterprise and Edu customers, for example. But the current scope is limited to GPT-5.2, excludes functions including image generation and internal search, and does not bring every form of system processing or every integration inside the boundary.
Some Azure regional and provisioned deployments can also keep model processing in one region, but model availability depends on the region and deployment type. A global deployment is a different proposition.
There are UAE sovereign-cloud providers making strong in-country residency commitments as well. Those may be the right route for some projects. The commitment still needs to be tested against the exact model, the exact workload and the contract being offered. “Sovereign AI cloud” on a product page is the start of that enquiry, not the end of it.
So the result of the screen was not that the project could never be done. It was that the tender’s apparent assumption was too broad.
The usual collection of enterprise tools could not simply be declared UAE-resident as a whole. The viable footprint was much smaller, and it would have to be designed deliberately.
Always double check official announcements
Quite often, tenders are written from information that was accurate, or at least looked accurate, at a point in time.
In October 2025, the company announced in-country processing for Microsoft 365 Copilot in the UAE and said it was expected in early 2026. That original announcement is still online. Somebody researching the market quickly could reasonably read it and carry the claim into an RFP.
The later position is different. An editor’s note added to Microsoft’s broader Copilot announcement on 3 April 2026 moved the UAE expectation to the end of 2026.
The old information wasn’t invented. The capability had been announced by the vendor itself. It just hadn’t arrived on the original timetable.
I found another version of the same problem in the AWS records. During the July refresh, different official surfaces left an ambiguous answer about how certain model calls from the UAE were routed. By the August refresh, AWS had rebuilt its compatibility table around the clearer In-Region, Geo and Global categories. The relevant cells could then be resolved as Global rather than local.
This is how unintentional misinformation gets into an AI project. It doesn’t always arrive as a false statement. It often arrives as two or three incomplete, time-sensitive truths that get joined together.
None of those facts proves that the project’s inference will happen inside the UAE today.
Once the combined claim makes its way into a tender, it starts to harden. Bidders price against it. Architects design around it. Commercial teams repeat it. Eventually it sounds less like an assumption and more like a settled property of the market.
That is exactly the kind of thing the Jurisdiction Screen is meant to interrupt.
The screen has a use-by date
The Jurisdiction Screen doesn’t pretend to be a machine that dispenses legal answers. It takes a project through a consistent enquiry and produces a record of what the available evidence actually supports.
The first part is the rubric. Which country does the data have to live in, by law or by contract? Which services and models are genuinely available there at the grade the project requires? Are there rules carried into the project by the organisation’s own customers?
Those questions are fairly durable.
The answers are not.
Behind the screen is an availability matrix and a jurisdiction fieldbook. Every material claim has a source and a date on which it was verified. The matrix distinguishes storage from processing, announced from generally available, and ordinary enterprise access from sovereign or government-grade deployment.
I refresh that data every month. Conflicts and missing evidence are checked first. Announced capabilities that have not yet shipped are checked again. Anything older than the freshness window is reverified.
If a claim can no longer be supported, it is marked stale and it does not go into the client memo as though nothing has changed.
This may sound like maintenance work, because it is. But without it the screen would gradually become a very confident way of repeating last quarter’s market.
The monthly cycle also gives the kit a memory. It records when a vendor changes a date, when a deployment becomes generally available, when a regional model catalogue expands and when an apparently local route turns out to use global processing.
That is more useful than running a fresh web search on every project and hoping that the first vendor page contains the whole answer.
In other words, the rubric doesn’t need to be reinvented each month. The evidence does need to be kept alive.
This belongs before the architecture
The tender did not need a confident green tick or a theatrical red cross. It needed its assumption exposed early enough for somebody to do something about it.
That might mean restricting the project to a smaller set of models and features. It might mean using a different deployment type or an in-country sovereign provider. It might mean asking the buyer to clarify what it means by processing, or seeking written approval for a tightly controlled exception.
It might also mean deciding that one part of the proposed system should not use a generative model at all.
Those are architecture and commercial decisions, not paperwork to be tidied up shortly before launch.
The Jurisdiction Screen is not legal advice, and I would not use it as a substitute for legal or other professional advice. Its job is to find the claims that need to be confirmed, show where the available evidence is weak and make the consequences visible. Vendor confirmation and appropriate counsel come next.
What I would not do is leave the jurisdiction question until a team has selected its models, priced the work and promised the outcome.
Before an AI project gets into detailed design, somebody needs to establish where the data is required to live, where the proposed models actually process it and which rules apply to the organisation using them. This is why I treat jurisdiction as something to establish before architecture, not something to tidy up afterwards.
Until the next one,
Chris
P.S. — The screen above is one of two that run before any of the three gates. How AI Projects Die is my free, twenty-page field book: both screens, the three gates, ten real engagements with the numbers left in, and one move at each. Take a copy.