LLM Data Residency: EU and Regional Routing | TrustedRouter
What LLM data residency covers and what it cannot: EU gateway routing, zero-retention tiers, and an attested gateway you can verify with one command.
Residency pins where inference runs; attestation proves who can read the prompt.
A residency clause lands in a customer DPA. A GDPR transfer analysis flags US processing. Sector rules name a region. However it arrives, AI data residency requirements eventually stop being a policy question and become a routing question: which routes can serve LLM inference from EU hosting, and what happens to the prompt once it arrives?
TrustedRouter's answer is an EU gateway with EU-focused routing on the same OpenAI-compatible API you already use. We are specific about what EU data residency means on an LLM API here: gateway location and routing preference across 220+ model routes, nothing beyond that. Several upstream model providers are US entities, and we say so. A serious residency review asks three separate questions: where, how long, and who. This page takes them in order.
NONCE=$(openssl rand -hex 16)
curl "https://api.trustedrouter.com/attestation?nonce=$NONCE"
# returns a JWT signed by the CPU vendor's root key;
# its image_digest matches the published artifactResidency: an EU gateway
EU-focused routing through an EU gateway, on the same OpenAI-compatible API. The claim covers gateway location and routing preference. It is not a blanket residency guarantee for every route, and we do not dress it up as one. Details at /eu.
Retention: nothing stored by default
TrustedRouter does not store prompt or output content by default. Every route carries a privacy tier: Open, Zero-Data-Retention, or TEE. Zero-Data-Retention routes use providers that contractually keep nothing. More at /security.
Access: the question location cannot answer
An EU address does not stop an operator from reading traffic in-region. Only hardware settles that objection. The prompt path runs inside a hardware-attested confidential-compute gateway with open source, a published image digest, and a live attestation check bound to your TLS session. Privacy you can check beats privacy you're promised. See /security.
EU routing should not require a sales call.
OpenRouter is a capable aggregator with a deep catalog, and its enterprise tier does offer in-region EU routing. Below that tier, it is gated. TrustedRouter's EU gateway and EU-focused routing are documented at /eu, alongside per-route Zero-Data-Retention and TEE tiers, and moving over changes one line: the base URL. See the migration guide.
One caution your compliance team will appreciate: residency alone does not make a deployment GDPR-compliant. Transfer analysis, DPAs, and subprocessor review still do the legal work. What TrustedRouter supplies is verifiable architecture plus readiness documentation your compliance team can assess: the DPA, the subprocessor list, and SOC 2 readiness, backed by a gateway whose behavior you can check rather than take on faith. It holds up at volume: a document-processing company scaled from zero to over a billion tokens per week through the attested gateway within three weeks of onboarding.
Questions
Does an EU gateway make my LLM API GDPR compliant?
No. Residency is one input to compliance. Transfer analysis, a DPA, and subprocessor review still do the legal work, and nothing on this page is legal advice. TrustedRouter provides the architecture side: an EU gateway with EU-focused routing, a DPA, a published subprocessor list, and SOC 2 and HIPAA readiness documentation your compliance team can assess against its own requirements.
Can every TrustedRouter model be pinned to the EU?
No. TrustedRouter offers an EU gateway and EU-focused routing, and claims no data-residency guarantees beyond that. Several upstream model providers are US entities. If your real concern is who can access the prompt rather than which country it transits, the TEE privacy tier runs end-to-end confidential compute, where even the serving provider cannot read the prompt, regardless of geography.
What is the difference between residency, retention, and access?
Residency is where inference runs; TrustedRouter's answer is the EU gateway. Retention is what is stored afterward; TrustedRouter does not store prompt or output content by default, and Zero-Data-Retention routes use providers that contractually keep nothing. Access is who can read traffic while it is processed; the attested TEE gateway answers that with a live, checkable proof instead of a policy. Most residency clauses are really about all three.
How do I verify the gateway instead of taking TrustedRouter's word?
Request an attestation with a fresh nonce. The gateway returns a JWT signed by the CPU vendor's root key, and the image digest in it matches the published open-source artifact. The attestation binds to your live TLS session, so it cannot be replayed from another machine. The whole check is one curl command, documented at /security.