Herman, I need you to brace yourself.
Why.
Because I've read Daniel's prompt and I've already skimmed the docs and it turns out the law everyone cites for this does not actually say the thing everyone says it says.
... That's my favorite genre.
The world's favorite genre. Anyway. So Daniel's asking about geographically restricted AI inference, whether it's become standard enterprise plumbing this year, and he wants the three-way split made properly clear: data residency, inference residency, and data sovereignty, because people use them interchangeably and they are not.
They are really not.
He wants to know what's actually driving demand, whether GDPR obliges anyone to run a model locally, and I'll spoil that one now: it does not.
Hold that. We'll get to it properly.
He's got four more threads. How jurisdictional multi-region inference works, whether smaller markets can get the same deal, what the trade-offs are in price, model availability, throughput and disaster recovery, and then the big one at the end, which is whether picking a model is on its way to meaning picking a jurisdiction the way picking an S-three bucket already does.
That last one is the question. Everything else is supporting material.
And the thing I keep circling is this. The cloud spent fifteen years training everyone to think of geographic choice as a dropdown. Region, region, region. Here's the part that isn't the same: this dropdown is shorter.
Before we get into the provider comparison we need the vocabulary straight, because three different things get conflated in every single procurement conversation and the conflation is not harmless. It leads people to spend money on the wrong layer.
Go.
Data residency is a question about geography. Where is the information stored, and where is it processed. That's the one cloud buyers have known for years, and it's the one vendors answer most readily.
And sovereignty is a different animal.
Sovereignty is a question about jurisdiction. Whose laws reach the data, and who can compel its disclosure. That's the distinction that does the work in this whole episode, because a deployment can fully satisfy residency and still fail sovereignty, and the failure is invisible from inside the region selector.
Say the shape of it. An EU region belonging to an American cloud provider.
Frankfurt data centre, European entity, European staff, and the parent company is still subject to its home country's disclosure law, so the data sitting in Frankfurt is sitting inside the reach of a legislature on another continent. Server location is a configuration choice. Sovereignty is an architecture choice. Those aren't the same kind of decision.
And inference residency is the third layer. Newest and narrowest.
Where the GPUs execute. Not where the bucket lives, not where the logs are written, where the arithmetic actually happens on the request. And the reason this is suddenly a conversation is that until reasonably recently, inference happened wherever the provider felt like routing it, and nobody could ask the question in a way that produced an answer.
So the model card said one thing, the region selector said another, and the GPUs were somewhere underneath all of it.
Now here's where I want to be blunt, because the framing of the whole discussion depends on it. The statutory requirement that everyone assumes is pushing this market does not exist. Not in GDPR, not in the AI Act.
Neither text names a deployment model.
GDPR requires a lawful basis, minimisation, security under Article thirty-two, and lawful transfers under Chapter Five. It never once says where a server has to be. The AI Act's high-risk duties, Articles nine through fifteen, risk management, data governance, record-keeping, human oversight, robustness, are outcome-based and technology-neutral. Not one of them names a location.
Which means the procurement checklist citing the regulation as the reason for on-premise is citing something that isn't there.
It's a myth, and it's a durable one because it's convenient. A vendor who wants to sell you a box has an obvious interest in you believing the law requires the box. A consultant who wants to sell you a sovereignty assessment has the same interest.
What's the actual driver then.
Three buckets and they're worth keeping separate. Regulation is one, and it's the one everybody points at. Contract is the second, and contract is frequently the more immediate constraint, because a client agreement can simply say processing happens in a named country.
Not the law. The client.
The client, in a signed document, with a penalty attached. That's the real teeth. The third bucket is policy. An organisation's own commitments, its published principles, the things it said out loud. Those are enforceable in reputation rather than in law, which is a different kind of pressure but not a weaker one.
And then sector rules stacked on top.
Health, finance, government, each with its own regime, each less interested in the technology than in the data class.
So the demand is real and the legal reason everyone gives for it is a ghost.
The demand is very real. The statutory inference-locality requirement is not.
There's a line I keep coming back to from the analysis of the Claude controls. Something like, a vendor answer that names a storage region satisfies a reader who was thinking about databases and satisfies nobody who was thinking about GPUs.
That's the whole gap in one sentence. Storage residency is a solved problem and vendors answer it fluently. Inference residency is a much thinner thing and vendors answer it more carefully.
So walk me through the offerings. October of this year, what does the shelf look like.
Anthropic's the one with the cleanest mechanism, so start there. There's a parameter you can set per request, inference geo, and it takes one of two values. US or global. There's also a workspace-level setting for what's allowed and what the default is.
And the price.
US-only inference is one point one times, and the multiplier applies across input, output, cache writes and cache reads.
All four.
Which means if you're a heavy cache user the ten percent isn't a ten percent on one line, it's a ten percent on every line you've got.
What's the model constraint.
Claude four point six and later. Older models will return a four hundred error if you ask for a geo you can't have. Which is actually the correct behaviour, failing loudly, but it's a migration problem for anyone with long-lived integrations on older models.
Now the part I think is the actual story and not the surcharge.
The workspace setting. Your geographic configuration is set when the workspace is created and it cannot be changed afterwards. Currently only US is available at that layer.
A one-way door.
And the second thing, which is the one I'd put on a poster. The response includes a field reporting where inference actually ran.
Not where you asked for it.
Where it ran. So the policy claim becomes a receipt. You asked for US, the response tells you US, and you can log it.
Hm.
That's rare and it's the right instinct and it's worth dwelling on for a second, because in every other compliance domain we've learned to accept attestation instead of measurement. A vendor says they did the thing and you believe them and you keep the paperwork. A receipt that arrives with every response is a different category of evidence.
Unless the receipt is wrong.
Then you have a much better problem than you had before, because now the error is a logged, timestamped, reproducible fact rather than a disagreement about intent.
Fine. OpenAI.
Ten regions of at-rest residency. Australia, Canada, the EEA and Switzerland, India, Japan, Singapore, South Korea, the UAE, the UK, and the US.
And inference residency.
Three. Europe, the US, and the UAE.
Ten down to three.
That ratio is the story of the year, honestly. Storage residency has been a commodity for a decade, so it's cheap to offer and it's offered everywhere. Inference residency means GPUs in a specific place, and GPUs in a specific place is an expensive thing to promise.
So what does the UAE one actually get you.
This is the best illustration of how thin it still is. Only two models are available there, GPT five point five and five point six Luna. No image generation. No internal search. No ChatGPT Work. No improved memory. No GPT-Live.
So you can have jurisdiction or you can have the product.
In that region, yes, that's roughly the trade. And notice that data residency on Enterprise and Edu is included at no extra cost, so the cheap layer is free and the expensive layer is the one with the asterisks.
Which tells you where the cost actually sits.
In the racks.
What about the cloud providers, because that's a different shape of offering.
AWS Bedrock does it with inference profiles. You pick a geography, us, eu, apac, in, and the profile routes your requests across the regions inside that geography. A US profile will go across us-east-one, us-east-two, us-west-two depending on load.
So you don't pick a region. You pick a boundary and the boundary picks a region.
And you get the load balancing for free, which is the point. There's also a global profile that routes worldwide, and that's the maximum throughput option, and it's the one you can't use if you have a boundary requirement.
The configuration cost there is real though.
You need IAM and service control policies set up across every destination region, because the request can land anywhere inside the boundary and your permissions have to cover all of it. That's not a click. That's a change-management exercise.
Google.
Jurisdictional multi-region endpoints, us and eu, plus locational endpoints if you want a specific country. There's one in France, one in Germany, and so on down the list.
And the eu endpoint is where the interesting decision lives.
The eu endpoint strictly covers EU member states and excludes the UK and Switzerland. That's not an oversight. That's a jurisdictional line drawn on purpose, and it's correct, because the UK is not in the EU and Switzerland is not in the EU, and a customer in Zurich who selects eu expecting coverage has selected the wrong thing.
Switzerland is surrounded by it.
Surrounded by it and outside it, legally, and the endpoint cares about the legal fact and not the map.
Azure.
Data Zones for the EU and the US. The simplification there is that you manage multi-region model availability as one pool rather than region by region.
Okay, now push on the thing I don't buy. All of this sounds like a story about regulation and none of it is a story about regulation.
Correct, and this is where the demand story gets more interesting than the compliance story. The buyers asking for this are overwhelmingly doing it because of a contract with someone else, or because of their own published commitments, or because a sector regulator in their industry has said something adjacent to it. Not because a statute says the GPUs must be in the country.
So the vendor is selling reassurance.
The vendor is selling a receipt. Which is a more honest product than reassurance, because a receipt can be audited and reassurance can only be believed. The receipt is the thing that closes the contract negotiation.
Daniel's going to like that framing.
He asked whether it's becoming standard infrastructure, and the honest answer is that it's becoming standard as a procurement line item before it's becoming standard as a technical capability. The checklist item exists everywhere. The actual ability to deliver it is uneven.
Fair. Before you move on.
Friends. Friends. Are you tired of your inference running somewhere you've never been? Try Jurisdiction-in-a-Box, the world's first handheld sovereign AI appliance. Just place your prompts inside the included laminated boundary and every token is processed within arm's reach of you personally. Guaranteed. Our patented Geographic Aura technology keeps your GPUs in a legally distinct zone at all times, no lawyers required. Ask your procurement team about Jurisdiction-in-a-Box today. Side effects include a faint humming, territory disputes, and an inability to explain to your clients where anything is. Do not use Jurisdiction-in-a-Box as a substitute for an actual jurisdiction. Jurisdiction-in-a-Box is a box.
Did we book that.
I did not book that.
Nobody's going to admit to it.
Moving on, and I want to come back to something you said, because the receipt is the good part and it's also the piece that's inconsistent. One provider does it. That's it.
Which means the compliance evidence you can actually audit is a single-vendor feature right now.
And the moment your architecture spans two providers, which most enterprises' does, you're back to attestation for the half that doesn't issue a receipt.
So there's a hole in the middle of this market and nobody's filled it.
The hole is that the cost is not the surcharge.
Go on.
Everyone reads the one point one multiplier and stops. That's the cheapest of the three costs, by a distance.
What are the other two.
Model availability, which we just saw with the UAE. And the Priority Tier accounting, where US-only inference burns one point one tokens of your committed capacity per token you send.
So the ten percent lands twice.
It lands twice. Once on the bill and once on the allowance. And if you sized your commitment against a global-inference workload and then moved to US-only for a client, your headroom disappears faster than your spreadsheet says it will.
That's the kind of thing that shows up in a quarterly review as an unexplained overage.
And the third cost is disaster recovery, which nobody puts on the slide. If your processing has to stay inside a boundary, your failover target has to be inside the boundary too. You can't evacuate to a region outside the jurisdiction when the primary goes down, because that would be the incident that breaks the contract.
So your recovery pool is smaller and it's the pool everyone else with the same requirement is also using.
Which is exactly why the multi-region architecture matters, and this is the part of the episode I actually find elegant.
The jurisdictional multi-region thing.
Here's what it does. Instead of buying capacity region by region, you buy one commitment that covers a whole jurisdictional boundary. One pool. The provider routes inside it for you, and the routing stays inside the line you drew.
So the capacity management problem and the compliance problem get solved by the same mechanism.
They get solved by the same mechanism, and for a long time those two things were in tension. Resilience wanted distribution. Compliance wanted confinement. You could have one or the other.
You can have both if the boundary is big enough.
The boundary is the unit. That's the shift. And Google's documentation says the quiet part, which is that this eliminates regional resource silos. You're not buying separate provisioned throughput per region and watching three of them idle while the fourth saturates. You're buying one and letting the router do the work.
Now the smaller markets question, because this is where I think the answer is worst.
It's the weakest part of the whole picture, yes. Look at the storage residency list versus the inference residency list and the shape of the gap is the whole thing. Ten regions of storage residency. Three of inference residency.
And the three are the ones with the GPU farms.
Google does better on this and it's worth saying, because they offer in-country processing across Brazil, Canada, France, Germany, the Netherlands, the UK, Australia, India, Japan, Singapore, South Korea. That's the longest list anyone has.
But it's not everyone's list.
It's not, and Anthropic's own regional compliance table shows it. Microsoft Foundry has no Asia-Pacific coverage and no Canada coverage at all, and Europe is listed as coming soon.
Coming soon is a word that means something different in procurement than it does in a release note.
In procurement it means you cannot sign this quarter. Which is fine if you're planning and fatal if you're not. And the general mechanism for a country without its own GPU capacity is that the provider routes you to the nearest jurisdiction that has it. Which may not be your jurisdiction. And that's the trap, because a customer in a country that lacks local inference can easily end up routed to a neighbour whose legal regime is not the one they were trying to stay inside. The residency is real. The sovereignty they thought they were buying is not.
So the smaller market gets a geography that looks right on a map and a legal position that isn't what they asked for.
Which is the cleanest example of the residency and sovereignty split we opened with. It's all the same distinction, just applied at a national level.
What about the operational trap. The one-way door thing.
Anthropic's workspace geo is set at creation and can't be changed. OpenAI's European API residency can only be configured for new Projects. Both of them are architectural decisions that have to be made before anyone has the requirements.
Before the client contract exists.
In a system where teams treat workspaces like disposable folders, spin one up, throw it away, spin up another. That habit and this configuration model are incompatible, and people are going to find that out in twenty twenty-seven when a client asks for a US-only attestation on a workspace that was created without one and cannot be changed.
The mitigation is boring.
Create the workspace per regulatory posture, not per project, and treat the geo as part of its name. That's it. That's the whole mitigation. But it requires knowing at creation time what you'll need at contract time, and most teams don't.
Now the sovereignty gap, and this is the bit that makes the whole market look thinner than the marketing.
DeepL's the case study. April of this year they announce they're adding AWS as a sub-processor, the change takes effect in May, and the opt-out window closes the day before the change takes effect. Thirty days, roughly. Accept or leave.
And the data centres are in Frankfurt.
And the parent company is subject to the CLOUD Act, so the Frankfurt fact is true and the sovereignty conclusion customers drew from it is not.
Which is the exact sentence from the sovereignty analysis. EU hosting does not make your AI sovereign, not on its own.
And the phrase is legal-control property rather than a geographic one. Once you've read that, you can't unread it, and it reorders the entire vendor landscape. Mistral's Microsoft partnership is the same shape. Sovereignty mostly in marketing language.
Which means the entire business is a relationship, not a setting.
And that's the honest summary. Residency is a fact you can verify. Sovereignty is a relationship you have to reason about.
Now the leak.
The embedding step, and this is the most-missed one and it's the one that catches people who did everything else right. An organisation self-hosts a model for data boundary reasons. Good. Careful. Expensive. Then it indexes the same corpus through a hosted embedding API.
And the content has moved.
Without a single request to the self-hosted model leaving the building, the thing you were protecting has been shipped to a third party, in an embedding format you probably don't consider data, under a term of service nobody read.
Which means inference residency alone is not a control. It's a control over one path out of a building with more than one door.
And that's why the framing matters. If you define the problem as where the GPUs are, you've defined a problem you can solve. If you define it as where the content goes, you've defined the actual problem, and the GPU question is one line item inside it.
Herman, be honest with me about the smaller-market thing for a second, because I think there's a version of this where the answer is that providers will never build this out evenly and the market just accepts an uneven map.
I think that's roughly right, and I think the reason is boring. GPU capacity is not like storage capacity. You can put a storage region anywhere there's power and a fibre run, and the economics work because storage is cheap and latency-tolerant. GPUs are neither. They're expensive, they're power-hungry, they're supply-constrained, and the workload is latency-sensitive. So a provider builds where the capacity economics work and sells a boundary that reaches as far as the nearest farm.
And the customer's jurisdiction is not a factor in that calculation.
It's a factor in the price they'll pay and not a factor in where the silicon goes.
There's something here that makes me nervous about the whole shape of the market, which is that we're asking providers to sell us a legal guarantee using a geographic product.
Say more.
The product is a location. The promise is a legal outcome. And those two things coincide most of the time and diverge exactly when it matters. The Frankfurt case is the proof. Everyone did the geographic thing correctly and got the legal thing wrong anyway.
That's the argument for the receipt, actually. If you can't trust the geography to deliver the legal outcome, then the only thing left is measurement. Which is why the response field reporting where inference actually ran is more than a nice feature.
Because it moves you from a promise to a log.
And a log survives the vendor relationship, which a promise doesn't.
I'll tell you what I think the answer to Daniel's last question is, and then you can argue with me.
Choosing a model has already become choosing a jurisdiction, but only for storage, and the inference half is real but thin, and the sovereignty half is mostly a story people tell themselves while the contract says otherwise. So we're most of the way to the world he's describing and the last stretch is the part nobody's selling.
And the last stretch is the expensive one.
The last stretch is always the expensive one. That's why it's last.
The reason it's expensive is that storage residency scales cheaply and inference residency doesn't. A storage bucket in a new country is a rack and an entity and a support team. A GPU region is a power contract and a supply chain and a latency budget, and the power contract is the hard part.
And the politics of the power contract is now a procurement input in a way that nobody planned for.
Which is a strange place for an AI purchase to end up. Two years ago you were comparing benchmarks. Now you're comparing jurisdictions and reading a sub-processor notice like it's a lease.
That's the architecture and the trade-offs anyway. What happened.
Ticket four four one seven two two. Opened it in March.
What for.
I wanted to know which region my data was processed in. Not stored in. Processed in.
Eleven weeks. Three different people. The first one sent me a page about storage buckets. The second one sent me the same page with a different heading. The third one told me my account was provisioned in Ireland and that this meant my data never left Ireland.
And the model I was using wasn't served from Ireland at the time.
Was it not.
It was served from the States. The account was in Ireland. The support answer was about the account.
So the answer you got was true and irrelevant at the same time.
Which is the correct answer to a question nobody asked. I asked where the arithmetic happened and they told me where the file was kept.
What'd you do with the ticket.
Left it open. It's still open. Every so often somebody sends me a satisfaction survey and I rate it.
How do you rate it.
Honestly.
What's the number.
Two.
Out of what.
It's two.
Hilbert, that's a support ticket, not a legal position. Why does it matter to you this much.
Because I've got four of them.
Four of what.
Four of these agreements. Same vendor, four accounts, one for each of the arrangements.
The arrangements with whom.
With people who own the animals.
Animals.
Horses. Four owners, four horses, one in Ireland, two in the States, one in Dubai. And each owner has a rule about where their records can be processed, because they've all read something, and none of them have read the same thing.
So you're running four separate AI accounts to keep four sets of horse records in four jurisdictions.
Three jurisdictions. Two of the horses are in the same country but they're with different owners and the owners want separate accounts.
Of course they do.
The Dubai one only has two models available.
I know what this is. That's the UAE inference residency limitation. Two models, no image generation, no memory, no internal search.
Four of the six features I was using are gone. So the horse in Dubai gets the short version and the horses in Kentucky get the long version, and the owner in Dubai is fine with it because the short version still does what she needs.
What does she need.
She wants the gait notes summarized and she doesn't want the notes to leave the country.
That's the lot.
It's the correct requirement and the tool costs ten percent more and has four fewer features and nobody at the vendor could tell me which region it ran in.
Did the receipt field help at all.
It did, once I found it. I print it. I've got a folder.
A folder of what.
Printouts. Every response. I staple them.
Every response.
Every response for the Dubai horse. The others I trust.
Why only Dubai.
Because Dubai is the one where I couldn't get a straight answer. The others answered on the first ticket. Ireland answered in nine days. Kentucky answered in a day and a half and the man was very clear.
So the market's unevenness is your actual daily problem. The geography is the same and the answer quality is not.
The tools are the same and the answers aren't. That's the whole of it.
And the folder.
The folder is the only part I can prove.
How long do you keep the staples in.
Until the horse moves.
Hilbert, that can't possibly work.
It's worked since March.
Which part.
The folder.
Alright. So the receipt exists, but not everywhere, and the configuration is a one-way door.
And the regulatory mandate everyone cites doesn't exist, and the drivers are contracts and policy, and the countries without GPU capacity get a boundary that isn't theirs.
Which leaves me with one question I don't have an answer for. Does inference residency close the gap with storage residency in the next eighteen months, or does the gap persist because placing GPUs is a fundamentally harder problem than placing buckets.
My guess is it narrows and never closes. The capacity economics are just different. Storage is cheap and latency-tolerant and you can put it anywhere with power and a fibre run. Inference needs the silicon in a specific place and the silicon is the scarce thing.
So the dropdown stays short.
It stays expensive, and the part nobody's selling you is the sovereignty, which is a relationship you have to reason about rather than a region you can select.
The one thing from Hilbert's side of this that I keep turning over is that the receipt is the only part he can prove. That's the direction the whole market should move. Not bigger promises, more measurable ones.
And the decision you make this year about where a workspace lives is the decision that constrains you next year, because the door only opens one way. That's the practical takeaway and it's the boring one and it's the one that will cost people money.
Choosing a model is becoming choosing a jurisdiction. But the jurisdiction list is shorter, it's more expensive, and unlike the region dropdown you've been using for a decade, you can't change your mind afterwards.
Thanks to Hilbert Flumingtop, our producer, who has been keeping us on the rails and keeping his own stapled archive.
If this was your kind of episode, go back for episode twenty, Architectural AI; episode five, Fine-Tuning ASR For Maximal Usability; and episode forty-eight, Renting vs. Building. This has been My Weird Prompts.
Send us your own prompt on Telegram at t dot me slash MWP listener bot, and we'll be back soon.
See you then.
