Data residency
Controls over the geographic region where a provider processes or stores your prompts and outputs.
Why it matters. Some regulations, contracts and customers require data to stay in a specific country or region.
How it works
Data residency is about where your data physically goes: which regions process requests and where any stored data, such as logs, files or caches, lives. A residency option lets you keep that within a chosen geography, such as the EU or US.
Providers offer it in different ways: regional endpoints, a region setting on a project, or cloud platforms that run the model in specific regions. Processing location and storage location can be separate commitments, and some features may not be covered. Availability often differs by model, and regional options can be priced differently.
Check the documentation for both processing and storage, for every feature you use. Residency says where data goes, not how long it is kept, so pair it with retention terms.
Worked example
Illustrative: an EU bank's contract requires processing in the EU. Model A is offered in an EU region on its maker's API, model B only through a cloud platform's EU region, and model C only in US regions. Only A and B qualify, and B needs the platform's own model ID.
Common mistakes
- Assuming a regional endpoint also keeps stored files, logs and caches in that region.
- Turning on a feature such as a hosted search tool that sends data outside the chosen region.
- Checking residency for the main model but not for the embedding or moderation models in the same pipeline.