Système d’IA à haut risque : la classification AI Act

L’essentiel

• L’échéance applicable au système d’IA à haut risque a bougé, pas les règles. Le règlement (UE) 2026/1744 reporte les obligations de l’annexe III au 2 décembre 2027 et celles de l’annexe I au 2 août 2028, sans toucher à l’article 6.
• Tant que la qualification n’est pas faite, vous ignorez quelle échéance vous concerne. Les obligations de transparence de l’article 50 n’ont fait l’objet d’aucun report et s’appliquent depuis le 2 août 2026.
• Deux voies mènent au haut risque : celle des produits de l’annexe I et celle des cas d’usage de l’annexe III. Seule la seconde se présente comme une liste.
• La dérogation de l’article 6, paragraphe 3, n’est pas un allègement. Elle impose de documenter l’analyse avant la mise sur le marché et d’enregistrer la déclaration dans la base de données européenne.
• Ni une clause contractuelle, ni la présence d’un opérateur humain, ni un découpage en modules ne modifient la qualification, qui suit la destination du système.

Le calendrier a bougé, la qualification reste due

Attendre que le régime du système d’IA à haut risque se stabilise avant de qualifier ses systèmes est aujourd’hui le vrai risque. Le règlement (UE) 2026/1744, dit omnibus numérique sur l’IA, a été publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet 2026, modifiant le règlement (UE) 2024/1689 (EUR-Lex). Il a déplacé les dates de mise en conformité. Il n’a pas modifié la question de savoir qui entre dans le champ. Trois dates coexistent désormais dans le même texte, et elles divergent :

1. 2 décembre 2027. Obligations applicables aux systèmes autonomes visés à l’annexe III, initialement prévues au 2 août 2026.
2. 2 août 2028. Obligations applicables à l’IA intégrée dans des produits déjà couverts par la législation d’harmonisation de l’Union au titre de l’annexe I, initialement prévues au 2 août 2027.
3. 2 août 2026. Les obligations de transparence de l’article 50, qui n’ont pas été reportées. L’information de l’utilisateur qui interagit avec un système d’IA s’applique depuis cette date, avec un court délai de grâce jusqu’au 2 décembre 2026 pour le marquage des contenus générés par machine.

La conséquence pratique passe souvent inaperçue. Une équipe qui n’a pas qualifié ses systèmes ne peut pas dire laquelle de ces trois dates gouverne sa feuille de route. Le report a d’ailleurs été arrêté sous forme de dates fixes, et non du mécanisme conditionnel initialement proposé par la Commission, qui aurait dépendu de la disponibilité des normes harmonisées (analyse Gibson Dunn). Aucun glissement supplémentaire n’est donc prévu. La qualification est le premier acte de gouvernance, pas une tâche de conformité aval. Elle détermine votre échéance, votre corpus d’obligations, la nécessité ou non d’une évaluation de la conformité, et l’existence d’une obligation d’enregistrement avant la mise sur le marché. Si votre registre des systèmes d’IA ne porte pas une décision de qualification par système, vous n’avez pas de position de conformité : vous avez l’intention d’en construire une plus tard.

Deux voies mènent au système d’IA à haut risque, une seule est une liste

L’article 6 ouvre deux chemins indépendants. Il suffit qu’un système emprunte l’un des deux.

Première voie : produits et composants de sécurité de l’annexe I

Au titre de l’article 6, paragraphe 1, un système est à haut risque lorsque deux conditions sont réunies. D’une part, le système d’IA est destiné à être utilisé comme composant de sécurité d’un produit, ou constitue lui-même un produit, couvert par la législation d’harmonisation de l’Union énumérée à l’annexe I : machines, dispositifs médicaux, ascenseurs, jouets, équipements radioélectriques, dispositifs de diagnostic in vitro et familles de produits réglementés analogues. D’autre part, ce produit doit être soumis à une évaluation de la conformité par un tiers au titre de cette même législation (article 6). La seconde condition est décisive et régulièrement oubliée. Appartenir à une famille de produits de l’annexe I ne suffit pas. Si le régime propre au produit autorise l’auto-évaluation, cette voie ne se referme pas. La notion de composant de sécurité est plus large qu’il n’y paraît. L’article 3, point 14, vise le composant dont la défaillance met en danger la santé et la sécurité, et pas seulement celui dont la fonction déclarée est la sécurité. Un optimiseur de rendement de combustion vendu comme fonction d’économie d’énergie peut ainsi être concerné, car sa défaillance crée un risque d’intoxication au monoxyde de carbone. L’omnibus a resserré la notion en excluant les composants qui se bornent à assister l’utilisateur sans créer de risque pour la santé ou la sécurité, comme le relève Travers Smith.

Seconde voie : les cas d’usage de l’annexe III

Au titre de l’article 6, paragraphe 2, un système est à haut risque s’il relève d’un cas d’usage énuméré à l’annexe III et qu’aucun des filtres de l’article 6, paragraphe 3, ne le fait sortir. C’est la voie qu’empruntent la plupart des éditeurs de logiciels, et celle que l’on a en tête lorsqu’on cherche la liste des cas de haut risque. Les deux voies emportent le même corpus d’obligations, mais des dates différentes : décembre 2027 pour l’annexe III, août 2028 pour l’annexe I. Un industriel qui livre un composant d’IA dans un matériel réglementé et un éditeur SaaS qui vend un outil de recrutement ne sont pas sur la même horloge.

Les huit domaines de l’annexe III, lus comme les lit un auditeur

La plupart des guides reproduisent l’annexe III sous forme de liste de secteurs. Ce cadrage produit des erreurs de qualification, car l’annexe ne régit pas des secteurs : elle régit des décisions. Chaque domaine se lit à partir de la décision que le système touche.

• Biométrie. Identification biométrique à distance, catégorisation biométrique déduisant des attributs sensibles ou protégés, et reconnaissance des émotions. Certaines pratiques biométriques sont d’ailleurs interdites au titre de l’article 5, et non simplement classées à haut risque.
• Infrastructures critiques. Uniquement lorsque le système agit comme composant de sécurité dans la gestion ou l’exploitation d’infrastructures numériques, du trafic routier ou de la fourniture d’énergie et d’eau. Un outil d’analyse administrative pour un opérateur d’énergie n’entre pas automatiquement dans le champ.
• Éducation et formation professionnelle. Décisions d’admission, évaluation des acquis, orientation vers un niveau d’enseignement et surveillance des comportements interdits pendant les examens. C’est l’évaluation certificative qui déclenche.
• Emploi et gestion des travailleurs. Toute la chaîne de recrutement, du sourcing à la sélection, ainsi que les décisions de promotion, de rupture, d’affectation des tâches et de suivi de la performance. C’est le domaine le plus large en pratique, et celui que les éditeurs sous-estiment le plus souvent.
• Accès aux services essentiels, publics et privés. Éligibilité aux prestations sociales, évaluation de la solvabilité, tarification et évaluation des risques en assurance vie et santé, régulation des appels d’urgence et triage.
• Répression. Évaluation du risque de commission ou de récidive, appréciation de la fiabilité des preuves, outils de type polygraphe et profilage au cours d’enquêtes.
• Migration, asile et contrôle aux frontières. Analyses de risque, examen des demandes de visa et d’asile, identification.
• Administration de la justice et processus démocratiques. Assistance aux autorités judiciaires dans la recherche et l’interprétation des faits et du droit, et systèmes destinés à influer sur le résultat d’une élection ou sur le comportement électoral.

Si votre système produit une donnée d’entrée pour l’une de ces décisions, vous relevez de l’annexe tant qu’un filtre ne vous en sort pas. C’est la présomption correcte, et c’est l’inverse du raisonnement spontané de la plupart des équipes. Notre guide opérationnel du règlement européen sur l’IA détaille ce qui suit lorsque la qualification tombe sur le haut risque.

L’article 6, paragraphe 3 : la dérogation qui coûte plus cher que la conformité

C’est la disposition la plus mal lue du régime du système d’IA à haut risque. L’article 6, paragraphe 3, permet à un fournisseur de conclure qu’un système relevant pourtant de l’annexe III n’est pas à haut risque, au motif qu’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 manière substantielle le résultat de la prise de décision.

Les quatre filtres

Un système ne sort du champ que s’il remplit au moins l’une de ces conditions :

1. Tâche procédurale étroite. Convertir des données non structurées en données structurées, classer des documents entrants dans des catégories prédéfinies, détecter des doublons.
2. Amélioration d’une activité humaine déjà accomplie. Le système affine un résultat qu’un humain a déjà produit, sans le remplacer ni refaire ce jugement de façon autonome.
3. Détection de schémas décisionnels ou d’écarts. Signaler qu’une décision s’écarte des schémas antérieurs, sans se substituer à l’appréciation humaine ni l’influencer en l’absence d’un examen approprié.
4. Tâche préparatoire. Indexer, rechercher, traduire ou relier des éléments en amont d’une évaluation.

Le projet de lignes directrices de la Commission retient une lecture étroite de ces filtres. Un système qui classe, note ou étiquette des éléments comme plus ou moins utiles pour un évaluateur humain dépasse la tâche purement procédurale, parce que cet ordonnancement façonne la décision. Sur le quatrième filtre, le critère tient à la proximité avec la décision finale et au point de savoir si la sortie constitue une recommandation spécifique, selon l’analyse de Freshfields.

Les deux exclusions

Deux éléments neutralisent entièrement les filtres. Un système qui effectue un profilage de personnes physiques est toujours à haut risque, sans exception. Et un composant inséré dans une architecture plus vaste ne peut invoquer un filtre lorsque la destination combinée ou les sorties conjointes de cette architecture influencent de manière substantielle une décision à haut risque.

Pourquoi invoquer la dérogation est un acte public

C’est ici que l’économie du choix bascule. Au titre de l’article 6, paragraphe 4, le fournisseur qui conclut qu’un système de l’annexe III n’est pas à haut risque doit documenter cette analyse avant la mise sur le marché ou la mise en service. Au titre de l’article 49, paragraphe 2, il doit ensuite s’enregistrer et enregistrer le système dans la base de données de l’UE. L’omnibus a maintenu cette obligation d’enregistrement tout en réduisant le volume d’informations exigé. La dérogation n’est donc pas une décision privée prise en revue de conception. C’est une déclaration déposée, visible des régulateurs, accompagnée de votre raisonnement et communicable aux autorités nationales compétentes sur demande. Si une autorité de surveillance du marché a des raisons suffisantes de considérer que le système a été mal classé, elle peut réévaluer la qualification et exiger une mise en conformité complète dans un délai déterminé. Comparez honnêtement les deux trajectoires. Accepter le haut risque, c’est construire le système de gestion des risques de l’article 9 et le reste des obligations du chapitre III sur une horloge fixée à décembre 2027. Invoquer la dérogation, c’est produire une analyse juridique défendable maintenant, publier la déclaration maintenant, et porter le risque d’une requalification assortie d’une exposition rétroactive. Pour un système réellement procédural, la dérogation est le bon choix. Pour un cas limite, c’est souvent la route la plus coûteuse.

Trois erreurs récurrentes de qualification

Le projet de lignes directrices ferme trois arguments encore courants en revue de conception.

« Nos conditions générales excluent les usages à haut risque »

La qualification suit la destination, définie à l’article 3, point 12, comme l’utilisation à laquelle le fournisseur destine le système, telle qu’elle ressort de la notice d’utilisation, des documents commerciaux et publicitaires, des déclarations et de la documentation technique. Une clause d’exclusion enfouie dans des conditions générales ne prime pas sur ce que votre marketing affirme que le produit fait. Lorsque la documentation présente une applicabilité large sans exclure clairement les usages à haut risque, la destination peut être lue comme les englobant, en particulier si ces usages sont réalisables et raisonnablement prévisibles. Un second effet de bord existe. Au titre de l’article 25, un distributeur, un importateur ou un déployeur qui appose son nom sur un système à haut risque, le modifie substantiellement ou détourne un système généraliste vers un usage à haut risque devient fournisseur et hérite des obligations correspondantes. Acheter un outil généraliste et le pointer vers une décision de recrutement fait de vous le fournisseur d’un système à haut risque.

« Nous avons un humain dans la boucle »

La présence d’un opérateur humain ne peut à elle seule empêcher la qualification. Celle-ci se décide au regard de la destination ; la supervision humaine est ce que l’article 14 exige une fois le système déjà qualifié. Traiter le relecteur comme un bouclier de qualification inverse la structure du règlement. Le degré d’implication humaine n’est pas pour autant indifférent. Il peut étayer l’argument selon lequel le système n’assure qu’une fonction limitée ou préparatoire qui n’influence pas substantiellement la décision, ce qui alimente l’analyse au titre de l’article 6, paragraphe 3. Mais il s’agit d’un argument de filtre, étayé par des éléments de preuve, et non d’une exemption générale. La distinction entre supervision humaine dans la boucle et sur la boucle compte pour la conception au titre de l’article 14, pas pour l’application de l’article 6.

« Nous l’avons découpé en modules »

Lorsque plusieurs composants d’IA forment un ensemble plus vaste doté d’une destination combinée, ou dont les sorties conjointes influencent substantiellement une décision, l’évaluation est globale. Découper une architecture en services individuellement anodins ne fait pas échec à la qualification. Les lignes directrices étendent le même raisonnement aux systèmes agentiques qui se coordonnent par des actions interconnectées. Seuls les composants réellement séparables, assurant des fonctions strictement procédurales ou préparatoires et ne concourant pas à la finalité à haut risque, restent hors du champ.

Ce que le projet de lignes directrices change concrètement

L’article 6, paragraphe 5, impose à la Commission de publier des lignes directrices sur la mise en oeuvre pratique des règles de classification. Le projet est paru le 19 mai 2026, après la date du 2 février 2026 fixée par le règlement, et a ouvert une consultation ciblée prolongée jusqu’au 23 juillet 2026 à la demande des parties prenantes (Commission européenne). Le texte définitif est attendu d’ici la fin de 2026. Le projet s’organise en principes généraux, voie des composants de sécurité de l’annexe I et cas d’usage de l’annexe III, assortis d’exemples pratiques de systèmes qui devraient ou ne devraient pas être classés à haut risque. La Commission précise que ces exemples ne sont pas exhaustifs et pourront être actualisés. Deux conséquences pour une équipe de gouvernance. Les lignes directrices sont non contraignantes et ne créent donc pas d’obligations par elles-mêmes. Mais elles sont conçues pour orienter les autorités de surveillance du marché vers une application uniforme, ce qui en fait le référentiel opérationnel auquel une autorité vous comparera. En France, la CNIL a d’ailleurs pris l’habitude de publier ses propres recommandations sur l’IA en articulation avec ce corpus. Et parce que le texte est encore à l’état de projet, une qualification prononcée aujourd’hui doit consigner la version sur laquelle elle s’appuie et porter un déclencheur de réexamen pour l’arrivée du texte définitif. C’est de l’hygiène de conformité IA ordinaire, peu coûteuse à intégrer maintenant et onéreuse à rattraper ensuite sur un portefeuille entier.

Faire de la qualification une trace défendable

Une qualification qui vit dans un fil de discussion n’est pas une qualification. Que vous aboutissiez au haut risque ou à un filtre de l’article 6, paragraphe 3, la sortie doit être une trace datée et attribuée. Elle devrait au minimum porter :

• L’identité du système et sa version, pour rattacher la décision à un objet précis.
• La destination telle que publiée, en citant votre propre notice d’utilisation et vos supports commerciaux plutôt qu’en les paraphrasant.
• La voie testée, annexe I ou annexe III, et le résultat de chacune.
• Le filtre éventuellement invoqué, avec le raisonnement et les éléments établissant que le système n’influence pas substantiellement la décision.
• Le contrôle du profilage et le contrôle d’architecture, consignés comme des négations explicites plutôt que laissés silencieux.
• Le responsable désigné, la date, et le déclencheur qui impose une réévaluation.

C’est ce dernier point que les équipes omettent. Une modification substantielle relance l’analyse, tout comme un changement dans la manière dont le produit est commercialisé. Une qualification est une affirmation portant sur une version et sur une destination déclarée, et ces deux éléments bougent. Conserver la trace à côté de la documentation technique, plutôt que dans un dossier juridique séparé, est ce qui la rend récupérable le jour où une autorité la demande. C’est la discipline qui fonde toute gouvernance de l’IA opérante : la décision et sa preuve vivent ensemble et restent adressables.

Questions fréquentes

Qu’est-ce qu’un système d’IA à haut risque ? C’est un système qui relève de l’une des deux voies de l’article 6. Soit il est un composant de sécurité d’un produit couvert par l’annexe I, ou constitue lui-même un tel produit, et ce produit est soumis à une évaluation de la conformité par un tiers. Soit il relève d’un cas d’usage énuméré à l’annexe III sans qu’aucun des quatre filtres de l’article 6, paragraphe 3, ne s’applique. Un système qui effectue un profilage de personnes physiques est dans tous les cas à haut risque. Quelles sont les lignes directrices de la Commission sur les systèmes à haut risque ? La Commission européenne a publié le 19 mai 2026 un projet de lignes directrices sur la classification des systèmes d’IA à haut risque, au titre de l’article 6, paragraphe 5. Elles interprètent les notions de classification et fournissent des exemples pratiques, non exhaustifs, de systèmes qui devraient ou non être qualifiés. Une consultation ciblée s’est tenue jusqu’au 23 juillet 2026 et la version définitive est attendue d’ici la fin de 2026. Non contraignantes, elles orientent néanmoins les autorités de surveillance du marché et servent donc de référence pratique. Quels cas d’usage l’annexe III retient-elle ? Huit domaines : biométrie ; infrastructures critiques ; éducation et formation professionnelle ; emploi et gestion des travailleurs ; accès aux services essentiels publics et privés, y compris la solvabilité et la tarification en assurance ; répression ; migration, asile et contrôle aux frontières ; administration de la justice et processus démocratiques. Le règlement européen sur l’IA est-il obligatoire ? Oui. C’est un règlement, donc directement applicable dans tous les États membres sans transposition nationale. Ce qui a changé en 2026 relève du calendrier et non du principe : le règlement (UE) 2026/1744 a reporté les obligations relatives au haut risque au 2 décembre 2027 pour l’annexe III et au 2 août 2028 pour l’annexe I. Les pratiques interdites et les obligations de transparence de l’article 50 s’appliquent déjà. Le report à décembre 2027 permet-il d’attendre ? Non, pour deux raisons. Si vous entendez vous prévaloir de la dérogation de l’article 6, paragraphe 3, l’analyse doit être documentée et enregistrée avant la mise sur le marché : c’est une obligation antérieure à la commercialisation, pas une échéance de 2027. Et si la qualification aboutit au haut risque, décembre 2027 est la date à laquelle l’évaluation de la conformité, la documentation technique, la journalisation, le système de management de la qualité et l’enregistrement doivent déjà être en place, non celle à laquelle le travail commence. Qui décide de la qualification, le fournisseur ou le déployeur ? Le fournisseur établit et documente la qualification. Le déployeur n’est pas pour autant passif : au titre de l’article 25, il devient fournisseur, avec l’ensemble des obligations correspondantes, s’il appose son nom ou sa marque sur un système à haut risque, le modifie substantiellement, ou l’emploie hors de sa destination déclarée pour un usage à haut risque. Beaucoup d’organisations qui se considèrent déployeurs sont en réalité fournisseurs d’au moins un système.

Conclusion

L’omnibus numérique a acheté du temps sur les obligations du système d’IA à haut risque. Il n’en a acheté aucun sur la question. L’article 6 demande toujours si un système est un composant de sécurité dans un produit réglementé, s’il relève de l’un des huit domaines de l’annexe III, et si l’un des quatre filtres étroits s’applique réellement. La réponse fixe votre échéance, votre corpus d’obligations et votre obligation d’enregistrement, et la seule voie qui ressemble à une échappatoire porte son propre coût de documentation et d’enregistrement préalables. Les organisations qui seront prêtes en décembre 2027 sont celles qui traitent dès maintenant la qualification comme une décision gouvernée et versionnée, dotée d’un responsable et d’un déclencheur de réexamen, plutôt que comme une note juridique rédigée quand l’échéance devient assez proche pour paraître réelle.