Localization Data Residency: Where Content Lives

Quick answer — Data residency is a promise about where content is stored. It is not the same as where it is processed, and translation jobs move data through several places — source content, translation memory, and model inference each have their own answer.

Vitra.ai Universe runs multi-tenant, in a dedicated region, or fully air-gapped.

Three words people use interchangeably

Residency is where data sits at rest. Processing location is where compute happens to it. Sovereignty is whose law reaches it, which can differ from both.

A vendor can honestly say your data is stored in Frankfurt while a model call processes it somewhere else entirely. Both statements are true and only one of them is usually what the question meant.

Ask about all three separately, or you will get an accurate answer to a question you did not ask.

What moves during one translation job

Inference is the row that catches people. Content can be stored in-region and still be sent to a model hosted elsewhere for the seconds it takes to translate, and that transit is what a strict reading of residency is actually about.

The questions that get useful answers

Where is content stored, and can that be pinned per organization rather than per account. Where does inference run for each model in the pipeline. Is anything retained after the job, and for how long. Is content used to train anything.

Then the one people forget: what happens on export. If leaving means the memory and glossaries stay behind, residency was never the binding constraint — portability was.

Choosing a shape

Multi-tenant cloud with a named region satisfies most requirements, especially where the concern is contractual rather than statutory.

A dedicated region tightens storage and inference together. An air-gapped install removes the question by removing the network, and on-premise sits between.

Whichever shape, insist the quality control evidence lives in the same place as the content it describes.

A verdict stored in a different jurisdiction from the asset it approved is an awkward thing to explain later.

Where records cannot leave the estate at all, residency is not enough — secure translation for sensitive records covers that case.

FAQ

Is data residency the same as where content is processed? No. Residency is where data sits at rest; processing location is where compute happens. Content can be stored in one region and sent to a model hosted elsewhere for the seconds translation takes.

What part of a translation job is most often overlooked in residency reviews? Model inference. Storage location is usually specified carefully while the question of where each model in the pipeline actually runs goes unasked, and that transit is what a strict reading covers.

Should translation memory be covered by a residency requirement? Yes, and separately from source content. Memory accumulates your approved language over years, is scoped per organization, and is often the most sensitive artifact in the system by the time anyone reviews it.

What should be asked about leaving a vendor? Whether memory and glossaries export in a usable format such as TMX. If the accumulated language stays behind, the binding constraint was portability rather than residency, and that is a harder problem.