Data processing location: stored here, processed there

Your files are stored in the right country. Your AI feature still sends them somewhere else every time someone clicks "Summarise". Many companies only learn this when an auditor asks the second question.

The first question is easy: where is the data stored? The second is harder: where is it processed? For AI, they often have different answers. If the terms are new to you, start with data residency in one page.

One document, several places

Follow a single document through a typical AI feature.

A customer uploads a contract. It is stored in a database in the country you chose. So far, so good.

A user asks for a summary. Your application reads the contract and sends it to an AI model through an API. The model runs on machines in whatever location the provider uses for that model. That may be the same country. It may be another continent.

The model processes the text and sends back a summary. Along the way, the request may be logged by the provider, cached to speed up repeat requests, or held for a period for abuse monitoring.

If the provider is busy in one region, the request may be routed to another to keep things running.

Finally, the summary is stored back in your database, in the right country again.

The start and the end of that journey are where you planned. The middle may not be.

Why the gap exists

Nobody designs this gap on purpose. It comes from how AI capacity is built.

Large models tend to run where large amounts of capacity sit, and that capacity is concentrated in a limited number of places. Providers often offer a model in some regions and not others, or add new regions later. Their failover and load balancing are built to keep the service up, which can mean sending work to wherever there is room.

Meanwhile, the people choosing the storage location and the people wiring in the AI model are often different teams, working months apart. The storage decision went through a security review. The AI integration went through a sprint.

Why it matters for audits

An audit, a security questionnaire from a large customer or a regulator's request will usually ask where personal or sensitive data is processed, not just where it is stored.

"Stored in-country" is a true answer to the wrong question. If the AI work happens elsewhere, the honest answer is that the data leaves the country for processing. Depending on the data, the sector and the contract, that may be fine, need extra paperwork, or not be allowed.

The worst time to find out is after the feature has shipped and customers rely on it.

Map the journey before someone else does

The fix starts with a simple map. For each AI feature, write down every place the data goes, and who runs it:

1. Storage: where the source data lives.
2. Application: where your own code runs when it prepares the request.
3. Model processing: where the provider runs the model for your account, and whether you can pin it to a region.
4. Logs and retention: whether the provider keeps prompts or outputs, where, and for how long.
5. Caches: whether repeated content is held anywhere to speed things up.
6. Failover: where requests go if the main region is unavailable.
7. People: who can access requests, for support or safety review, and from which countries.
8. Results: where outputs are stored and who can see them.

Most teams can fill in the first and last rows in minutes. The middle rows take a conversation with the provider. That conversation is the point.

Questions for your AI provider

• In which locations is this model processed for my account?
• Can I restrict processing to one country or region? Is that a setting or a contract term?
• Do you keep prompts or outputs? Where, for how long, and can I turn it off?
• If the region I choose is busy or down, what happens to my requests?
• Which other companies process my data on your behalf, and where?
• Can I get a record showing where each request ran?

If the answers are vague, treat the processing location as unknown. The full list is in our checklist of questions before sending customer data to AI.

Closing the gap

There are three common ways teams close it.

Choose in-region processing where it exists. Some providers let you pin a model to a region. It may cost more or limit which models you can use.

Keep sensitive data out of the request. Remove or mask names, account numbers and other identifiers before sending text to a model, where the task allows it.

Run the AI work where the data is. Use capacity located in the same country as your data, so the journey never leaves.

Whichever you choose, write it down, keep evidence and check it again whenever you switch model or provider. A new model version can come with a new processing location.

What we are building

Starfield Fabric is designed for the third option. We are building standardized compute close to power, connectivity and demand, connected through one programmable network for AI inference. Residency-aware placement means data stays where your policies say it stays, with workloads placed by policy, on latency, data residency, model and load.

The design goal is that every workload can generate an auditable record of commitment, placement and delivery. That record is what turns "processed here" from a promise into something an auditor can check.