Le 19 mai 2026, la Commission européenne a publié des draft guidelines sur la classification des systèmes d’IA à haut risque au titre de l’article 6 de l’AI Act. Ces lignes directrices, ouvertes à consultation jusqu’au 23 juillet 2026, ont un objectif clair : aider les fournisseurs, déployeurs et autorités à déterminer plus concrètement si un système d’IA relève ou non du régime « high-risk ». Elles ne sont pas juridiquement contraignantes, mais elles constituent à ce stade le cadre d’interprétation de la Commission et orienteront les autorités de surveillance.
Les obligations applicables aux systèmes d’IA à haut risque entreront progressivement en vigueur, avec une première échéance majeure au 2 décembre 2027 pour les systèmes relevant de l’annexe III, suivie du 2 août 2028 pour les systèmes intégrés dans des produits couverts par l’annexe I.
La Commission précise que les guidelines visent à favoriser une application uniforme de l’article 6 de l’AI Act et qu’elles s’appuient sur des exemples concrets pour guider l’interprétation.
I- Les deux scénarios de classification prévus par l’article 6
1. Premier scénario : l’article 6(1) et l’annexe I
Un système d’IA est classé à haut risque lorsqu’il réunit trois conditions cumulatives :
- Il est destiné à être utilisé comme composant de sécurité d’un produit, ou constitue lui-même un tel produit.
- Ce produit est couvert par l’une des législations d’harmonisation de l’Union listées à l’annexe I.
- Le produit concerné doit faire l’objet d’une évaluation de conformité par un tiers.
Autrement dit, la seule présence d’IA dans un produit déjà règlementé ne suffit pas. La qualification à haut risque suppose un lien avec une logique de sécurité produit et une articulation avec les régimes européens de conformité déjà existants. Les guidelines rappellent aussi que l’AI Act ne détermine pas lui-même les modules de conformité applicables : ceux-ci restent définis par les législations sectorielles d’harmonisation de l’Union.
2. Deuxième scénario : l’article 6(2) et l’annexe III
Le second scénario concerne les systèmes d’IA qui relèvent d’un des cas d’usage énumérés à l’annexe III de l’AI Act. Ici, le raisonnement n’est pas centré sur un produit, mais sur un usage spécifique de l’IA dans des domaines jugés sensibles. Les guidelines rappellent un point fondamental : les cas visés dans les annexes I et III sont listés de manière exhaustive. Cela signifie qu’un système d’IA utilisé dans un secteur sensible n’est pas automatiquement à haut risque si son cas d’usage précis n’est pas explicitement visé dans les annexes I et III de l’AI Act.
La Commission distingue notamment huit grands domaines au sein de l’annexe III :
- Biométrie ;
- Infrastructures critiques ;
- Éducation et formation professionnelle ;
- Emploi, gestion de la main-d’œuvre et accès à l’emploi indépendant ;
- Accès à des services privés essentiels, à des services publics et à des prestations sociales essentielles ;
- Répression ;
- Migration, asile et contrôle aux frontières ;
- Administration de la justice et processus démocratiques.
II- Le rôle déterminant de la destination du système
1. La nécessité de la description de l’usage prévu du système
La classification à haut risque dépend non seulement de ce que le système fait techniquement, mais aussi de ce que le fournisseur décrit comme son usage envisagé dans la documentation technique, les supports contractuels, les conditions d’utilisation ainsi que les éléments promotionnels et marketing.
Ce point est particulièrement important pour les systèmes à usage général ou à usages multiples. Lorsqu’un système d’IA est destiné à être utilisé dans une grande diversité de contextes et d’applications, sans limitation claire des usages à haut risque, ces usages peuvent être considérés comme faisant partie de sa destination dès lors qu’ils sont raisonnablement prévisibles. Les guidelines précisent ainsi qu’il ne suffit pas d’indiquer formellement que certains usages à haut risque sont exclus si, dans les faits, la description du produit laisse entendre ou favorise des usages multiples incluant de tels cas.
2. Le système n’a pas besoin d’être déjà utilisé pour être classifié à haut risque
Les guidelines précisent qu’un système d’IA peut être qualifié à haut risque avant même son utilisation effective. Ce qui compte, c’est son usage prévu avant la mise sur le marché de l’Union européenne ou sa mise en service. C’est donc à ce stade que le fournisseur doit évaluer la classification et, le cas échéant, se préparer à satisfaire les obligations applicables.
III- Les clarifications relatives à la notion de “composant de sécurité”
Les guidelines apportent ici une double lecture.
1. Une approche intentionnelle : la fonction de sécurité
Un système d’IA constitue un composant de sécurité lorsqu’il est destiné, selon la finalité définie par le fournisseur, à prévenir ou atténuer des risques pour la santé ou la sécurité des personnes ou des biens. Cette définition est autonome par rapport aux définitions sectorielles existantes. Elle couvre par exemple des fonctions de détection d’anomalies, d’identification de besoins de maintenance critiques, de blocage d’un fonctionnement dangereux, de limitation d’effets d’un risque ou de déclenchement de mesures de sécurité.
2. Une approche fondée sur le risque : la défaillance ou le dysfonctionnement
Un système peut aussi être qualifié de composant de sécurité si sa défaillance ou son dysfonctionnement est susceptible de mettre en danger la santé, la sécurité des personnes ou les biens. Cette approche désigne par exemple les faux positifs, les faux négatifs, la perte de fonction, l’instabilité des performances, la dérive ou encore des erreurs de classification conduisant à des décisions dangereuses. En revanche, les préjudices réputationnels, les pertes financières, les dégradations mineures ou l’inconfort sont explicitement exclus de cette logique de mise en danger.
IV- Article 6(3) : les clarifications sur le « mécanisme de filtrage »
L’article 6(3) prévoit un mécanisme de filtrage permettant d’exempter un système d’IA de la qualification à haut risque dans le cas où la destination du système d’IA est couverte par un cas d’utilisation de l’annexe III mais ne présente pas de risques significatifs de préjudice.
Cette exemption est strictement encadrée : elle ne s’applique que si le système ne présente pas de risque significatif de préjudice pour la santé, la sécurité ou les droits fondamentaux, et s’il remplit au moins une des quatre conditions prévues par le texte. Les guidelines rappellent en outre que cette logique repose sur une idée centrale : le système ne doit pas influencer de manière substantielle le résultat du processus décisionnel.
1. Une exemption strictement conditionnée
Le mécanisme de filtrage ne constitue pas une dérogation générale permettant d’écarter facilement la qualification à haut risque. Il s’agit d’une exception d’interprétation, fondée sur une analyse concrète de la finalité du système, de son contexte d’utilisation et de son influence réelle sur la décision. Les lignes directrices précisent que le fournisseur doit examiner avec attention les tâches que le système est destiné à accomplir, ce qui renvoie directement à la destination du système, à ses conditions d’usage et au cadre décisionnel dans lequel il s’insère.
2. Les quatre conditions du mécanisme de filtrage
Le mécanisme repose sur quatre cas d’usage bien identifiés, qui correspondent à des situations où le système reste dans un rôle d’assistance sans influencer de manière déterminante la décision finale. Ces conditions sont alternatives et non cumulatives, mais doivent être interprétées de manière stricte.
a. La réalisation d’une tâche procédurale étroite
Le système effectue une tâche si limitée qu’elle n’entraîne qu’un risque réduit. Ces tâches sont par nature étroites et circonscrites, de sorte que les risques associés restent faibles, y compris lorsqu’elles s’inscrivent dans un cas d’usage relevant de l’annexe III. Elles correspondent typiquement à des fonctions de support comme la structuration ou le traitement de l’information. En revanche, cette condition ne s’applique pas à tous les systèmes de catégorisation : dès lors qu’un système porte un jugement de valeur sur des données pertinentes pour la prise de décision, il ne peut plus être considéré comme purement procédural.
b. L’amélioration du résultat d’une activité humaine préalablement réalisée
Le système ajoute une couche d’amélioration à une activité déjà réalisée par un humain, sans la remplacer, ni la revoir complètement. Cette condition repose sur trois critères cumulatifs : une activité humaine a été accomplie, cette activité a conduit à un résultat identifiable, et le système d’IA intervient uniquement pour améliorer ce résultat. Le système ne doit donc ni réviser en profondeur ce travail, ni s’y substituer, mais simplement en améliorer la qualité ou la forme. L’idée centrale est que le système reste dans le prolongement direct de l’intervention humaine initiale.
c. La détection de schémas décisionnels constants ou d’écarts par rapport aux pratiques habituelles en matière de décision
Le système intervient ex post pour comparer des décisions déjà prises, sans remplacer ni influencer l’évaluation humaine initiale sans supervision appropriée. Ce cas de figure suppose de remplir trois conditions cumulatives : l’évaluation humaine doit avoir été achevée, le système doit se limiter à une analyse comparative a posteriori, et il ne doit pas être destiné à remplacer ou influencer cette évaluation initiale. Le système joue ici un rôle de contrôle ou d’analyse des pratiques, par exemple pour identifier des incohérences ou des anomalies, mais sans intervenir dans la décision elle-même ni orienter directement des décisions futures.
d. L’exécution d’une tâche préparatoire à une évaluation pertinente
Le système prépare, structure ou facilite les éléments nécessaires à une évaluation ultérieure, sans modifier la logique ou le résultat de cette évaluation. Cette tâche préparatoire intervient en amont de toute prise de décision et vise uniquement à organiser les informations utiles à l’analyse. Elle ne doit ni modifier la substance, ni la finalité, ni la logique de l’évaluation ultérieure. De plus, le système n’alimente pas directement la décision en tant que telle : il prépare les éléments nécessaires sans exercer d’incidence substantielle sur le résultat final. En particulier, il ne doit ni décider, ni classer des personnes ou des situations à des fins décisionnelles.
3. L’exception relative au profilage : trois critères cumulatifs à analyser
Pour déterminer si un système réalise effectivement un profilage, trois conditions doivent être réunies de manière cumulative : le système doit mettre en œuvre un traitement automatisé, ce traitement doit porter sur des données à caractère personnel, et il doit avoir pour finalité d’évaluer certains aspects personnels d’une personne physique.
Ainsi, le simple fait d’utiliser des données personnelles n’est pas suffisant. De même, une classification ou une segmentation d’individus fondée sur des caractéristiques personnelles (par exemple l’âge ou le sexe) ne constitue pas nécessairement un profilage lorsque l’objectif n’est pas de tirer des conclusions, réaliser des prédictions ou porter une évaluation sur les individus concernés.
En revanche, lorsqu’un système utilise des données personnelles afin d’analyser, prévoir ou évaluer des caractéristiques telles que les performances professionnelles, la fiabilité, les préférences, les intérêts ou le comportement probable d’une personne, il s’agit bien d’un profilage.
À titre d’exemple, un système d’IA utilisé dans un processus de recrutement pour évaluer les décisions et les comportements des recruteurs afin d’identifier des écarts par rapport aux politiques de recrutement de l’entreprise réalise un profilage, dès lors qu’il évalue les caractéristiques personnelles des personnes concernées à partir de données à caractère personnel. À l’inverse, un système utilisé par les autorités douanières pour évaluer le risque de non-conformité de marchandises sur la base d’informations relatives aux cargaisons et aux opérateurs économiques n’évalue pas des aspects personnels de personnes physiques et ne constitue donc pas un profilage.
4. Les systèmes d’IA intégrés dans des architectures complexes doivent être évalués dans leur ensemble
Les lignes directrices relatives à l’AI Act précisent que la qualification d’un système d’IA à haut risque ne peut pas être appréciée uniquement au niveau de chacun de ses composants pris isolément.
Lorsqu’un système d’IA est constitué de plusieurs systèmes ou interagit avec d’autres systèmes d’IA au sein d’une architecture plus complexe, c’est la configuration combinée et sa destination globale qui doivent être analysées.
Ainsi, lorsque plusieurs systèmes d’IA contribuent conjointement à une décision individuelle ou sont destinés à être utilisés dans un cas d’usage à haut risque, l’ensemble de la configuration peut être qualifié de système d’IA à haut risque, même si certains composants pourraient, pris séparément, bénéficier d’une exemption au titre de l’article 6(3).
Cette approche s’applique également aux architectures interconnectées et aux systèmes d’IA agentiques coordonnant plusieurs actions ou outils : dès lors que ces éléments poursuivent ensemble une destination à haut risque, ils doivent être évalués comme un tout.
V- Quelles obligations subsistent lorsqu’un système bénéficie du filtrage ?
L’exemption du haut risque ne signifie pas absence totale d’obligations. Le fournisseur qui décide d’appliquer le mécanisme de filtrage doit procéder à une auto-évaluation documentée avant la mise sur le marché ou la mise en service du système. Cette documentation doit notamment décrire :
- La destination du système ;
- Les raisons pour lesquelles il relève de l’article 6(2) ;
- Les raisons justifiant l’application de l’une des conditions du mécanisme de filtrage de l’article 6(3) ;
- Les raisons pour lesquelles le système n’effectue pas de profilage.
Le système doit en outre être enregistré dans la base de données de l’Union européenne prévue par l’article 71 de l’AI Act. Les autorités de surveillance du marché peuvent contrôler cette classification, demander des mesures correctives et, en cas de mauvaise qualification destinée à contourner les obligations applicables, des sanctions peuvent être prononcées.
Conclusion
Avec ces nouvelles guidelines, le message est clair : la classification d’un système d’IA à haut risque exige une analyse structurée, documentée et contextualisée, qui combine examen de l’usage prévu, des fonctionnalités réelles, de l’environnement d’utilisation, du niveau d’influence sur la décision et, le cas échéant, de l’existence d’un profilage ou d’une intégration dans un système complexe.
Pour les organisations, une mauvaise qualification peut conduire à sous-estimer les obligations applicables, à fragiliser la gouvernance de l’IA et à accroître le risque de non-conformité.
👉 Vous devez qualifier vos systèmes d’IA et structurer votre mise en conformité avec l’AI Act ?
Découvrez notre plateforme de management de l’IA, qui vous accompagne pour centraliser vos cas d’usage et opérationnaliser votre conformité en pilotant vos obligations dans la durée, dans un cadre directement intégré à votre écosystème.