Data Residency

A commitment about the geographic location where data is stored and processed — and, for AI tools, three separate questions: where data rests, where inference runs, and who can access it remotely.

In depth

Data residency is a vendor commitment that data stays within a defined geography. For AI tools it is really three distinct questions that procurement teams often collapse into one checkbox: storage residency (where chat history, files, and logs rest), inference residency (where the model actually processes the prompt — a vendor can store history in Frankfurt while GPUs in Virginia run the inference), and operational access (whether personnel in a third country can reach the data for support or abuse monitoring, which the EDPB treats as a transfer in its own right). Residency is not a compliance label: the GDPR does not require personal data to stay in the EU, only a lawful Chapter V mechanism for transfers out of it — and an EU-resident deployment can still violate every other obligation. Availability varies sharply by vendor and tier, and offerings change frequently, so residency claims belong in the contract, not the marketing page.

Examples

  • A DPIA that records storage in an EU region but misses that model inference for the same product runs on US infrastructure.
  • A procurement checklist that asks 'EU data residency: yes/no' and never asks where support engineers who can read logs are located.
  • A team choosing an AI vendor tier specifically because its contract pins both storage and inference to an EU region.

How Locke handles data residency

Locke reduces what residency has to protect: detection and masking run entirely on the user's device, so flagged personal data never reaches the AI vendor's infrastructure in any region. What does cross the border is pseudonymized before it leaves the machine — the supplementary-measure approach the EDPB recommends when data must transit to a third country.

See the product

Reading on this topic