GDPR-compliant LLM routing: what US-based gateways don't tell you
Data residency, sub-processors, Schrems II, and the EU AI Act — a precise briefing

This post is not an alarm. It's a briefing. If you're a European company using an LLM gateway — or shipping AI features into the European market — there are specific compliance questions you should be able to answer, and several of them don't have clean answers when your gateway is US-based.

I'm not a lawyer. Nothing here is legal advice. But I've been through enough procurement cycles with European enterprises to know which questions get asked, which answers pass, and which answers kill deals. Let me lay them out.

The four angles that matter

When a European compliance team reviews an LLM integration, they typically look at four things:

1. Data residency — where prompts and completions are physically processed and stored.
2. Sub-processors — the chain of third parties touching the data, and under which jurisdiction each operates.
3. Data Processing Agreement (DPA) — the contractual document governing how personal data is handled.
4. EU AI Act implications — depending on use case classification, additional obligations on transparency, risk management, and human oversight.

Each of these is answerable. Each is also different depending on whether your gateway is US-based or EU-based.

Data residency in practice

The basic question: when a user in Paris sends a prompt that contains personal data through your AI feature, where is that prompt processed?

• Direct to Anthropic/OpenAI: processed in the provider's region, typically US unless you've configured an EU region (Anthropic offers EU regional processing for some models; OpenAI has European zonal options in Azure).
• Via a US-hosted gateway (OpenRouter, Vercel, Portkey, Helicone, Cloudflare AI Gateway on default config): processed at least once on US infrastructure before hitting the model provider.
• Via an EU-hosted gateway (HiWay on OVH, or a self-hosted LiteLLM in an EU region): processed on EU infrastructure, then forwarded to whichever provider region you configure.

The gateway step matters because it's a distinct processing event. Even if your underlying model provider has an EU region, passing through a US-hosted gateway first adds a US processing link to the chain.

For most B2C products with non-sensitive data, this is a non-issue. For B2B products selling to regulated sectors (health, finance, government, legal, education) it frequently is.

Sub-processors: the chain you actually sign for

When you sign with a gateway, you typically accept their sub-processor list. That's the chain of additional vendors who may touch the data — CDN, log infrastructure, monitoring, authentication, cloud provider.

For a typical US-hosted gateway, the sub-processor chain might include:

• AWS or GCP (US cloud, with EU regions available)
• A US-based observability vendor (Datadog, New Relic, etc.)
• A US-based email provider
• A US-based auth provider
• A US-based CDN (Cloudflare is a mixed case)

Each of those is a separate data flow you're signing for. Your own customers or compliance team will expect you to list them, or at least vouch for the gateway's list.

For an EU-hosted gateway on OVH (our case), the sub-processor chain is shorter and more European:

• OVH (French cloud)
• Stripe (payment processing — unavoidable for card payments, but minimized to what's strictly needed)
• A limited set of EU-based supporting services

Shorter chains are easier to document and easier to get through compliance review.

The DPA question

GDPR requires a DPA between you (the controller) and any processor handling personal data. When you sign with a gateway, you sign a DPA with them.

Three things to check on any gateway DPA:

1. Does it commit to a specific processing region? If the DPA is silent on region or says "we may process globally," your compliance team will flag it. You want a commitment — "processing occurs in region X" — or at least a configurable option that produces a signed commitment.

2. What's the breach notification timeline? GDPR requires notification to authorities within 72 hours of a breach being known. Your gateway's commitment in the DPA should be fast enough that you can meet your own 72-hour window after they tell you.

3. What's the sub-processor change notification? The DPA should commit to notifying you in advance when they add new sub-processors, so your compliance team can evaluate the chain. Vague "we'll notify when reasonably possible" language is a problem.

Most US gateways have DPAs. The quality varies. The specificity on processing region is usually the weakest point.

Schrems II, briefly

Schrems II is a 2020 CJEU ruling that invalidated the previous EU-US data transfer framework. The follow-up — EU-US Data Privacy Framework, adopted in 2023 — is currently in force but under legal challenge.

What this means practically: transfers of personal data from the EU to the US rely on legal mechanisms (the DPF, or Standard Contractual Clauses with supplementary measures) that have been challenged in court before and may be again. Using a US-based gateway means you are relying on those mechanisms, which are legally valid today but not bulletproof.

For many companies this is acceptable risk. For some — public-sector buyers, healthcare, regulated finance, legal services — it's enough of a concern to prefer EU-based alternatives where possible. The EU AI Act has amplified this preference.

The EU AI Act layer

The EU AI Act came into force in 2024, with phased obligations rolling through 2026-2027. The relevant part for LLM gateway users:

• Prohibited practices (e.g. certain manipulation, mass biometric categorization) are banned outright.
• High-risk systems (credit scoring, hiring, education grading, law enforcement use, and others) have mandatory obligations: risk management, data governance, human oversight, transparency, logging.
• General-purpose AI models (the big foundation models) have transparency and documentation obligations on the provider side.
• Transparency obligations apply broadly: users must know when they're interacting with an AI system.

The gateway layer isn't directly regulated, but your use of a gateway is part of your compliance picture. If you're operating a high-risk system, you'll need documentation showing how data flows, where it's processed, and who has access. That documentation is significantly easier to produce if your processing chain is short and EU-based.

For high-risk use cases, the combination of EU-hosted infrastructure + explicit DPA + short sub-processor chain + no-prompt-logging-by-default is close to a checklist answer for half of the compliance document.

The compliance checklist

For evaluating any LLM gateway on the compliance angle, here's the checklist I'd use:

Data residency

• Is the gateway's primary processing region documented in writing?
• Can you commit to an EU-only processing region if needed?
• Does the DPA reflect the regional commitment?
• Are backups processed in the same region?

Sub-processors

• Is the sub-processor list public?
• Is each sub-processor's jurisdiction documented?
• Is there a notification mechanism for changes?
• Can you veto specific sub-processors if they're unacceptable to your customers?

Prompt handling

• Is prompt logging on or off by default?
• If logging is on, what's the retention?
• Can prompt logging be disabled per API key?
• Are logs accessible only in the commitment region?

DPA quality

• Does the DPA specify a processing region?
• Is breach notification ≤ 72 hours?
• Does it require sub-processor change notification?
• Are data subject request handling timelines specified?

EU AI Act alignment

• Does the gateway publish a list of supported foundation models with their providers?
• Is there documentation suitable for high-risk system compliance?
• Is there a transparency statement you can link to?

Business presence

• Is the gateway operated by an EU-based legal entity (or US with clean EU subsidiary)?
• Where are the people who respond to data subject requests based?
• Is there an EU representative (Article 27 GDPR) if the entity is non-EU?

If you can't answer most of these for your current gateway, that's useful information.

What the honest answers look like

For transparency, here's how HiWay answers each bucket:

Data residency. All processing on OVH French infrastructure. Configurable to EU-only when contractually required. Backups stay in region.

Sub-processors. Short list, published. Primarily EU-based with limited exceptions (Stripe for payments). Notification in advance for changes.

Prompt handling. Zero prompt logging by default. Optional debug logging per API key with bounded retention. Logs stay in region.

DPA. Specifies OVH French region. 72-hour breach notification. Sub-processor change notification commitment. Included with paid tiers.

EU AI Act. Published model catalog with provider attribution. Documentation template for customers building high-risk systems. Transparency page.

Business presence. Operated by Mytm-Group, French SARL. People responding to data subject requests are based in France.

This isn't to say HiWay is the only option that gets these right. Self-hosted LiteLLM in an EU region under your own entity can produce equivalent answers. The point is that US-hosted gateways structurally can't, even when individual elements are configurable.

What US-hosted gateways sometimes do tell you

To be fair: some US gateways have made real compliance investments. Portkey has enterprise tiers with regional options. Helicone has an OSS self-host option that lets you deploy in your own EU region. Cloudflare AI Gateway benefits from Cloudflare's global regulatory sophistication.

What they can't typically offer is "we are an EU-based entity under EU law with EU-based personnel as first-line responders." That's a structural difference between US and EU gateways, and for some compliance conversations, it's the deciding factor.

What to do if you're already on a US gateway

If you're reading this and realizing your current stack is US-hosted end to end, don't panic. Steps:

1. Document what you have. Write down your current data flow, sub-processors, and DPA commitments. You can't fix what you haven't mapped.
2. Talk to your compliance team. Ask what their hard requirements are versus preferences. The answer often surprises both directions.
3. Evaluate the risk for your specific use case. B2C consumer app serving non-sensitive data has a different risk profile than B2B healthcare.
4. If migration is warranted, start with highest-risk data flows. You don't have to move everything at once. Move the regulated workloads first.
5. Update your public documentation. If you say "GDPR-compliant" on your marketing site, your actual architecture should back that up.

Migration from a US gateway to an EU one — assuming both are OpenAI-compatible — is a base_url change. See our migration post.

The honest takeaway

US-hosted LLM gateways are not unusable by European companies. Many work with them today. But they have structural characteristics that create specific compliance friction, and that friction gets worse as EU AI Act obligations phase in and as compliance teams mature.

If your use case is sensitive — regulated sectors, high-risk AI Act classifications, customers with strict procurement — an EU-based gateway reduces the compliance surface area materially. If your use case is low-sensitivity, US-hosted options are fine and often more feature-rich today.

The question isn't "is US hosting legal?" It mostly is, for now. The question is "does it make my compliance conversations harder?" For many European buyers, the honest answer is yes.

---

Next: the honest guide to choosing an LLM router in 2026 — a decision framework.