How LLM Governance and Runtime Control Tools Enforce Data Residency on Each Request, and How to Evaluate Them

What per-request enforcement requires

Most residency commitments are made at a coarse level: a contract clause, a tenant setting or a region chosen when a model endpoint is provisioned. Data movement happens at a finer level. Each request assembles a prompt, may pull context from a retrieval source, may call tools, and may fall back to a different model if the first one is unavailable. A region setting made months earlier does not see any of that.

Enforcement at request level has four technical properties. First, the decision is made before data leaves, not after. Second, it is made outside the model. NIST observes that LLMs take data and instructions as a single stream of tokens, so there is no separation between data and the control plane, and that this separation must be enforced by architecture, with policy enforcement established around the agent and between the systems, data, credentials and environments it touches. An instruction in a system prompt asking the model to stay in region is not a residency control. Third, the decision is deterministic, so the same input under the same policy produces the same outcome and can be tested. Fourth, the decision leaves a record that an auditor can inspect.

The policy itself encodes a legal determination: which jurisdictions are permitted for which data classes. A tool enforces that decision. It does not make it.

Enforcement, configuration, monitoring and review

Vendors use the same vocabulary for very different mechanisms. Classifying a tool by what it does to an individual request cuts through the labels. The table describes mechanisms, not any specific product.

• Configuration: A region, tenant or contract setting applied ahead of time. It sets defaults but does not evaluate each request, so it cannot catch a fallback route, a retrieval source or a tool call that sits outside the setting.
• Enforcement: A policy decision point in the execution path evaluates each request and applies allow, redact or block before data leaves. This is the only category that prevents a violation rather than reporting one.
• Monitoring: Telemetry and alerts that show where traffic went. Useful for detection and drift, but the data has already moved when the alert fires.
• After-the-fact review: Sampling or audit of stored interactions. It supports investigation and attestation, but it depends on what was captured and cannot undo a transfer.

Separating residency at the endpoint, the path and the evidence layer

Treat residency as three separate questions, because a tool can satisfy one and fail the others.

The model endpoint layer asks where inference runs. A regional endpoint answers this for requests that reach it, but it says nothing about how requests were routed there or what else was sent along.

The request path layer asks what is allowed to leave, and toward where. Four data elements travel through it: the user prompt, retrieved context, tool-call payloads and model outputs. Each can carry regulated content independently. A prompt that is clean can be joined to a retrieved document that is not, and a tool call can carry record identifiers the user never typed. Enforcement needs to inspect each element at the point where it is assembled or sent. Where multiple models are in use, routing logic needs to be inside the policy boundary, so a fallback cannot send data to a region the policy does not permit.

The evidence and retention layer asks where the record of the interaction lives. Logs and decision records often contain the prompts and context themselves. If they are shipped to a central store in another jurisdiction, the residency commitment is broken by the audit trail. Evidence needs the same constraint as the traffic it describes, with retention the customer can set.

Where runtime policy enforcement fits

Runtime policy enforcement is the approach that places the decision in the execution path. Trussed works this way: it enforces policy at runtime across models, agents, tools and MCP servers, applying allow, redact or block to individual interactions and tool calls, and it is enforced at runtime, not reviewed after the fact. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, so the decision point and the evidence it generates can stay inside the jurisdiction the customer chooses. Enforcement produces audit-ready evidence as a by-product of each decision rather than as a separate reporting step.

This addresses the request path and the evidence layer. It does not replace the endpoint layer: you still need to know where each model runs, and the policy needs to name the permitted destinations. Nor does it replace the legal work of deciding what each data class may do.

On timing, the EU AI Act is in motion. As of October 2026, the Commission reports that an AI Omnibus has entered into force, amending the Act, and that enforcement powers of the AI Office, the European Data Protection Supervisor and national competent authorities apply from 2 August 2026 for certain provisions. Because enforcement is shared, evidence may be requested by more than one body. Separately, the FTC has stated that model providers who fail to honor their privacy commitments to customers may be liable under the laws it enforces. The practical reading is that a residency statement should be backed by technical enforcement and evidence, not only by a contract clause.