In highly regulated industries like energy, healthcare and financial services, data residency is a real constraint. Some data has to stay in a specific country or region, and that isn't up for negotiation.
When I first tried to open up our data warehouse to AI, I checked where the data was stored and which region the platform was set up in. Both were fine. Then I found that the platform's built-in AI assistant was sending our questions to a different provider altogether. Nothing flagged it. We only spotted it in the small print, during a deep dive with our cyber security team.
Since then I've talked about this with a lot of people, from data leaders to cyber security teams, and it's a shared nightmare. Keeping data in region is hard enough already, and AI makes it harder. So the usual reaction is to file AI under "not for us".
It's worth being clear which AI I mean. Productivity AI, where employees use it to summarise a document or draft some notes, needs big general models, because the work is general. That deserves its own post, and I'll be covering it soon. This post is about product: AI built into something you ship, doing a specific job, where someone picks the model and the endpoint on purpose.
None of this is an argument for holding back. Every AI service comes with trade-offs, like any other technology. The organisations that get on well with it know what they've accepted. The ones that get stuck either don't know, or say no to everything because they can't tell. And to be fair, it's hard. The documentation is confusing, and it changes faster than most people can keep up with.
The biggest models need a lot of specialist hardware, and there isn't enough of it to go round. So providers put their biggest models where the hardware is, which tends to be a small number of large regions. The model you want often isn't available where your data has to stay.
That's the whole tension. A strict residency rule and the biggest models pull against each other.
This is where it quietly goes wrong. Most people check where their data is stored and which region their cloud service is set up in, and assume the AI runs there too.
Often it doesn't. A request can be handled anywhere across a whole continent, or by another cloud provider or company entirely, like the assistant in our data warehouse. Sending it wider is often the only way to reach the model you want, because that model isn't in your region.
Nothing errors, and the architecture diagram still looks right.
And you won't easily find out. It's rarely on the product page. It's usually buried in a sub-processor list or the small print, or you only find out by asking. The engineer who switched it on was doing their job, and nobody asked them the compliance question.
Some providers also keep a copy of each request for a while, to check for abuse. That's a separate question from where the request was handled, so ask how long they keep it and where.
The obvious question is "does this job need a frontier model?" The honest answer is usually "maybe not, but it'll do the job". Frontier models are good at everything, so they always win that argument. Turn the question round.
First, read your rule properly. "Data must stay in the UK" and "data must be protected wherever it's processed" are very different rules. Some mean nothing can leave. Others allow it if the contract covers it. In the UK, the financial and data protection regulators generally accept a contract, as long as you can show your working. They rarely ask for a breach to be impossible. They want to see that you checked.
Then see what fits inside it. That's your shortlist. At its tightest, it's models you host yourself. Next out are the models your cloud provider runs for you in your region, through AWS, Microsoft, Google or Databricks. The ones you host yourself tend to be smaller open models, because they need far less hardware.
Then test the job on that shortlist. Use real examples, not a demo. Most product AI does something narrow: classifying a ticket, pulling fields out of a document, deciding where a query should go. A smaller model does that well, and I've seen it hold up in production.
Take the data warehouse. Say you want people to ask it questions in plain English, and your rule says the data stays in the UK. Your shortlist is the models that run in the UK, whether you host them or your cloud provider does. Take a few hundred questions your analysts have already answered, run them through, and check the model gets the same numbers. If it does, often enough for the job, you're done. You never had to ask whether a frontier model would be better.
It doesn't have to be one model, either. Split the job by what each step actually sees. Working out which tables to use and writing the query only needs the table structure, not the data in it, so a bigger model further out can do that part. The step that runs the query and formats the results is the one that touches customer data, and that can be a much smaller model you control completely. Just make sure nothing from the results goes back to the bigger model. Your rule is about the data, so it only needs to cover the steps that see it.
It's often cheaper too. Running your own model gets pitched as the expensive, cautious option. For a narrow job, it's usually cheaper and simpler than paying for a big model you don't need, and the residency problem goes away because nothing leaves your region.
You only have a real decision if nothing on the list is good enough. Then you can either change the job, or take the gap to whoever owns the rule, with evidence. That means you can answer:
That's a much better conversation than "can we use AI?" You're asking about one model for one job, and showing exactly where it falls short.
So don't ask whether it's secure, because you'll get a confident yes. And don't ask which region you're in. Ask someone to show you where a single request goes, from start to finish. Once you know what you've accepted, you can say yes and mean it.