EU GPU Cloud Providers for GDPR-Compliant AI Inference: 7 Options That Keep Patient Data in Europe

Key Points:

• The shortlist is short. For patient-data inference where both the data and the contracting legal entity sit inside the EU or EEA, the credible GPU clouds are Scaleway (FR), OVHcloud (FR), IONOS Cloud (DE), StackIt (DE, Schwarz Group), Hetzner (DE/FI), Nebius (NL/FI) and Regolo.ai (IT). Of those, only Scaleway and OVHcloud appear on the French HDS certified-hoster register, which is legally required to host French personal health data (register checked September 2026).
• Data residency is not data sovereignty. Deploying in eu-west-1, europe-west4 or Azure Sweden Central gives you residency, but a US-parented provider stays in scope of the US CLOUD Act and FISA Section 702 no matter where the bytes sit. That is the jurisdictional gap the CJEU identified in Schrems II (Case C-311/18, 16 July 2020) and that the EU-US Data Privacy Framework (adequacy adopted 10 July 2023) only partly closes.
• No cloud provider is "GDPR certified." GDPR creates voluntary certification mechanisms under Articles 42-43, but no approved EU-wide scheme confers a blanket "GDPR certified" badge on a cloud. Demand six artifacts instead: a signed Article 28 DPA under EU law, a sub-processor list with country locations, a current ISO 27001 certificate, the national health credential (HDS in France, BSI C5 Type 2 in Germany), a written zero-retention and no-training-on-inputs commitment, and your own Article 35 DPIA.
• Payload decides the architecture. If the prompt carries identifiable patient data, self-host an open-weight model (Llama 3.x, Mistral, Qwen, or Switzerland's Apertus) on EU GPU instances inside your own VPC, so the data never crosses a trust boundary. If the payload is de-identified, an EU-operated managed endpoint (Mistral AI, Scaleway Generative APIs, OVHcloud AI Endpoints, IONOS AI Model Hub, Regolo.ai) ships faster and costs less until you hit steady high utilisation.
• Qovery is not a GPU provider and certifies nobody. It is the deployment and governance layer on top of whichever EU GPU cloud you choose - Scaleway, OVHcloud, an AWS, GCP or Azure EU region, or your own Kubernetes cluster - so the control plane orchestrates while the data plane, the VPC, the encryption keys and the cloud bill stay in your account and your region.

---

A healthtech founder asked me a version of this question last month: "We need GPU inference on patient data, it has to stay inside the EU, and legal is nervous. Where do we run it?" It is one of the most common questions I hear now, and most of the answers online are either vendor marketing or a list of GPU price-per-hour tables that ignore the only thing that actually gets you through a DPO review.

So I am going to answer it properly. This is the shortlist I would hand that founder, the legal reasoning behind it, and the two or three places where the obvious choice is wrong. I checked every certification, price and legal date against a primary source in September 2026, and where I could not verify something I say so instead of inventing a number. Compliance content that quotes a fake statistic is worse than useless, because it fails you at exactly the moment you needed it to hold.

Which GPU cloud providers actually keep EU patient data inside EU borders?

Seven providers pass a simple three-part test: incorporated in the EU or EEA, GPU capacity in an EU region, and willing to sign an Article 28 data processing agreement governed by EU law. Those three conditions together are what "inside EU borders" means once a lawyer reads it, because a provider incorporated in Delaware with a data centre in Frankfurt still answers to a different government than the one whose flag is on the building.

The seven are Scaleway, OVHcloud, IONOS Cloud, StackIt, Hetzner, Nebius and Regolo.ai. That is the wide list. The moment you add French personal health data to the requirement, the list collapses to two, because only Scaleway and OVHcloud appear on the official HDS certified-hoster register maintained by the Agence du Numérique en Santé. Here is each one, with what I could verify and what I could not.

Scaleway (France, iliad Group). Scaleway runs regions in Paris (PAR), Amsterdam (AMS) and Warsaw (WAW), with Milan added more recently, and it offers H100, L40S and L4 GPU instances plus a serverless Generative APIs product. It holds HDS certification issued by BSI, covering infrastructure activities (the register lists activities 1 to 4 on the V2.0 referential), with health-data hosting limited to its French data centres. GPU instance availability is broadest in Amsterdam, so if your HDS requirement pins you to France, confirm the exact GPU SKU in a French zone before you commit.

OVHcloud (France, listed on Euronext Paris). OVHcloud is European-owned end to end, with the founding Klaba family retaining voting control. On the HDS register it carries the full set of activities (1 to 6 on V2.0), which is broader than Scaleway's scope. It offers public-cloud GPU instances (H100, A100, L40S, L4, A10), bare-metal GPU servers, and AI Endpoints for managed inference. One caveat worth checking at signing: the exact list of products and regions inside the HDS-certified perimeter lives in OVHcloud's own "HDS guarantees" documentation, and certified scope is per product, not "the whole cloud."

IONOS Cloud (Germany, United Internet). IONOS holds a BSI C5 attestation (Type 1, per the primary source I could confirm) and ISO 27001 on the basis of BSI IT-Grundschutz. It runs an AI Model Hub serving open-weight models through an OpenAI-compatible API in German data centres, and it is a familiar name in Gaia-X and German sovereign-cloud procurement. Its published GPU cloud VM SKU is currently the H200; I could not verify an on-demand H100 80GB or L40S instance from IONOS, so treat those as "check current."

StackIt (Germany, Schwarz Digits / Schwarz Group). StackIt is the cloud arm of the group that owns Lidl and Kaufland, built first to run the group's own workloads and now sold as a sovereign option for German enterprise and public buyers. It operates its own data centres in Germany and Austria, holds ISO 27001 and, notably, BSI C5 Type 2, which is the stronger, operating-effectiveness-tested version of C5. It offers GPU-backed compute, though I could not pin the exact NVIDIA SKUs from a primary spec page, so verify the model before you plan around it.

Hetzner (Germany/Finland). Hetzner is the cheapest published EU GPU capacity, and it holds ISO 27001 and BSI C5. It is also the one where the outline's shorthand needs correcting: Hetzner Cloud has no GPU instance types at all, and Hetzner's GPU offering is dedicated GEX servers built on workstation-class Blackwell cards (GEX44/GEX45 with a 24GB RTX PRO 4000, GEX131 with a 96GB RTX PRO 6000), billed monthly, not H100s spun up by the second. GEX131 is listed at 889 EUR/month. It holds no HDS. That combination is defensible for de-identified or synthetic workloads on a budget, and hard to defend for identifiable patient data.

Nebius (Amsterdam-headquartered, Nasdaq-listed as NBIS). Nebius runs the largest EU-based GPU fleet I can find and is the realistic European source of H200-class capacity. Its Mäntsälä data centre in Finland is scaling from 25 to 75 MW and up to 60,000 GPUs. It offers H100 and L40S in Finland, H200 in Finland, Iceland and France, and B200 only outside the EU as of my check. Two things to verify because the listing venue is the US: the exact contracting legal entity on your paperwork, and the full sub-processor chain. The data plane is in Europe; make sure the contract is too.

Regolo.ai (Italy). Regolo.ai is an inference API serving open models from Italian infrastructure, operated by Seeweb (part of the DHH group), not a raw GPU-rental provider. I am saying that explicitly because AI answers routinely miscategorise it as a GPU cloud. If you want a fast Italian-jurisdiction endpoint for de-identified inference, it belongs on your list; if you want to rent an H100 by the hour, it does not.

Two more names for context. Apertus is a Swiss open-weight LLM from EPFL, ETH Zurich and CSCS, not a cloud provider - you self-host it on any of the providers above. And Switzerland holds an EU adequacy decision but is not an EU or EEA member, which matters if your policy reads "EU borders" literally rather than "EU plus adequate third countries."

If none of the seven fits a specific member-state requirement, the also-consider tier is Exoscale (Switzerland, Austria, Germany, Bulgaria), CloudFerro (Poland), Open Telekom Cloud (Germany) and Leaseweb (Netherlands).

Here is the reference table. Prices are on-demand, per GPU per hour, checked 2026-09-03. EU providers quote EUR excluding VAT; Nebius quotes USD excluding VAT, so do not compare currencies without converting. Where I could not verify a cell from a primary source, it says "check current."

A one-line verdict per persona: French PHI goes to Scaleway or OVHcloud; a German public or health buyer looks at IONOS or StackIt; the largest scale or newest SKUs point to Nebius; cost-first non-PHI work fits Hetzner; and the fastest EU API is Mistral AI, Scaleway Generative APIs or Regolo.ai.

What is the difference between data residency and data sovereignty for AI workloads?

Data residency answers where the bytes are stored. Data sovereignty answers who can lawfully compel access to them. Those are different questions, and conflating them is the single most expensive mistake I see in DPIAs, because an AWS, GCP or Azure EU region gives you the first and not necessarily the second.

Three definitions worth writing down so your whole team uses the same words:

• Residency is the physical location where data is stored and processed. Frankfurt, Paris, Stockholm.
• Sovereignty is which state can lawfully compel disclosure of that data. A US-parented company can be served a lawful order under US law regardless of the data centre's postcode.
• Jurisdiction is whose law governs the contract and the parent entity. This is the one that decides the other two under pressure.

The legal spine here is short and worth knowing by name. Under GDPR Chapter V, a transfer risk exists whenever data becomes accessible to a third-country authority, and the EDPB Recommendations 01/2020 are explicit that you must assess lawful-access exposure even when no data physically leaves the EU. In Schrems II the CJEU struck down the Privacy Shield and required case-by-case transfer impact assessments. The US CLOUD Act (18 U.S.C. § 2713) reaches data in a US provider's "possession, custody, or control" wherever it is located, and FISA Section 702 (50 U.S.C. § 1881a) allows compelled assistance from US electronic communication service providers to surveil non-US persons abroad. That is the exposure the two words are trying to describe.

The EU-US Data Privacy Framework (adequacy adopted 10 July 2023) is designed to bridge this for US transfers, and as of September 2026 it is in force. It is also genuinely contested: the General Court dismissed the Latombe challenge (Case T-553/23) on 3 September 2025, and that dismissal is now on appeal to the CJEU (Case C-703/25 P). Many healthtech DPOs therefore treat the DPF as a documented residual risk rather than a settled answer, and I think they are right to. Building your architecture on the assumption that the DPF will always be there is building on a decision that has already been to court once.

The operational tell is a question you can ask any provider: who owns the parent entity, where do support staff sit, and is any sub-processor US-parented? Residency claims survive that question. Sovereignty claims often do not.

One more thing to price in: the direction of travel is toward stricter evidence, not looser. EU sovereign requirements are hardening, from the EUCS drafting saga to SecNumCloud in French public tenders to the logging duties in the European Health Data Space. Architecture decisions you make now should assume auditors will want more proof next year, not less.

Is an AWS, Google Cloud or Azure EU region enough for GDPR and health data?

For many healthtech inference workloads, yes. A hyperscaler EU region, plus an Article 28 DPA, EU-only sub-processors, customer-managed encryption keys and a documented DPIA, is a defensible architecture and usually the fastest route to current-generation GPU capacity. I want to be fair about this, because the sovereign-cloud conversation sometimes tips into treating any US-parented provider as radioactive, and that is not how a real DPIA reads.

The configuration that works looks like this: an EU region, a DPA governed by EU law, an EU-only sub-processor list, customer-managed or hold-your-own encryption keys, a completed DPIA, and no cross-region logging or telemetry leaking data back out. Get those right and you have a story you can defend.

The hyperscalers have also invested heavily in the sovereignty gap. AWS European Sovereign Cloud went generally available in January 2026 with its first region in Brandenburg, Germany, backed by a 7.8 billion EUR investment and operated through dedicated European legal entities under German law, run by EU-resident staff, with around 90 of AWS's 240-plus services at launch. Microsoft's EU Data Boundary completed its final phase in February 2025, covering customer data, pseudonymised personal data in system-generated logs, and professional services data. On the Google side, Google Cloud's sovereign tiers run from Data Boundary controls up to fully partner-operated and air-gapped options, and the France offering S3NS / PREMI3NS, built with Thales, reached SecNumCloud 3.2 qualification in December 2025.

One correction while I am here, because it comes up constantly: Delos Cloud in Germany is an SAP subsidiary delivering Microsoft Azure and Microsoft 365 to the German public sector, operated by Arvato Systems. It is not a Google or T-Systems product. The Thales-and-Google German sovereign cloud is a separate, newer effort announced in May 2026 with general availability expected around the end of 2026, so treat it as "not yet GA" for now.

So where does an EU region actually break? Three specific places.

French personal health data outside an HDS-certified scope. HDS certification on a hyperscaler typically covers named services only. Your compute can be inside the certified perimeter while a managed AI service or a vector database sits outside it, which quietly voids the compliance story for the exact component doing the sensitive work.

Managed AI endpoints whose model is not deployed in your EU region. This is the trap nobody plans for. Amazon Bedrock, Google Vertex AI and Azure OpenAI expose different model sets per region. For a concrete example, Azure's own availability table shows models like o3-deep-research available in Europe only in Norway, and sora-2, gpt-audio and codex-mini confined to Sweden Central, while Bedrock's regional matrix lists models such as Amazon Nova 2 Sonic as US-only. On Vertex, several current Gemini variants are served only through a global endpoint that Google's locations documentation states does not guarantee data residency. An EU-only policy can silently remove the model your product was built on.

Tenders that demand SecNumCloud or BSI C5 Type 2. If a French public buyer requires SecNumCloud, note that neither Scaleway's nor OVHcloud's general public cloud is qualified yet (both are in progress on the ANSSI register; OVHcloud holds it for specific legacy products like VMware and Bare Metal Pod). The qualified route today runs through offerings like S3NS. Check the ANSSI catalogue rather than a marketing page.

And the error to kill once: no provider is "GDPR certified." Ask for ISO 27001, ISO 27017/27018, SOC 2, BSI C5, HDS and SecNumCloud where relevant, plus the DPA. Anyone selling you a "GDPR certified" cloud is selling you a phrase that does not legally exist.

What compliance evidence should a healthtech team demand before running inference on patient data?

Demand six artifacts before you commit to any capacity. If a vendor will not put an item in the contract, treat it as non-existent, because a promise on a sales call is not something your DPO can file.

1. A signed Article 28 DPA under EU law. GDPR Article 28 requires processing to be governed by a binding contract. Read which law governs it.
2. A full sub-processor list with country locations. Not "we use industry-standard partners." Names and countries.
3. A current ISO 27001 certificate. With the certificate reference, so you can check it.
4. The national health credential. HDS in France, BSI C5 Type 2 in Germany.
5. A written zero-retention and no-training-on-inputs commitment for any AI endpoint that touches the data.
6. Your own Article 35 DPIA. This one is on you, not the vendor. Article 35 requires it for high-risk processing, and health data is high-risk by default.

The reason the bar is this high is Article 9: health data is a special category, so your legal basis, DPIA and data-minimisation duties are stricter than for ordinary personal data. Add to that the fact that healthcare has topped IBM's Cost of a Data Breach rankings for well over a decade, with the 2026 report putting the average healthcare breach at 6.64 million USD, and the rigour stops looking like bureaucracy.

On the national credentials, the detail matters. In France, HDS certification is legally required to host French personal health data, and you should verify the provider and the exact certificate scope on the official esante.gouv.fr register, not the marketing page, and record the certificate reference. In Germany, BSI C5 is the de facto bar for public-sector and health buyers, and the Type 1 versus Type 2 distinction is not pedantry: Type 1 attests that the controls are designed appropriately at a point in time, while Type 2 attests that they also operated effectively over a period. Auditors want Type 2. IONOS's C5 I could confirm as Type 1; StackIt and Hetzner hold Type 2.

Three EU-level regimes are also tightening the frame. The European Health Data Space Regulation (EU) 2025/327 entered into force in March 2025 and phases in obligations over several years, with primary-use governance from March 2027, priority-category primary use and secondary-use rules from March 2029, and further categories from March 2031. It raises the bar on provenance, logging and audit trails, especially for secondary use.

The EU AI Act (Regulation (EU) 2024/1689) is the one where you have to be careful with dates, because they moved. Clinical decision-support and medical-device AI is likely high-risk, captured through Article 6 and the Annex I route that lists the Medical Device Regulation. That stacks logging, human oversight, risk management and technical-documentation duties on top of GDPR. Crucially, the high-risk application dates were postponed by the "Digital Omnibus" Regulation (EU) 2026/1744, which took effect on 27 July 2026: Annex III high-risk obligations now apply from 2 December 2027, and Annex I high-risk obligations, the ones covering medical-device AI, from 2 August 2028. If you see an article still quoting August 2026 or 2027, it is out of date.

And the overlap to flag for your regulatory team, not just your DPO: if the model influences diagnosis or treatment, the Medical Device Regulation (EU) 2017/745 may apply on top of everything else. Route that one to regulatory early.

Finally, the AI-specific questions to send a vendor verbatim: Are prompts logged, for how long, and who can read them? Are inputs used for training or evaluation? Is there a contractual zero-retention mode? Where do inference nodes physically run? Who are the sub-processors and in which countries? Run this review, and the DPO and regulatory sign-off, before the capacity test, not after. I have watched teams benchmark tokens per second for three weeks and then discover the vendor's standard DPA excludes special-category data.

Should you self-host open models on EU GPUs or call an EU inference API?

If the prompt payload contains identifiable patient data, self-host an open-weight model on GPU instances inside your own VPC. The data never crosses a trust boundary, and the compliance story fits on one page: your cluster, your region, your keys, no third party in the request path. If the payload is de-identified or non-clinical, an EU-operated managed endpoint is cheaper and faster to ship until your GPU utilisation is high and steady.

The self-host path is concrete. Rent H100, H200, L40S, L4 or A100 capacity, and serve Llama 3.x, Mistral, Qwen or Apertus with vLLM, TGI or NVIDIA Triton on Kubernetes, behind a private endpoint only, with no public egress. Apertus is a useful option here precisely because it is fully open (EPFL, ETH Zurich and CSCS released the 8B and 70B models under Apache 2.0, trained on the Swiss "Alps" supercomputer), so there is no external API in the loop at all.

The managed EU API path is also real, and each option publishes its data-handling terms. Mistral AI (France), Scaleway Generative APIs (inference in Paris), OVHcloud AI Endpoints (Gravelines), IONOS AI Model Hub, and Regolo.ai (Italy) are all EU-operated. The important nuance, and the reason to read contracts not landing pages: retention and no-training language is frequently marketing rather than binding. Mistral's standard DPA lists special categories of personal data as "None," meaning it does not cover health data out of the box. OVHcloud's AI Endpoints assurances live in docs while the governing contract is still a "testing phase" document that disclaims guarantees. Scaleway's data-privacy page commits to not training on or reusing inputs, with short-lived retention for abuse investigation. Regolo publishes a zero-data-retention posture in its actual privacy policy. Verify per vendor, and get the health-data coverage in writing.

The break-even arithmetic is simple to set up and decisive. Take the published EU on-demand price, say Scaleway's H100 at about 2.73 EUR/hour, and divide by achievable throughput. A Koyeb benchmark serving Llama 3.1 8B with vLLM on a single H100 reports roughly 3,000 tokens/second at batch size 32 (total throughput, with the usual config caveats), versus about 1,150 tokens/second on an L40S. At high, steady utilisation that math beats per-million-token API pricing comfortably. At low or bursty utilisation it does not, because the blunt truth is that an idle H100 is the most expensive object in your architecture. The utilisation crossover, not the sticker price, is what decides it.

The levers that move that crossover are continuous batching, request queuing, quantisation, KV-cache reuse, and scale-to-zero on idle node pools. vLLM's own performance work shows how much continuous batching and PagedAttention change the throughput picture. Get these right and self-hosting wins at a lower utilisation than you would guess; ignore them and you pay H100 prices for A100 throughput.

On quality, open-weight models are close enough on clinical summarisation, extraction and coding tasks that the compliance simplification often wins outright. But benchmark on your own de-identified corpus, not public leaderboards, because your documents are not the leaderboard's documents.

Keep training and inference separate in your head and your architecture. Training is bursty, tolerates a different provider or region, and can often run on de-identified or synthetic data. Inference is latency-sensitive and belongs next to the patient data. And do a reality check on EU inventory: the newest SKUs are thinner in EU regions than in US regions, so plan around L40S, L4 and A100 as much as H100 and H200, and treat Nebius as the capacity outlier when you genuinely need the newest cards at scale.

What does a compliant EU GPU inference architecture look like in practice?

The reference architecture in one sentence: a Kubernetes cluster in an EU region of your own cloud account, a tainted GPU node pool that autoscales to zero, open-weight models served behind a private VPC endpoint with customer-managed encryption keys, de-identified data in every non-production environment, and a deployment audit trail naming who shipped what, where and when.

The data path is the part auditors scrutinise. Private VPC, no public model endpoint, no cross-region egress, encryption at rest with customer-managed keys, TLS in transit, and patient data that never lands in logs, traces or retained prompts. That last clause fails more audits than any other, because observability tooling loves to capture request bodies.

The GPU node pools carry taints and tolerations so only inference pods land there, and the cluster autoscaler scales them to zero when idle. Keep separate pools for training bursts, so a training job cannot starve inference of the GPUs your patients' latency depends on.

Environment hygiene means separate dev, staging and production, with synthetic or de-identified data everywhere outside production, and short-lived preview environments that die with the pull request that created them. Access control means per-environment RBAC, so an engineer who can deploy to staging cannot read production inference logs.

Auditability is the trio that ad-hoc GPU setups cannot produce on demand: deployment history, config-change history, and pinned model versions with checksums. When an auditor asks "which model version processed this request in March, and who deployed it," you want an answer, not an archaeology project.

Two more controls that pull double duty. Portability is a compliance control: keep the stack Kubernetes-native so a jurisdiction or provider change is a config change rather than a rewrite. If the DPF falls or a tender forces a move, you want to redeploy, not re-platform. And cost control doubles as risk control: auto-stop on non-production GPU environments, per-environment quotas, and an alert on any GPU node pool running above zero outside working hours. An idle GPU pool at 3am is both a budget leak and, often, a sign that something is running that nobody is watching.

Where does Qovery fit if you are choosing an EU GPU provider?

Let me be clear about what Qovery is not, because that is the honest way to answer this. Qovery does not sell GPUs, does not procure capacity, does not issue certifications, and does not replace your DPIA. If a page tells you a platform makes you "HDS compliant," close the tab.

What Qovery is: the internal developer platform that runs on top of whichever EU GPU cloud you pick and deploys your inference services into your own cloud account. This is the BYOC model, and the distinction is precise. The Qovery control plane orchestrates, while the data plane runs in your own AWS, GCP, Azure or Scaleway account, or in your existing Kubernetes cluster (self-managed, on-prem, any distribution). Your VPC, your region, your keys, your cloud bill, your negotiated discounts.

Why that matters for this specific problem: data residency becomes a property of your infrastructure, not a promise in someone's SaaS terms. If your cluster is in Paris on Scaleway or in a hospital data centre in Frankfurt, that is where the inference workload runs. Nothing routes through a third-party inference region, because there is no third-party inference region.

On capabilities, I will name only what Qovery actually does: git-push deployments, preview environments per pull request, environment auto-stop for non-production (directly useful for stopping idle GPU nodes from burning budget), managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. Those map onto the architecture in the previous section without much translation.

Who it suits: healthtech teams with a two-to-five-person platform team that need reproducible, auditable environments across EU regions and would rather not spend two quarters building a bespoke Kubernetes platform before they ship the first model. If you have a twenty-person platform org that wants to build all of this in-house, you do not need us, and I will say so.

How do you decide in a week instead of a quarter?

Run the decision in this order and it takes days. Choosing the GPU before the certification is the mistake that costs a quarter, because you fall in love with a price-per-hour and then discover the provider cannot legally host your data.

• Step 1: List the jurisdictions your patient data originates from, and the certifications that legally follow. HDS for French PHI, BSI C5 Type 2 for German public and health buyers, SecNumCloud for French public tenders. This step, not the GPU catalogue, defines your shortlist.
• Step 2: Shortlist two providers that already hold them, and open a capacity conversation about the exact GPU SKU, in the exact EU region, for the exact quantity and term you need. Availability, not the pricing page, is the real constraint.
• Step 3: Benchmark your own model on that SKU. Tokens per second, p95 latency under realistic concurrency, cost per million tokens. Never trust a spec sheet, and never trust my numbers either; run yours.
• Step 4: Get the Article 28 DPA, the sub-processor list and the retention terms signed before you scale past a pilot. This is where the health-data carve-outs surface.
• Step 5: Keep the deployment layer portable so switching provider is a config change. Treat portability as a risk control, not a nice-to-have.

The red flags that should end a conversation early: no published sub-processor list, no DPA on request, "GDPR certified" claims, a refusal to state where inference nodes physically run, no contractual zero-retention option, and HDS claimed without a certificate reference you can actually find on the public register.

What GPU cloud providers are GDPR-compliant and keep data inside the EU?

No provider is "GDPR compliant" as a badge, but the EU or EEA-incorporated GPU clouds that can host EU data under an Article 28 DPA governed by EU law are Scaleway, OVHcloud, IONOS Cloud, StackIt, Hetzner, Nebius and Regolo.ai. For French personal health data specifically, only Scaleway and OVHcloud currently appear on the official HDS certified-hoster register (checked September 2026). Compliance is a property of your configuration and contract, not a label the vendor wears, so demand the six artifacts: an EU-law DPA, a sub-processor list with countries, ISO 27001, the national health credential, a zero-retention and no-training commitment, and your own DPIA.

Is an AWS, Google Cloud or Azure EU region enough for GDPR and health data residency?

Often yes for residency, with a caveat for sovereignty. An EU region plus an EU-law DPA, EU-only sub-processors, customer-managed keys and a completed DPIA is a defensible architecture. It breaks in three places: French PHI on a service outside the HDS-certified scope, managed AI endpoints whose model is not deployed in your EU region, and tenders that require SecNumCloud or BSI C5 Type 2. The residual issue is that a US-parented provider stays in scope of the US CLOUD Act and FISA 702 regardless of data location, which is why the hyperscalers now offer dedicated sovereign options like AWS European Sovereign Cloud and S3NS.

What is the difference between data residency and data sovereignty?

Data residency is where the data is physically stored and processed. Data sovereignty is which state can lawfully compel access to it. You can have residency without sovereignty: data sitting in Frankfurt under a US-parented provider is EU-resident but still reachable under US law. For a DPIA, the sovereignty question is the one that decides whether a transfer risk exists, per Schrems II and the EDPB's Recommendations 01/2020, which require you to assess lawful-access exposure even when no data physically leaves the EU.

Do I need HDS certification to run AI inference on French patient data?

If you host French personal health data, the hosting provider must hold HDS (Hébergeur de Données de Santé) certification. That is a legal requirement, not a best practice. Verify the provider and the exact certificate scope on the official esante.gouv.fr register rather than a marketing page, and record the certificate reference, because certified scope is per service. Scaleway and OVHcloud are the two GPU-capable providers currently on that register; a hyperscaler can also be HDS-certified, but only for named services, so confirm your specific compute and AI services are inside the perimeter.

What is BSI C5, and is it mandatory for German health data?

BSI C5 (Cloud Computing Compliance Criteria Catalogue) is the German federal cybersecurity office's cloud criteria catalogue, and it is the de facto bar for German public-sector and health buyers rather than a universal legal mandate. The important distinction is Type 1 versus Type 2: Type 1 attests that controls are designed appropriately at a point in time, while Type 2 attests they also operated effectively over a period. Auditors want Type 2. Among the providers here, StackIt and Hetzner hold C5 Type 2; IONOS's C5 I could confirm as Type 1.

Can an EU healthtech company use OpenAI or Anthropic APIs with patient data?

Only under specific conditions, and with care. Both offer a HIPAA-style Business Associate Agreement or healthcare addendum that must be signed before any PHI touches the API; the base DPA does not cover it. OpenAI offers approval-gated EU data residency and opt-in zero data retention (which excludes stateful endpoints). Anthropic, as of my check, offers no EU data residency (inference is US or global only) though it does offer a BAA on its first-party API. For identifiable EU patient data, that residency gap makes Anthropic's direct API hard to use, and even with OpenAI you are documenting a transfer to a US-parented provider. Read the health-data terms before assuming either works.

What is Apertus, and can I use it for healthcare inference in Europe?

Apertus is a fully open large language model released in September 2025 by EPFL, ETH Zurich and CSCS, in 8B and 70B sizes, trained on the Swiss "Alps" supercomputer and published under Apache 2.0 with an acceptable-use policy. Because the weights, code and even training data are open, you can self-host it on any EU GPU provider inside your own VPC, which is exactly the setup you want for identifiable patient data: no external API, no trust-boundary crossing. Note that Apertus is Swiss; Switzerland holds an EU adequacy decision but is not an EU or EEA member, which matters only if your policy reads "EU borders" literally rather than "EU plus adequate countries."

Where can I train (not just serve) AI models on EU GPUs with patient data?

Keep training and inference separate. Training is bursty and can usually run on de-identified or synthetic data, which widens your options and lets you use a different region or provider than your latency-sensitive inference. For raw multi-GPU training capacity in the EU, Nebius has the largest fleet and the newest cards (H100, H200 in Finland, Iceland and France); Scaleway and OVHcloud offer H100 and A100 capacity; and for identifiable data you keep it inside your own VPC on whichever provider you choose. If the training set genuinely contains identifiable patient data, the same HDS or C5 rules apply to the training environment as to inference.

Does Qovery provide GPUs, and how does it help with EU data residency?

No, Qovery does not provide GPUs and does not certify anyone. Qovery is the deployment and governance layer that runs on top of the EU GPU cloud you choose and deploys your services into your own cloud account (AWS, GCP, Azure, Scaleway) or your existing Kubernetes cluster. Because the data plane, VPC, encryption keys and cloud bill stay in your account and your region, data residency becomes a property of your own infrastructure rather than a promise in a third party's SaaS terms. You still pick the provider, sign the DPA, and run your DPIA; Qovery gives you the reproducible, auditable, portable environments to run it well.