The region is a contract term, not an API setting you can assume. A request touches a GPU, the provider's own people and its subcontractors, and each sits somewhere.
Your customer's contract says where their data may be processed. So how do you control where your LLM requests run, and can you keep them in one country or rule some countries out?
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland: you call a shared model through one API and pay per token.
Take a hypothetical requirement sheet from one of your customers. It has three lines: (a) inference only in the EU or EEA, (b) no processing in Iceland or Norway, and (c) processing in Germany only. We test each line below.
Where an LLM request is processed, station by station
At the provider, an LLM request is processed in two places: the gateway that checks your API key, and the GPU running the model. Our legal page describes each station of our serverless inference.
| Station | What we see | What we keep |
|---|---|---|
| Gateway | Your API key, the model you asked for and your prompt, which passes through in memory | A usage record: your organisation and user, the model, token counts and the time |
| GPU | Your prompt, in GPU memory in a European data centre, while the model writes the answer | Recent prompt prefixes in GPU memory, until newer requests replace them |
| Answer streams back | The response, as it streams back to your app | The output token count, added to the usage record |
A prompt prefix is the opening part of a prompt. Recent prompt prefixes stay in GPU memory as a cache until newer requests replace them, which makes a repeated start cheaper. Apart from that cache, prompts and outputs are processed, not stored. We never log them, write them to a database or use them for training.
The prompt itself is processed on the GPU. Once newer requests have replaced its prefix, the usage record is all that remains, and it never contains your prompt or the response.
Two more parties can reach data around a request. One is the people who run our platform. The other is subprocessors, the companies that run part of the service for us.
What region pinning controls, and what it leaves open
Region pinning controls the GPU step: which data centre runs the model that reads your prompt. It does not decide where support staff work, where subprocessors sit or how traffic is routed across networks.
With us, the service you choose sets the GPU location. Serverless models run in Paris and Finland. Dedicated endpoints are GPUs reserved for your workload. Their data centre is agreed for that workload, and you can ask us for a specific EU location.
Line (a) of the sheet, inference only in the EU or EEA, is met for the GPU step. Paris and Finland are both in the EU.
The example has a limit. It tests the GPU step, the provider's people and its subcontractors. Network routing and your own systems are out of scope here. So is the CLOUD Act question: whether a US law lets US authorities demand data from US-owned providers.
Keeping processing in one country, such as Germany
A single-country requirement is a test of the provider's published locations. You can only pin to countries the provider already lists; no API setting adds another.
Line (c), processing in Germany only, is not met by our serverless models. They run in Paris and Finland, and neither is in Germany.
A Germany-only clause also reaches past the GPU. Our team works in Berlin and Zurich, and can access account details, usage records and system logs. Ask your customer what "processing" covers in their clause: the GPU, the logs, or support access as well.
For a dedicated endpoint, the data centre is agreed per contract. Ask for the exact country in writing before you build, and do not assume a location the provider has not confirmed.
Excluding countries and third-country transfers
Excluding a country means checking three lists: GPU locations, staff locations and subprocessor locations.
Line (b), no processing in Iceland or Norway, is met for our GPU step. Our serverless GPUs are in Paris and Finland.
The contract wording matters more than the map. The EEA (European Economic Area) is the EU plus Iceland, Liechtenstein and Norway. The European Commission's adequacy page speaks of data flowing "from the EU (and Norway, Liechtenstein and Iceland)", one data area. So a clause that says "EU or EEA" still allows both countries your customer wanted out.
Our subprocessors are mainly in the EU and the EEA. Anything outside is covered by the GDPR's safeguards, such as standard contractual clauses. The specific countries are in our subprocessor list, which we send on request. Standard contractual clauses are contract terms, pre-approved by the European Commission, that can be a ground for a transfer outside the EU.
A third country is any country outside the EU and EEA. Under GDPR Article 44, a transfer there needs the conditions of Chapter V, the GDPR's rules for transfers, to be met. That includes an onward transfer, where data moves again from that third country to another. One route is an adequacy decision: a European Commission finding that a country protects data well enough. Data can then flow there without any further safeguard.
Switzerland is outside the EU and the EEA, and it has such a decision. So data can flow to Switzerland, where our Zurich team works, without any further safeguard.
To rule a country out, ask for the list through our legal page and check each entry. Which subprocessors apply depends on the service you choose, so your choice of service can rule a subprocessor out. We tell you before we add or replace one, and you can object within 10 business days.
Verifying the region in the contract and in your records
The contract is where a region becomes verifiable. Under GDPR Article 28, a processor handles personal data only on the controller's documented instructions, including about transfers to a third country.
The controller decides what is processed and why; the processor does the processing for them. Under our DPA, you are the controller and we are the processor. You can instruct us in writing, audit us with notice, and choose deletion or return when you leave. The DPA is Annex 1 of our terms, so it applies when you accept them. We recommend writing the countries you allow into your written instructions under the DPA, not leaving them to a region setting.
Your records show what each request left behind. Our legal page shows an example usage record for one request to `moonshotai/kimi-k3`. It lists 1,204 input tokens, of which 896 were cached, and 312 output tokens. These are example values from that page, not a measurement of your workload.
Kimi K3 costs $3.00 per 1M input tokens, $0.75 per 1M cached input tokens and $15.00 per 1M output tokens. At Kimi K3 prices read on 23 October 2026, the example request costs about $0.0063:
uncached = 1204 - 896 # 308 input tokens read in full
cost = (uncached * 3.00 + 896 * 0.75 + 312 * 15.00) / 1_000_000
print(round(cost, 4)) # 0.0063 US dollarsThe record is enough to reconcile your bill, and it holds no prompt text. Evidence of location comes from the contract and our published locations, so keep them together.
Questions to ask a provider before you sign
Seven questions turn a region claim into terms you can check.
- In which countries are the GPUs that run my model, for each service I use?
- How will you tell me before that location changes?
- Where do the people who can access my usage records and logs work?
- Which subprocessors apply to my service, in which countries, and on what transfer basis?
- How long do I have to object to a new subprocessor?
- Does the DPA let me give written instructions on transfers and audit you?
- What is kept after a request, and for how long?
If every answer matches your customer's sheet, sign and keep the answers with the contract. Does the sheet name a country outside our published locations? Then book a call with our engineers and bring the sheet, before you commit to a customer date.