AI Act santé : IA médicale et haut risque en 2026

L’essentiel. L’intelligence artificielle en santé cumule trois régimes. Au titre du règlement (UE) 2024/1689 (AI Act), une IA qui est elle-même un dispositif médical, ou le composant de sécurité d’un dispositif médical soumis à l’évaluation d’un organisme notifié au titre des règlements (UE) 2017/745 (MDR) et 2017/746 (IVDR), est à haut risque (art. 6(1)). Depuis le règlement (UE) 2026/1744, les exigences correspondantes (art. 8 à 15) s’appliquent à ces systèmes à compter du 2 août 2028 ; les systèmes de santé listés à l’annexe III — triage aux urgences, catégorisation biométrique à partir de signaux physiologiques, assurance santé — relèvent d’une échéance distincte, le 2 décembre 2027. Au titre du MDR, le logiciel reste un dispositif médical marqué CE. Au titre du RGPD, les données de santé sont des données sensibles (art. 9) et leur hébergement pour le compte de tiers impose en France la certification HDS (art. L. 1111-8 CSP), sur le référentiel v2 obligatoire depuis le 16 mai 2026.

Article publié le 2 juillet 2026 et mis à jour le 17 septembre 2026 : échéances corrigées après le règlement (UE) 2026/1744 (2 août 2028 pour l’annexe I, 2 décembre 2027 pour l’annexe III), cas de l’annexe III propres à la santé ajoutés, questions-réponses MDCG 2025-6 et projet de lignes directrices de la Commission du 19 mai 2026 intégrés, référentiel HDS v2 et sanctions précisés.

L’IA médicale est le terrain où l’AI Act déploie sa plus grande sévérité, et pour cause : une erreur d’un algorithme d’aide au diagnostic, de tri des urgences ou de dosage engage directement la sécurité des patients. Le législateur européen n’a pas créé de régime parallèle : il a greffé l’AI Act sur la réglementation existante des dispositifs médicaux. Cette articulation, élégante sur le papier, pose des questions concrètes de coordination aux établissements de santé et aux industriels.

Pour l’hôpital qui déploie un outil de détection de nodules pulmonaires, la medtech qui développe un logiciel de dépistage rétinien ou l’éditeur d’un assistant de codage PMSI, la question n’est pas de savoir s’il faut se conformer, mais à combien de régimes simultanés, et à quelle date. Les sanctions de l’AI Act (jusqu’à 15 M€ ou 3 % du chiffre d’affaires mondial pour les obligations du haut risque, art. 99(4)) s’ajoutent à celles du MDR et du RGPD (art. 83(5) : 20 M€ ou 4 %).

Le cadre légal : trois régimes qui se superposent

L’AI Act et les deux voies vers le haut risque

Le règlement (UE) 2024/1689 organise deux voies vers la qualification « haut risque » (art. 6).

Première voie : le produit réglementé (art. 6(1)). Deux conditions cumulatives : le système d’IA est lui-même un produit, ou le composant de sécurité d’un produit, couvert par une législation d’harmonisation listée à l’annexe I ; et ce produit est soumis, au titre de cette législation, à une évaluation de la conformité par un tiers. L’annexe I, section A, vise le règlement (UE) 2017/745 (MDR) et le règlement (UE) 2017/746 (IVDR). Un logiciel d’IA qualifié de dispositif médical de classe IIa ou supérieure, donc évalué par un organisme notifié, est un système d’IA à haut risque. Les questions-réponses MDCG 2025-6 du 19 juin 2025, adoptées par le groupe de coordination des dispositifs médicaux avec le Comité IA, en tirent la grille suivante :

Deux précisions du MDCG méritent d’être retenues : le « fabricant » au sens du MDR est, en principe, le « fournisseur » au sens de l’AI Act (c’est aussi ce que prévoit l’art. 25(3) pour les composants de sécurité), et la qualification haut risque ne fait jamais monter le dispositif dans une classe MDR supérieure. La logique ne joue que dans un sens. Le projet de lignes directrices de la Commission sur la classification, publié le 19 mai 2026, ajoute que le choix par le fabricant d’un module d’évaluation de la conformité ne modifie pas la qualification : ce qui compte est que la législation sectorielle impose un contrôle renforcé.

Seconde voie : le cas d’usage (art. 6(2) et annexe III). Contrairement à une idée répandue, la santé n’est pas absente de l’annexe III. Quatre points concernent directement le secteur :

• point 5(d) : les systèmes destinés à évaluer et classer les appels d’urgence, à établir des priorités dans l’envoi des services d’urgence, ainsi que les systèmes de triage des patients dans les soins de santé d’urgence. Le projet de lignes directrices cite expressément l’IA qui priorise les patients d’un service d’urgences, même sans acte d’évaluation clinique ;
• point 5(a) : les systèmes utilisés par ou pour les autorités publiques afin d’évaluer l’éligibilité des personnes à des prestations et services publics essentiels, y compris les services de soins de santé ;
• point 5(c) : l’évaluation des risques et la tarification en assurance vie et santé ;
• point 1(b) : la catégorisation biométrique selon des attributs sensibles. Le projet de lignes directrices y range un système qui déduit un état de santé de la démarche, d’un ECG ou d’un EEG pour classer des personnes selon un stade de maladie.

Point capital pour les fabricants : selon le même projet de lignes directrices, un outil de triage qui est aussi un dispositif médical relève des deux voies cumulativement, pas alternativement. Le régime des articles 8 à 15 est le même, mais l’échéance d’application diffère.

Le calendrier réel après l’omnibus

Le règlement (UE) 2026/1744 du 8 juillet 2026, publié le 24 juillet et en vigueur depuis le 27 juillet 2026, a reporté les exigences du haut risque. Les dates sont fixes, sans condition liée à la disponibilité des normes harmonisées.

Un système à haut risque déjà mis sur le marché avant la date qui le concerne n’est soumis au règlement (hors art. 5) qu’en cas de modification importante de sa conception après cette date (art. 111(2), aligné par l’omnibus sur les nouvelles échéances) ; un logiciel médical certifié en 2027 et non modifié en profondeur n’a donc pas à être recertifié au titre de l’AI Act en 2028. Le calendrier complet de l’AI Act et notre analyse de l’omnibus numérique détaillent ces règles.

Le MDR : la réglementation des dispositifs médicaux

Un logiciel est un dispositif médical dès lors qu’il a une finalité médicale au sens de l’art. 2(1) MDR : diagnostic, prévention, contrôle, prédiction, pronostic, traitement ou atténuation d’une maladie. La règle 11 de l’annexe VIII classe en IIa au minimum tout logiciel destiné à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques, en IIb ou III selon la gravité des conséquences possibles. La plupart des logiciels d’aide à la décision médicale relèvent donc d’un organisme notifié, et par ricochet du haut risque de l’AI Act. Le document MDCG 2019-11 reste la référence pour la qualification et la classification des logiciels.

Le principe posé par l’AI Act est celui de l’intégration, pas de la duplication. L’art. 8(2) permet aux fournisseurs de produits couverts par l’annexe I d’intégrer les processus d’essai et de documentation de l’AI Act dans ceux de la législation sectorielle, pour assurer la cohérence et éviter les doublons ; l’art. 11(2) permet une documentation technique unique ; l’art. 43(3) renvoie à la procédure d’évaluation de la conformité prévue par la législation sectorielle, l’organisme notifié vérifiant en plus les exigences des articles 8 à 15. MDCG 2025-6 confirme que le système de management de la qualité, la documentation technique, l’évaluation de conformité et la surveillance après commercialisation du MDR peuvent porter les exigences de l’AI Act, à condition que les dimensions propres à l’IA soient effectivement ajoutées : risques pour les droits fondamentaux, gouvernance des données d’entraînement, journalisation, biais d’automatisation, notice aux déployeurs. Notre analyse de la documentation technique AI Act et celle du marquage CE des systèmes d’IA précisent ces exigences.

Une notion demande une vigilance particulière : la modification substantielle de l’art. 3(23) AI Act est autonome par rapport à la modification significative du MDR. Une même évolution du modèle doit être analysée sous les deux textes. En revanche, les changements prédéterminés d’un système apprenant, décrits dans la documentation technique initiale et évalués lors de l’évaluation de conformité, ne constituent pas une modification substantielle (art. 3(23) et 43(4)).

Le RGPD et l’article 9

Les données de santé (art. 4(15)) sont des catégories particulières de données au sens de l’article 9 du RGPD. Leur traitement est interdit, sauf exception du paragraphe 2 : consentement explicite (a), médecine préventive, diagnostic, prise en charge sanitaire sous la responsabilité d’un professionnel soumis au secret (h, complété par le paragraphe 3), intérêt public dans le domaine de la santé publique (i), recherche scientifique avec garanties appropriées (j). L’entraînement d’un modèle sur des données de patients ne se rattache pas automatiquement à la finalité de soins : il faut lui trouver sa propre base légale et son propre fondement au titre de l’art. 9(2). Sur le régime de ces données sensibles et la doctrine de la CNIL, la vigilance doit être maximale.

L’omnibus a supprimé l’ancien art. 10(5), limité aux systèmes à haut risque, et l’a remplacé par un article 4 bis applicable à tous les systèmes et modèles depuis le 27 juillet 2026 : il autorise, sous six conditions cumulatives et par spécification de l’art. 9(2)(g) RGPD, le traitement de données sensibles aux seules fins de détection et de correction des biais. Pour un fabricant qui doit démontrer la représentativité de ses jeux de données (art. 10(2)(f) et (g)), c’est un fondement utile, mais étroit : il ne couvre pas l’entraînement lui-même. Notre guide IA et RGPD développe cette articulation.

Qualification pratique : votre IA est-elle à haut risque ?

La qualification n’est jamais automatique pour les usages périphériques : un assistant conversationnel, un outil d’optimisation hospitalière ou un module de veille sanitaire doit être analysé à l’aune de sa destination réelle, telle qu’elle ressort de la notice, des supports commerciaux et de l’usage prévisible, et non de la seule présentation interne. Notre grille de classification des risques IA aide à trancher.

Les obligations concrètes pour hôpitaux et medtech

Pour l’éditeur ou le fabricant (fournisseur)

Le développeur d’un logiciel médical d’IA est fournisseur au sens de l’art. 3(3) et cumule les obligations du MDR et celles de l’art. 16 de l’AI Act : système de gestion des risques (art. 9), gouvernance et qualité des données d’entraînement, de validation et de test (art. 10), documentation technique (art. 11), journalisation (art. 12), transparence et notice d’utilisation (art. 13), surveillance humaine par conception (art. 14), exactitude, robustesse et cybersécurité (art. 15), système de management de la qualité (art. 17), évaluation de la conformité (art. 43), marquage CE (art. 48), enregistrement dans la base de données de l’UE (art. 49) et surveillance après commercialisation (art. 72). La distinction des rôles est développée dans notre article fournisseur ou déployeur AI Act.

Pour l’établissement de santé (déployeur)

L’hôpital ou la clinique qui utilise l’outil est déployeur (art. 3(4)) et relève de l’art. 26 : usage conforme à la notice (26(1)), surveillance humaine confiée à des personnes compétentes (26(2)), pertinence des données d’entrée (26(4)), suivi du fonctionnement et suspension en cas de risque (26(5)), conservation des journaux au moins six mois (26(6)) et, pour les systèmes de l’annexe III, information des personnes concernées lorsque le système contribue à une décision les concernant (26(11)), qui peuvent demander une explication des décisions produisant des effets juridiques ou similaires (art. 86). L’art. 26(9) précise que le déployeur utilise les informations fournies au titre de l’art. 13 pour réaliser son analyse d’impact RGPD.

L’analyse d’impact relative à la protection des données (AIPD) appliquée à l’IA est obligatoire : l’art. 35(3)(b) RGPD vise le traitement à grande échelle de données sensibles, et la CNIL a inscrit dans sa liste des traitements soumis à AIPD (délibération n° 2018-327 du 11 octobre 2018) les traitements de données de santé mis en œuvre par les établissements de santé pour la prise en charge des personnes. La désignation d’un DPO est obligatoire au titre de l’art. 37(1)(c) pour les organismes dont l’activité de base implique un traitement à grande échelle de données sensibles.

S’y ajoute, pour les hôpitaux publics et les établissements privés assurant une mission de service public, l’analyse d’impact sur les droits fondamentaux de l’art. 27, mais uniquement pour les systèmes à haut risque de l’annexe III (un outil de triage 5(d), par exemple), pas pour ceux qui ne relèvent que de l’art. 6(1). Notre guide RGPD à l’hôpital présente le socle sur lequel ces obligations viennent se greffer.

Le maintien d’un professionnel de santé dans la boucle

Un point non négociable : l’IA médicale ne décide pas seule. La surveillance humaine (art. 14 pour la conception, 26(2) pour l’usage) rejoint l’interdiction de principe des décisions entièrement automatisées de l’article 22 du RGPD lorsque la décision produit des effets juridiques ou significatifs ; l’art. 22(4) interdit en outre de fonder une telle décision sur des données de santé hors consentement explicite ou intérêt public important. Le diagnostic reste un acte médical ; l’algorithme l’assiste. Notre article sur le contrôle humain des systèmes d’IA détaille comment organiser cette supervision sans la réduire à un bouton d’arrêt.

L’hébergement des données de santé : la certification HDS

Toute personne qui héberge des données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de tiers, doit être certifiée « hébergeur de données de santé » (art. L. 1111-8 du Code de la santé publique, art. R. 1111-8-8 à R. 1111-11). Le responsable de traitement qui héberge ses propres données, un hôpital sur son infrastructure par exemple, n’est pas soumis à cette obligation. Le référentiel de certification v2, approuvé par l’arrêté du 26 avril 2024, s’applique aux nouvelles certifications depuis le 16 novembre 2024 et à tous les hébergeurs certifiés depuis le 16 mai 2026. Il impose un hébergement physique dans l’Espace économique européen, l’information contractuelle du client sur tout accès distant depuis un pays tiers et une clause de réversibilité (exigence 27) ; un décret de mars 2026 complète le contenu obligatoire du contrat (art. R. 1111-11), avec effet en septembre 2026. L’exercice sans certification est puni de trois ans d’emprisonnement et de 45 000 € d’amende, portée à 225 000 € pour les personnes morales (art. L. 1115-1 CSP). Notre guide de l’hébergement HDS détaille le dispositif.

Conséquence pour l’IA médicale : les jeux de données d’entraînement identifiants, les données de patients traitées en production et les journaux de l’art. 12 sont des données hébergées. Un fournisseur de modèle ou un prestataire cloud qui les conserve, même sous forme de journaux de requêtes, relève en principe de l’activité d’hébergement au sens de l’art. R. 1111-9 et doit être certifié. Le cas d’un traitement strictement transitoire, sans aucune conservation, est débattu ; en pratique, l’établissement doit exiger la certification ou s’en tenir à des données anonymisées. La liste des hébergeurs certifiés est publiée par l’Agence du numérique en santé. Les questions de transferts hors UE et d’accès depuis des pays tiers se posent avec la même acuité pour l’IA générative.

Un exemple sectoriel : le cabinet médical

Un cabinet qui adopte un assistant d’IA pour la rédaction de comptes rendus ou l’aide à la décision doit combiner les registres : information des patients (art. 13 RGPD), fondement de l’art. 9(2)(h), hébergement HDS du prestataire, contrat de sous-traitance, et, si l’outil est un dispositif médical, usage conforme à sa notice. Notre guide RGPD au cabinet médical détaille ce socle, auquel l’AI Act ajoute la couche « système d’IA ».

Piloter cette conformité multi-régimes suppose de tracer, pour chaque outil, sa qualification MDR, son statut AI Act, sa date de mise sur le marché (déterminante pour l’art. 111(2)) et son traitement RGPD. Un registre des systèmes d’IA articulé au registre des traitements est le support naturel de ce suivi ; c’est ce type de référentiel unique que Legiscope structure.

Recommandations opérationnelles

1. Qualifiez d’abord au titre du MDR. La classe du dispositif et l’intervention d’un organisme notifié commandent la qualification haut risque par l’art. 6(1).
2. Vérifiez ensuite l’annexe III. Triage aux urgences (5(d)), éligibilité aux soins (5(a)), assurance santé (5(c)), catégorisation à partir de signaux physiologiques (1(b)) : l’échéance est alors le 2 décembre 2027, même pour un outil qui n’est pas un dispositif médical.
3. Unifiez la documentation. Une documentation technique MDR enrichie des exigences des art. 9 à 15 (art. 11(2)), un seul système de management de la qualité (art. 17(3)), une seule évaluation de conformité (art. 43(3)).
4. Sécurisez l’hébergement. Certification HDS v2 de toute infrastructure conservant des données de santé identifiantes, y compris les journaux ; hébergement en EEE ; cartographie des accès depuis des pays tiers.
5. Cadrez le RGPD. Fondement de l’art. 9(2) pour chaque finalité (soins, entraînement, correction des biais via l’art. 4 bis), AIPD, DPO, information des patients.
6. Garantissez la supervision médicale. Aucun système ne doit produire un effet significatif sur le patient sans intervention humaine qualifiée (art. 14 et 26(2) AI Act, art. 22 RGPD).
7. Datez chaque mise sur le marché. La règle de l’art. 111(2) protège les systèmes mis sur le marché avant la date qui les concerne tant qu’ils ne subissent pas de modification importante de leur conception : sans registre daté, elle est inopposable.

Pour suivre les lignes directrices finales de la Commission, la révision annoncée du MDR et les échéances de 2027-2028, inscrivez-vous à la newsletter : une analyse par semaine, écrite par un docteur en droit.

Ce qu’il faut retenir

• Une IA médicale est à haut risque par l’art. 6(1) dès qu’elle est un dispositif médical (ou son composant de sécurité) évalué par un organisme notifié : classe IIa et au-delà, classe I stérile ou de mesurage. La classe I simple et les logiciels internes (art. 5(5) MDR) échappent à cette voie.
• La santé figure aussi à l’annexe III : triage aux urgences (5(d)), éligibilité aux soins (5(a)), assurance santé (5(c)), catégorisation biométrique (1(b)). Les deux voies se cumulent.
• Échéances fixées par le règlement (UE) 2026/1744 : 2 décembre 2027 pour l’annexe III, 2 août 2028 pour les dispositifs médicaux ; art. 50 applicable depuis le 2 août 2026 ; art. 111(2) pour les systèmes déjà sur le marché.
• L’AI Act s’intègre dans les procédures du MDR (art. 8(2), 11(2), 43(3) ; MDCG 2025-6) : une documentation, un organisme notifié, mais des exigences IA réellement ajoutées.
• Côté RGPD : art. 9(2) pour chaque finalité, AIPD obligatoire (art. 35(3)(b), liste CNIL), DPO (art. 37(1)(c)), art. 22 ; côté français, certification HDS v2 de tout hébergeur tiers, hébergement en EEE, sanctions pénales de l’art. L. 1115-1 CSP.

FAQ

Toute IA utilisée en santé est-elle à haut risque ?

Non. Elle l’est si elle constitue un dispositif médical (ou son composant de sécurité) soumis à l’évaluation d’un organisme notifié, ou si son usage correspond à un point de l’annexe III (triage aux urgences, éligibilité aux soins, assurance santé, catégorisation biométrique). Un outil administratif, logistique ou d’information sans finalité médicale ne l’est pas, même utilisé dans un établissement de santé ; il reste soumis à l’art. 4 et, s’il dialogue avec des personnes, à l’art. 50.

Quand les obligations s’appliquent-elles pour un logiciel médical d’IA ?

Pour les dispositifs médicaux relevant de l’annexe I, les exigences des art. 8 à 15 s’appliquent aux systèmes mis sur le marché à compter du 2 août 2028 (règlement (UE) 2026/1744). Pour les systèmes de l’annexe III, la date est le 2 décembre 2027. Les interdictions de l’art. 5 (depuis le 2 février 2025), l’obligation de moyens en matière de maîtrise de l’IA (art. 4) et les obligations de transparence de l’art. 50 (depuis le 2 août 2026) sont déjà applicables.

Faut-il refaire une évaluation de conformité au titre de l’AI Act et du MDR ?

Non : l’art. 43(3) renvoie à la procédure du MDR, et l’organisme notifié y vérifie en plus les exigences des art. 8 à 15. La documentation technique peut être unique (art. 11(2)) et le système de management de la qualité intégré (art. 17(3)). Les questions-réponses MDCG 2025-6 précisent ce que le fabricant doit ajouter à son dossier MDR ; des lignes directrices sectorielles de la Commission sont annoncées.

L’hébergement HDS est-il obligatoire pour les données d’entraînement ?

Dès lors que les données de santé sont identifiantes ou réidentifiables, ont été recueillies dans un cadre de prévention, de diagnostic, de soins ou de suivi social et médico-social, et sont hébergées par un tiers, la certification HDS s’impose. Des données réellement anonymisées échappent au RGPD et à l’exigence HDS, mais l’anonymisation véritable est un standard exigeant, rarement atteint sur des données de santé fines.

Un chatbot d’information santé grand public est-il concerné ?

Il n’est en principe pas un dispositif médical s’il ne poursuit pas de finalité médicale individuelle. Il est soumis à l’art. 50(1) (indiquer à l’utilisateur qu’il dialogue avec une IA) et, s’il traite des données personnelles, au RGPD. Il peut relever du haut risque s’il évalue l’urgence d’une situation pour orienter vers les services d’urgence (annexe III, 5(d), à apprécier au regard des lignes directrices), et devient un dispositif médical s’il fournit une aide au diagnostic individuelle.

Le DPO est-il obligatoire pour un établissement déployant de l’IA médicale ?

Oui : l’art. 37(1)(c) impose la désignation d’un DPO aux organismes dont l’activité de base implique un traitement à grande échelle de données sensibles, ce qui est le cas des établissements de santé indépendamment de l’IA. Le déploiement d’IA médicale renforce l’utilité de cette fonction, notamment pour l’AIPD et l’art. 26(9) AI Act, sans en changer le fondement.

---

Sources : Règlement (UE) 2024/1689 (AI Act), texte consolidé (EUR-Lex) — Règlement (UE) 2026/1744 du 8 juillet 2026, JOUE L du 24 juillet 2026 (EUR-Lex) — Règlement (UE) 2017/745 (MDR) — Règlement (UE) 2017/746 (IVDR) — MDCG 2025-6, FAQ on the interplay between the MDR/IVDR and the AI Act, 19 juin 2025 (PDF) — Commission européenne, projet de lignes directrices sur la classification des systèmes d’IA à haut risque, 19 mai 2026 — Commission européenne, Bureau de l’IA, calendrier de mise en œuvre de l’AI Act — Arrêté du 26 avril 2024 (référentiel HDS v2), Légifrance — Référentiel de certification HDS v2 (ANS, PDF) — CNIL, liste des traitements pour lesquels une AIPD est requise.

Thiébaut Devergranne est docteur en droit (Paris II), titulaire du CAPA, et travaille depuis plus de vingt ans sur le droit des technologies, dont six années au sein des services du Premier ministre (SGDN/DCSSI). Il a fondé donneespersonnelles.fr et Legiscope. Cet article présente le cadre applicable au 17 septembre 2026 ; l’articulation MDR / AI Act fait l’objet de lignes directrices sectorielles annoncées et d’une proposition de révision des règlements MDR/IVDR en cours d’examen. Vérifiez l’état du droit et faites-vous accompagner avant toute mise sur le marché ou tout déploiement d’IA médicale.