Le Règlement européen sur l’Intelligence Artificielle (IA Act) instaure les systèmes d’IA « à haut risque ». Ces systèmes nécessitent un véritable « Passeport » pour entrer en Europe. Ils font l’objet d’exigences strictes de conformité avant et pendant leur mise en service, car ils peuvent affecter de manière significative la santé, la sécurité ou les droits fondamentaux des personnes.

Cette catégorie inclut par exemple les IA utilisées dans le recrutement (tri de CV), le crédit bancaire, l’accès à l’éducation ou à des services publics essentiels, la reconnaissance biométrique ciblée, l’évaluation de candidats à un emploi ou de justiciables, etc..

Le présent article se concentre sur les obligations juridiques concrètes incombant aux acteurs intervenant sur les systèmes d’IA à haut risque, en mettant en avant les exigences de l’IA Act en matière de conformité. Nous examinerons les obligations qui pèsent sur chaque type d’acteur – du fournisseur/développeur de l’IA jusqu’à son utilisateur professionnel (déployeur), en passant par les importateurs et distributeurs – ainsi que les conditions pratiques de mise en conformité prévues par le règlement.

1. Définition des systèmes d’IA à haut risque selon l’AI Act

Le chapitre III du Règlement IA définit les critères qualifiant une IA de « haut risque ». Nous les avons présentés dans notre article précédent.

Les systèmes d’IA ainsi qualifiés ne sont pas interdits (à la différence des usages « à risque inacceptable » bannis par le règlement, comme le scoring social ou la manipulation cognitive de populations), mais leur mise sur le marché est conditionnée au respect de nombreuses exigences légales. Ils doivent notamment être enregistrés dans une base de données européenne dédiée (art. 49 et 71) et faire l’objet d’une évaluation de conformité préalable (autoévaluation ou audit par un tiers selon les cas – art. 43).

De plus, le législateur européen a prévu un délai transitoire, jusqu’à 2 août 2026, pour l’application de ces obligations.

2. Exigences de conformité applicables aux systèmes d’IA à haut risque

Tous les systèmes d’IA à haut risque doivent satisfaire à un noyau d’exigences obligatoires portant sur leur conception et leur fonctionnement (IA Act, chap. III sec. 2). Il s’agit de garanties techniques et organisationnelles destinées à assurer la sécurité, la fiabilité, la transparence et le respect des droits fondamentaux tout au long du cycle de vie du système.

Ces exigences doivent être prises en compte dès la phase de développement et être documentées pour prouver la conformité.

En pratique, elles constituent autant de chantiers à mettre en œuvre par le fournisseur de l’IA avant mise sur le marché.

2.1. La mise en place d’un système de gestion des risques (art. 9)

Le développeur doit instaurer un processus de gestion des risques continu et itératif tout au long du cycle de vie de l’IA.

Concrètement, il s’agit d’identifier et d’évaluer de manière proactive les risques pour la santé, la sécurité ou les droits en lien avec l’usage prévu du système, puis de mettre en œuvre les mesures de remédiation adaptées.

Ce processus se poursuit après la mise en service, grâce aux données collectées durant l’utilisation réelle (retours du déployeur, incidents, etc.) afin de mettre à jour l’évaluation des risques et apporter des corrections si nécessaire.

Par exemple, pour un logiciel d’IA évaluant des candidatures à l’embauche, le fournisseur devra identifier les risques de discrimination ou d’erreur de classement des candidats, tester son algorithme pour mesurer ces risques et prévoir des garde-fous (interventions humaines, ajustements de paramètres) afin de les réduire à un niveau acceptable.

2.2. La qualité des données et gouvernance (art. 10)

Les jeux de données utilisés pour entraîner, valider et tester le système doivent répondre à des critères stricts de qualité, de pertinence et de représentativité.

L’IA Act impose d’examiner et corriger les biais éventuels dans les données susceptibles d’affecter la sécurité ou les droits fondamentaux (biais conduisant à de la discrimination notamment).

Le fournisseur doit mettre en place des procédures de gestion des données (traçabilité de leur origine, nettoyage, annotation, etc.) et pouvoir démontrer que les données sont aussi complètes et exemptes d’erreurs que possible eu égard à l’usage visé.

Le règlement autorise d’ailleurs, si nécessaire, l’utilisation de données sensibles (par ex. sur l’origine ethnique ou la santé) pour détecter et corriger des biais – sous réserve de justifier qu’aucune alternative (données synthétiques, anonymisées) ne permettait d’atteindre ce résultat (art. 10, §5).

Par exemple le fournisseur d’une IA de reconnaissance faciale devra veiller à ce que son jeu d’entraînement comporte une diversité suffisante de visages (âges, origines, genres) afin d’éviter des taux d’erreur plus élevés pour certains groupes, et devra effectuer des tests pour détecter d’éventuels biais raciaux ou de genre dans les résultats, en prenant des mesures correctives si un biais est détecté.

2.3. Documentation technique (art. 11)

Une documentation exhaustive du système d’IA doit être rédigée et tenue à jour, conformément à la liste d’éléments détaillés figurant à l’annexe IV de l’IA Act.

Cette documentation comprend notamment une description du système, de son architecture et de son mode de fonctionnement (y compris les algorithmes utilisés), les données employées, les tests effectués, les mesures de gestion des risques appliquées et la description des indicateurs de performance.

Elle a pour objectif de démontrer la conformité du système aux exigences du RIA et de fournir aux autorités de surveillance les informations nécessaires pour évaluer cette conformité.

2.4. Enregistrement des activités (logs) (art. 12)

Le système d’IA à haut risque doit être conçu de manière à enregistrer automatiquement les événements significatifs survenant lors de son fonctionnement (historique d’utilisation, résultats produits, erreurs, etc.).

Cette traçabilité permet de comprendre et expliquer ultérieurement les décisions de l’IA, investiguer les incidents ou non-conformités, et d’une manière générale assurer le suivi du comportement du système sur le terrain.

Les « journaux » (logs) ainsi générés devront être conservés pendant une durée d’au moins 6 (six) mois (art. 19) et mis à disposition des autorités en cas d’enquête.

Par exemple un système d’IA de diagnostic médical devra enregistrer pour chaque cas les recommandations ou résultats qu’il a fournis, les données d’entrée principales, l’heure et l’identifiant de la session, afin qu’en cas d’erreur de diagnostic signalée, on puisse retracer ce qui s’est passé.

2.5. La transparence vis-à-vis du déployeur (art. 13)

Le règlement n’impose pas ici de transparence directe envers les personnes physiques concernées (ce point relève d’autres dispositions ou du RGPD), mais bien envers l’utilisateur professionnel (déployeur) du système.

Le fournisseur doit fournir avec l’IA des instructions d’utilisation claires, complètes et compréhensibles pour le déployeur.

Cette notice doit notamment décrire les capacités et les limites du système, les performances attendues (ex. niveaux de précision avec leurs métriques), les mesures de surveillance humaine à mettre en place lors de l’utilisation (voir infra), les exigences matérielles ou logicielles nécessaires pour le faire fonctionner, les éventuels réglages ou maintenance requis, ainsi que la manière d’utiliser et d’interpréter les logs générés.

L’objectif est que le client/déployeur comprenne le fonctionnement du système et ses enjeux afin de l’utiliser de façon appropriée et conforme : « le fonctionnement de l’IA doit permettre aux déployeurs d’interpréter correctement ses sorties d’un système et de les utiliser de manière appropriée » (art. 13 §1).

En pratique, cette obligation devrait se traduire par la remise d’un manuel utilisateur détaillé et d’informations sur les performances et limites du modèle.

2.6. Surveillance humaine (art. 14)

Il s’agit d’une exigence centrale de l’IA Act : le système d’IA à haut risque doit être conçu et développé de sorte à pouvoir être effectivement supervisé par des êtres humains lors de son utilisation.

Il faut prévoir des mesures techniques et organisationnelles permettant à une personne de garder le contrôle ou du moins d’avoir un regard critique sur le fonctionnement de l’IA.

L’IA Act distingue deux types de mesures de surveillance humaine, qui peuvent être combinées :

• des mécanismes intégrés dans le système lui-même par le fournisseur (par exemple des alertes en cas de situation ambiguë, la possibilité pour l’IA de se mettre en pause ou de solliciter une validation humaine avant une action critique, etc.), et/ou ;

• des mesures à mettre en œuvre par le déployeur utilisateur (procédures internes, double-vérification humaine des décisions, etc.), définies en amont par le fournisseur.

En pratique, le fournisseur doit livrer un système tel que les personnes chargées de l’utiliser ou de le superviser puissent : comprendre ses capacités et limites, surveiller son fonctionnement et détecter d’éventuels signes d’anomalie ou d’erreur, rester conscientes du risque d’ « automatisation biaisée » (le fait de faire aveuglément confiance à l’IA), et interpréter correctement ses résultats pour prendre des décisions éclairées.

Par exemple un logiciel d’IA d’aide à la décision pour accorder des crédits doit permettre aux analystes humains de vérifier les facteurs ayant conduit à la recommandation de l’IA, de repérer si l’algorithme se comporte de façon inattendue (ex : un score de risque anormalement élevé pour un profil habituellement sans risque) et de reprendre la main sur la décision finale. Le fournisseur pourra indiquer dans la notice les points à surveiller et pourra intégrer des explications ou justifications visibles par l’agent humain pour chaque décision de l’IA.

2.7. Niveaux de performance, robustesse et cybersécurité (art. 15)

Le système d’IA doit afficher un niveau de performance approprié en termes de précision, de fiabilité et de sécurité cybernétique, y compris en tenant compte d’une utilisation prolongée du système.

Le fournisseur doit s’assurer que l’IA maintien des performances constantes dans ces domaines tout au long de son cycle de vie, en particulier face à des conditions d’utilisation variées ou à des interactions avec des utilisateurs humains ou d’autres systèmes.

L’IA doit être robuste, c’est-à-dire résiliente aux erreurs ou incohérences internes, et si elle continue à apprendre en phase d’utilisation (systèmes évolutifs), elle doit éviter les effets de boucle auto-renforçante (par exemple, éviter qu’un biais initial ne se renforce à chaque nouvel apprentissage). Côté cybersécurité, l’IA doit être protégée contre des attaques visant à altérer ses résultats ou son comportement : l’Act mentionne explicitement la résistance aux tentatives d’empoisonnement de données ou de modèle et aux exemples contradictoires (adversarial examples).

Un système d’IA à haut risque ne doit pas pouvoir être facilement trompé ou manipulé par des acteurs malveillants.

Par exemple pour une IA de détection de fraudes, le fournisseur devra tester la capacité du système à résister à des entrées spécialement conçues pour contourner les détections (« adversarial attacks ») et mettre en place des contrôles pour prévenir toute altération non autorisée du modèle ou de ses données d’entraînement.

Toutes ces exigences doivent être prises en charge en premier lieu par le fournisseur lors de la conception du système. C’est lui qui doit concevoir des solutions techniques et organisationnelles pour s’y conformer, puis en fournir la preuve dans la documentation et la phase d’évaluation de conformité.

Les autres acteurs (importateur, distributeur, utilisateur) ont, de leur côté, intérêt et obligation de vérifier que ces exigences sont remplies avant d’importer, de distribuer ou d’utiliser le système (voir plus loin).

Notons que l’IA Act prévoit la possibilité de normes harmonisées ou spécifications techniques pour faciliter le respect de ces exigences (par exemple, des normes ISO pour la gestion des risques ou la qualité des données), ainsi que la reconnaissance de bonnes pratiques sectorielles équivalentes pour éviter les doublons avec des réglementations existantes. Ainsi, un fournisseur déjà soumis à des normes de sécurité (p. ex. un fabricant de dispositif médical IA) pourra intégrer les démarches de test/validation déjà exigées par la réglementation santé directement dans son processus de conformité IA Act.

De même, une banque développant un système d’IA pourra s’appuyer sur ses procédures de gouvernance interne en matière de risques pour satisfaire en partie aux exigences de gestion de la qualité de l’IA Act.

3. Obligations des acteurs

3.1. Obligations du fournisseur d’un système d’IA à haut risque

Le fournisseur est l’acteur qui développe ou fait fabriquer le système d’IA et le met sur le marché sous son nom ou sa marque (que ce soit contre rémunération ou gratuitement).

En pratique, il s’agit souvent du développeur ou éditeur du système d’IA. Le fournisseur est le principal responsable de la conformité d’un système d’IA à haut risque : il doit assurer que le système respecte toutes les exigences listées précédemment (chap. III, sec. 2) avant sa mise sur le marché ou sa mise en service.

L’IA Act lui impose pour cela un certain nombre d’obligations organisationnelles et procédurales additionnelles (chap. III, sec. 3) destinées à encadrer la mise sur le marché et le suivi du système. Les principales obligations concrètes pesant sur le fournisseur sont les suivantes :

• système de gestion de la qualité : le fournisseur doit mettre en place un système de management de la qualité (QMS) documenté, proportionné à la taille de son organisation. À l’instar du principe d’« accountability » du RGPD, il s’agit d’avoir des procédures internes démontrant la prise en compte de l’IA Act. Ce QMS doit inclure notamment : une stratégie de mise en conformité réglementaire, des procédures pour le design et le développement du système (vérification, tests préalables, contrôle qualité logiciel), des procédures de gestion des risques et de suivi du cycle de vie, la tenue de la documentation, et la gestion des modifications. Le système de qualité doit être auditable et permettre de prouver que le fournisseur contrôle ses processus de développement en vue de la conformité.

• évaluation de conformité et certification CE : avant de commercialiser le système, le fournisseur doit faire procéder à une évaluation de conformité conformément aux procédures définies à l’art. 40 e s. du RIA. Selon les cas, il peut s’agir d’une autoévaluation interne (contrôle interne du produit, si la loi le permet) ou d’une évaluation par un organisme notifié tiers (surtout pour certains systèmes plus sensibles, par exemple. les IA de biométrie ou certains produits déjà réglementés). Si l’évaluation conclut que le système est conforme, le fournisseur doit alors établir et signer une déclaration de conformité UE (engageant sa responsabilité sur le respect de l’IA Act), puis apposer le marquage CE sur le système ou sa documentation. Le marquage CE, accorde le passeport, en indiquant officiellement que l’IA satisfait aux exigences européennes applicables. Sans cela le système d’IA à haut risque ne peut être mis sur le marché légalement. Par ailleurs, les systèmes classés à haut risque selon l’annexe III doivent être enregistrés dans la base de données européenne dédiée avant leur déploiement cela vise à créer un registre public de ces IA pour la transparence et le suivi.

• identification et traçabilité : le fournisseur doit indiquer clairement son nom, sa raison sociale/trademark et ses coordonnées sur le système d’IA ou son emballage ou documentation. Ceci vise à ce que l’origine et le responsable du système soient toujours identifiables pour les utilisateurs et les autorités. Il doit également s’assurer que chaque système ou modèle d’IA a un identifiant unique pour son enregistrement ;

• conservation de la documentation et des logs : l’IA Act impose au fournisseur de conserver pendant au moins 10 ans après la mise sur le marché une copie notamment du dossier technique complet du système, de la déclaration de conformité, des certificats délivrés par les organismes notifiés (art. 18, §1). Par ailleurs, les journaux (logs) générés automatiquement par le système doivent être conservés au minimum 6 mois (par le fournisseur ou le déployeur) afin d’assurer la traçabilité. Ces durées visent à permettre des contrôles même plusieurs années après la commercialisation, ou de retrouver la documentation en cas d’incident tardif ;

• surveillance post-marché et mesures correctives : même après la mise sur le marché, le fournisseur garde une responsabilité quant au suivi du fonctionnement de son IA. Il doit mettre en place un système de surveillance post-commercialisation (art. 72) afin de recueillir des informations sur les performances en conditions réelles, notamment via les retours des déployeurs. Si le fournisseur identifie qu’un système déployé n’est pas conforme au règlement ou présente un risque nouveau pour la sécurité ou les droits, il est tenu de prendre sans délai les mesures correctives qui s’imposent. Cela peut aller de la mise à jour logicielle corrective jusqu’au rappel du produit ou la suspension de son utilisation. Dans certains cas graves, le fournisseur doit aussi notifier les autorités compétentes (les autorités de surveillance de marché) des problèmes de sécurité survenus et des actions engagées. Cette obligation d’action corrective est essentielle pour maintenir la conformité dans le temps et éviter que des défaillances connues ne perdurent ;

• coopération avec les autorités : le fournisseur d’IA à haut risque doit coopérer avec les régulateurs nationaux et l’Office européen de l’IA. Concrètement, sur demande motivée d’une autorité, il doit fournir l’accès à la documentation technique, aux informations nécessaires sur le système et son fonctionnement. Il doit aussi se soumettre aux audits ou contrôles éventuels et appliquer toute mesure corrective imposée par ces autorités (ex : retrait du marché si le système est jugé dangereux). Cette coopération s’inscrit dans la démarche de surveillance continue du marché : chaque fournisseur doit être prêt à justifier de sa conformité à tout moment.

Ains, le fournisseur en tant qu’architecte principal de la conformité des IA à haut risque doit assurer la qualité des données, fournir la documentation, analyser les risques, tester, etc., puis formaliser cette conformité par une certification CE et un enregistrement du système. Il doit aussi maintenir un haut niveau de vigilance après la commercialisation. Ces démarches visent à ce que les systèmes d’IA à haut risque arrivent sur le marché avec des garanties sérieuses de fiabilité et de respect des droits. Dans la pratique, les fournisseurs devront souvent mobiliser des équipes pluridisciplinaires (juristes, experts IA, assurance qualité) pour constituer les dossiers de conformité et piloter la mise en place des mesures requises.

3.2. Obligations du déployeur d’un système d’IA à haut risque

Le déployeur est l’utilisateur final professionnel qui met en service un système d’IA à haut risque sous son autorité, dans le cadre de ses activités (par opposition à un usage purement personnel). Il s’agit par exemple d’une entreprise qui utilise un logiciel d’IA pour trier des candidatures, d’un hôpital utilisant une IA de diagnostic, d’une banque recourant à un système de scoring de crédit, ou encore d’une administration publique employant un algorithme pour attribuer des prestations.

L’IA Act impose à ces utilisateurs professionnels un éventail d’obligations destinées à garantir que l’IA est utilisée de manière responsable et conforme à sa destination.

On peut les résumer ainsi :

• utilisation conforme et mesures internes : le déployeur doit utiliser le système conformément aux instructions d’utilisation du fournisseur et prendre les mesures techniques et organisationnelles appropriées pour s’assurer du respect de ces instructions. Autrement dit, il ne doit pas utiliser l’IA pour un usage non prévu ou d’une manière qui détournerait les garanties prévues. Il doit également veiller à intégrer l’IA dans ses processus en suivant les recommandations du fournisseur. Par exemple, si la notice exige une validation humaine pour certains résultats critiques, le déployeur doit mettre en place cette procédure. Le déployeur pourra en outre être soumis à d’autres obligations légales externes selon le secteur (ex : un hôpital doit en plus respecter le secret médical, etc.).
• culture et compétences IA : l’IA Act exige (art. 4) que les déployeurs (et également les fournisseurs, mais peut-être dans une moindre mesure en pratique) garantissent un niveau suffisant de connaissances en IA à leur personnel impliqué dans l’utilisation du système. Le but affiché est d’éviter une utilisation maladroite ou aveugle de l’IA par manque de compréhension. La formation devra être adaptée au contexte et aux tâches de chacun : par exemple, former des recruteurs à détecter un biais potentiel d’un outil de tri de CV, ou former des médecins à interpréter les suggestions d’une IA diagnostique. Cette obligation est une innovation réglementaire visant à responsabiliser les organisations utilisatrices, en complément des obligations du fournisseur.

• surveillance humaine opérationnelle : le déployeur doit assigner la supervision humaine du système à des personnes physiques compétentes et formées, avec l’autorité et les ressources nécessaires pour intervenir. En pratique, cela signifie désigner explicitement des opérateurs ou responsables humains qui surveilleront le fonctionnement de l’IA au quotidien. Le déployeur est libre d’organiser cette supervision comme il le souhaite (département dédié, contrôle hiérarchique, etc.), mais il doit en tout cas mettre en œuvre les mesures de surveillance prévues par le fournisseur. Par exemple, s’il utilise un système de détection de fraudes bancaires, il devra avoir des analystes humains chargés d’examiner les alertes émises par l’IA et d’éventuellement bloquer ou valider les décisions, conformément aux recommandations du fournisseur. Le déployeur doit aussi éviter l’automatisation totale des décisions lorsque l’IA Act l’impose – par exemple, en matière de reconnaissance biométrique, il est interdit de prendre des décisions uniquement sur la base de l’IA sans confirmation humaine indépendante.

• qualité des données d’entrée : si le déployeur fournit lui-même des données d’entrée au système (ex : alimentation continue d’un modèle), il lui incombe de s’assurer que ces données sont appropriées et suffisamment représentatives de l’usage prévu. Cette obligation vise à éviter qu’un usage dans un contexte différent ou avec des données inadaptées ne rende l’IA dangereuse ou biaisée. Par exemple, une collectivité locale qui utilise un algorithme formé nationalement pour allouer des aides sociales devra vérifier que les données locales qu’elle injecte (profil de la population) ne sortent pas du cadre pour lequel l’IA a été validée.

• suivi du fonctionnement et feedback : le déployeur a l’obligation de surveiller le fonctionnement de l’IA en service conformément aux instructions du fournisseur. Cela inclut le suivi des indicateurs de performance ou alertes fournis par le système. De plus, si pertinent, il doit fournir un retour d’information au fournisseur sur la performance de l’IA. En effet, le fournisseur compte sur les utilisateurs finaux pour collecter des données de post-market monitoring. Par exemple, un hôpital utilisant une IA de diagnostic pourra transmettre au développeur des retours anonymisés sur les cas d’erreurs ou les taux de succès, afin d’affiner le modèle. Ce partage d’information sera souvent contractualisé entre le fournisseur et le client : le règlement encourage d’ailleurs le fournisseur à inclure dans ses contrats une clause imposant au déployeur de lui remonter les données pertinentes sur la performance du système. Cela contribue à améliorer l’IA et à garantir le maintien de la conformité.

• suspension et notification en cas de risque : si le déployeur constate des indications que l’utilisation conforme de l’IA pourrait générer un risque sérieux pour la santé, la sécurité ou les droits fondamentaux, il doit immédiatement en informer le fournisseur (ou le distributeur/importateur) ainsi que l’autorité de surveillance compétente, et suspendre l’utilisation du système jusqu’à ce que le risque soit écarté. Autrement dit, le déployeur ne doit pas continuer à utiliser un système qu’il soupçonne d’être dangereux ou gravement non-conforme. Par exemple, si une entreprise utilisant une IA détecte que celle-ci produit des décisions discriminatoires illégales (ex. rejet de candidatures uniquement de personnes d’un certain genre ou origine), elle doit stopper son utilisation et le signaler pour remédiation. Cette obligation rejoint celle du fournisseur sur les mesures correctives : elle vise à circonscrire rapidement tout risque émergent lié à l’IA.

• signalement des incidents graves : le déployeur doit rapporter sans délai au fournisseur tout incident grave survenu lors de l’utilisation de l’IA, puis en informer également l’importateur ou distributeur le cas échéant et les autorités de surveillance. Un incident grave se définit comme tout dysfonctionnement ou usage ayant entraîné ou pouvant entraîner un préjudice grave pour une personne. Par exemple, un hôpital déployant une IA de traitement qui commet une erreur ayant mis en danger un patient devra le notifier. Ce reporting doit se faire immédiatement après détection de l’incident. Il permet au fournisseur d’initier l’enquête interne requise (l’IA Act impose au fournisseur d’enquêter sur les causes de tout incident sérieux et de prendre action). Les autorités peuvent ainsi être alertées simultanément pour un suivi.

• transparence envers les personnes affectées : deux obligations spécifiques renforcent la transparence vis-à-vis des humains impactés par l’IA ;

1. d’une part, dans le milieu de travail, si un employeur (déployeur) introduit un outil d’IA à haut risque pour surveiller, évaluer ou prendre des décisions concernant ses employés, il doit préalablement informer les travailleurs concernés (et leurs représentants) de cette utilisation. Par exemple, une entreprise déployant un système d’IA pour analyser les performances de ses employés devra en avertir clairement ces derniers avant mise en service, conformément au droit du travail applicable ;
2. d’autre part, en règle générale, lorsque le déployeur utilise une IA à haut risque pour prendre des décisions concernant des personnes physiques (par ex. un algorithme décidant de l’octroi d’un prêt, ou aidant à une décision de justice), il doit informer les individus visés qu’une décision les concernant a été assistée par un système d’IA.

• conservation des logs : lorsque le système d’IA traite des données à caractère personnel, le déployeur doit conserver les journaux générés automatiquement par le système pendant une durée appropriée à l’usage, au minimum six mois.

• coopération avec les autorités : à l’instar des fournisseurs, les déployeurs doivent coopérer avec les autorités compétentes dans le cadre de l’application du Règlement.

• analyse d’impact sur les droits fondamentaux  : enfin, l’IA Act introduit à l’article 27 une obligation pour certains déployeurs de conduire, avant le déploiement, une analyse d’impact « droits fondamentaux » relative à l’IA haut risque qu’ils veulent utiliser. Cette FRIA ressemble à une évaluation de type AIPD du RGPD, mais centrée plus largement sur tous les droits et impacts sociétaux. Elle vise à ce que le déployeur réfléchisse en amont aux conséquences potentielles de l’IA sur les personnes concernées et aux mesures pour mitiger ces risques. Toutefois, cette obligation ne s’applique pas à tous les déployeurs ni à toutes les IA haut risque. Sont exemptés les systèmes d’IA qui sont des composants de sécurité de produits (déjà testés dans le cadre d’une certification produit) ou certains systèmes dans les infrastructures critiques. En pratique, les analyses d’impact concernent surtout les systèmes listés en annexe III (haut risque « sociétal ») et les déployeurs appartenant à certaines catégories : les entités de droit public, les acteurs privés chargés d’un service public important (éducation, santé, services sociaux, logement, etc.), ainsi que certains opérateurs privés dans la finance (banques, assurances). Le Bureau Européen de l’IA élaborera un modèle de questionnaire standardisé pour aider les déployeurs à réaliser ces analyses d’impact plus facilement. Une fois l’analyse effectuée, le déployeur doit transmettre les résultats à l’autorité nationale de surveillance du marché, sauf exemption particulière. Cette exigence des analyses d’impact traduit la volonté du législateur de responsabiliser les utilisateurs finaux sur les impacts éthiques et sociétaux de l’IA, en complément des démarches du fournisseur. En synthèse : un déployeur public ou assimilé doit “penser avant d’agir” en matière d’IA, en évaluant comment l’outil va impacter les citoyens et comment prévenir les atteintes aux droits

Les déployeurs de systèmes d’IA à haut risque se voient imposer de nombreuses exigences par le règlement. Ils doivent intégrer l’IA de façon maîtrisée, avec des procédures de contrôle, de transparence et de feedback. Le respect de ces obligations permet non seulement d’assurer la conformité légale, mais aussi de favoriser une utilisation plus responsable et bénéfique de l’IA dans l’organisation.

3.3. Obligations des importateurs et distributeurs de systèmes d’IA à haut risque

L’IA Act prévoit des obligations spécifiques pour les acteurs qui interviennent en aval du fournisseur dans la chaîne commerciale : principalement l’importateur (qui fait venir un système d’IA d’un pays tiers pour le marché UE) et le distributeur (qui revend un système au sein de l’UE). L’objectif est d’impliquer ces intermédiaires dans le respect des règles et d’éviter qu’ils n’introduisent sur le marché européen des IA non conformes.

3.3.1. Importateurs

Toute entité qui importe d’un pays hors-UE un système d’IA à haut risque en vue de sa mise sur le marché européen assume des responsabilités comparables à celles d’un fabricant de produit. Avant d’importer, l’importateur doit vérifier que le fournisseur a bien effectué l’évaluation de conformité et constitué la documentation technique requise. Il doit aussi s’assurer que le système porte le marquage CE et est accompagné de la déclaration de conformité UE et des instructions d’utilisation.

En somme, l’importateur a un devoir de diligence : « ne pas placer sur le marché un système dont il a des raisons de croire qu’il n’est pas conforme ». S’il constate des non-conformités ou des documents manquants, il doit s’abstenir de commercialiser le produit tant que le fournisseur n’a pas remédié aux manquements. Par ailleurs, l’importateur doit indiquer sur le produit ou la documentation son propre nom et adresse de contact (afin d’identifier la chaîne d’approvisionnement). Une fois le produit sur le marché, il a l’obligation de conserver une copie de la déclaration de conformité UE, des certificats et des instructions d’utilisation pendant 10 ans, et de veiller à ce que la documentation technique puisse être obtenue si une autorité la demande. Si l’importateur apprend qu’un système qu’il a mis sur le marché présente un risque pour la santé, la sécurité ou les droits, il doit en informer immédiatement le fournisseur, le représentant autorisé et les autorités de surveillance concernées. Il doit également coopérer avec les autorités en fournissant toutes les informations et en prenant, le cas échéant, les mesures correctives (par ex. organiser un rappel du produit non conforme). Exemple : une société européenne important un logiciel d’IA américaine de recrutement devra contrôler que ce logiciel est bien certifié CE, que le fabricant lui a remis un dossier technique complet (en langue requise) et les notices. Si tel n’est pas le cas, elle ne pourra pas légalement distribuer ce logiciel tant que la conformité n’est pas établie. En cas de problème découvert plus tard (ex. biais discriminatoire majeur), l’importateur devra alerter les autorités et cesser de le distribuer jusqu’à correctif.

3.3.2. Distributeurs

Ce sont les acteurs qui, sans être fournisseur ni importateur, offrent en vente ou fournissent un système d’IA à haut risque (par ex. un revendeur, un magasin de logiciels, une place de marché numérique). Le distributeur doit agir avec prudence et s’assurer que le fournisseur et, le cas échéant, l’importateur ont rempli leurs obligations de conformité. Concrètement, avant de distribuer un produit, il doit vérifier la présence du marquage CE, de la déclaration de conformité et de la notice d’utilisation, ainsi que l’identité du fournisseur/importateur sur le produit. S’il a des doutes raisonnables sur la conformité d’un système (par exemple un produit sans marquage ou venant d’une source non officielle), il doit s’abstenir de le commercialiser et informer soit le fournisseur soit les autorités du problème. Le distributeur doit également assurer la conservation des conditions d’origine du produit - il ne doit pas le modifier d’une manière qui affecterait la conformité (par ex. changer la notice ou le logiciel sans autorisation). Si un risque ou une non-conformité est porté à sa connaissance (par le fournisseur ou via une alerte), il doit contribuer à relayer l’information et à exécuter d’éventuelles mesures correctives (retrait des rayons, etc.). Enfin, comme tous les acteurs, il doit coopérer en cas de contrôle et fournir les informations nécessaires aux autorités.

3.4. Le transfert de responsabilité

L’article 25 de l’IA Act consacre cette règle de « transfert de responsabilité » lorsqu’un acteur de la chaîne transforme ou rebrande une IA : par exemple, une entreprise qui achète un algorithme et l’intègre dans son produit sous son nom endosse la responsabilité pleine de conformité de ce produit comme si elle en était le fournisseur. Ceci vise à éviter qu’un simple changement de marque serve à diluer les obligations.

Conclusion

L’IA Act impose aux acteurs de l’écosystème IA - développeurs, fournisseurs, distributeurs, importateurs, utilisateurs - un ensemble complet d’obligations juridiques concrètes visant à assurer que les systèmes d’IA à haut risque soient sûrs, transparents, et respectueux des droits tout au long de leur cycle de vie.

Au-delà de la conformité légale, comprendre et appliquer ces obligations permet aux acteurs de contribuer à une IA plus éthique et digne de confiance. Un fournisseur qui documente et gère sérieusement les risques de son IA, ou un déployeur qui encadre par une supervision humaine effective, verront non seulement leur risque juridique diminuer, mais aussi la qualité et l’acceptabilité sociale de leurs systèmes augmenter. L’IA Act, en posant ce cadre, promeut ainsi une vision d’un développement de l’intelligence artificielle « responsable par design », où chaque acteur est conscient de ses devoirs.

Il reste néanmoins nécessaire d’accompagner la mise en œuvre de ces obligations. Les entreprises auront besoin d’un accompagnement, de guides pratiques juridiques pour traduire les principes du règlement en actions concrètes et efficientes. Ce que Cloix Mendès-Gil peut proposer.

Dans le cadre du cycle « le Règlement sur l’Intelligence artificielle », nous vous proposons de nous retrouver chaque mois pour améliorer notre compréhension commune de ce règlement et que vous soyez ainsi prêt pour son entrée en application :

• #1 Entrée en vigueur et champ d’application de l’IA Act : quel périmètre exact pour les juristes ?
• #2 Pratiques d’IA interdites : analyse des dispositions de l’article 5
• #3 Classifications juridiques des systèmes d’IA : comprendre les catégories de risque
• #4 Obligations juridiques concrètes des acteurs de l’IA à haut risque : exigences et conformité
• #5 Transparence et explicabilité juridiques des systèmes d’IA : portée exacte des obligations pour les juristes
• #6 Modèles d’IA à usage général : encadrement et responsabilités
• #7 Impacts de l’IA Act sur les contrats IT : adaptations nécessaires
• #8 Mesures de soutien à l’innovation : bacs à sable réglementaires et autres initiatives
• #9 Gouvernance interne et responsabilité juridique : analyse critique des obligations organisationnelles
• #10 Mise en œuvre et surveillance : rôle des autorités nationales et européennes
• #11 Bases de données de l’UE sur les IA à haut risque : transparence et accessibilité
• #12 Codes de conduite et lignes directrices : rôle et élaboration
• #13 Sanctions en cas de non-conformité : cadre et implications

Le département Contrats informatique, données & conformité peut vous accompagner dans tout le cycle de vie de création de votre SIA : de l’étude de faisabilité, à la révision des contrats, de l’étude d’impact des droits fondamentaux, en passant par la préparation des dossiers des IA à haut risque.

Pour toute question, n’hésitez pas à nous contacter.