Le triptyque réglementaire : AI Act, RGPD-S et HDS au service de la confiance médicale

L'IA transforme aujourd'hui le parcours de soins, du tri aux urgences à la lecture d'imagerie en passant par la prédiction de réhospitalisation. Chacun de ces usages mobilise des données dont la sensibilité est maximale au sens de l'article 9 du RGPD. Or, contrairement à une croyance encore répandue, aucun de ces trois cadres ne se substitue à un autre : ils se complètent.

Le RGPD-S régit la donnée personnelle de santé : licéité du traitement, minimisation, droits des personnes, analyse d'impact (PIA). La certification HDS, ancrée dans les articles R1111-8-8 et R1111-9 du Code de la santé publique, encadre l'hébergeur physique et logique. L'AI Act, lui, ne s'intéresse ni au stockage ni à la donnée brute : il vise le système algorithmique lui-même — sa robustesse, sa transparence, sa supervision humaine, sa documentation.

J'ai accompagné récemment un éditeur de logiciels d'aide à la décision oncologique qui pensait être conforme parce que son cloud était certifié HDS. C'était vrai pour l'infrastructure, mais l'absence de système de gestion des risques au sens de l'article 9 de l'AI Act rendait son produit inutilisable sur le marché européen post-août 2026. Ce sont trois métiers, trois équipes, trois livrables documentaires — mais une seule architecture cible. La doctrine GNIUS publiée par l'Agence du Numérique en Santé confirme cette lecture : le RGPD et l'AI Act se cumulent dès qu'un système haut risque traite des données personnelles.

Classification AI Act : pourquoi les données de santé sont au cœur du régime haut risque

Le Règlement (UE) 2024/1689 organise les systèmes d'IA en quatre niveaux de risque : inacceptable (interdit), haut risque (encadré), risque limité (transparence) et risque minimal (libre). La santé concentre l'essentiel du haut risque.

Deux portes d'entrée existent vers ce régime. L'Annexe I liste les législations sectorielles préexistantes dont relèvent les dispositifs médicaux (Règlement (UE) 2017/745 — MDR) et les dispositifs médicaux de diagnostic in vitro (Règlement (UE) 2017/746 — IVDR). Tout logiciel marqué CE en classe IIa, IIb ou III bascule automatiquement en haut risque AI Act. L'Annexe III vise des usages spécifiques : triage médical, accès aux services de santé essentiels, IA RH appliquée au recrutement de soignants, ou systèmes biométriques utilisés en milieu hospitalier.

Concrètement, un logiciel de détection de mélanomes, une IA de priorisation aux urgences ou un outil d'aide à la prescription tombent dans le haut risque. Les obligations associées sont denses : système de gestion des risques (article 9), gouvernance et qualité des données d'entraînement (article 10), documentation technique (article 11), journalisation (article 12), transparence vis-à-vis de l'utilisateur (article 13), supervision humaine effective (article 14), robustesse, exactitude et cybersécurité (article 15).

Je rappelle systématiquement à mes clients que ces obligations ne sont pas optionnelles. Pour un usage très ciblé — par exemple un guide synthétique de la classification haut risque appliquée à la santé — je renvoie vers la doctrine Regulia sur les systèmes haut risque, qui détaille l'annexe III et la FRIA (Fundamental Rights Impact Assessment) introduite à l'article 27. Le calendrier, révisé par l'accord « omnibus numérique » du 7 mai 2026 : 2 décembre 2027 pour l'Annexe III, 2 août 2028 pour l'Annexe I.

La certification HDS : le socle de sécurité pour l'entraînement des modèles d'IA

La certification HDS — Hébergeur de Données de Santé — est française et obligatoire dès qu'un tiers héberge des données personnelles de santé pour le compte d'un responsable de traitement. Elle est encadrée par les articles L1111-8 et R1111-8-8 du Code de la santé publique et le référentiel HDS publié par l'ANS (Agence du Numérique en Santé).

Selon les chiffres officiels publiés par esante.gouv.fr, on compte 411 hébergeurs certifiés HDS en mai 2026 et 10 organismes de certification habilités. La certification couvre six activités : mise à disposition de sites physiques, infrastructure matérielle, infrastructure virtuelle, plateforme applicative, administration/exploitation du SI et sauvegarde des données.

Pour une IA, cette certification n'est pas un détail. Trois moments du cycle de vie d'un modèle exigent un environnement HDS :

  • L'entraînement : les jeux de données labellisés (imagerie, dossiers patients, comptes rendus opératoires) sont des données personnelles de santé, même pseudonymisées dans la majorité des cas.
  • L'inférence : les requêtes utilisateur contiennent des données de santé en clair (description clinique, valeurs biologiques).
  • La journalisation et le réapprentissage continu (fine-tuning, RLHF) : tout journal contenant un prompt patient est lui-même donnée de santé.

Le pont avec l'AI Act se fait à l'article 10 du Règlement (UE) 2024/1689 sur la gouvernance des données : qualité, représentativité, traçabilité, examen des biais. Or, on ne peut pas auditer la qualité d'un dataset stocké dans une infrastructure non auditée. C'est précisément pour cela que notre méthode IAPRO consiste à déployer une stack Ollama + OpenWebUI + RAG dans un environnement HDS souverain (français ou européen), avec quantization adaptée aux GPU disponibles. Le résultat : un modèle Mistral ou Llama 3 fine-tuné sur des corpus médicaux internes, sans aucune sortie de donnée vers une API tierce. La cohérence HDS + AI Act se construit dès l'architecture, pas en bout de chaîne.

RGPD-S et AI Act : gérer la tension entre besoin de données et minimisation

Tout ingénieur ML connaît la règle : plus il y a de données, meilleur est le modèle. Tout DPO connaît le principe opposé : minimiser. Cette tension est particulièrement vive en santé, où l'oncologie computationnelle ou la génomique exigent des volumes massifs pour atteindre la robustesse clinique.

L'AI Act n'efface pas le RGPD : il s'y superpose. La doctrine de la CNIL sur l'articulation IA / RGPD est claire : le règlement (UE) 2016/679 reste pleinement applicable à toute IA traitant des données personnelles. Mais l'AI Act apporte deux nouveautés utiles pour le secteur santé.

D'abord, l'article 10 §5 autorise, sous conditions strictes, le traitement de catégories particulières de données (article 9 RGPD) lorsque c'est strictement nécessaire à la détection et à la correction des biais d'un système haut risque. Cette base légale spécifique n'existait pas avant — elle facilite légalement l'audit de biais sur des données ethniques, de genre ou pathologiques. Ensuite, l'article 59 prévoit le traitement de données personnelles dans les bacs à sable réglementaires (AI regulatory sandboxes), ce qui ouvre une voie de R&D supervisée.

En pratique, je recommande trois actions concrètes : (1) une PIA RGPD unique couvrant entraînement, inférence et journalisation ; (2) un volet « gouvernance des données » de la documentation technique AI Act qui reprend et étend la PIA ; (3) une politique de minimisation appliquée au prompt-engineering — un prompt RAG bien construit n'a besoin que des extraits cliniques pertinents, pas du dossier complet. Pour les PME HealthTech qui démarrent, notre calculateur de ROI IA intègre le coût marginal de cette double conformité dans la projection à 3 ans.

L'EHDS : vers un espace européen de données de santé pour la recherche et l'innovation

Le Règlement EHDS (European Health Data Space) a été publié au JOUE le 5 mars 2025 et est entré en vigueur le 26 mars 2025. Il pose le premier espace européen de données sectoriel, avec deux régimes distincts : usage primaire (soins directs au patient, dossier médical partagé interopérable) et usage secondaire (recherche, innovation, politiques publiques, supervision).

Selon la Commission européenne (DG SANTE), le calendrier est jalonné :

  • Mars 2027 : adoption par la Commission des actes d'exécution clés.
  • Mars 2029 : application pour le premier groupe de catégories prioritaires en usage primaire (Patient Summaries, ePrescriptions/eDispensations) et la majorité des règles d'usage secondaire (données EHR).
  • Mars 2031 : usage primaire étendu à l'imagerie médicale, aux résultats de laboratoire et aux comptes rendus d'hospitalisation ; usage secondaire étendu aux données génomiques.
  • Mars 2035 : ouverture conditionnelle de HealthData@EU aux pays tiers.

Pour les éditeurs et les hôpitaux, l'EHDS est à la fois une opportunité (accès à des données massives pseudonymisées via les Health Data Access Bodies nationaux) et une contrainte (interopérabilité au standard EEHRxF, opt-out patient, finalités strictement limitées par permis). L'articulation avec l'AI Act est mécanique : un modèle entraîné via un permis EHDS devra démontrer qualité et représentativité des données conformément à l'article 10. L'EHDS facilite l'accès à la matière première ; l'AI Act conditionne sa transformation en produit.

Souveraineté numérique : infrastructures et AI Factories pour une IA santé décentralisée

La conformité ne suffit pas si l'infrastructure dépend d'acteurs extra-européens soumis à des lois extraterritoriales (CLOUD Act, FISA 702). C'est pourquoi la Commission a structuré une stratégie d'infrastructure ambitieuse.

D'après la stratégie IA Santé de la Commission européenne, EuroHPC a lancé 19 AI Factories dont 17 incluent la santé parmi leurs thématiques. À cela s'ajoutent les projets d'AI Gigafactories pour l'entraînement de modèles massifs, la révision du Chips Act pour l'autonomie en semi-conducteurs, et le futur Cloud and AI Development Act pour stimuler la capacité cloud souveraine. Côté données, l'European Cancer Imaging Initiative vise 60 millions d'images d'ici fin 2026, et l'initiative 1+ Million Genomes mobilise 26 États membres.

Pour une PME HealthTech ou un cabinet médical de groupe, accéder à une AI Factory reste un parcours administratif. La voie pragmatique est l'IA on-premise souveraine : une stack Ollama + Mistral 7B quantisée sur un serveur GPU local, ou un déploiement OpenWebUI + Llama 3 hébergé chez un acteur HDS européen. C'est notre angle d'attaque chez IAPRO depuis Roubaix : zéro transfert hors UE, contrôle complet du fine-tuning, coûts maîtrisés. Le panorama complet des dispositifs de soutien financier est détaillé sur notre hub aides au financement IA.

Les défis techniques : interopérabilité, anonymisation et détection des biais

Au-delà du juridique, trois chantiers techniques structurent un projet d'IA santé conforme.

L'interopérabilité d'abord. L'EHDS impose le format européen EEHRxF (European Electronic Health Record Exchange Format) pour les échanges transfrontaliers. En pratique, cela suppose un mapping vers HL7 FHIR, des terminologies SNOMED CT, LOINC et CIM-11, et une gestion fine des identifiants nationaux (INS en France). Un modèle d'IA entraîné sur des CRH (comptes rendus hospitaliers) non normalisés produira des résultats non transférables.

L'anonymisation et la pseudonymisation ensuite. Le considérant 26 du RGPD distingue la donnée anonyme (hors RGPD) de la donnée pseudonymisée (toujours dans le RGPD). Pour l'EHDS en usage secondaire, la pseudonymisation est la règle, avec gestion des clés par le Health Data Access Body. Pour l'entraînement, attention : les modèles de langue peuvent mémoriser des séquences rares et reconstituer une identité — la robustesse contre les attaques par inversion de modèle fait partie de l'article 15 AI Act.

La détection des biais enfin. L'article 10 §2 g) du Règlement (UE) 2024/1689 impose un examen des biais possibles susceptibles de porter atteinte aux droits fondamentaux ou de produire des discriminations interdites. En santé, un biais d'algorithme peut produire un sous-diagnostic systématique sur une sous-population. Concrètement : panels de tests stratifiés par sexe, âge, origine déclarée, comorbidités, et métriques de fairness documentées dans l'annexe IV. Pour la matrice complète des documents à produire, je renvoie vers la bibliothèque documentaire Regulia.

Roadmap de conformité : étapes clés pour déployer une solution d'IA santé

Voici la séquence que j'applique chez IAPRO sur les projets HealthTech et hospitaliers, distillée de plusieurs audits conduits ces deux dernières années.

Étape 1 — Cartographie des données sources (M0 à M1). Identifier les flux : données collectées en propre, achetées, sous convention de recherche, ou issues de partenariats hospitaliers. Pour chaque flux : base légale RGPD, statut HDS, présence d'une PIA, conservation, ré-identifiabilité.

Étape 2 — Qualification du risque AI Act (M1 à M2). Décider si le système relève de l'Annexe I (via MDR/IVDR), de l'Annexe III (usages listés), ou d'un régime de transparence (article 50). Cette qualification structure l'ensemble du projet et engage la responsabilité du fournisseur (article 25).

Étape 3 — Architecture HDS + supervision humaine (M2 à M4). Choisir un hébergeur HDS, dimensionner les GPU, concevoir l'interface utilisateur de manière à intégrer dès le départ le human-in-the-loop. Un radiologue qui valide une suggestion de l'IA doit pouvoir refuser, corriger et tracer son choix.

Étape 4 — Documentation technique unique (M4 à M6). Construire le dossier de l'annexe IV : description du système, données d'entraînement, performances, métriques de biais, monitoring prévu, plan de réponse aux incidents. Ce dossier sert aussi à l'audit HDS et à la PIA RGPD.

Étape 5 — Évaluation de conformité et marquage CE (M6 à M9). Pour les Annexe I, organisme notifié sous MDR/IVDR. Pour les Annexe III autonomes, procédure d'évaluation interne ou notifié selon le module.

Étape 6 — Surveillance post-marché continue (à partir de M9). Article 72 AI Act + matériovigilance MDR + journalisation HDS : un seul flux d'incidents, un seul reporting consolidé. Notre hub métiers IAPRO détaille les déclinaisons par profession régulée.

ROI et compétitivité : transformer la contrainte réglementaire en avantage stratégique

L'erreur fréquente consiste à présenter la conformité comme un centre de coûts. C'est une lecture étroite. Trois leviers économiques jouent en sens inverse.

D'abord, la barrière à l'entrée. Un éditeur certifié HDS + conforme AI Act haut risque + marqué CE construit un trio quasi infranchissable pour un concurrent extra-européen ou pour une startup sans culture réglementaire. Les DSI hospitaliers refusent désormais d'évaluer les produits qui ne présentent pas ces trois marqueurs.

Ensuite, le coût évité des sanctions. Le Règlement (UE) 2024/1689 prévoit, à l'article 99, des amendes pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel pour les pratiques interdites, 15 millions ou 3 % pour les manquements aux exigences haut risque, 7,5 millions ou 1 % pour informations incorrectes aux autorités. Auxquelles s'ajoutent les sanctions RGPD (jusqu'à 4 % du CA), les retraits MDR/IVDR et les responsabilités civiles. Pour une synthèse opérationnelle du barème et de la doctrine, je renvoie vers le guide Regulia sur les sanctions AI Act.

Enfin, l'accès au financement et aux marchés. Bpifrance, France 2030 et les programmes Horizon Europe / DEP filtrent désormais leurs dossiers santé via une grille AI Act + HDS. Le guichet Bpifrance et les appels à projets de France Num n'ouvrent leurs lignes de financement IA qu'aux projets démontrant une trajectoire de conformité crédible. Sans cette grille, pas d'argent public et difficilement de levée privée sérieuse.

FAQ — AI Act et données de santé

L'AI Act remplace-t-il le RGPD pour les données de santé ?

Non. Le Règlement (UE) 2024/1689 complète le RGPD (Règlement (UE) 2016/679) sans s'y substituer. La CNIL et la doctrine GNIUS sont explicites : dès qu'un système d'IA traite des données personnelles, le RGPD s'applique en parallèle. L'AI Act ajoute des obligations sur l'algorithme (gestion des risques, documentation, supervision humaine), le RGPD demeure le cadre des droits des personnes.

Une solution d'IA peut-elle être conforme sans certification HDS en France ?

Non, dès lors qu'elle héberge des données personnelles de santé pour le compte d'un tiers. Les articles L1111-8 et R1111-8-8 du Code de la santé publique imposent la certification HDS à l'hébergeur. Une IA SaaS qui traite des dossiers patients via un cloud non-HDS expose son éditeur et ses clients à une non-conformité immédiate, indépendamment de l'AI Act.

Quelles sont les dates clés d'application des règles haut risque de l'AI Act ?

Le 2 décembre 2027 pour les systèmes haut risque listés à l'Annexe III (triage médical, accès aux services essentiels, biométrie hospitalière, etc.). Le 2 août 2028 pour les systèmes haut risque relevant de l'Annexe I, qui inclut les dispositifs médicaux et dispositifs de diagnostic in vitro régis par les règlements MDR (UE) 2017/745 et IVDR (UE) 2017/746.

Quelle est la différence entre usage primaire et secondaire dans l'EHDS ?

L'usage primaire désigne l'utilisation des données pour les soins directs du patient (consultation transfrontalière, partage entre soignants). L'usage secondaire couvre la réutilisation à des fins de recherche, d'innovation, de politiques publiques ou de supervision réglementaire, sous permis délivré par un Health Data Access Body. Les finalités commerciales pures et les décisions défavorables aux personnes sont interdites en usage secondaire.

Comment l'AI Act impose-t-il la gestion de la qualité des données d'entraînement ?

L'article 10 du Règlement (UE) 2024/1689 exige des jeux de données pertinents, représentatifs, exempts d'erreurs et complets autant que possible. Il impose un examen des biais, des procédures de collecte documentées, et l'identification des lacunes. L'article 10 §5 autorise exceptionnellement le traitement de catégories sensibles strictement pour détecter et corriger ces biais.

Quelles sont les sanctions financières en cas de non-conformité à l'AI Act ?

L'article 99 du Règlement (UE) 2024/1689 prévoit jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel pour les pratiques interdites, 15 millions ou 3 % pour les manquements aux obligations haut risque (article 16, gouvernance des données, supervision humaine), et 7,5 millions ou 1 % pour informations incorrectes aux autorités. Ces sanctions se cumulent avec celles du RGPD.

L'hébergement HDS est-il obligatoire pour toutes les applications d'IA en santé ?

Oui, dès que l'application héberge des données personnelles de santé pour le compte d'un tiers responsable de traitement. Les six activités définies à l'article R1111-9 sont concernées, de la mise à disposition d'infrastructure à la sauvegarde. Une IA déployée en propre par un établissement de santé sur son propre SI relève d'un régime distinct, mais les exigences de sécurité demeurent équivalentes.

Comment garantir le human-in-the-loop dans un diagnostic assisté par IA ?

L'article 14 du Règlement (UE) 2024/1689 exige une supervision humaine effective : interface qui rend interprétable la sortie, possibilité de refuser ou de modifier la décision, formation des utilisateurs, traçabilité du choix final. En diagnostic, cela suppose que le médecin reste prescripteur, que la suggestion IA soit présentée comme telle, et que le journal conserve l'historique des arbitrages cliniciens.

Quels sont les rôles de la CNIL et de la DGE dans l'application de ces réglementations ?

La CNIL conserve son rôle d'autorité RGPD et hérite d'un rôle central dans la supervision AI Act, notamment pour les systèmes traitant des données personnelles. La DGE (Direction Générale des Entreprises) coordonne l'application aux entreprises et l'innovation IA. L'ANSM intervient pour les dispositifs médicaux MDR/IVDR, l'ANS pour HDS, et le futur Office français de l'IA pourrait centraliser certaines compétences AI Act.

Que signifie concrètement le concept d'AI Factory pour les startups de santé ?

Les AI Factories sont des centres EuroHPC qui mutualisent des ressources de supercalcul accessibles aux startups, PME et chercheurs. 19 ont été lancées, 17 incluent la santé. Concrètement, une HealthTech peut candidater pour obtenir des heures GPU sur des clusters européens souverains afin d'entraîner ou de fine-tuner un modèle, sans investir dans une infrastructure propre. Les conditions d'accès varient selon chaque AI Factory nationale.

Pour aller plus loin avec IAPRO

Vous pilotez une HealthTech, dirigez un cabinet médical de groupe ou un établissement de santé, et vous voulez sécuriser une trajectoire AI Act + HDS + RGPD-S sans empiler trois prestataires distincts ? Notre formule Audit AI Act Santé combine en un seul livrable la qualification haut risque, l'architecture HDS cible et la documentation technique annexe IV. Échangeons concrètement sur votre cas via le formulaire de contact IAPRO.

Liens utiles