Data residency or data localisation?

"I live in Lisbon" and "I am not allowed to leave Lisbon" both put you in the same city. They describe very different situations. One is where you are. The other is a rule about where you must stay.

Data residency and data localisation differ in a similar way. People often use them as if they were the same. This piece explains how each term is usually used, where they overlap, and how to tell which one a requirement really means.

This article is general information, not legal advice. The terms are not used consistently in law or in contracts. Your counsel should confirm what applies to you.

Data residency: where data is kept

Data residency usually describes the place where data is stored. It is often a choice. A company decides to keep its customer records in a particular country or region, perhaps for performance, customer comfort or internal policy. (We cover the basics in Data residency in one page.)

Residency can also be a contract term. A customer may require a supplier to keep its data in a named region. That is a promise between two parties. It is not, by itself, a law.

Data localisation: where data must stay

Data localisation usually describes a legal requirement. A law or regulation says certain data must be stored, and sometimes processed, inside a country. It may limit or forbid copies abroad, or allow transfers only after approval.

Localisation rules often target specific kinds of data. Examples include some public-sector records, certain financial or health data, telecoms data, or data a government considers important to national security.

How they differ in practice

Source of the requirement. Residency often comes from a policy or a contract. Localisation comes from a law or regulator.

Flexibility. A residency requirement can sometimes be changed by agreement. A localisation rule cannot be waived by a contract.

Scope. Residency often covers storage only. Localisation may also cover processing, backups, support access and copies.

Consequences. Breaking a residency promise is usually a contract issue. Breaking a localisation rule can be a regulatory matter.

Examples a compliance team will recognise

These are typical patterns, not descriptions of any one law.

A software contract with a regional clause. A customer requires that its data be stored in a named region. Support staff elsewhere may still view it. This is residency.

Personal data transfer conditions. A privacy law allows personal data to leave the country only under certain conditions, such as approved safeguards. Data can move, with conditions. This sits between the two and is often called a transfer restriction.

A public-sector requirement. A government body requires that certain records be stored and processed only within the country, by approved providers. This is localisation.

A sector rule. A regulator requires a financial firm to keep certain records in the country, available for inspection. This leans towards localisation, at least for those records.

Why processing matters for AI

For AI, the difference between storage and processing is important. A model answering a question reads the input, works on it and produces an output. That is processing, even if nothing is stored afterwards.

A residency promise that only covers storage may say nothing about where that processing happens. A localisation rule that covers processing may require the AI work itself to run in the country. (We look at this gap in Stored here, processed there.)

So when a requirement arrives, it helps to ask:

1. Does it come from a law, a regulator, a contract or an internal policy?
2. Does it cover storage, processing, or both?
3. Does it cover backups, logs and support access?
4. Does it allow transfers under conditions, or forbid them?
5. What evidence will we need to show we complied?

Evidence is the common thread

Whether the requirement is residency or localisation, someone will eventually ask for proof. Where was the data? Where was it processed? Who could access it?

A statement in a contract is a start. A record of where each piece of work actually ran is stronger. (See A receipt for AI work.)

What we are building

We are designing for requirements that cover both where data is kept and where it is processed.

Starfield deploys standardized compute close to power, connectivity and demand, then connects it through one programmable network for AI inference. Workloads are placed by policy, on latency, data residency, model and load, and every workload can generate an auditable record of commitment, placement and delivery.

Location in those records is attested by the operator, not cryptographically proven, and the record is meant to support your compliance work, not replace legal advice.

If your AI work must stay within a country or region, use Request capacity below.