AI Act : classer un système d’IA à haut risque (article 6, annexes I et III)

Le règlement (UE) 2024/1689 sur l’intelligence artificielle (IA), dit AI Act, ne classe pas des modèles ni des technologies : il classe des systèmes selon l’usage qu’on en fait. L’article 6 ouvre deux voies vers le haut risque (les produits réglementés de l’annexe I, les domaines sensibles de l’annexe III) et une porte de sortie étroite, verrouillée dès qu’il y a profilage. Cette page traite la classification comme une procédure d’architecture, rejouée système par système et usage par usage, avec les erreurs qui faussent le résultat.

→ Lire l’explication complète de la marmotte

État du texte de l’article 6 après le règlement (UE) 2026/1744

Le volet IA de l’omnibus numérique, le règlement (UE) 2026/1744, est paru au Journal officiel (JO) de l’Union européenne (UE) le 24 juillet 2026. Il est en vigueur depuis le 27 juillet 2026 et modifie le règlement 2024/1689. Les mécanismes de classement décrits ici (deux voies, dérogation, verrou du profilage, obligation de documenter) viennent du texte d’origine. Sur chaque point de détail, la version consolidée publiée sur EUR-Lex fait foi, et pas une diapositive de webinaire datée d’avant juillet.

L’omnibus a aussi décalé les échéances : les obligations liées à l’annexe III s’appliquent au 2 décembre 2027, celles liées à l’annexe I au 2 août 2028. Le détail se trouve dans la page calendrier de l’AI Act. Ces dates ne réduisent pas le travail de classement, elles le rendent urgent : un système acheté ou développé maintenant sera encore en service à ces dates.

Prérequis du classement : inventaire et destination déclarée

Le classement porte sur une unité précise : un système d’IA (définition de l’article 3, point 1) associé à une destination. L’article 3, point 12, définit la destination comme l’utilisation prévue par le fournisseur, y compris le contexte et les conditions d’utilisation décrits dans la notice, la documentation commerciale et la documentation technique. Avant de classer quoi que ce soit, trois éléments doivent exister.

Un inventaire qui voit l’IA embarquée. Le module de « recommandation intelligente » du progiciel métier, la fonction de scoring activée par défaut dans l’outil de gestion des ressources humaines, l’appel à un modèle de langage (LLM, Large Language Model) caché derrière un bouton « résumer » : tout cela compte. Un inventaire limité aux projets étiquetés « IA » rate la majorité du parc. La source la plus fiable reste le croisement entre la base de gestion des configurations (CMDB, Configuration Management Database), les contrats fournisseurs et les flux sortants vers des API (Application Programming Interface) de modèles.
Une destination écrite par usage, pas par produit. Un même moteur peut servir à trier des tickets de support et à évaluer des agents d’accueil. Ce sont deux lignes d’inventaire et deux classements distincts.
Un rôle identifié pour chaque ligne. Le fournisseur classe et documente ; le déployeur vérifie que son usage reste dans la destination déclarée. Le partage des responsabilités est détaillé dans la page rôles fournisseur et déployeur.

Le compromis central se joue ici. Une destination étroite et précise permet souvent de sortir du haut risque ou de rester dans la dérogation, mais elle enferme l’usage : toute extension fait basculer le classement. Une destination large laisse de la marge aux équipes métier, mais elle fait payer d’emblée les obligations du haut risque. La position défendue ici : écrire une destination étroite, puis gouverner les changements d’usage par un processus de réexamen. L’inverse, c’est-à-dire déclarer large pour ne plus y penser, revient à acheter le régime le plus lourd sans l’avoir choisi.

La destination ne se déduit jamais de la technologie. Une régression logistique qui évalue, pour une autorité publique, l’éligibilité de foyers à une aide au logement relève de l’annexe III (point 5, a)) ; un modèle de pointe qui reformule des notices de montage n’y relève pas. La page LLM et IA rappelle pourquoi le mot « IA » couvre bien plus que les modèles de langage.

Voie de l’annexe I : composant de sécurité et évaluation par un tiers

L’article 6, paragraphe 1, pose deux conditions cumulatives :

le système d’IA est un composant de sécurité d’un produit couvert par la législation d’harmonisation listée à l’annexe I, ou il est lui-même un tel produit ;
ce produit doit faire l’objet d’une évaluation de conformité par un tiers selon cette législation.

Si l’une des deux conditions manque, le système n’est pas à haut risque par cette voie. Il peut toujours l’être par l’annexe III, qu’il faut examiner séparément.

La section A de l’annexe I liste les textes du nouveau cadre législatif : machines (directive 2006/42/CE), jouets, bateaux de plaisance, ascenseurs, appareils destinés aux atmosphères explosibles (ATEX), équipements radioélectriques, équipements sous pression, installations à câbles, équipements de protection individuelle (EPI), appareils à gaz, dispositifs médicaux (règlement 2017/745) et dispositifs médicaux de diagnostic in vitro (règlement 2017/746). Pour ces produits, l’AI Act s’applique directement, en plus du texte sectoriel.

La section B couvre la sûreté de l’aviation civile, les véhicules à deux ou trois roues, les véhicules agricoles et forestiers, les équipements marins, l’interopérabilité ferroviaire, la réception des véhicules à moteur (règlements 2018/858 et 2019/2144) et l’aviation civile pour les aéronefs sans équipage (règlement 2018/1139). Pour ces textes, l’article 2, paragraphe 2, limite l’application de l’AI Act à l’article 6, paragraphe 1, aux articles 102 à 109 et à l’article 112. Les exigences du haut risque y entrent par la législation sectorielle, qui les intègre lors de ses propres révisions. Elles ne s’appliquent pas directement.

Le piège de cette voie est la condition du tiers. Ce qui la remplit, c’est ce que le texte sectoriel impose pour la catégorie de produit concernée, pas la présence de « sécurité » dans le nom du composant. Selon la catégorie et la procédure choisie, certains produits passent par un organisme notifié, d’autres relèvent du contrôle interne du fabricant. La réponse se lit donc dans la procédure d’évaluation de conformité du texte sectoriel, article par article. Autre point à surveiller : l’annexe I vise la directive 2006/42/CE, que le règlement (UE) 2023/1230 remplace à partir de janvier 2027. Le renvoi est à vérifier dans la version consolidée au moment du classement.

Voie de l’annexe III : les huit domaines et leurs exclusions

L’article 6, paragraphe 2, classe à haut risque les systèmes visés à l’annexe III. Celle-ci ne liste pas des technologies, mais des cas d’utilisation répartis en huit domaines :

Domaine	Cas visés	Exclusion ou limite à lire de près
1. Biométrie	identification biométrique à distance ; catégorisation sur attributs sensibles ou protégés ; reconnaissance des émotions	la vérification « un contre un » (confirmer qu’une personne est bien celle qu’elle prétend être) est exclue
2. Infrastructures critiques	composants de sécurité de la gestion et de l’exploitation des infrastructures numériques critiques, du trafic routier, de la fourniture d’eau, de gaz, de chauffage, d’électricité	le système doit être un composant de sécurité, pas un simple outil d’optimisation
3. Éducation et formation	accès, admission, affectation ; évaluation des acquis ; choix du niveau d’enseignement ; surveillance des examens
4. Emploi	recrutement et sélection (offres ciblées, filtrage, évaluation des candidats) ; décisions sur les conditions de travail, la promotion, le licenciement ; attribution des tâches ; suivi des performances
5. Services essentiels	éligibilité aux prestations sociales par ou pour les autorités publiques ; solvabilité et note de crédit ; tarification et risque en assurance-vie et maladie ; tri des appels d’urgence et des patients	la détection de fraude financière est exclue du point solvabilité
6. Répression	usages par ou pour les autorités répressives
7. Migration, asile, frontières	usages par ou pour les autorités compétentes
8. Justice et démocratie	aide aux autorités judiciaires ; influence sur une élection ou sur le vote	les outils logistiques de campagne sont exclus

Lire une ligne de l’annexe III, c’est vérifier trois éléments : le domaine, l’acteur (plusieurs points visent l’usage « par ou pour » une autorité publique) et l’effet sur des personnes physiques. La frontière avec les pratiques interdites de l’article 5 (certains usages de reconnaissance des émotions ou de notation sociale, par exemple) est traitée dans la page pratiques interdites. La règle d’ordre est la suivante : on teste l’interdiction avant le haut risque, puisqu’un système interdit n’a pas à être classé, il doit être arrêté.

L’annexe III peut évoluer. L’article 7 permet à la Commission d’ajouter ou de modifier des cas d’utilisation à l’intérieur des huit domaines existants, selon les critères de l’article 7, paragraphe 2. Un classement « non concerné » reste donc valable jusqu’à la prochaine modification de l’annexe, pas au-delà.

Dérogation de l’article 6, paragraphe 3, et verrou du profilage

Un système relevant de l’annexe III peut sortir du haut risque s’il ne présente pas de risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux, notamment parce qu’il n’influence pas de façon significative le résultat de la décision. Il faut en plus qu’une des quatre conditions suivantes soit remplie :

a) il exécute une tâche procédurale étroite ;
b) il améliore le résultat d’une activité humaine déjà réalisée ;
c) il détecte des constantes ou des écarts dans des décisions, sans remplacer ni influencer l’évaluation humaine préalable en l’absence d’un examen humain approprié ;
d) il exécute une tâche préparatoire à une évaluation relevant d’un cas de l’annexe III.

Le verrou s’applique ensuite, sans exception : un système de l’annexe III qui effectue un profilage de personnes physiques est toujours à haut risque. Le profilage est défini à l’article 4, point 4, du règlement général sur la protection des données (RGPD), auquel renvoie l’article 3, point 52 : un traitement automatisé qui évalue des aspects personnels, notamment pour analyser ou prédire le rendement au travail, la situation économique, la santé, les préférences, la fiabilité, le comportement ou les déplacements d’une personne. Noter, classer ou prédire, à partir de ses données, un aspect personnel d’un individu, c’est du profilage. Cocher la case a) pour un score d’employabilité ne résiste pas à une lecture attentive du RGPD.

Le critère qui tranche en pratique, c’est l’effet réel sur la décision, pas la place du système dans la chaîne. Une tâche « préparatoire » qui écarte 80 % des dossiers avant tout regard humain ne prépare rien : elle décide. Le test honnête consiste à retirer le système et à se demander si le résultat final pour la personne change. Si la réponse est oui, la dérogation ne tient pas. L’argument « un humain valide à la fin » n’y change rien quand cet humain valide en lot, avec un bouton « tout approuver ».

Les paragraphes 6 à 8 de l’article 6 permettent à la Commission d’ajouter, de modifier ou de supprimer des conditions de dérogation par acte délégué, sans abaisser le niveau global de protection. L’article 6, paragraphe 5, imposait à la Commission de publier au plus tard le 2 février 2026 des lignes directrices accompagnées d’exemples de cas à haut risque et non à haut risque. Avant de rédiger une dérogation, il faut consulter leur état et leur contenu sur le site de la Commission européenne : elles indiquent la lecture que retiendront les autorités.

Arbre de décision de l’article 6

Le schéma suivant montre l’ordre des tests. Les deux voies sont indépendantes : un système qui échoue au test de l’annexe I doit quand même passer le test de l’annexe III. La dérogation ne concerne que la voie de l’annexe III, et le profilage la neutralise.

Les deux sorties « non haut risque » ne mènent pas à zéro obligation. La maîtrise de l’IA (article 4, voir la page maîtrise de l’IA) et les interdictions de l’article 5 continuent de s’appliquer, ainsi que, selon le type de système, les obligations de transparence de l’article 50 (informer les personnes qu’elles interagissent avec une IA, marquer les contenus générés).

Documentation de l’évaluation, enregistrement et réexamen

L’article 6, paragraphe 4, impose au fournisseur qui considère qu’un système de l’annexe III n’est pas à haut risque de documenter son évaluation avant la mise sur le marché ou la mise en service, et de la remettre aux autorités sur demande. Le texte d’origine y ajoutait l’enregistrement prévu à l’article 49, paragraphe 2, dans la base de données de l’UE de l’article 71. La proposition omnibus de la Commission du 19 novembre 2025 visait à alléger cet enregistrement ; pour savoir ce que le règlement 2026/1744 a retenu, il faut lire la version consolidée. La documentation de l’évaluation, elle, reste exigée dans tous les cas.

Une évaluation défendable tient sur une page et contient au minimum :

la destination exacte, avec sa version et sa date ;
le ou les points de l’annexe III examinés et la raison pour laquelle ils s’appliquent ou non ;
la condition de dérogation invoquée, avec la preuve que le système n’influence pas la décision de façon significative (position dans le flux, existence et effectivité de l’examen humain) ;
l’analyse du profilage au sens du RGPD ;
les événements qui déclenchent un réexamen.

Les conditions d’exploitation sont les mêmes que pour un référentiel de configuration. Chaque fiche a un propriétaire nommé, est versionnée et conservée avec les versions de la destination auxquelles elle s’applique. Le réexamen se déclenche sur des événements précis, pas sur un rythme annuel de principe :

Le dernier maillon du cycle est le plus coûteux : un changement de destination par un déployeur peut faire de lui un fournisseur au sens de l’article 25, paragraphe 1, point c), avec toutes les obligations correspondantes. La mécanique est détaillée dans la page rôles fournisseur et déployeur. Pour la supervision, le signal le plus fiable n’est pas juridique : c’est l’apparition d’un nouveau consommateur d’un modèle ou d’une API, visible dans les journaux de la passerelle d’appels. L’observabilité décrite dans la page observabilité LLM en production fournit ce signal à moindre coût.

Erreurs de classement fréquentes et contournements

Le classement a sa propre surface d’attaque : des contournements, volontaires ou non, qui produisent un « non haut risque » sur papier pour un système qui l’est en pratique. En conformité, la case la mieux remplie est souvent celle qui protège le moins.

Classer la technologie au lieu de la destination. Le raisonnement « c’est un simple modèle statistique » ou « c’est juste un LLM » n’a aucune valeur au regard de l’article 6. La contre-mesure consiste à structurer l’inventaire par usage, pas par composant.
Oublier l’IA embarquée dans un logiciel acheté. L’éditeur est fournisseur, l’organisation est déployeuse. Si la fonction relève de l’annexe III, les obligations du déployeur s’appliquent. Pour un modèle consommé par API, la page AI Act pour le déployeur d’un modèle par API précise la répartition. La contre-mesure : une clause contractuelle qui impose à l’éditeur d’annoncer toute fonction d’IA activée et sa classification.
Invoquer la dérogation pour un système qui note ou classe des personnes. Il s’agit de profilage, donc le verrou s’applique. Aucune rédaction ne contourne l’article 4, point 4, du RGPD.
Restreindre la destination sans contrôler l’usage. Écrire « ne pas utiliser pour évaluer des personnes » dans les conditions générales d’utilisation (CGU), puis livrer un tableau de bord trié par employé, ne trompe personne. La destination inclut la documentation commerciale et le contexte d’utilisation : un usage prévisible que tout dans le produit encourage pèse plus lourd qu’une phrase d’avertissement.
Découper un système pour faire passer chaque morceau en tâche « procédurale ». Un pipeline extraction, puis score, puis tri, où aucun maillon pris isolément ne « décide », reste un système qui détermine le résultat. Le test de l’effet s’applique à la chaîne entière.
Confondre « pas haut risque » et « pas d’obligation ». Les articles 4 et 5 restent applicables, l’article 50 selon le type de système, tout comme le RGPD, qui encadre déjà les décisions automatisées (article 22).
Figer le classement. Une annexe modifiable par acte délégué combinée à un éditeur qui livre des fonctions chaque trimestre : un classement daté de la mise en service perd vite sa valeur.

Ce que la classification ne garantit pas

Une fiche de classement exacte ne rend pas le système conforme. Elle détermine quel régime s’applique : pour le haut risque, système de gestion des risques, gouvernance des données, documentation technique, journalisation, contrôle humain, robustesse et cybersécurité (articles 9 à 15), ainsi que les obligations du déployeur de l’article 26. La mise en œuvre de ces exigences reste à faire.

La classification ne dit rien non plus de la sécurité du système. Un système « minimal » peut fuir des données via un connecteur, être détourné par injection d’instructions ou coûter très cher par abus d’API. Ces risques relèvent de l’architecture (voir la page guardrails programmatiques), pas de l’article 6. Enfin, la fiche ne constitue pas un avis juridique sur un cas particulier : elle cite les articles, et l’arbitrage d’un cas litigieux revient à un juriste qui s’appuie sur le texte consolidé et les lignes directrices de la Commission.

Exemple : quatre usages d’une régie des eaux fictive

Une régie fictive de distribution d’eau potable inventorie quatre usages. Aucun n’est un tri de CV (curriculum vitae), et chacun suit une branche différente de l’arbre.

La lecture du schéma enseigne trois choses. D’abord, l’usage 1 bascule parce que le système agit sur l’exploitation ; s’il se contentait d’afficher des alertes à un opérateur qui décide seul, la qualification de composant de sécurité serait à réévaluer. Ensuite, l’usage 3 est le cas classique de l’IA embarquée : personne n’a lancé de « projet IA », pourtant la régie se retrouve déployeuse d’un système à haut risque, avec les obligations de l’article 26 (contrôle humain, surveillance, information des représentants du personnel). Enfin, le passage de 4a à 4b résume tout l’article 6 : même outil, même éditeur, une colonne de score en plus, et le système passe d’une fiche de dérogation à l’intégralité du régime du haut risque. Si c’est la régie qui active ce score hors de la destination prévue par l’éditeur, elle peut devenir fournisseur (article 25, paragraphe 1, point c)). Ce changement doit donc déclencher un réexamen, pas une simple note de version.

🐝 Ce qui arrive si on s’en passe

Sans classement par usage, un système relevant de l’annexe III fonctionne sans gestion des risques, sans journalisation exploitable ni contrôle humain effectif, et personne ne s’en aperçoit avant une demande d’autorité. Sans fiche d’évaluation écrite avant la mise en service, la dérogation de l’article 6, paragraphe 3, ne peut plus être défendue : elle devait exister avant, pas être reconstituée ensuite. Sans réexamen déclenché par les changements d’usage, un déployeur qui ajoute un score devient fournisseur sans le savoir, et porte des obligations de conception qu’il ne peut plus remplir sur un système déjà utilisé. Enfin, sans inventaire de l’IA embarquée, les fonctions activées par les éditeurs échappent à toute décision : la conformité dépend alors des notes de version d’un tiers.

🦫 Explication de la marmotte 🍫

La loi européenne sur l’intelligence artificielle range les programmes dans plusieurs catégories. La plus exigeante s’appelle « haut risque ». Pour savoir si un programme y entre, on ne regarde pas sa technique : on regarde à quoi il sert et sur qui il agit. On commence donc par dresser la liste de tous les programmes utilisés, y compris ceux cachés dans des logiciels achetés, et on note pour chacun son usage exact. Ensuite, on pose les questions dans l’ordre. Le programme est-il interdit ? Si oui, on l’arrête. Sert-il à la sécurité d’un produit déjà très contrôlé, comme un dispositif médical ou un ascenseur, vérifié par un organisme extérieur ? Si oui, il est à haut risque. Touche-t-il un domaine sensible de la liste officielle, comme l’emploi, l’école, les aides sociales, le crédit, la justice ou la sécurité de l’eau et de l’électricité ? Si oui, il est en principe à haut risque. Il peut y échapper s’il ne fait qu’une petite tâche annexe qui ne change pas la décision finale, mais jamais s’il note ou classe des personnes. Dans ce cas, il faut écrire et conserver cette analyse avant de l’utiliser. Chaque fois que l’usage change, on recommence. Une erreur à ce stade fait qu’un programme qui juge des gens fonctionne sans aucune protection, et sans pouvoir le justifier devant une autorité.

Pages voisines

La citent

AI Act : classer un système d'IA à haut risque (article 6, annexes I et III)

Elle cite

: les deux pages se citent l’une l’autre.