AI Act et système à haut risque : la définition juridique de l'article 6 expliquée

La qualification « haut risque » constitue la ligne de partage de tout l'AI Act : c'est elle qui déclenche la cascade d'obligations la plus lourde du règlement, entre gestion des risques, documentation technique et supervision humaine. Pourtant, cette définition n'a rien d'intuitif, et sa lecture littérale de l'article 6 laisse souvent les praticiens perplexes face à des renvois croisés vers les annexes du texte.

L'actualité récente complique encore l'exercice : le calendrier d'application n'est plus celui annoncé lors de l'adoption du règlement en 2024. Le Digital Omnibus, adopté par le Parlement européen le 16 juin 2026, a reporté l'application des obligations de l'annexe III du 2 août 2026 au 2 décembre 2027. Ce report ne change toutefois rien à la définition elle-même du système à haut risque, ni à l'intérêt de la qualifier dès maintenant. Cet article revient sur la définition légale posée par l'article 6, détaille les catégories de l'annexe III, explique le mécanisme d'exclusion qui permet parfois d'échapper à cette qualification, présente les obligations concrètes qui en découlent, et actualise le calendrier d'application à la lumière du Digital Omnibus.

La définition juridique du système d'IA à haut risque

Avant d'entrer dans le détail des catégories concernées, il convient de comprendre la mécanique juridique posée par l'article 6, pivot de tout le règlement, ainsi que la place de cette qualification parmi les autres niveaux de risque prévus par le texte.

Le fondement textuel : l'article 6 du règlement

Le règlement (UE) 2024/1689, dit AI Act, est entré en vigueur le 1er août 2024. Son article 6 ne définit pas directement, dans le corps du texte, ce qu'est un système à haut risque : il organise plutôt un mécanisme de renvoi vers deux annexes distinctes, l'annexe I et l'annexe III, dont l'application concrète détermine, au cas par cas, si un système donné relève ou non de cette qualification.

Les deux grands critères de qualification, ou « voies » d'entrée dans le haut risque

Une première voie, fondée sur l'annexe I, vise les systèmes utilisés comme composant de sécurité d'un produit, ou qui constituent eux-mêmes un produit, dès lors que ce produit relève d'une législation d'harmonisation de l'Union et doit faire l'objet d'une évaluation de conformité par un tiers. Une seconde voie, fondée sur l'annexe III, vise des systèmes entrant dans une liste précise de catégories d'usage, indépendamment de tout produit sous-jacent. Cette seconde voie mérite d'être soulignée pour les praticiens habitués à raisonner en termes de produits réglementés : un système d'IA peut parfaitement être qualifié de haut risque alors même qu'il est commercialisé seul, sous forme de logiciel autonome, sans intégration à un dispositif physique.

Haut risque, risque limité, risque minimal : ne pas confondre les niveaux

Le règlement distingue quatre niveaux de risque, qui n'emportent pas les mêmes conséquences. Le risque inacceptable rassemble les usages purement et simplement interdits, tels que la notation sociale ou la manipulation comportementale ; le Digital Omnibus y a d'ailleurs ajouté, en juin 2026, une nouvelle interdiction visant les contenus intimes non consentis générés par IA. Le haut risque, objet de cet article, emporte des obligations lourdes et documentées. Le risque limité se contente d'une obligation de transparence, comme pour les chatbots ou les contenus générés par IA, qui doivent signaler leur nature artificielle. Le risque minimal, enfin, ne fait l'objet d'aucune contrainte spécifique au titre du règlement.

Les catégories de systèmes visées par l'annexe III

Une fois la mécanique de l'article 6 posée, il reste à examiner concrètement les usages que l'annexe III range dans la catégorie haut risque, puisque c'est cette seconde voie qui concerne le plus grand nombre d'organisations, bien au-delà des seuls fabricants de produits industriels.

Panorama des huit domaines couverts

L'annexe III retient huit domaines. La biométrie couvre l'identification biométrique à distance, la catégorisation biométrique et la reconnaissance des émotions. Les infrastructures critiques englobent la gestion des réseaux d'énergie, d'eau, de gaz ou de transport. L'éducation et la formation professionnelle visent les systèmes déterminant l'accès aux établissements ou l'évaluation des acquis des élèves. L'emploi et la gestion des travailleurs couvrent les outils de recrutement, d'évaluation des candidats et de gestion de la performance. L'accès à des services essentiels publics et privés inclut le scoring de crédit, l'assurance et l'évaluation des demandes de prestations sociales. S'y ajoutent l'application de la loi, la migration et le contrôle des frontières, ainsi que l'administration de la justice et les processus démocratiques.

Le tableau suivant illustre, pour chacun de ces huit domaines, un exemple concret d'application et le type d'acteur généralement concerné par la qualification.

Ce tableau appelle un commentaire pratique essentiel : le domaine « emploi et gestion des travailleurs » mérite une attention particulière, car il touche un nombre très large d'organisations, bien au-delà des seuls éditeurs spécialisés. Toute entreprise utilisant un outil d'aide au recrutement ou d'évaluation de la performance, même développé par un tiers, doit vérifier sa qualification au regard de ce domaine, indépendamment de son secteur d'activité principal.

Une liste évolutive, précisée par les lignes directrices de la Commission

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, fondé sur l'article 6(5) du règlement. Ce document, soumis à consultation ciblée jusqu'au 23 juin 2026, ne modifie pas le texte du règlement lui-même : il précise l'interprétation des concepts clés utilisés pour la classification et fournit des exemples concrets de cas devant, ou non, être qualifiés de haut risque, pour l'ensemble des domaines couverts par l'annexe III.

Le mécanisme d'exclusion : quand un système de l'annexe III échappe à la qualification

L'appartenance d'un système à l'une des huit catégories de l'annexe III ne suffit pas, à elle seule, à emporter automatiquement la qualification de haut risque. Le règlement prévoit un mécanisme d'exclusion, dont la portée reste toutefois strictement encadrée par une exception majeure.

Le filtre général d'exclusion

Un système relevant d'une catégorie de l'annexe III peut ne pas être qualifié de haut risque s'il ne présente pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux des personnes. Cette condition doit se combiner avec une seconde exigence cumulative : le système ne doit pas non plus influencer sensiblement le résultat d'une décision prise à l'égard d'une personne physique.

Les hypothèses concrètes de tâche procédurale limitée

Parmi les situations concrètes susceptibles de justifier cette exclusion figurent l'exécution d'une tâche purement procédurale, l'amélioration du résultat d'une activité humaine déjà réalisée, ou encore la détection de schémas ou d'anomalies sans que le système ne se substitue à l'appréciation humaine. Il appartient toutefois au fournisseur de documenter cette auto-évaluation avec rigueur, y compris et surtout lorsqu'elle le conduit à écarter la qualification haut risque, car c'est précisément ce raisonnement qui sera examiné en cas de contrôle par les autorités de surveillance du marché.

L'exception à l'exception : le profilage toujours considéré comme haut risque

Cette faculté d'exclusion connaît une limite stricte : lorsque le système effectue du profilage de personnes physiques, l'exclusion ne joue jamais, quelle que soit par ailleurs l'analyse de risque conduite par le fournisseur. Un système qui construit un profil individuel à des fins de prédiction ou d'évaluation reste donc systématiquement qualifié de haut risque dès lors qu'il relève de l'une des catégories de l'annexe III, sans qu'aucune argumentation contraire ne puisse être valablement opposée.

Les obligations concrètes déclenchées par la qualification haut risque

Une fois la qualification établie, qu'elle résulte de l'annexe I ou de l'annexe III, le règlement impose un ensemble d'obligations structurées, réparties entre le fournisseur du système et son déployeur, chacun devant assumer des responsabilités propres.

Les obligations pesant sur le fournisseur

Le fournisseur doit mettre en place un système de gestion des risques couvrant l'ensemble du cycle de vie du système, garantir la gouvernance et la qualité des données utilisées pour l'entraînement, la validation et les tests, établir une documentation technique détaillée conforme à l'annexe IV du règlement, et assurer la tenue de journaux permettant la traçabilité du fonctionnement du système. Il doit également intégrer une supervision humaine effective dès la conception, garantir un niveau approprié de robustesse, de précision et de cybersécurité, procéder au marquage CE et à la déclaration UE de conformité, et enregistrer le système dans la base de données européenne dédiée.

Les obligations propres au déployeur

Le déployeur, c'est-à-dire l'organisation qui utilise concrètement le système dans le cadre de son activité, conserve des obligations qui lui sont propres, distinctes de celles du fournisseur. Il doit assurer une supervision humaine effective lors de l'utilisation réelle du système, conserver les journaux générés automatiquement par celui-ci, informer les personnes concernées lorsque le règlement l'exige, et, pour certains déployeurs du secteur public, conduire une analyse d'impact sur les droits fondamentaux préalablement à la mise en service.

Le tableau ci-dessous synthétise cette répartition des rôles entre fournisseur et déployeur.

Le commentaire à retenir ici rejoint une logique déjà connue en matière de conformité réglementaire européenne : la responsabilité ne se transfère jamais intégralement à l'un des maillons de la chaîne. Une entreprise qui déploie un outil d'IA développé par un tiers ne peut se contenter d'invoquer la conformité du fournisseur pour s'exonérer de ses propres obligations de supervision humaine et de traçabilité, tout comme, dans un registre voisin, une entité financière reste responsable de sa conformité au règlement DORA même lorsqu'elle recourt à un prestataire informatique par ailleurs supervisé au niveau européen.

Qui est responsable : fournisseur, déployeur, ou les deux ?

Cette question de la répartition des responsabilités mérite d'être approfondie, tant elle structure en pratique la négociation contractuelle entre les acteurs de la chaîne de valeur de l'IA.

Le principe de responsabilité partagée

Le fournisseur reste responsable de la conformité intrinsèque du système qu'il met sur le marché, tandis que le déployeur conserve des obligations qui lui sont propres, au premier rang desquelles la supervision humaine effective. Une entreprise qui achète ou intègre un système d'IA développé par un tiers demeure donc co-responsable de sa conformité, sans pouvoir se retrancher derrière la seule documentation fournie par l'éditeur du système.

Le cas de la modification substantielle par un tiers

Le règlement prévoit une hypothèse particulière : toute personne qui modifie substantiellement un système à haut risque peut, de ce seul fait, devenir elle-même fournisseur au sens du texte. Cette requalification emporte une conséquence pratique importante, puisque l'ensemble des obligations complètes du fournisseur initial lui est alors transféré, y compris la documentation technique, l'évaluation de conformité et le marquage CE.

Clauses contractuelles à prévoir avec les sous-traitants techniques

Il est recommandé de prévoir, dans les contrats conclus avec les sous-traitants techniques intervenant sur un système d'IA, des clauses de coopération organisant la transmission des preuves de conformité nécessaires au déployeur, tout en articulant cette transparence avec la protection légitime des secrets d'affaires du fournisseur. Une répartition contractuelle claire des responsabilités en cas de modification du système en cours de contrat permet, en outre, d'éviter les zones grises quant à l'identité du responsable en cas de requalification ultérieure.

Le calendrier d'application, actualisé après le Digital Omnibus

Le calendrier de l'AI Act a connu, depuis son adoption, une évolution significative qu'il convient de présenter avec précision, tant les échéances initialement annoncées diffèrent aujourd'hui de celles réellement applicables.

Le calendrier initial du règlement

Le texte prévoyait, lors de son adoption, une application échelonnée en quatre temps. Les interdictions de l'article 5 et l'obligation de littératie IA de l'article 4 s'appliquaient depuis le 2 février 2025. Les obligations pour les modèles d'IA à usage général s'appliquaient depuis le 2 août 2025. Les obligations complètes pour les systèmes à haut risque de l'annexe III étaient initialement prévues pour le 2 août 2026, tandis que celles concernant les systèmes de l'annexe I intégrés à des produits réglementés devaient s'appliquer à compter du 2 août 2027.

Le report acté par le Digital Omnibus

Un accord politique est intervenu entre le Conseil et le Parlement européen le 7 mai 2026, formellement adopté par le Parlement le 16 juin 2026, dans le cadre du paquet législatif dit Digital Omnibus. Ce texte reporte l'application des obligations pleines de l'annexe III du 2 août 2026 au 2 décembre 2027, et repousse corrélativement l'échéance applicable aux systèmes de l'annexe I intégrés à des produits déjà certifiés, vers août 2028. En contrepartie de cet assouplissement de calendrier, le compromis a également introduit un durcissement matériel du texte, en étendant les interdictions de l'article 5 aux contenus intimes non consentis générés par IA.

Le commentaire à retenir de ce tableau est le suivant : ce report de seize mois ne doit en aucun cas être interprété comme un allègement de la définition juridique du haut risque, ni comme une invitation à différer la démarche de qualification. Les organisations qui attendraient l'approche de l'échéance de décembre 2027 pour engager leur cartographie prendraient un retard difficile à rattraper, tant la documentation exigée par le règlement suppose un travail préalable substantiel.

Ce que ce report ne change pas

L'obligation de littératie IA et les interdictions de l'article 5 restent pleinement applicables depuis février 2025, sans que le Digital Omnibus ne les remette en cause. L'enregistrement dans la base de données européenne demeure par ailleurs obligatoire sans exception, y compris pour les systèmes bénéficiant par ailleurs d'un allègement de calendrier. Le report ne dispense donc en rien de la démarche de cartographie et de qualification, qui reste à mener sans attendre l'échéance désormais fixée à décembre 2027.

Comment savoir si votre outil d'IA entre dans la catégorie haut risque

Au terme de cette présentation de la définition, des catégories et du calendrier, il reste à traduire ces éléments en une démarche pratique de qualification, applicable à l'échelle de chaque organisation.

Une démarche en trois étapes

La première étape consiste à cartographier l'ensemble des systèmes d'IA utilisés ou envisagés au sein de l'organisation, y compris ceux adoptés spontanément par certaines équipes en dehors de tout processus de validation formel. La deuxième étape consiste à confronter chaque usage recensé aux huit catégories de l'annexe III, en s'appuyant sur les exemples fournis par les lignes directrices de la Commission européenne. La troisième étape, souvent négligée, consiste à documenter précisément le raisonnement ayant conduit à la qualification retenue, ce raisonnement étant lui-même examiné en cas de contrôle, au-delà de la seule conclusion affichée.

Les secteurs les plus exposés

Les ressources humaines et le recrutement figurent parmi les usages les plus fréquemment concernés, tout comme les établissements financiers et les assureurs recourant à des outils de scoring de crédit. Le secteur de l'éducation et de la formation, ainsi que le secteur public au sens large, notamment pour les usages liés à la justice, à la migration ou à l'application de la loi, complètent cette liste des domaines les plus exposés à la qualification haut risque.

Le cas particulier des PME

Une PME qui développe elle-même une solution d'IA destinée à un usage professionnel relevant de l'un des secteurs sensibles se trouve pleinement soumise aux obligations de fournisseur décrites plus haut, sans dérogation de principe liée à sa taille. Lorsqu'elle se contente d'acheter une solution tierce, la charge de conformité se déplace pour partie vers le fournisseur, sans pour autant supprimer les obligations propres de déployeur qui continuent de lui incomber, notamment en matière de supervision humaine. Le règlement prévoit néanmoins certaines mesures de soutien et allègements procéduraux pour les acteurs de taille réduite, qu'il convient d'examiner au cas par cas selon la nature exacte du système concerné.

Foire aux questions sur l'AI Act et le système à haut risque

Les questions suivantes reprennent, sous une forme synthétique, les points les plus fréquemment soulevés par les fournisseurs et déployeurs de solutions d'IA confrontés à cette qualification.

Qu'est-ce qu'un système d'IA à haut risque au sens de l'article 6 de l'AI Act ?

Un système d'IA à haut risque est un système qui, soit constitue un composant de sécurité d'un produit relevant d'une législation d'harmonisation de l'Union et soumis à évaluation de conformité par un tiers, soit relève de l'une des catégories d'usage listées à l'annexe III du règlement, sous réserve du mécanisme d'exclusion prévu par le texte.

Quels sont les huit domaines couverts par l'annexe III ?

L'annexe III couvre la biométrie, les infrastructures critiques, l'éducation et la formation, l'emploi et la gestion des travailleurs, l'accès aux services essentiels, l'application de la loi, la migration et le contrôle des frontières, ainsi que la justice et les processus démocratiques.

Dans quels cas un système de l'annexe III échappe-t-il à la qualification haut risque ?

Un système relevant de l'annexe III peut échapper à cette qualification s'il ne présente pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux, et s'il n'influence pas sensiblement le résultat d'une décision. Cette exclusion doit être documentée par le fournisseur, qui reste tenu de justifier son raisonnement en cas de contrôle.

Le profilage empêche-t-il toujours d'échapper à cette qualification ?

Oui. Lorsque le système effectue du profilage de personnes physiques, l'exclusion ne peut jamais être invoquée, quelle que soit l'analyse de risque conduite par ailleurs par le fournisseur. Le système reste alors systématiquement qualifié de haut risque.

Quelle est la date d'application des obligations haut risque après le Digital Omnibus ?

Le Digital Omnibus, adopté par le Parlement européen le 16 juin 2026, a reporté l'application des obligations pleines pour les systèmes à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027. Les interdictions et l'obligation de littératie IA restent, en revanche, applicables depuis février 2025.

Conclusion

La définition du système d'IA à haut risque repose sur une architecture à deux voies, produit réglementé d'un côté, usage listé à l'annexe III de l'autre, tempérée par un mécanisme d'exclusion strictement borné par l'exception du profilage. Cette architecture demeure inchangée malgré le report de calendrier acté par le Digital Omnibus en juin 2026 : ce que la réforme a repoussé, c'est l'échéance d'application des obligations pleines, pas la définition juridique elle-même ni l'intérêt d'engager, dès à présent, la cartographie de ses systèmes d'IA.

Cette exigence de cartographie et de documentation continue rejoint d'ailleurs une tendance plus large du droit européen de la conformité, que l'on retrouve dans d'autres textes structurant aujourd'hui la gouvernance des entreprises, qu'il s'agisse du reporting de durabilité imposé par la CSRD ou de la vigilance exigée sur l'ensemble d'une chaîne de valeur par la loi de 2017 et son pendant européen, la CS3D, dont la transposition en droit français reste d'ailleurs toujours en attente à ce jour. Dans les trois cas, le législateur européen impose aux organisations de documenter, de tracer et de justifier leurs choix, plutôt que de se contenter d'une conformité de façade. Pour les fournisseurs et déployeurs de systèmes d'IA, l'enjeu des prochains mois consiste donc à transformer ce délai supplémentaire en réelle préparation, plutôt qu'en simple report de l'échéance.

‍