Data residency for AI inference, in one page

"Where is our data?" used to be a question for the IT team. Now it comes from customers, auditors and procurement, and it now covers AI as well as storage. Data residency is the short name for the answer.

This is a one-page guide to what it means, why it keeps coming up, and what a business should be able to say about it.

What data residency means

Data residency means your data is stored and processed in a named place, usually a country, sometimes a region or a group of countries.

Two words in that sentence matter.

Named. You know the place, and you can say it in a contract or an audit. "Somewhere in our cloud" is not residency. "Processed in Germany" is.

Processed. Residency is about more than where files sit. When an AI service reads a document, summarises a call or answers a question, it processes data. That processing happens on a machine in a place. Residency covers that too.

A related idea is about whose laws apply to the data and who could be compelled to hand it over. Residency is narrower and more practical: it is about where the data physically is and where the work on it runs.

Why more rules ask for it

There is no single residency law. The requirement reaches businesses from several directions at once.

Data protection rules. Many countries and regions have rules about personal data, including when and how it can be moved abroad. Moving it is often allowed, but with conditions and paperwork.

Sector rules. Banks, insurers, health providers and public bodies often have their own requirements about where sensitive data can be held and processed.

Customer contracts. Large customers increasingly write residency into their contracts with suppliers. If your product uses AI on their data, their terms become your terms.

Internal policy. Some companies simply decide that certain data, such as source code, legal files or product plans, does not leave a given country.

The result is the same: a business needs to know, and be able to show, where its data is processed. The details depend on the country, the sector and the data, which is why a legal team should be part of the conversation.

Why AI makes it harder

Before AI, residency was mostly a storage question. You picked a data centre region, stored your files there and were largely done.

AI adds a step. Your data now gets sent to a model, which may run somewhere else. A company can store everything in one country and still send every customer email to a model processed in another. Many teams only discover this during an audit. We follow one document through that journey in stored here, processed there.

AI capacity is also concentrated. Large models tend to run in a limited number of large sites. If the capacity you need is not available in the country you need, residency and AI start to pull against each other.

What a business should be able to say

If someone asks about residency for an AI feature, you should be able to answer five questions:

1. Which data does this feature send to a model? Be specific: customer messages, files, transcripts, metadata.
2. Where is that data stored? Name the country or region.
3. Where is the AI work processed? Name it separately. It may differ.
4. What is kept afterwards? Logs, prompts, outputs, copies used for improving models.
5. How do you know? A contract clause, a provider setting, or a record of where each request ran.

The fifth question is where many answers fall apart. A promise in a sales document is not the same as evidence. Auditors increasingly want something they can check.

Two common mix-ups

Residency is not the provider's home country. A provider based in one country may process your requests in another, and the reverse.

Residency is not encryption. Encrypting data protects it from being read. It does not change where it is stored or processed. Both matter, and they answer different questions.

How to approach it

Start with your data, not with providers. Sort the data your AI features use into what is sensitive and what is not. Not everything needs residency.

Ask providers the processing question directly. "Where is my request processed?" deserves a named answer, and ideally a setting you can control. Our checklist of questions before sending customer data to AI lists the rest.

Get it in writing, and get records. Residency terms in the contract, plus a way to see where work actually ran.

Plan for change. Rules and customer demands move. A setup where location is a setting will adapt more easily than one where it is built into the architecture.

What we are building

Residency is one of the reasons we started Starfield. If AI is going to process sensitive data in everyday business, it has to be able to run in the places that data is allowed to be.

We are building Starfield Fabric: standardized compute close to power, connectivity and demand, connected through one programmable network for AI inference. The network is designed for residency-aware placement: data stays where your policies say it stays, and workloads are placed by policy, on latency, data residency, model and load. Every workload can generate an auditable record of commitment, placement and delivery, so the answer to "how do you know?" is a record, not a promise.