Data Residency in AI Deployment
A deployment can keep every record in the right country and still fail on residency. That sounds like a contradiction until you follow the data instead of the database.
Source data is only the first stop. Once a workflow starts, copies multiply quietly: passages are embedded and stored in a vector index, prompts travel to wherever the model actually runs, traces capture the text someone will later need to debug, and backups replicate all of it somewhere else. A security review that only asks where the originals live has checked one stop on a five-stop route.
Residency is a route, not an address
Start with inference, because it is the stop people forget. A model call is a data transfer. If your records sit in a European region but the model endpoint routes requests elsewhere for capacity or price, residency broke in transit while every dashboard still showed the database at home. This is why routing modes matter as much as storage regions. AWS built its AWS European Sovereign Cloud around exactly this point: content stays in the region selected, and Bedrock inference there runs in-region rather than through global cross-region routing. You may never need a sovereign cloud. You do need to know which mode your deployment is in, and to be able to say so in one sentence.
Retrieval is the second quiet copy. Embeddings feel abstract, so teams treat the vector store as plumbing. It is a derived copy of your documents, often including the text chunks themselves, and it inherits the same residency and access rules as the source. Same for the eval set, which is built from real examples because synthetic ones do not measure much. Real examples mean regulated data in a test file, usually with weaker controls than the system it tests.
Then there are the records the system keeps about itself. Logs and traces are where prompts go to be readable. They are also the first thing an incident review asks for, so you cannot simply switch them off. The workable answer is deliberate: traces live inside the same boundary as the data, access to them is named rather than general, and retention is a number someone chose, not a default nobody remembers setting.
The vendor questions belong on this route too. What a platform does with inputs and outputs is a documented position, not a matter of trust. Amazon Bedrock, for example, states that customer inputs and outputs are not shared with model providers and are not used to improve the base models, and offers private connectivity from a customer's VPC. Whatever stack you choose, get the equivalent answers in writing for training use, retention, and who operates the service. If a provider cannot answer plainly, that is an answer.
Start the review before the architecture hardens
Most security reviews stall deployments for a boring reason: they arrive at the end, when every answer has already been built. Is the agent allowed to read that share? Which keys encrypt the backups, and who holds them? How long do traces survive? Asked in week one, these are design choices, cheap to make well. Asked after the build, the same questions become rebuilds, and the review gets blamed for a delay the schedule created.
So ask for the questionnaire first. A good review also improves the system in ways nobody files under security. Deciding which data the workflow may touch forces the scope conversation teams keep postponing. Deciding who can read the logs forces an honest answer about how much sensitive text the system will handle. Security teams, in our experience of reading their questionnaires, are often the first people to ask what the system is actually for. That question deserves an early audience.
Four controls answer the bulk of most reviews, and none of them is exotic. The agent gets its own identity, scoped to the systems and actions its task needs, never a borrowed human login. Retrieval checks the requesting user's permissions before documents reach the model, so the system cannot summarise what the person asking was never allowed to read. Inference runs in-region or over private routes, with any cross-region behaviour off or explicitly disclosed. And the records stay inside the boundary, under a retention limit with a named owner.
Governance is who can change the answer
Residency settings and guardrails (the in-line checks that constrain what a system may read, send and do) describe a deployment on the day it ships. Governance decides whether it still looks like that in six months. The NIST AI Risk Management Framework puts this well in structure if not in so many words: its Govern function wraps Map, Measure and Manage, because the standing decisions about accountability are what keep the other three honest over time.
In practice, governance for a deployment is a short list of named permissions. Who can add a new data source to the system's reach. Who can widen what the agent is allowed to do without asking. Who approves a model swap, knowing a new model can mean a new region, a new retention position, a new subprocessor list. Who can grant themselves access to the traces. If those four questions have names attached, the review's findings stay fixed after they are fixed. If they have a committee attached, they quietly unfix themselves.
Honesty about limits, then. Residency is not security: data can sit in exactly the right place and still be exposed by an over-permissioned agent or a prompt injection that talks the system into fetching what it should not. Keeping everything in-region or on premises narrows your model choices and can add cost and latency, and for some workloads that trade is wrong. And some data should not enter an AI workflow at all, in any region, under any control set. A review that ends in "not this workflow" has done its job, not failed it.
The decision to take from this is sequencing, not caution. Draw the route, start the review while the answers are still cheap, and name who can change them. Deployments that do this tend to find the security review is the shortest part of the project. Deployments that treat it as a final exam keep retaking it.
Work with us
If your AI project is waiting on a security review it hasn't started yet, begin earlier this time: tell us where your data has to live and what it may never touch, through Trida AI's intake, and we will design the deployment to that boundary from the first sketch.