EU hosting tells you only where the model runs, not how the provider handles your data. Prefer a provider that states all four answers in a contract or on a public page. Check that before you build on it.
Which EU-hosted LLM API will pass a bank's or insurer's review, including DORA? This guide follows one hypothetical feature: an insurer's claims summary. It reads a claim file of 3,000 tokens and writes a summary of 400 tokens. A token is the unit a model reads and bills by, usually a word or part of a word.
We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland. That gives your customer's reviewer two named locations to write into the contract. Serverless means you call a model through our API and pay per token.
What a bank or insurer needs from its AI supplier
A bank or insurer needs a contract that sets out who does what for each technology service it buys. DORA has applied since 17 January 2025 to banks, insurance companies, investment firms and other financial entities. Its rules on technology providers include key contractual provisions.
In the contract chain, your customer is the financial entity. You are its technology service provider. If you call our API, we sit one level below you. Article 30 says the rights and obligations of both sides are set out in writing. DORA binds your customer. It reaches you through the contract your customer asks you to sign.
Which DORA contract terms reach your inference provider
Article 30 lists terms every technology contract must carry. Three matter first for an LLM API:
- Locations. The contract names the regions or countries where services are provided and data is processed, including storage. The provider must tell the customer in advance if it plans to change them.
- Data access and return. It provides access, recovery and return of data in an easily accessible format when the arrangement ends or the provider fails.
- Subcontracting. It says whether you may hire others to deliver part of the service, and on what conditions. If you call our API, we are one of those others.
Three more terms apply to critical or important functions. DORA defines such a function as one whose disruption would materially impair the customer's financial performance or the soundness or continuity of its services. Your customer decides which of its functions qualify. Ask which label your feature carries.
| Term for critical or important functions | What to ask the provider |
|---|---|
| Full service level descriptions with precise performance targets | Which service levels are in the contract, and which targets are measured? |
| Rights of access, inspection and audit | How can the customer and its supervisor audit you and the provider under you? |
| Exit strategy with an adequate transition period | How long can you keep running while you move to another provider? |
Map where data goes and who can see it
Start with the locations term. Then trace one request. The table shows what we see and keep for your claims summary, as published on our Trust page on 20 October 2026.
| Stop | What we see | What we keep |
|---|---|---|
| Your app sends the request | Nothing yet, the request travels over HTTPS | Nothing |
| Our gateway checks your key | Your API key, the model and your prompt, in memory | A usage record |
| The GPU runs the model | Your prompt, in GPU memory in a European data centre | Recent prompt prefixes, until newer requests replace them |
| The answer returns | The response, as it streams back | The output token count, added to the usage record |
Prompts and outputs are processed, not stored, and never used for training. The usage record holds your organisation and user, the model, token counts and the time. We never log prompt text. So the row for us on your data map has no stored prompts, no training use and one in-memory cache.
The GPU row matters for your data map. A prompt prefix is the start of your prompt, kept so repeated prompts are cheaper to process. It stays in GPU memory, not on disk, until newer requests replace it. Ask every provider the same question about caches and logs.
Next, the subprocessors. Ours are mainly in the EU and the European Economic Area (the EU plus Iceland, Liechtenstein and Norway). The full list is available by email, and we name no individual subprocessor here. Anything outside that area is covered by GDPR safeguards, such as standard contractual clauses, the EU's model contract terms for data transfers. We tell you before we add or replace one, and you can object within 10 business days. That gives your customer written terms on locations and subprocessors, ready to pass to its reviewer.
Check audit, service levels and exit before you sign
DORA gives the customer and its supervisor audit rights for critical or important functions. Our data processing agreement (DPA), the contract part that governs personal data, is Annex 1 of our terms and applies when you accept them. Under the DPA you can instruct us in writing and audit us with notice. That covers you auditing us. DORA's audit right is your customer's over you, so ask its lawyers whether the DPA is enough for the chain. It also obliges us to tell you immediately about any breach involving your personal data.
Your customer and its lawyers decide whether those terms satisfy Article 30.
Service levels come next. Our status page shows live status. Business customers also get a direct line to the engineers who run the platform, with contractual response times. Ask for the response times and targets in writing, as Article 30 expects for critical or important functions.
When you leave, you choose whether we delete or return your account data and usage records. We never stored your prompts, so there is nothing of them to return. Moving the workload is a technical task. Our serverless models run behind one OpenAI-compatible API (the same request format as OpenAI's). Your code then points at a different base URL and model ID. Your exit plan then rests on a test you have run, not on a promise.
Reviewers will also ask about certification. ISO 27001 is a standard for managing information security. Our ISO 27001:2022 audit is in progress. Read that as work in progress, not as a certificate.
Run a portable pilot and keep the evidence
Use synthetic or properly anonymised claim files for the pilot. The calculation below is hypothetical: 500 files of 3,000 input tokens and a 400-token summary each. It uses the price of the MiniMax M3 model from our models page, read on 20 October 2026. Input costs $0.40 per million tokens and output $2.00.
pilot = 500 claim files
input tokens = 500 x 3,000 = 1,500,000
output tokens = 500 x 400 = 200,000
input cost = 1,500,000 / 1,000,000 x $0.40 = $0.60
output cost = 200,000 / 1,000,000 x $2.00 = $0.40
total = $1.00Calculated example from hypothetical inputs. It uses the full input price, with no discount for cached prompt prefixes. It shows that a pilot costs about a dollar in tokens. It does not show whether the summaries are right, what review time costs or whether a regulator accepts your exit test.
Repeat the 500 files on a second model: that is your exit test. Then collect the evidence your customer will want:
- The contract or terms with locations, subcontracting and subprocessor conditions.
- The DPA, and the breach-notice and audit terms inside it.
- A dated copy of the provider's Trust page and models page.
- The pilot results from both models, with their token costs.
- The service levels you agreed in writing.
To review a deployment against your customer's requirements, bring them to our compliance team through our Trust page.