So keep one region record per model that serves your requests, not one line per provider. Check it again whenever you add a model or an alias changes its target.
Where is my data processed when I call a model through an LLM API? You may have been told your provider is "EU-hosted". This guide shows why that answer belongs to each model, and how to check it. It follows one hypothetical team that calls three models.
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland. Serverless means you call a model through our API and pay per token, without running servers yourself.
Residency belongs to the model, not the provider
Residency belongs to the model because each model runs on its own servers. One API address can reach many models. Each of them is deployed on hardware somewhere, and different models can sit in different places.
A provider that says "we are EU-hosted" answers for its company. Your request does not reach a company. It reaches one deployed model, on one set of GPUs, in one data centre. That deployment is where your prompt is read and your answer is written.
The question a buyer asks is therefore too broad. "Is the provider EU-hosted?" can be true for most models and false for one. The useful question is narrower: where does this model, under this model ID, process my request? The model ID is the name you put in the request's `model` field.
Why the GDPR makes it a per-request question
The GDPR (the EU's General Data Protection Regulation) turns the location of each model into a legal question. It defines processing as any operation on personal data, including retrieval, consultation, use and disclosure by transmission. Sending a prompt that contains personal data to a model is such an operation. So the place where the model runs is a place where your data is processed.
Sending personal data to a third country, meaning a country outside the EU and the wider European Economic Area, is a transfer. Under Article 44, such a transfer is allowed only when the GDPR's rules for transfers, set out in its Chapter V, are met.
The EDPB (the board of the EU's data protection authorities) puts the practical duty plainly. You need to know where the personal data goes, so that it is protected wherever it is processed. On an international cloud, you must assess whether your data will be transferred to third countries, and where. Remote access from a third country also counts as a transfer, for example support staff reaching a model's servers.
An EU region on a model page does not finish your assessment. It is one fact your assessment needs, for each model. For storage, remote access and legal control in more depth, see AI data residency, explained properly.
Where each of our models runs, and how to read it
Each of our model pages states where that model runs, in a field called Processing region. Our models list carries every model with its API ID, prices, context window and processing region. Each model page also says: "Check the model's processing region before sending data."
Take GLM-5.3 as the example. Its page shows the model ID `z-ai/glm-5.3` and, under Processing region, "EU-hosted". The page's FAQ section repeats it in a sentence: GLM-5.3 runs on EU-hosted infrastructure. Prompts and outputs are processed, not stored, and never used for training.
To see which model IDs our API accepts right now, call `GET /models`. Our serverless documentation calls it the authoritative list of IDs the serverless API accepts. Use that list to find the IDs, and each model page to read the region.
Here is the record for a hypothetical team. Its code calls three model IDs. GLM-5.3 runs a coding assistant, and our routing alias runs a support chat. The third is an embedding model, which turns text into numbers a search index can compare, for searching internal documents.
| Model ID in your code | Model that serves the request | Processing region on its page | Page, read 23 October 2026 |
|---|---|---|---|
| `z-ai/glm-5.3` | GLM-5.3 | EU-hosted | GLM-5.3 |
| `qwen/qwen3-embedding-8b` | Qwen3 Embedding 8B | EU-hosted | Qwen3 Embedding 8B |
| `lyceum/router` | Lyceum Router | EU-hosted | Lyceum Router |
| `lyceum/router` | MiniMax M3, its target today | EU-hosted | MiniMax M3 |
Three IDs in the code need four rows. The next section explains the fourth.
Routing aliases need a record for the model behind them
A routing alias is a model ID that lets the provider choose the model for you. Our Lyceum Router works this way: we choose the model for each request and bill it as that model. Today it sends each request to MiniMax M3.
The router's page states its own processing region: EU-hosted. So does the MiniMax M3 page. Your record still needs both rows. The router page says it sends requests to MiniMax M3 "today", so that target can change.
The bill shows the same split. In the hypothetical month below, the chat traffic is billed at MiniMax M3's prices. The volumes are illustrative; the prices are our list prices, read on 23 October 2026.
z-ai/glm-5.3 40M input x $1.40 per 1M = $56.00
8M output x $4.40 per 1M = $35.20 subtotal $91.20
qwen/qwen3-embedding-8b 200M input x $0.02 per 1M = $4.00
lyceum/router (billed as MiniMax M3)
20M input x $0.40 per 1M = $8.00
4M output x $2.00 per 1M = $8.00 subtotal $16.00
Monthly total: $91.20 + $4.00 + $16.00 = $111.20The router line is priced as MiniMax M3, because MiniMax M3 serves it. The model that sets the price is the model that processes the request. So the model named on your bill for the router is the model your region record must list.
The example uses full list prices and ignores the lower price for repeated prompt text, so it overstates the cost. It does not show where your own logs, storage or support access sit. It also does not settle your legal assessment.
Three questions to ask any provider, per model
Ask the same three questions of every provider, for every model ID you call. They work the same way whether the provider is us or anyone else.
- Where is this model processed? Ask for a published field or a contract clause, not a sales answer about the company.
- What serves the request when this ID does not? An alias, a fallback or a failover can send the request to another model or another region. Ask which ones, and where they run.
- Is the answer in the contract or only on a web page? A page can change without notice. A contract term binds the provider.
Ask about subprocessors too: the companies that run part of the service for the provider. Our answer is in the FAQ below. For dedicated inference, which reserves GPUs for you, the location is agreed per contract, so tell us if you need a specific EU location.
Keep a region record and re-check it
Keep the region record next to your records of processing, the list of processing activities that Article 30 of the GDPR requires. Give each row the model ID and the model that serves it. Add the region as the page states it, the page link and the date you read it.
Re-check the record at three moments. Check it when you add a model ID to your code. Check it when an alias changes its target. And check it when a model page changes. Our routing aliases make the second one matter: the record for `lyceum/router` is only as current as the day you read its page.
We recommend a specific model ID rather than an alias wherever a requirement names one processing location. Then the model that processes your data is the one you recorded.
Open our models list, read the processing region for each model ID in your code, and write it into your region record.