EU / European Union / revised 28 Oct 2026
France HDS: Hosting Health Data for AI Inference
Any organisation that hosts personal health data collected in France for prevention, diagnosis, care or social follow-up on behalf of someone else must hold HDS certification. Since the 2024 referential, certified hosting sites must be physically located in the European Economic Area, which makes the location of an AI inference provider a certification question, not only a GDPR one.
- Citation
- Code de la santé publique, Article L.1111-8 and Articles R.1111-8-8 et seq.; HDS certification referential v2.0 (arrêté of 26 April 2024)
- Regulator
- Agence du Numérique en Santé (ANS), accredited certification bodies under COFRAC, and the CNIL for GDPR matters
- In force
- HDS referential v2.0 published 16 May 2024; transition for existing certificates ended 16 May 2026
- Maximum penalty
- Hosting health data without the required certification is a criminal offence under Article L.1115-1 of the Code de la santé publique; GDPR breaches carry fines up to EUR 20 million or 4% of worldwide annual turnover
Who needs HDS certification
Article L.1111-8 of the Code de la santé publique requires any person who hosts personal health data on behalf of the natural or legal persons at the origin of their production or collection, or on behalf of the patient, to be certified when the hosting is digital. The certification covers six activities, from providing and maintaining the physical sites (activities 1 and 2) to administering and operating the information system (activities 5 and 6). A provider that only offers a compute service without hosting the data may fall outside, but an inference provider that holds prompts in memory, caches them or logs them on behalf of a hospital or a digital health company is in scope analysis territory.
The 2024 referential and EEA hosting
The HDS certification referential v2.0, adopted by arrêté of 26 April 2024 and published on 16 May 2024, added data sovereignty requirements. The physical hosting of health data must be located in the EEA, and the requirement extends to the host's subcontractors. Hosts must also disclose to their customers any transfer risk arising from extra-EEA legislation applicable to them or their subcontractors and publish a map of transfers.
Existing certificate holders had 24 months to move to v2.0, so since 16 May 2026 every valid HDS certificate attests to the v2.0 requirements.
Interaction with GDPR
HDS sits on top of the GDPR; it does not replace it. Health data is a special category under Article 9, so you still need an Article 9(2) condition, a DPIA under Article 35 for large-scale processing, and a Chapter V transfer mechanism if any access happens from outside the EEA. The CNIL remains the supervisory authority for those questions.
- 01
Certified hosting for every component that touches data
Map each hop: the gateway, the pseudonymisation vault, the model runtime, and any provider-side abuse monitoring store. Each one that hosts health data on your behalf needs to be HDS-certified or to sit inside a certified host's perimeter. - 02
EEA-only physical location, including subcontractors
A model provider's EU region is not enough if its abuse-monitoring logs or support tooling stores prompts elsewhere. Ask for the subcontractor list and the transfer map the 2024 referential requires. - 03
Zero retention at the inference layer
Prompts held only in memory and discarded after the response shrink the hosting footprint. Confirm the provider's zero data retention setting is contractual and applies to your tenant, not just a default. - 04
Pseudonymise before the model sees the text
Replace the NIR, names and dates of birth with tokens held in a vault inside your certified perimeter. The model receives pseudonymised data, which is still personal data under GDPR, so this reduces exposure rather than removing HDS scope. - 05
Remote access controls
Administrative access from outside the EEA by a provider's support staff raises the same questions as storage. Restrict privileged access to EEA-based operators and log it.
| # | Rule | Legal rationale |
|---|---|---|
| 01 | Route requests tagged with French health data only to endpoints whose host and subcontractors appear on the customer's HDS register. | Certification attaches to the host and site. An endpoint not on the register is an uncertified host regardless of where it sits. |
| 02 | Restrict failover to EEA facilities (for example Paris to Frankfurt or Amsterdam). | The 2024 referential requires physical hosting in the EEA. A failover that leaves the EEA breaches it during an incident, exactly when audits look hardest. |
| 03 | Mask NIR numbers, patient names and dates of birth in-path before forwarding. | Data minimisation under GDPR Article 5(1)(c) and a smaller blast radius if a downstream component is misconfigured. |
| 04 | Block any provider whose zero data retention flag is false for the tenant. | Provider-side retention turns a transient compute call into hosting, pulling the provider into HDS scope. |
fr-hds-health
The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.
Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.
How the policy engine workspackage yttsecunet.policies.fr_hds_health
import rego.v1
default allow := false
eea_regions := {"eu-west-3", "eu-central-1", "eu-west-1", "eu-north-1"}
allow if {
input.request.data_class == "health_fr"
input.route.provider_region in eea_regions
input.route.host_id in data.hds_register.certified_hosts
input.route.zdr == true
input.guardrail.nir_masked
}
allow if {
input.request.data_class != "health_fr"
input.route.provider_region in eea_regions
}
reasons contains "host not HDS certified" if {
not input.route.host_id in data.hds_register.certified_hosts
}Each item is verifiable against configuration, signed receipts or contract records. Tick through it with your DPO.
Is an LLM API provider a health data host?
It depends on what it does with the data. A provider that stores prompts, logs or embeddings on your behalf is likely hosting; one that processes transiently with contractual zero retention has a stronger argument that it is not. Get a written position from your counsel and the provider.
Does pseudonymisation take us out of HDS scope?
Generally no. Pseudonymised health data is still personal health data. Anonymised data that cannot be re-identified falls outside, but free-text clinical prompts are hard to anonymise reliably.
Is YTT Secunet HDS-certified?
YTT Secunet's certifications are SOC 2 Type II, ISO 27001 and ISO 27701. For HDS workloads, customers deploy Sovereign Dedicated inside their own certified host or route through a certified host's endpoints, and YTT Secunet's policy and proof layer enforces and evidences that routing.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.