AI Act et IA dans la santé : obligations pour les intégrations de dispositifs médicaux

Si vous développez de l'IA pour la santé, à savoir des outils d'imagerie diagnostique, des systèmes d'aide à la décision clinique, des algorithmes de triage des patients ou des logiciels de surveillance à distance, vous opérez simultanément sous deux cadres réglementaires européens concurrents. L'AI Act et le Règlement sur les dispositifs médicaux (RDM 2017/745) ou le Règlement sur les dispositifs médicaux de diagnostic in vitro (RDIV 2017/746) s'appliquent tous deux à votre produit. Leurs exigences se chevauchent, interagissent et se renforcent mutuellement dans certains cas. Les gérer correctement en parallèle constitue l'un des défis de conformité les plus complexes dans la réglementation européenne de la santé numérique.

Cet article explique précisément comment le double cadre s'applique, quelles sont vos obligations spécifiques sous chaque régime, et où un seul processus de conformité peut satisfaire les deux.

Pourquoi l'IA dans la santé fait face à un double cadre réglementaire

L'AI Act classe les systèmes d'IA comme étant à haut risque selon deux voies distinctes. La première voie s'applique aux systèmes d'IA qui sont des composants de sécurité de produits déjà réglementés par une législation spécifique de sécurité des produits de l'UE. La seconde voie s'applique aux systèmes d'IA autonomes dans certains domaines à fort impact listés à l'annexe III.

Pour l'IA dans la santé, la première voie est la plus déterminante.

L'article 6(1) de l'AI Act stipule qu'un système d'IA est à haut risque lorsqu'il est un composant de sécurité d'un produit couvert par la législation d'harmonisation de l'UE listée à l'annexe I de l'AI Act, et lorsque ce produit lui-même doit faire l'objet d'une évaluation de la conformité par un tiers en vertu de cette législation sectorielle. Le RDM et le RDIV figurent tous deux explicitement à l'annexe I.

La conséquence est la suivante : tout système d'IA intégré dans un dispositif médical réglementé est automatiquement classé comme étant à haut risque en vertu de l'AI Act, quelle que soit la fonction de l'IA. Il n'est pas nécessaire d'évaluer s'il répond à des critères supplémentaires. Si le dispositif est réglementé par le RDM ou le RDIV, l'IA intégrée est à haut risque.

Pour l'IA clinique autonome qui n'est pas intégrée dans un dispositif physique mais fournit des aides à la décision, au triage ou des sorties diagnostiques, la voie passe par l'article 6(2) et l'annexe III. L'annexe III §5(b) couvre l'IA utilisée dans l'administration d'infrastructures numériques critiques. Plus pertinent pour les logiciels cliniques, les systèmes d'IA utilisés dans les services essentiels, y compris les services de santé, peuvent entrer dans le champ d'application selon leur fonction spécifique et la population qu'ils concernent. Les orientations réglementaires sur la position des logiciels d'aide à la décision clinique dans ce spectre continuent d'évoluer.

L'IA en tant que dispositif médical : la double classification

Le terme « IA en tant que dispositif médical » (AIaMD), parfois appelé logiciel en tant que dispositif médical (SaMD) avec capacité d'IA, décrit un logiciel dont l'objectif principal est médical et qui utilise l'IA ou l'apprentissage automatique pour atteindre cet objectif.

Sous le RDM et le RDIV, la classification d'un dispositif médical détermine l'intensité de l'évaluation de la conformité requise :

Classe de dispositif	Exemples	Voie de conformité RDM
Classe I	Outils de base non invasifs	Autocertification (aucun organisme notifié)
Classe IIa	Aide au diagnostic à risque faible à modéré	Intervention d'un organisme notifié requise
Classe IIb	Diagnostics à risque plus élevé, systèmes de surveillance	Audit complet du SMQ par l'organisme notifié
Classe III	Risque élevé, maintien des fonctions vitales	Examen de la conception par l'organisme notifié
RDIV Classe C/D	Diagnostics in vitro à haut risque	Évaluation complète par l'organisme notifié

Les logiciels de diagnostic basés sur l'IA se retrouvent généralement en Classe IIa ou supérieure selon les règles de classification des risques du RDM. L'IA utilisée dans les diagnostics in vitro pour les diagnostics compagnons, le dépistage du cancer ou la détection des maladies infectieuses atteint généralement la Classe C ou D du RDIV.

Le GCDM (Groupe de coordination des dispositifs médicaux) a publié des orientations sur la qualification et la classification des logiciels sous le RDM, que l'Agence européenne des médicaments (EMA) a complétées par des considérations spécifiques à l'IA pour les produits réglementés. Les fabricants doivent consulter à la fois le MDCG 2019-11 (classification des logiciels) et le MDCG 2021-6 (IA/ML dans les dispositifs médicaux) lors de la détermination de la classification.

Comment les évaluations de conformité de l'AI Act et du RDM/RDIV interagissent

C'est la question qui préoccupe les équipes de conformité dans le secteur des technologies médicales : une entreprise doit-elle mener deux évaluations de conformité entièrement séparées, ou peuvent-elles être coordonnées ?

La réponse, en vertu de l'article 43(1) de l'AI Act, est qu'elles peuvent être coordonnées, et dans de nombreux cas, doivent l'être.

Pour un système d'IA qui est un composant de sécurité d'un dispositif médical (article 6(1)), l'AI Act exige une évaluation de la conformité par un tiers via un organisme notifié. Le RDM et le RDIV exigent déjà l'intervention d'un organisme notifié pour les Classes IIa, IIb, III et les classes RDIV équivalentes. L'AI Act autorise explicitement l'organisme notifié qui conduit l'évaluation RDM/RDIV à couvrir également les exigences d'évaluation de la conformité de l'AI Act pour les produits de l'annexe I.

En pratique : si votre organisme notifié évalue votre dispositif de diagnostic IA de Classe IIb en vertu du RDM, ce même organisme notifié peut et doit également examiner votre documentation de conformité à l'AI Act en même temps. Ce n'est pas automatique : l'organisme notifié doit être désigné sous les deux régimes et vous devez structurer votre documentation en conséquence. Cela élimine toutefois la nécessité de deux processus d'évaluation entièrement distincts.

Pour les systèmes d'IA relevant de l'annexe III §1 (identification biométrique), une évaluation distincte de l'AI Act par un organisme notifié est requise indépendamment de la réglementation sectorielle. L'IA diagnostique qui n'utilise pas l'identification biométrique ne relève pas de cette sous-disposition.

La voie de marquage CE

Un système d'IA intégré dans un dispositif médical porte le marquage CE en vertu du RDM ou du RDIV. L'AI Act ne crée pas de marquage CE distinct pour les produits de l'annexe I : le marquage CE unique de la législation sectorielle couvre le produit, à condition que les obligations de l'AI Act aient été respectées dans le cadre de l'évaluation de la conformité.

Pour les logiciels cliniques d'IA autonomes relevant de l'annexe III de l'AI Act (non via l'article 6(1)), un processus distinct d'évaluation de la conformité et de marquage CE au titre de l'AI Act s'applique.

Obligations complètes de l'AI Act pour les fournisseurs d'IA dans la santé

La classification en tant que « système d'IA à haut risque » implique que l'ensemble des obligations des articles 9 à 15 s'applique. Voici ce que chacun exige dans un contexte clinique.

Article 9 : Gestion des risques

Vous devez établir, mettre en œuvre, documenter et maintenir un système de gestion des risques pour le cycle de vie du système d'IA. Dans un contexte clinique, cela signifie intégrer votre processus de gestion des risques au titre de l'AI Act avec votre cadre existant de gestion des risques des dispositifs médicaux RDM/ISO 14971. Les deux sont compatibles mais utilisent des terminologies différentes : le RDM se concentre sur les risques de sécurité clinique, tandis que l'AI Act exige une perspective plus large incluant les risques pour les droits fondamentaux, les risques de discrimination et les risques liés à une utilisation prévisible abusive.

Article 10 : Données d'entraînement, de validation et de test

Les exigences de l'AI Act en matière de données d'entraînement pour l'IA dans la santé sont parmi les plus exigeantes dans tous les secteurs. Vos ensembles de données d'entraînement doivent :

Être pertinents, représentatifs, exempts d'erreurs et complets
Tenir compte des caractéristiques spécifiques au contexte géographique, situationnel ou fonctionnel prévu
Être examinés pour détecter les biais possibles pouvant affecter la santé ou la sécurité des personnes physiques
Refléter la diversité de la population de patients en termes d'âge, de sexe, d'origine ethnique et d'autres variables démographiques pertinentes

L'interaction avec les données de catégorie spéciale de l'article 9 du RGPD est déterminante. Les données de santé sont des données de catégorie spéciale en vertu du RGPD. Leur traitement pour l'entraînement à l'IA nécessite soit un consentement explicite, soit une base juridique spécifique en vertu de l'article 9(2) du RGPD, généralement la recherche scientifique ou l'intérêt public en vertu du droit national. Les exigences de l'AI Act en matière de données d'entraînement ne modifient pas les exigences du RGPD : les deux s'appliquent simultanément. Un ensemble de données conforme à l'AI Act mais dépourvu d'une base de traitement RGPD valide reste non conforme.

Article 11 : Documentation technique

La documentation technique pour l'IA dans la santé doit suivre les exigences de l'annexe IV et inclure des descriptions détaillées de l'architecture du système, de la méthodologie d'entraînement, des ensembles de données de validation et des métriques de performance désagrégées par sous-groupes pertinents de patients, des limitations connues et des cas limites prévisibles dans l'utilisation clinique.

Pour les outils de diagnostic IA, les métriques de performance désagrégées par données démographiques des patients, incluant les différences de performance selon les groupes d'âge, le sexe et, le cas échéant, l'origine ethnique, ne sont pas facultatives. Les régulateurs et les organismes notifiés examinant les dossiers techniques d'IA dans la santé vérifieront spécifiquement si le système a été validé pour les populations de patients où il sera déployé.

Article 12 : Tenue des registres et journalisation

Les systèmes d'IA à haut risque doivent automatiquement enregistrer les événements pertinents pour les performances du système et la traçabilité des décisions. Pour l'IA clinique, cela signifie maintenir une piste d'audit des sorties générées par l'IA qui est accessible au personnel clinique examinant une décision de soins. Lorsqu'un système d'IA génère une suggestion diagnostique, cette suggestion et les entrées utilisées pour la générer doivent être enregistrées et conservées sous une forme permettant un examen rétrospectif.

Article 13 : Transparence et information aux déployeurs

Les fournisseurs doivent fournir aux déployeurs, c'est-à-dire aux hôpitaux, cliniques et réseaux de santé, un document d'instructions d'utilisation comprenant l'usage prévu du système, ses caractéristiques de performance, ses limitations connues, l'expertise requise des utilisateurs et les circonstances dans lesquelles le système pourrait produire des sorties peu fiables. Dans les contextes cliniques, ces informations doivent être intégrées dans la documentation de formation clinique et de processus de travail.

Article 14 : Supervision humaine

Les systèmes d'IA dans la santé doivent être conçus pour permettre au personnel clinique de superviser de manière significative, d'interpréter et, le cas échéant, d'ignorer la sortie de l'IA. Cela n'est pas satisfait par une simple case à cocher générique « humain dans la boucle ». L'AI Act exige que la fonction de supervision humaine soit techniquement mise en œuvre dans la conception du système : le personnel clinique peut intervenir, contourner ou signaler des sorties, et ces interventions sont enregistrées.

Les modèles boîte noire qui fournissent une recommandation clinique sans aucune indication des facteurs à l'origine de cette recommandation créent à la fois un problème de conformité à l'article 14 et un problème de gouvernance clinique. Les mécanismes d'explicabilité ne sont pas imposés par leur nom dans l'AI Act, mais l'obligation de supervision exige fonctionnellement que le personnel clinique puisse porter un jugement éclairé sur la recommandation de l'IA.

Article 15 : Exactitude, robustesse et cybersécurité

Le système doit atteindre des niveaux d'exactitude appropriés pour son usage prévu et doit être résilient face aux erreurs, aux incohérences et aux tentatives de manipulation adversariale. Dans les contextes de santé, cela exige des seuils de performance documentés établis lors de la validation clinique, une surveillance de la dérive après déploiement et un processus défini pour suspendre le système d'IA si les performances tombent en dessous des seuils cliniques acceptables.

Article 27 : Obligations ADFR pour les déployeurs dans la santé

L'Analyse d'impact sur les droits fondamentaux (ADFR) est l'une des innovations les plus significatives de l'AI Act pour les déployeurs. En vertu de l'article 27, tout déployeur qui est soit un organisme public, soit une entité fournissant un service d'intérêt public général, doit réaliser une ADFR avant de déployer un système d'IA à haut risque.

Les hôpitaux sont des organismes publics dans la plupart des États membres de l'UE. Cela signifie qu'ils sont tenus de réaliser une ADFR avant de déployer tout système d'IA à haut risque, y compris les outils de diagnostic IA, les systèmes de triage des patients et les logiciels d'aide à la décision clinique.

Les cliniques privées et les prestataires de soins de santé fournissant des services dans le cadre de contrats de santé publique ou fournissant des services accessibles au grand public relèvent probablement également de la catégorie « service d'intérêt public ». La frontière n'est pas encore définitivement interprétée dans tous les États membres, mais les prestataires de soins de santé doivent appliquer l'obligation ADFR à moins de pouvoir clairement établir que leurs services sont entièrement privés et en dehors de tout cadre de santé publique.

Une ADFR pour l'IA dans la santé doit évaluer l'impact probable du système sur les droits fondamentaux, notamment le droit à la santé, le droit à la non-discrimination, le droit à la vie privée et les droits des populations vulnérables incluant les enfants, les patients âgés et les personnes handicapées.

Principaux risques dans l'IA de santé : ce que les régulateurs examineront

Les biais algorithmiques dans les diagnostics constituent le risque le plus médiatisé que les régulateurs et les organismes notifiés scruteront. Des études ont documenté des disparités de performance significatives dans les outils de diagnostic IA pour la dermatologie, la radiologie et la cardiologie selon des groupes raciaux et démographiques. Un dossier technique qui n'aborde pas ces disparités sera examiné avec attention dans les processus d'évaluation RDM et AI Act.

L'interaction entre les ensembles de données de validation clinique et les populations de déploiement en conditions réelles constitue un second domaine de risque clé. Un système validé sur un ensemble de données d'un seul hôpital dans un pays peut présenter des performances significativement différentes sur une population de patients différente. L'obligation de surveillance post-commercialisation de l'AI Act et les exigences de surveillance après commercialisation du RDM traitent toutes deux de ce point, mais les entreprises doivent activement suivre les performances en conditions réelles désagrégées par variables démographiques pertinentes.

Orientations pratiques pour les entreprises de technologie médicale

Pour les entreprises de technologies de santé développant des dispositifs médicaux intégrant de l'IA ou des logiciels cliniques :

Déterminez d'abord votre classe de dispositif RDM/RDIV. Cela détermine si un organisme notifié est nécessaire et sous quel régime.
Si un organisme notifié est requis en vertu du RDM/RDIV, engagez-le tôt sur sa capacité d'évaluation au titre de l'AI Act. Tous les organismes notifiés ne sont pas encore désignés ou équipés pour les évaluations de l'annexe I de l'AI Act.
Structurez votre documentation technique pour répondre à la fois aux exigences de l'annexe II/III du RDM et aux exigences de l'annexe IV de l'AI Act dans un ensemble de documents intégrés unique. La duplication est inutile ; les lacunes sont coûteuses.
Intégrez votre processus de gestion des risques au titre de l'AI Act avec votre processus ISO 14971 dès le début de la phase de conception. Adapter rétroactivement les exigences de l'AI Act à un dossier de gestion des risques RDM déjà complété est beaucoup plus coûteux.
Si vous déployez de l'IA dans un contexte hospitalier, réalisez l'ADFR avant le démarrage. L'ADFR est une obligation du déployeur, pas du fournisseur, mais les fournisseurs qui proposent une documentation prête pour l'ADFR à leurs clients hospitaliers bénéficient d'un avantage significatif à l'achat.

DilAIg génère les quatre documents obligatoires dont les fournisseurs et les déployeurs ont besoin, y compris l'ADFR. Si vous développez de l'IA dans la santé et devez produire votre documentation technique de l'annexe IV, votre Déclaration de conformité, votre ADFR et votre Avis de transparence, démarrez votre audit en 50 questions sur dilaig.com.

FAQ : AI Act et IA dans la santé

Q : Chaque outil d'IA clinique nécessite-t-il une évaluation par un organisme notifié au titre de l'AI Act ? Pas nécessairement. Si l'IA est intégrée dans un dispositif médical nécessitant une évaluation par un organisme notifié en vertu du RDM/RDIV (Classe IIa et supérieure), cette évaluation couvre l'exigence de l'AI Act en vertu de l'article 6(1). Les logiciels cliniques autonomes qui ne se qualifient pas comme dispositifs médicaux sous le RDM peuvent nécessiter leur propre évaluation de la conformité à l'AI Act, selon la classification de l'annexe III. Les outils logiciels cliniques à risque plus faible qui ne répondent pas aux critères de l'annexe III peuvent s'autocertifier.

Q : Un hôpital peut-il utiliser un outil de diagnostic IA qui n'a pas encore de marquage CE au titre de l'AI Act ? Jusqu'en août 2026 (reportée au 2 décembre 2027 dans le cadre de l'accord Omnibus), les obligations de l'AI Act pour les systèmes à haut risque ne sont pas encore pleinement applicables pour les nouveaux systèmes mis sur le marché. Cependant, les systèmes mis sur le marché à partir de la date d'application effective devront satisfaire aux obligations complètes de l'AI Act avant le déploiement. Les hôpitaux qui procèdent à des achats d'outils de diagnostic IA maintenant doivent inclure les délais de conformité à l'AI Act dans leurs critères et contrats d'achat.

Q : Quelle est la différence entre une ADFR et une évaluation de la conformité à l'AI Act ? Une évaluation de la conformité est réalisée par ou pour le compte du fournisseur (l'entreprise qui a développé le système d'IA) pour démontrer que le système répond aux exigences techniques de l'AI Act. Une ADFR est réalisée par le déployeur (l'hôpital ou la clinique) pour évaluer l'impact spécifique du déploiement de ce système dans leur contexte sur les droits fondamentaux. Les deux sont requises, par des parties différentes, pour le même système à haut risque.

Q : L'AI Act s'applique-t-il à l'IA utilisée uniquement à des fins administratives dans un hôpital ? L'IA utilisée pour des tâches administratives, à savoir la planification, la facturation et l'allocation des ressources, n'est pas automatiquement à haut risque au titre de l'AI Act simplement parce qu'elle est utilisée dans un hôpital. Elle doit répondre à un critère de l'annexe III ou être un composant de sécurité de produit au titre de l'article 6(1) pour être classée à haut risque. L'IA administrative qui ne prend pas de décisions affectant les soins de patients individuels n'entre pas dans la classification à haut risque dans la plupart des cas.

Q : Comment le RGPD interagit-il avec les exigences de données d'entraînement de l'AI Act ? Les exigences de données d'entraînement de l'article 10 de l'AI Act et le RGPD opèrent en parallèle. Une entreprise d'IA dans la santé s'entraînant sur des données patients doit se conformer aux deux. Le RGPD exige une base légale valide pour le traitement de données de santé de catégorie spéciale, généralement le consentement explicite, des motifs de recherche scientifique ou un intérêt public substantiel en vertu du droit national. L'AI Act ajoute des exigences de qualité des données, de représentativité et d'examen des biais. Aucune réglementation ne prime sur l'autre.

Principaux points à retenir

L'IA dans la santé fait face à deux cadres réglementaires concurrents : l'AI Act et le RDM/RDIV. Les deux s'appliquent simultanément et doivent être traités ensemble.
En vertu de l'article 6(1) de l'AI Act, tout système d'IA intégré dans un dispositif médical réglementé est automatiquement classé comme étant à haut risque, quelle que soit la fonction de l'IA.
Le même organisme notifié peut conduire à la fois l'évaluation de la conformité RDM/RDIV et l'évaluation au titre de l'AI Act pour les produits de l'annexe I, permettant un processus coordonné plutôt que dupliqué.
Les articles 9 à 15 imposent des obligations spécifiques pour l'IA dans la santé en matière de gestion des risques, de diversité des données d'entraînement, de désagrégation des performances démographiques, de journalisation, de supervision humaine et de robustesse clinique.
Les hôpitaux sont des organismes publics et sont donc tenus de réaliser une ADFR (article 27) avant de déployer tout système d'IA à haut risque.
Les biais algorithmiques entre les données démographiques des patients constituent le domaine le plus scruté par les régulateurs et les organismes notifiés évaluant l'IA dans la santé.
Les fournisseurs qui intègrent la documentation de l'AI Act et du RDM dès la phase de conception évitent une adaptation coûteuse et créent un avantage à l'achat auprès des clients hospitaliers.