The EU AI Act's August 2026 enforcement milestone lands on the teams shipping models to European users, and the part that reaches developers is not the novelty — it is data residency and provable controls. Compliance reviews increasingly end with one question: show us which model saw which data, and where that data could have gone.
This is a technical checklist, not legal advice. Talk to counsel about obligations; this is the engineering side of the same conversation.
Why residency is a routing problem
Treat your app's data as having at least three classes, each with a different tolerance:
- Class 1 — EU user data. Highest constraint. It needs providers with plausible EU handling: region-pinned inference where offered, zero-retention paths where available, and documented retention commitments.
- Class 2 — Internal sensitive data. PHI, financial records, employee data. Same routing discipline as Class 1, plus stricter model selection: prefer providers with published data-use-off options on the exact model path you run, not the brand in general.
- Class 3 — Open experimentation. Synthetic data, public corpora, throwaway prompts. Flexible; use whatever model fits the task and the budget.
The routing point: the class determines the route, not the app. One app that models Class 1 support chats and Class 3 background summarization needs different provider paths per request class — a single "we use provider X" answer is not an architecture, it is a hope.
Provider-side controls to verify (per model path)
Residency is not brand-level; it is path-level. For each provider-then-model-then-path combination you run, ask and record:
- Region pinning. Which regions does this exact path support? Pinning is per-request or per-key depending on the provider; know which. How data residency works without building local infrastructure is worth a read even if you never use that gateway — the framing is correct.
- Retention settings. Which paths offer zero-retention or short-retention options, and is the option on by default, on by opt-in, or not present at all?
- Training data use. Off on which paths, on which, and does an enterprise contract override the default?
- Sub-processors and mirrors. Some paths replicate across buildings for latency; the contract may say EU, the mirror may not be.
Write these findings down per path. The document itself is most of the audit evidence.
Enforce classes at the gateway layer
Once classes are modelled, the routing policy is simple:
- Map each API key and environment to its allowed provider-arth path set.
- Default-deny: unclassified traffic does not get a model, it gets a config error.
- Log per request: which path served it, which region, which key.
- Alert on drift: a new model added to a Class 1 key's path is a policy event, not a convenience.
The logic is not a novel invention — it is the same least-privilege pattern you already apply to databases, applied to model paths. What's new in 2026 is that auditors ask for the trail, not the promise.
The audit trail is a feature, not a chore
"Show us" is the end state of every compliance request. A gateway gives you the answer as an export: every request, with the serving path, the data class it carried, and the cost. Mappace's usage records include the serving path and token counts per request, so the answer to "where did EU data go last month" is a filtered export, not an archaeology dig.
What is not out of scope here: local inference. A self-hosted model reduces one trust boundary — it does not replace provenance, retention policy, or documentation. If the entire strategy is "we run it in a server next to the datacenter," the review finishes the same way: show us the rest.
Before the August window closes, do the three hour-scale tasks: classify the data, pin the paths, export one month of history as your baseline. The full routing and residency setup lives in the docs, and the current model catalog lists which paths support which regions in the model catalog.