Partie 3: Règlement sur l'IA : articulations réglementaires et mise en conformité pratique
Par Vaclav Vlcek, MD
Le règlement sur l'IA s'applique rarement seul. Un dispositif médical est déjà soumis au RDM ou au règlement relatif aux dispositifs médicaux de diagnostic in vitro (RDIV). Le règlement sur l'IA s'applique lorsque la fonction concernée constitue un système d'IA relevant de son champ ; le RGPD s'applique lorsque des données à caractère personnel sont traitées ; et si le produit est commercialisé aux États-Unis comme dispositif médical, il relève également du cadre applicable de la FDA.
La partie 2: Exigences essentielles pour les systèmes d'IA des dispositifs médicaux traitait des exigences du règlement lui-même. Cette partie traite de l'articulation de ces exigences avec les autres régimes, et de la manière de mener un seul travail de conformité qui les couvre tous.
En bref
Pour un dispositif médical doté d'IA, le règlement sur l'IA s'applique parallèlement au règlement sectoriel applicable (RDM ou RDIV), au RGPD et, si le produit est commercialisé aux États-Unis comme dispositif médical, au cadre applicable de la FDA. En première approche, le RGPD régit la licéité du traitement des données à caractère personnel et les garanties dues aux personnes concernées, tandis que l'article 10 du règlement sur l'IA ajoute, pour les systèmes à haut risque, des exigences de qualité et de gouvernance des données. La séparation n'est pas nette : le RGPD régit également l'exactitude et la loyauté, et l'article 4 bis du règlement sur l'IA comporte une autorisation étroite de droit de l'Union pour certains traitements destinés à la détection des biais, sans écarter les autres exigences du RGPD.
Une analyse d'impact sur les droits fondamentaux au titre de l'article 27 peut être exigée de certains déployeurs en plus d'une analyse d'impact relative à la protection des données au titre du RGPD, mais son champ est étroit : un fabricant n'est pas visé du seul fait de sa qualité de fournisseur, même si l'obligation peut l'atteindre lorsqu'il est aussi déployeur relevant de l'une des catégories de l'article 27, paragraphe 1. Le règlement sur l'IA et le cadre de la FDA partagent une structure fondée sur le risque, mais divergent sur les droits fondamentaux, l'enregistrement et la gestion des modifications. Pour les systèmes classés exclusivement au titre de l'article 6, paragraphe 1, le chapitre III, sections 1 à 3 (à l'exception de l'article 6, paragraphe 5) s'applique à compter du 2 août 2028.
Comment le règlement sur l'IA et le RGPD s'articulent
Lorsqu'un dispositif médical doté d'IA traite des données à caractère personnel, deux règlements s'appliquent simultanément. En première approche, le RGPD régit la licéité du traitement et les garanties dues aux personnes concernées ; pour les systèmes à haut risque, l'article 10 du règlement sur l'IA ajoute des exigences de qualité et de gouvernance des données. Cette répartition n'est pas absolue, le RGPD régit aussi l'exactitude et la loyauté, et l'article 4 bis du règlement comporte une autorisation étroite de droit de l'Union pour certains traitements destinés à la détection des biais, sans écarter les autres exigences du RGPD, de sorte qu'un fabricant traite les deux régimes ensemble et non l'un après l'autre.
Gouvernance des données
Le point de départ est la qualité des données. L'article 10 du règlement sur l'IA exige que les jeux de données d'entraînement, de validation et de test d'un système à haut risque soient pertinents, suffisamment représentatifs et, dans la mesure du possible, exempts d'erreurs et complets, et que les biais éventuels soient examinés et atténués de manière appropriée. Lorsqu'un système d'IA à haut risque est développé sans recourir à des techniques d'entraînement de modèles d'IA, l'article 10, paragraphes 2 à 4, et l'article 4 bis, paragraphe 1, ne s'appliquent qu'aux jeux de données de test. Le RGPD considère les mêmes données sous un autre angle : au titre des articles 5 et 6, elles doivent être traitées de manière licite et loyale et sur une base valable au titre de l'article 6, par exemple le consentement, ou une mission d'intérêt public prévue par le droit de l'Union ou le droit d'un État membre. Un jeu de données doit donc franchir deux obstacles distincts avant de pouvoir être utilisé.
Exemple: prédiction du risque de diabète par IA. Une entreprise de technologie de santé développe un outil qui prédit le risque de diabète de type 2 à partir de dossiers médicaux électroniques, de questionnaires sur le mode de vie et de données génétiques. Au titre du RGPD, les données génétiques et de santé requièrent une base juridique au titre de l'article 6 et une exception particulière au titre de l'article 9, paragraphe 2, avant tout traitement. Si le système d'IA de l'outil est à haut risque, l'article 10 du règlement sur l'IA demande ensuite, dans la mesure où ces données sont utilisées dans les jeux de données d'entraînement, de validation ou de test, si elles sont pertinentes et suffisamment représentatives pour la tâche de prédiction, et si les biais éventuels dans l'étiquetage et la collecte ont été examinés et atténués de manière appropriée.
Des données peuvent être détenues licitement et rester en deçà de ce qu'exige l'article 10.
Minimisation des données et représentativité
Il faut ici respecter les deux régimes simultanément, ce qui demande de la rigueur. L'article 10 exige la pertinence, une représentativité suffisante et des contrôles contre les biais. Il n'exige pas de maximiser les données, et un plus grand nombre de variables ne réduit pas de lui-même les écarts de performance entre groupes de patients. Le RGPD limite les données à caractère personnel traitées à ce qui est nécessaire au regard de la finalité déclarée, en vertu du principe de minimisation des données (article 5, paragraphe 1, point c)). Les exigences de l'article 10 doivent donc être atteintes en cohérence avec la minimisation des données, et non en contradiction avec elle.
Exemple: prédiction du risque de réadmission hospitalière. Une entreprise du secteur de la santé développe un modèle qui prédit une réadmission dans les 30 jours suivant la sortie, entraîné sur les antécédents médicaux, des indicateurs de mode de vie, le statut socio-économique, la maîtrise de la langue et les conditions de logement. L'article 10 demande si ce jeu de données est pertinent et suffisamment représentatif pour la population visée, et si les biais éventuels ont été examinés et atténués, non s'il est volumineux. Le RGPD demande séparément si le niveau de revenu et la situation de logement sont nécessaires au regard de la finalité déclarée. Chaque variable doit se justifier sous les deux angles.
En pratique, la solution consiste à documenter, pour chaque variable, pourquoi elle est nécessaire et non simplement utile.
Transparence et droits des personnes concernées
La transparence traverse les deux régimes, sous des angles différents. Le RGPD (articles 12 à 16) donne à une personne le droit de savoir comment ses données sont collectées et utilisées, et d'y réagir, la rectification figurant à l'article 16. Le règlement sur l'IA (article 13) exige qu'un système à haut risque soit suffisamment transparent pour que les déployeurs puissent interpréter ses sorties et les utiliser de manière appropriée, accompagné d'une notice d'utilisation portant sur la destination, la performance, les limites et les mesures de contrôle humain.
Exemple: un système de triage à IA dans un hôpital. Le système priorise les patients des urgences à partir des paramètres vitaux, des symptômes et des antécédents. Au titre du RGPD, l'hôpital doit fournir les informations pertinentes prévues à l'article 13 ou 14, sous réserve des exceptions légales, finalité, base juridique, durée de conservation, ainsi que les droits d'accès et de rectification. Le règlement sur l'IA répartit les obligations différemment : l'article 13 impose au fournisseur de rendre le système transparent pour l'hôpital en tant que déployeur, avec des instructions sur la performance et les limites, tandis que l'article 26 confie à l'hôpital les obligations liées à l'utilisation, dont l'affectation du contrôle humain à un personnel compétent et l'utilisation conforme à ces instructions. À noter également que ce cas d'usage figure à l'annexe III en tant que « systèmes de tri des patients admis dans les services de santé d'urgence » : il peut donc être classé au titre de l'article 6, paragraphe 2, indépendamment de toute voie relevant de l'annexe I.
Satisfaire les exigences du RGPD ne règle pas celles du règlement. Ce dernier vise à ce que les déployeurs puissent interpréter la sortie et l'utiliser de manière appropriée, plutôt que de la suivre aveuglément.
Catégories particulières de données à caractère personnel
Les données de santé font l'objet d'un traitement particulier dans les deux régimes. Au titre de l'article 9 du RGPD, les données de santé ne peuvent être traitées que dans des conditions strictes, par exemple sur le fondement d'un consentement explicite ou d'une autre condition ou exception applicable prévue à l'article 9, paragraphe 2, telle qu'un motif de santé publique prévu par le droit de l'Union ou le droit d'un État membre. Le fait qu'un signal donné relève de l'article 9 dépend de ce qu'il révèle : les mesures d'humeur, de sommeil et issues d'objets connectés constituent des catégories particulières de données dans la mesure où elles révèlent l'état de santé ou une autre caractéristique de l'article 9, et les données biométriques ne constituent des catégories particulières que lorsqu'elles sont traitées aux fins d'identifier une personne de manière unique.
Le règlement sur l'IA ajoute ses propres conditions par l'article 10 et exige que ces mêmes données soient suffisamment représentatives et de qualité contrôlée. Séparément, l'article 4 bis (inséré par le train de mesures omnibus numérique, qui a supprimé l'ancien article 10, paragraphe 5) comporte une autorisation étroite de droit de l'Union, destinée à satisfaire l'article 9, paragraphe 2, point g), du RGPD, pour certains traitements de catégories particulières de données aux fins de la détection et de la correction des biais. L'article 4 bis, paragraphe 1, concerne les fournisseurs de systèmes à haut risque. L'article 4 bis, paragraphe 2, étend cette autorisation, dans les mêmes conditions et sous les mêmes garanties, aux fournisseurs et déployeurs d'autres systèmes et modèles d'IA ainsi qu'aux déployeurs de systèmes à haut risque. Ces garanties sont cumulatives et non alternatives. L'article 4 bis, paragraphe 2, ne crée pas par lui-même, pour ces acteurs, d'obligation de procéder à une détection ou une correction des biais ; les fournisseurs de systèmes à haut risque restent soumis aux obligations distinctes de l'article 10, paragraphe 2, points f) et g). À noter également que l'article 4 bis ne dispense pas d'une base juridique au titre de l'article 6 du RGPD et n'écarte pas les autres exigences du RGPD.
Exemple: évaluation du risque de trouble psychique. Une plateforme de santé numérique évalue le risque de dépression à partir de questionnaires remplis par les patients, de données comportementales et de données issues d'objets connectés. Dans la mesure où ces signaux d'humeur, de sommeil et d'objets connectés révèlent l'état de santé, il s'agit de données de santé au sens de l'article 9 du RGPD : le traitement requiert donc un consentement explicite ou une autre condition ou exception applicable prévue à l'article 9, paragraphe 2. Si le système d'IA de la plateforme est à haut risque, l'article 10 exige ensuite, dans la mesure où ces données sont utilisées dans les jeux de données d'entraînement, de validation ou de test, qu'elles soient pertinentes et suffisamment représentatives pour la prédiction, que les biais éventuels soient examinés et atténués, et qu'une gouvernance des données documentée existe.
Un jeu de données de grande qualité dépourvu de base juridique ne peut pas être utilisé du tout. Les mesures de sécurité techniques et organisationnelles peuvent en partie s'inscrire dans un système de management de la sécurité de l'information, pour lequel nous proposons un conseil ISO 27001 ; la base juridique, la limitation des finalités, les droits des personnes concernées et la gouvernance des données de l'article 10 vont au-delà.
Analyses d'impact
Deux analyses d'impact peuvent s'appliquer au même système, et elles ne sont pas interchangeables. L'analyse d'impact relative à la protection des données du RGPD (article 35) apprécie les conséquences du traitement pour la protection des données à caractère personnel et les risques pour les droits et libertés des personnes physiques.
L'analyse d'impact sur les droits fondamentaux du règlement sur l'IA figure à l'article 27, pèse sur les déployeurs et non sur les fournisseurs, est réalisée avant le déploiement, et a un champ étroit. Elle ne s'applique qu'aux systèmes classés au titre de l'article 6, paragraphe 2, à l'exception de l'annexe III, point 2, et seulement lorsque le déployeur est un organisme de droit public, une entité privée fournissant des services publics, ou un déployeur de systèmes d'évaluation de la solvabilité ou de tarification en assurance vie et santé visés à l'annexe III, points 5 b) et c). Un fabricant n'est pas visé du seul fait de sa qualité de fournisseur ; l'obligation peut toutefois l'atteindre lorsqu'il est aussi déployeur relevant de l'une des catégories de l'article 27, paragraphe 1. Elle ne s'applique pas non plus à tout système à haut risque du secteur public. Lorsque les deux s'appliquent, elles s'articulent : l'article 27, paragraphe 4, permet de renvoyer, dans l'analyse d'impact sur les droits fondamentaux, à une analyse d'impact relative à la protection des données réalisée au titre de l'article 35 du RGPD, ou d'en reprendre les parties pertinentes. Elles répondent néanmoins à des questions différentes, car un traitement licite et bien documenté ne garantit pas un résultat équitable.
Obligation de rendre compte
Les deux régimes créent des obligations étendues de responsabilité, de documentation et de conservation. Le principe de responsabilité du RGPD (article 5, paragraphe 2, et article 24) rend le responsable du traitement comptable de la conformité et lui impose d'être en mesure de la démontrer. Le règlement sur l'IA reprend une logique comparable : un fournisseur d'un système à haut risque met en place un système de gestion de la qualité documenté (article 17), établit la documentation technique (article 11) et la tient, avec les autres pièces prescrites, à la disposition des autorités pendant dix ans après la mise sur le marché ou la mise en service (article 18).
Comment le règlement se situe par rapport au cadre de la FDA américaine
Un fabricant qui commercialise un produit dans l'Union et aux États-Unis comme dispositif médical doit composer avec deux cadres réglementaires dont la logique de fond est proche, mais dont la portée diffère. Toutes deux procèdent par le risque, et toutes deux s'intéressent à la transparence, au suivi et à la qualité.
La FDA agit dans le paradigme du dispositif médical ; le règlement sur l'IA opère de manière transversale et ajoute un cadre transversal de droits fondamentaux auquel il n'existe pas d'équivalent direct côté FDA. Le cadre américain a également évolué : la FDA a modifié le 21 CFR Part 820, l'a renommé Quality Management System Regulation (QMSR) et a rendu la réglementation modifiée applicable au 2 février 2026. Elle incorpore par renvoi l'ISO 13485:2016 et l'article 3 de l'ISO 9000:2015. La convergence est réelle mais incomplète. Dans l'Union, l'application des normes harmonisées demeure volontaire, et l'article 17, paragraphe 3, permet d'intégrer les éléments du système de gestion de la qualité du règlement au système de gestion de la qualité existant au titre du RDM ou du RDIV, généralement structuré autour de l'EN ISO 13485, plutôt que d'imposer une norme déterminée. Nous accompagnons cette transition avec notre conseil FDA 21 CFR 820.
Exemple: un même corpus d'éléments de preuve, deux marchés. Un fabricant qui prépare une soumission 510(k) et une évaluation de la conformité dans l'Union peut constituer une grande partie des éléments de gouvernance des données et de validation de la performance une seule fois et les réutiliser lorsque cela est pertinent, avec des compléments propres à chaque ordre juridique. Pour un système d'IA classé à haut risque au titre de l'article 6, paragraphe 1, l'organisme notifié examine les exigences applicables, dont les articles 10 et 15. Du côté de la FDA, les exigences légales et réglementaires applicables prévalent ; les principes de la Good Machine Learning Practice (GMLP) sont des principes directeurs non contraignants. Un plan de contrôle des modifications prédéterminées (Predetermined Change Control Plan, PCCP) est un instrument prévu pour les modifications planifiées, qu'un fabricant propose dans sa soumission de mise sur le marché et sur lequel la version définitive des lignes directrices de la FDA d'août 2025 formule des recommandations — et non quelque chose que comporte chaque soumission.
Les deux tableaux qui suivent présentent la comparaison.
| Aspect | FDA | Règlement sur l'IA |
|---|---|---|
| Approche fondée sur le risque | Classe les types de produits selon le risque et les contrôles nécessaires pour garantir la sécurité et l'efficacité ; la destination et les indications influent également sur la classification | Interdit certaines pratiques (article 5), classe certains systèmes comme étant à haut risque (article 6) et attache à d'autres des obligations de transparence (article 50) |
| Transparence et explicabilité | Met l'accent sur l'étiquetage, la formation des utilisateurs et la compréhension du système | Impose juridiquement la transparence (article 13) : capacités, destination, contrôle humain |
| Gestion du cycle de vie | Les obligations applicables de la FDA après commercialisation continuent de s'appliquer. Le document de janvier 2025 sur le cycle de vie de l'IA demeure un projet de lignes directrices et recommande un suivi sur l'ensemble du cycle de vie du produit ; les lignes directrices PCCP d'août 2025 sont définitives et portent sur certaines modifications planifiées | Exige une surveillance après commercialisation (article 72) et une nouvelle évaluation de la conformité en cas de modification substantielle (article 43, paragraphe 4) |
| Contrôle humain | Les documents de la FDA traitent, le cas échéant, de l'aptitude à l'utilisation et de l'interaction entre l'humain et l'IA ; il n'existe pas d'équivalent direct à l'obligation transversale du règlement sur l'IA | Obligatoire pour les systèmes à haut risque (article 14) |
| Biais et équité | Les principes GMLP traitent des jeux de données représentatifs et de la performance sur les populations visées, mais ces principes ne sont pas contraignants ; les exigences légales applicables de la FDA demeurent exécutoires | L'article 10 encadre expressément les biais dans les données ; l'article 9 les prend en compte dans la gestion des risques lorsqu'ils présentent des risques pertinents |
| Gestion de la qualité | QMSR (21 CFR Part 820), qui renvoie à l'ISO 13485:2016 et à l'article 3 de l'ISO 9000:2015, applicable depuis le 2 février 2026 | Système de gestion de la qualité de l'article 17 ; en vertu de l'article 17, paragraphe 3, ses éléments peuvent être intégrés au système de gestion de la qualité existant au titre du RDM ou du RDIV, l'application des normes demeurant volontaire |
Tableau 1 : là où les approches de la FDA et du règlement sur l'IA se recoupent. Les références au règlement sur l'IA renvoient au règlement (UE) 2024/1689 tel que modifié par le train de mesures omnibus numérique, règlement (UE) 2026/1744. Plusieurs des dispositions citées ici ont été modifiées ; voir la note de citation ci-dessous.
| Aspect | FDA | Règlement sur l'IA |
|---|---|---|
| Cadre juridique | Cadre de la FDA pour les dispositifs médicaux | Transversal, avec un accent sur les droits fondamentaux |
| Encadrement éthique | Pas de régime transversal directement équivalent en matière de droits fondamentaux ; les documents de la FDA traitent néanmoins des biais, de la transparence, de l'interaction entre l'humain et l'IA et de l'équité en santé | Central : interdit les usages manipulateurs ou abusifs (article 5) et exige des analyses d'impact sur les droits fondamentaux de certains déployeurs |
| Gestion des modifications | PCCP pour les modifications planifiées des fonctions logicielles de dispositifs fondées sur l'IA, selon les lignes directrices définitives d'août 2025 | L'article 43, paragraphe 4, exige une nouvelle évaluation de la conformité en cas de modification substantielle. Pour les systèmes qui continuent d'apprendre, les modifications prédéterminées et documentées lors de l'évaluation initiale de la conformité ne constituent pas une modification substantielle |
| Incidences sur les droits fondamentaux | Pas d'obligation directement équivalente d'analyse d'impact sur les droits fondamentaux | Exigée uniquement de certains déployeurs de systèmes relevant de l'article 6, paragraphe 2 (article 27) ; un fabricant n'est pas visé du seul fait de sa qualité de fournisseur, mais peut l'être en tant que déployeur relevant de l'une des catégories de l'article 27, paragraphe 1 |
| Enregistrement public | Enregistrement de l'établissement et listage du produit, le cas échéant | L'enregistrement au titre de l'article 49 couvre principalement les systèmes de l'annexe III et les constatations au titre de l'article 6, paragraphe 3 ; un produit classé exclusivement au titre de l'article 6, paragraphe 1, n'en relève en général pas, et certaines parties de la base de données ne sont pas publiques |
Tableau 2 : là où les approches de la FDA et du règlement sur l'IA divergent. Les références au règlement sur l'IA renvoient au règlement (UE) 2024/1689 tel que modifié par le règlement (UE) 2026/1744.
La lecture pratique pour un fabricant présent à l'échelle mondiale : les deux cadres réglementaires traitent des modifications planifiées après la mise sur le marché, mais avec des éléments déclencheurs, des procédures et des conséquences juridiques différents. Un PCCP n'est donc pas assimilable à la modification substantielle du règlement sur l'IA.
Deux compléments européens souvent cités sont plus étroits qu'il n'y paraît. L'analyse d'impact sur les droits fondamentaux n'atteint que certains déployeurs de systèmes relevant de l'article 6, paragraphe 2 — un fabricant n'est pas visé du seul fait de sa qualité de fournisseur — et l'enregistrement au titre de l'article 49 ne concerne en général pas un produit classé exclusivement au titre de l'article 6, paragraphe 1.
Un chemin de conformité pratique
Le travail se maîtrise mieux lorsqu'il suit un ordre, et une grande partie des éléments de preuve qu'un fabricant produit déjà pour le RDM, le RDIV ou la FDA peut être réutilisée lorsque cela est pertinent.
Qualifier le produit, classer le système d'IA et déterminer les rôles
Déterminer si le produit contient un système d'IA ou constitue lui-même un système d'IA, en appliquant chaque élément de l'article 3, point 1. La capacité d'inférence, au-delà d'un traitement de données simple, est un critère distinctif central, et le système doit en outre présenter un certain degré d'autonomie. Pour la classification à haut risque, vérifier les deux volets de l'article 6, paragraphe 1 : que l'IA soit un composant de sécurité d'un produit ou constitue elle-même un produit couvert par une législation de l'annexe I, section A, telle que le RDM ou le RDIV, et que ce produit soit soumis à une évaluation de la conformité par un tiers.
Se référer à l'article 6, paragraphes 1 bis et 1 ter, pour déterminer si l'IA constitue un composant de sécurité, le paragraphe 1 bis écarte les systèmes utilisés exclusivement pour certaines fonctions étrangères à la sécurité, le paragraphe 1 ter rétablit cette qualité lorsqu'une défaillance ou un dysfonctionnement mettrait en danger la santé et la sécurité, L'article 6, paragraphe 1 quater, précise quant à lui si la condition d'évaluation de la conformité par un tiers de l'article 6, paragraphe 1, point b), est remplie. L'annexe III doit être analysée séparément, un système pouvant être classé de manière indépendante au titre de l'article 6, paragraphe 2. Déterminer ensuite les rôles en présence : fournisseur, fabricant de produits, déployeur, mandataire, importateur ou distributeur. Le fabricant du produit peut notamment devenir le fournisseur d'un système d'IA intégré. Pour le marché américain, déterminer si le produit ou la fonction logicielle constitue un dispositif, s'il s'agit d'un logiciel dispositif médical ou d'un logiciel intégré à un dispositif médical selon le cas, sa classification FDA et la voie de mise sur le marché applicable. Le rôle détermine toutes les obligations qui suivent.
Réaliser une analyse d'écart entre les régimes
Confronter la conformité existante au titre du RDM/RDIV et de l'ISO 13485 aux obligations du règlement, en particulier la gouvernance des données (article 10), le contrôle humain (article 14) et la transparence (article 13). Y opposer les exigences légales et lignes directrices applicables de la FDA, dont les principes GMLP et, lorsqu'un PCCP est proposé, les lignes directrices PCCP de la FDA, ainsi que le suivi en conditions réelles, de sorte qu'une seule liste d'écarts serve les deux marchés.
Étendre le système de gestion de la qualité et la documentation technique
Intégrer les éléments relatifs à l'IA prévus à l'article 17 dans le système qualité existant par l'intermédiaire de l'article 17, paragraphe 3, et construire la documentation technique de l'article 11 (architecture, sources et gouvernance des données, contrôles des risques et cybersécurité au titre de l'article 15) de manière à servir, autant que possible, à la fois à une évaluation de la conformité dans l'Union et à une soumission à la FDA, avec des compléments propres à chaque ordre juridique. En vertu de l'article 43, paragraphe 3, ce sont les exigences de la section 2 et l'évaluation du système de gestion de la qualité de l'article 17 qui entrent dans la procédure sectorielle.
Réunir les compétences requises
Mobiliser, en interne ou au moyen d'un examen externe, des personnes compétentes en IA à haut risque dans le secteur de la santé, en validation des modèles, en atténuation des biais et dans la réalisation des analyses d'impact relatives à la protection des données et aux droits fondamentaux.
Assurer la traçabilité et la documentation des jeux de données
Tenir les données d'entraînement, de validation et de test traçables et documentées, en consignant les procédures de prétraitement et d'étiquetage ainsi que les contrôles qualité appliqués. Pour l'évaluation dans l'Union, l'annexe VII, point 4.3, prévoit que l'organisme notifié se voie accorder un accès complet à ces jeux de données dans la mesure où cela est pertinent et limité à ce qui est nécessaire à l'accomplissement de ses tâches, sous réserve, le cas échéant, de garanties de sécurité. Pour l'examen par la FDA, fournir les informations et données probantes requises par la voie applicable ; cela n'équivaut pas automatiquement à remettre les jeux de données bruts. Identifier les catégories particulières de données à caractère personnel, appliquer les exigences du RGPD et, lorsque l'article 4 bis est invoqué pour la détection ou la correction des biais, satisfaire ses conditions cumulatives.
Suivre les orientations et les échéances ouvertes
Suivre la Commission européenne, le Bureau de l'IA et les autorités nationales sur l'articulation entre le RDM et le règlement, ainsi que la FDA sur les GMLP, le PCCP et la mise en œuvre de la QMSR, qui renvoie désormais à l'ISO 13485. Deux dates méritent d'être inscrites au calendrier : la Commission doit adopter les actes délégués de l'article 2, paragraphe 13, au plus tard le 2 août 2027, et les organismes notifiés relevant de l'annexe I, section A, auxquels l'article 43, paragraphe 3, renvoie doivent demander une désignation au titre du règlement au plus tard le 28 janvier 2028 : il s'agit d'une échéance pour déposer la demande, non pour l'obtenir.
Où cela laisse un fabricant
Sur l'ensemble des trois parties, la forme de la tâche est claire. Un système d'IA lié à un dispositif médical est classé à haut risque par l'article 6, paragraphe 1, lorsque les deux conditions sont réunies, en appliquant les précisions des paragraphes 1 bis à 1 quater ; l'ensemble des exigences prolonge largement les systèmes sectoriels et qualité déjà en place ; et le règlement s'articule avec le RGPD, le cadre de la FDA, le RDM et le RDIV en des points déterminés, qui peuvent être traités ensemble. Sur le calendrier, le chapitre III, sections 1 à 3 (à l'exception de l'article 6, paragraphe 5) s'applique à compter du 2 août 2028 aux systèmes classés exclusivement au titre de l'article 6, paragraphe 1, sous réserve de l'article 111. L'article 113 attribue le 2 décembre 2027 à la voie de l'article 6, paragraphe 2, et de l'annexe III, et le 2 août 2028 à la voie de l'article 6, paragraphe 1, et de l'annexe I. Lorsqu'une seule voie s'applique, la date est claire. Le règlement ne détermine pas expressément la date lorsqu'un système relève indépendamment des deux voies.
La conformité documentaire est la partie la plus accessible. Le défi durable consiste à construire des produits dotés d'IA et des systèmes qualité qu'une équipe peut exploiter, tenir à jour et présenter à un organisme notifié.
Un fabricant qui traite le règlement comme une extension des systèmes qu'il exploite déjà, et non comme un régime séparé, est mieux placé pour cela.
QMLogic accompagne les fabricants sur ce terrain avec son conseil EU AI Act pour les logiciels de dispositifs médicaux. La série commence par Ce que le règlement sur l'IA implique pour les dispositifs médicaux.
Questions fréquentes
Le respect du RGPD signifie-t-il que les données sont aussi conformes au règlement sur l'IA ?
Non. En première approche, le RGPD régit la licéité du traitement et les garanties dues aux personnes concernées, tandis que l'article 10 du règlement sur l'IA ajoute, pour les systèmes à haut risque, des exigences de qualité et de gouvernance des données : pertinentes, suffisamment représentatives et, dans la mesure du possible, exemptes d'erreurs et complètes, avec des biais éventuels examinés et atténués de manière appropriée. Des données peuvent être licites au titre du RGPD et rester en deçà des exigences de l'article 10.
Une analyse d'impact sur les droits fondamentaux est-elle la même chose qu'une analyse d'impact relative à la protection des données ?
Non. Une analyse d'impact relative à la protection des données au titre de l'article 35 du RGPD apprécie les conséquences du traitement envisagé pour la protection des données à caractère personnel et les risques pour les droits et libertés des personnes physiques. Une analyse d'impact sur les droits fondamentaux au titre de l'article 27 du règlement sur l'IA apprécie les risques pour les droits fondamentaux. Elle pèse sur les déployeurs mentionnés à l'article 27, paragraphe 1, et non sur les fournisseurs du seul fait de leur qualité de fournisseur : organismes de droit public, entités privées fournissant des services publics, et déployeurs de systèmes visés à l'annexe III, points 5 b) et c), relatifs à l'évaluation de la solvabilité et à l'assurance vie et santé, pour les systèmes classés au titre de l'article 6, paragraphe 2, à l'exception de l'annexe III, point 2. Lorsque les deux s'appliquent, l'article 27, paragraphe 4, permet de renvoyer à une analyse d'impact relative à la protection des données ou d'en reprendre les parties pertinentes.
Le règlement sur l'IA s'aligne-t-il sur l'approche de la FDA américaine ?
En partie. Les deux procèdent par le risque et traitent de la transparence, du suivi et de la gestion de la qualité, et depuis le 2 février 2026 la QMSR de la FDA renvoie à l'ISO 13485:2016. La convergence est incomplète : dans l'Union, l'application des normes harmonisées demeure volontaire, et l'article 17, paragraphe 3, permet l'intégration au système de gestion de la qualité existant au titre du RDM ou du RDIV plutôt que d'imposer une norme. Les approches divergent sur les droits fondamentaux, l'enregistrement et le traitement des modifications : un fabricant présent à l'échelle mondiale planifie donc pour les deux.
Quelle est la première étape pratique vers la conformité au règlement sur l'IA ?
La classification et le rôle. Vérifier si le produit est un système d'IA, puis vérifier les deux conditions de l'article 6, paragraphe 1 : que l'IA soit un composant de sécurité d'un produit relevant de l'annexe I, section A, ou constitue elle-même un tel produit, par exemple couvert par le RDM ou le RDIV, et que ce produit soit soumis à une évaluation de la conformité par un tiers. L'article 6, paragraphes 1 bis et 1 ter, encadre la voie du composant de sécurité, et l'article 6, paragraphe 1 quater, la voie de l'évaluation par un tiers. L'annexe III doit être analysée séparément, l'article 6, paragraphe 2, pouvant classer un système de manière indépendante. Déterminer ensuite si l'entreprise est fournisseur ou déployeur.
