AI data residency is the requirement that the regulated data an AI system touches is stored and processed only inside a permitted country or region. For an AI workload that covers four places, and a residency answer has to hold for all of them: the training and fine-tuning data, the prompts sent for inference, the vector store behind retrieval, and the region where the model itself runs.
This post is about those four locations. If you need the legal requirements themselves, country by country, they are in our guide to data residency requirements.
Why AI makes residency harder
Residency asks data to stay put. Most AI systems are built to move data to wherever the compute is: a model endpoint, a GPU cluster, a managed vector database. Each of those moves can cross a border that nobody drew on the architecture diagram.
Under the GDPR the consequence is concrete. Article 44 permits a transfer of personal data to a third country only if the conditions of Chapter V are met, which in practice means an adequacy decision (Article 45), appropriate safeguards such as standard contractual clauses (Article 46), or one of the narrow derogations in Article 49. A prompt that carries a customer’s name to a model hosted outside the EEA is a transfer under that rule, whether or not anyone filed it as one.
The four places AI data goes
Training and fine-tuning data
Training data is the easiest location to see and the hardest to take back. Once personal data has trained or fine-tuned a model, the question becomes whether the model itself still carries it.
The European Data Protection Board addressed this in Opinion 28/2024, adopted on 17 December 2024. It states that “AI models trained with personal data cannot, in all cases, be considered anonymous”, and that information from the training set “may still remain ‘absorbed’ in the parameters of the model”. Whether a given model counts as anonymous is decided case by case.
For residency, the practical reading is this: unless you can show a model is anonymous, treat the place its weights are deployed as a place your training data went. A model fine-tuned on German customer records and then served from another continent may have moved that data with it.
Inference: where your prompts are processed
Every inference call sends data to a model. The residency question is where that model runs, and the answer depends on a setting that many teams never change.
Cloud model services offer deployment options that route requests across regions for capacity and price. Microsoft’s deployment types for Foundry Models state that inferencing data for Global types “may be processed in any Azure region”, Data Zone types process data “only within the Microsoft-specified data zone (US, EU, or Asia Pacific (APAC))”, and Standard types process prompts and responses within the customer-specified Azure geography. The same page says data stored at rest remains in the designated geography for all deployment types, which is exactly why a region picker can look like a residency answer when it covers only storage.
Amazon Bedrock works the same way. Its cross-Region inference documentation describes geographic profiles, which route requests within a geography such as the US or EU, and global profiles, which route them to “any supported AWS commercial Region worldwide”. AWS recommends the geographic option for data residency requirements, and CloudTrail records the Region that actually processed each request in an inferenceRegion field of its additional event data, which is the evidence an auditor will want.
Embedding calls count too. Turning a document into a vector is an inference request, so the embedding model’s location is part of the residency answer for any retrieval system.
RAG and vector stores
Retrieval-augmented generation (RAG) copies your documents into a second system. They are split into chunks, each chunk is embedded, and the vectors are written to a vector store, usually with the chunk text beside them so it can be handed back to the model at query time.
That creates three locations to account for: where the documents were chunked, where the embedding model ran, and where the vector store lives. Vector stores are often provisioned early, in whichever region was quickest, and never revisited. If the source documents were subject to residency, the store holding their text and vectors is too.
Model hosting location and support access
The last location is the least visible: who can reach the model, the store, or the logs, and from where. The EDPB’s Recommendations 01/2020 on supplementary measures (version 2.0, adopted 18 June 2021) state that “remote access from a third country (for example in support situations) and/or storage in a cloud situated outside the EEA offered by a service provider, is also considered to be a transfer.”
So an AI service hosted in Frankfurt and supported by engineers elsewhere can still involve a transfer. The hosting region answers where the bytes sit. It does not answer who can open them, which is the question sovereignty asks; our data sovereignty guide covers that distinction.
The move that makes the problem smaller
Every residency obligation attaches to data that crosses a boundary. The cheapest way to satisfy one is to send less across it.
The EDPB makes the same point in its own terms. Paragraph 137 of Recommendations 01/2020 notes that “in some cases it might not be necessary to transfer certain data”, and lists data minimisation among the measures that limit exposure in a transfer. For AI workloads that translates into a few concrete moves, made while the data is still on the machine that produced it:
- Remove or mask personal identifiers before records are sent to a model or written to a training set.
- Embed documents with a model running inside the boundary, so only vectors and the chunks you choose to keep reach the vector store.
- Aggregate or drop records a model does not need, so the thing that leaves is derived rather than raw.
- Pin inference to a regional or in-country deployment type, and check the provider’s logs for where requests were processed.
None of these replaces a transfer assessment. They shrink what the assessment has to cover.
Where Expanso fits
Expanso runs pipelines on nodes you control, so filtering, masking, and routing happen at the source. On the security and governance page, payloads are processed on your nodes and only the outputs a job configures move downstream. Jobs are targeted to labeled nodes by site, region, environment, or hardware role, which is how a pipeline for one country’s records is pointed at machines in that country.
Two boundaries belong in your review. Managed Expanso Cloud receives operational metadata, including metrics, health, and logs, for fleet coordination, so logging configuration is part of the residency picture. And residency, privacy, and compliance depend on the complete pipeline configuration and operating environment, so test the node selection and every output in the environment where the job will run.
For retrieval, the Expanso documentation includes a RAG recipe that chunks documents, embeds them with a model served by Ollama on the node, and writes the vectors to Qdrant. The recipe states which versions it was proved on and its limits. For removing identifiers before data leaves, see how to remove PII from logs before export and the data governance use case.
If you have a specific residency obligation for an AI workload, book a review and bring the requirement along with the pipeline. We will map where each piece of data goes.
FAQ
Is sending a prompt to an LLM API a cross-border data transfer?
It is if the prompt contains personal data and the model runs outside the country or region where that data must stay. Under GDPR Article 44, a transfer of personal data to a third country needs a Chapter V basis, and the API call is the transfer. Check which region processes the request, not only where your account or resource is created.
Does the EU AI Act require AI training data to stay in the EU?
No. Article 10 of the AI Act sets data governance and quality requirements for the training, validation, and testing data of high-risk AI systems, and asks that data sets take into account the geographical setting the system is intended for, to the extent its purpose requires. It does not say where that data must be stored or processed. Transfers of personal data are still governed by the GDPR.
Does choosing an EU cloud region guarantee AI data residency?
Not on its own. Some model services store data at rest in your chosen geography while processing inference requests elsewhere, depending on the deployment type. Microsoft’s Global deployment types and Amazon Bedrock’s global inference profiles are two documented examples. Remote support access from outside the EEA can also count as a transfer.
Does fine-tuning on personal data make the model subject to residency rules?
It can. The EDPB’s Opinion 28/2024 says models trained with personal data cannot in all cases be considered anonymous, and that decision is made case by case. Until a model has been shown to be anonymous, treat its deployment locations as locations of the training data.
Where can I find the data residency requirements for each country?
Our guide to data residency requirements covers the legal rules by jurisdiction, including the GDPR, China’s PIPL, and other national regimes. This post covers how those rules apply to the parts of an AI system.
