Data Residency for RAG: What Actually Has to Stay In-Region

It's tempting to treat embeddings as anonymized, since they're just arrays of numbers rather than readable text. They're not anonymized in any legal sense: given the same embedding model, an embedding can often be used to reconstruct something close to the original text, and regulators that care about where personal data lives generally treat an embedding of personal data as personal data, not as a derived, exempt artifact. If your residency obligation covers the source document, assume it covers the embedding too, and check where your embedding model actually runs, not just where you store the resulting vectors.

If you store vectors in an in-region vector database but call a hosted embedding API that runs in a different region, the source text crosses that boundary on every embedding call, even if the resulting vector never leaves. This is the single most common residency gap in RAG systems: the storage layer is compliant, and the compute layer that produced what's stored isn't. Check this for every hosted component in the pipeline, not only the embedding call: a reranking API or a generation model with the same out-of-region execution problem creates the identical gap.

Work through source documents, embeddings, retrieved content in transit, and logs as separate categories, and check each against the specific residency requirement you're under, whether that's a customer contract, a sector rule, or a jurisdiction's data protection law. Some obligations only cover the source document; others explicitly extend to derived data like embeddings. Don't assume the strictest reading applies everywhere if your actual contract or regulation says otherwise, and don't assume the loosest reading applies either. Read the specific text.

Retrieved content and query text often end up in a logging or observability pipeline that runs on infrastructure in a different region than the rest of the stack, especially if that pipeline is a third-party tool adopted for convenience. This is frequently the actual residency issue in an otherwise well-architected system: the application and database are in the right place, and the logs quietly aren't.

This gap is easy to miss because the logging pipeline usually predates the RAG project itself: a team adopts an observability tool for general application monitoring, then routes the RAG pipeline's logs into it without re-checking whether that tool's region matches what the RAG system's data now requires. Treat every new pipeline that touches query text or retrieved content as a fresh residency question, even when the tool itself is already approved for other use cases.

• Where does the source document live, and does that match the requirement?
• Where does the embedding model actually execute, not just where the resulting vector is stored?
• Where does retrieved content travel in transit, including any reranking or generation calls?
• Where do logs and observability data for this pipeline live?
• Does your written obligation cover derived data like embeddings, or only source documents?

Data residency asks where data is stored or processed. Data sovereignty asks who can compel access to it regardless of where it sits, since infrastructure run by a company subject to another country's laws can potentially be compelled to produce data even when that data physically stays in-region. If your obligation is sovereignty rather than residency, choosing an in-region data center from a vendor headquartered elsewhere may not satisfy it, and that distinction is worth confirming with whoever wrote the requirement rather than assuming the two are interchangeable.