What is an EU-hosted LLM proxy?

An EU-hosted LLM proxy is a server-side layer that sits between your applications and every large language model provider you use. It intercepts each request, applies your organisation's data and access rules, forwards the request to a provider inside EU jurisdiction where possible, and keeps a record of what happened. All of that runs on infrastructure physically located in the European Union.

The category exists because European organisations are being asked to prove three things at once: where their prompts go, how their AI costs are attributed, and what records they can produce during an EU AI Act review. A proxy is the operational answer.

Why "EU-hosted" is different from "GDPR-friendly"

Any US-based AI provider will tell you they respect GDPR. The legal distinction that matters is not whether data is handled carefully, but where it physically resides while being processed and which government has legal access to it.

The Schrems II ruling from the Court of Justice of the European Union (Case C-311/18, 16 July 2020) struck down the EU-US Privacy Shield precisely because US intelligence services can compel disclosure of data held by US companies even when that data belongs to European customers. The EU-US Data Privacy Framework that followed has restored a legal basis for many transfers, but it has not removed the underlying tension.

The practical consequence for regulated European organisations is this. Routing prompts through a US-region endpoint is a transfer under Chapter V of GDPR, and it requires either a transfer mechanism or a lawful derogation. Routing prompts through an EU-hosted proxy that forwards to a provider's EU region avoids the transfer entirely for that request.

The three failure modes an EU-hosted proxy prevents

1. Silent data leakage across jurisdictions. A developer signs up for a US AI service on a company card. Prompts containing customer names, invoice numbers, and product roadmaps start flowing to US servers before the DPO has heard of the tool. An EU-hosted proxy centralises the endpoint so this cannot happen without the platform team seeing it.
2. Cost that finance cannot explain. Every LLM provider bills after the fact by token count. Without attribution at the request level, finance sees a single monthly total and has no way to allocate it to teams, products, or workflows. A proxy tags every request with the team and project it belongs to.
3. Audit evidence that does not exist. The EU AI Act (Regulation (EU) 2024/1689) requires providers and deployers of high-risk AI systems to keep records of automated events for the lifetime of the system under Article 12, maintain data governance documentation under Article 10, and demonstrate accuracy, robustness, and cybersecurity measures under Article 15. If those records were never generated at request time, they cannot be reconstructed later. A proxy generates them automatically.

What an EU-hosted LLM proxy does not do

Vendor marketing often blurs these boundaries. We name them explicitly.

• It is not an AI model. A proxy calls existing models on your behalf. It does not do inference itself. Model capabilities, latency, and accuracy come from the upstream provider.
• It does not certify EU AI Act compliance. The Act does not permit a vendor to certify a customer. A proxy produces records that the customer's own risk assessment and human oversight processes must then use. Compliance is a shared responsibility with a strict split.
• It does not replace legal review. A DPO still needs to sign off on which providers may be used for which data categories. A proxy makes the "which" question much easier to answer, but it does not answer it.

How Ciralgo implements the pattern

Ciralgo sits between your applications and every LLM provider your organisation uses. Applications continue to call the OpenAI or Anthropic SDK, only the base URL changes. Ciralgo then does five things per request.

1. Route to a provider inside the EU where the workload allows.
2. Redact personal data at the proxy layer before the request leaves your infrastructure.
3. Attribute the request to a team, project, and workflow using a header your app supplies.
4. Log a tamper-evident record of the request, the routing decision, and the response metadata.
5. Return the response using the same shape the calling SDK expects.

Full technical detail lives in the docs. The product overview walks through the wire-compatibility model. The documentation lists the concrete provider regions Ciralgo can currently reach and maps each Ciralgo record to the specific AI Act article it satisfies.

Providers Ciralgo can route to inside the EU

The table below is a snapshot. Provider EU availability changes as vendors open new regions and deprecate old ones. This page is refreshed quarterly.

Providers where EU residency is not currently possible

Not every model has an EU-region endpoint. Where residency is a hard requirement, Ciralgo defaults to blocking those providers and lets you enable them per workload with an explicit sign-off. Common cases:

• Frontier models with reasoning modes that are only served from the provider's home region.
• Fine-tuned closed models hosted on the training region for latency reasons.
• Providers still building out their EU footprint.

The honest position is that "EU-hosted" today means EU-first with named exceptions your DPO has approved. It does not mean "no US endpoint under any circumstances." Any vendor claiming the latter is either misrepresenting their coverage or serving from a much smaller subset of models than you might need.

What to check before choosing an EU-hosted LLM proxy

1. Where does the proxy's own control plane run? A proxy that routes to EU providers but hosts its own control plane in the US has not solved the problem.
2. Where are the logs stored? Same question. Request logs contain the sensitive material, not just the routing decisions.
3. Which specific provider regions can the proxy reach? Ask for the current list, not a headline claim.
4. How does the proxy handle the case where the requested provider has no EU region? The right answer is "policy-driven block with per-workload override," not "silent US fallback."
5. What records are generated per request, and in what format? Article 12 of the AI Act specifies logs of automated events, and auditors read this literally. CSV export is not enough for a serious audit.
6. How does it handle personal data in prompts? Detection at the proxy layer is table stakes. Ask what pattern set is used and how false positives are handled.
7. What is the DPA, and what is the current sub-processor list? These are the two documents your procurement and DPO will read first.

Frequently asked questions

Is an EU-hosted LLM proxy the same as an AI gateway?

Overlapping but not identical. "AI gateway" usually refers to a US-market category focused on cost control, rate limiting, and provider fallback. "EU-hosted LLM proxy" adds data residency and EU AI Act evidence generation as first-class concerns.

Do we still need a DPA with each underlying provider?

Usually yes. The proxy is a data processor with respect to the customer, and the underlying provider is a sub-processor. Standard sub-processing terms in the proxy's DPA cover this pattern.

What about latency?

Modern EU-region endpoints have latency comparable to US regions for European users. The proxy layer adds a small overhead, typically under a hundred milliseconds.

Can we self-host the proxy?

Some deployment models allow this. Self-hosting is not the same as compliance, though. See the security page for how residency is handled without self-hosting for most customers.

Related reading

• Ciralgo product overview
• Documentation
• Security posture
• Data Processing Agreement
• Current sub-processors list

Last refreshed: 8 July 2026. This page is reviewed quarterly.