Qualifier, c’est déterminer le régime juridique applicable à partir des caractéristiques que le droit juge pertinentes. Paul Amselek y voyait une manière de « projeter une pensée rationalisatrice sur les choses du monde ».[1]

Le règlement européen sur l’intelligence artificielle (ci-après l’« AI Act ») en offre une illustration concrète : le « haut risque » ne se déduit pas de la technologie considérée abstraitement, mais de sa destination, de ses usages et, dans certains cas, des conséquences de sa défaillance. La qualification procède ainsi moins d’une appréciation théorique de la dangerosité de l’IA que d’un examen fonctionnel du système dans son contexte d’utilisation.[2]

La Commission européenne a publié, le 19 mai 2026, un projet de lignes directrices précisément consacré à cette classification. Le document fournit de nombreux exemples pratiques et expose l’interprétation que la Commission entend donner à l’article 6.[3]

Comprendre le haut risque consiste donc moins à dresser une liste d’IA dangereuses qu’à comprendre comment le droit les qualifie.

I. Qualifier le système

A.  Les préalables à la qualification

a)  Interdire, informer, encadrer

Le haut risque doit d’abord être replacé dans l’architecture générale de l’AI Act.

Certaines pratiques sont interdites. L’article 5 vise notamment certaines techniques de manipulation préjudiciable, l’exploitation de vulnérabilités ou certaines formes de notation sociale. Le règlement Omnibus adopté en juillet 2026 a complété cette liste par de nouvelles interdictions, applicables à compter du 2 décembre 2026, concernant notamment certaines représentations intimes ou sexuellement explicites réalistes générées sans le consentement requis ainsi que certains contenus relatifs aux abus sexuels sur enfants.[4]

D’autres usages ne sont pas interdits mais soumis à des obligations particulières de transparence. L’article 50 impose ainsi différentes obligations aux fournisseurs et aux déployeurs de certains systèmes. Les fournisseurs de systèmes générant des contenus de synthèse doivent notamment, dans les conditions prévues par l’AI Act, veiller à ce que leurs sorties soient marquées dans un format lisible par machine et détectables comme ayant été générées ou manipulées par une IA.[5]

L’actualité en donne une illustration. À la mi-août 2026, Anthropic a présenté le mécanisme de marquage destiné aux textes générés par Claude. Il ne repose ni sur une mention visible ni sur des caractères cachés, mais sur l’introduction d’un motif statistique dans certains choix de mots. Sa détection permet d’identifier la probabilité d’intervention du modèle, avec des limites notamment pour les textes courts, très factuels ou fortement remaniés.[6]

L’exemple permet de saisir la différence avec le haut risque. Ici, le droit cherche d’abord à rendre perceptible ou détectable l’intervention d’une IA. Le haut risque répond à une autre logique : la qualification déclenche des exigences portant sur la conception, la documentation, l’évaluation et l’utilisation du système.

Ces régimes peuvent toutefois se superposer. Un système à haut risque peut également être soumis à des obligations de transparence, tandis que les modèles d’IA à usage général relèvent d’un régime propre.[7]

L’enjeu n’est donc pas de choisir entre des catégories exclusives, mais d’identifier le moment où les exigences propres au haut risque deviennent applicables.

b) Avant le haut risque, le système d’IA

Tout logiciel n’est pas nécessairement un système d’intelligence artificielle au sens de l’AI Act.

L’article 3, point 1), vise un système automatisé conçu pour fonctionner avec différents niveaux d’autonomie, susceptible de présenter une capacité d’adaptation après son déploiement et qui, pour des objectifs explicites ou implicites, déduit, à partir des entrées qu’il reçoit, la manière de générer des sorties telles que des prédictions, des contenus, des recommandations ou des décisions susceptibles d’influencer des environnements physiques ou virtuels.[8]

La Commission a consacré à cette seule définition des lignes directrices spécifiques, publiées le 6 février 2025. Elles visent précisément à aider les opérateurs à distinguer les systèmes relevant de l’AI Act des logiciels qui n’entrent pas dans cette définition.[9]

Une fois ce premier seuil franchi, un élément devient central pour la qualification du haut risque : la destination du système.

c) La destination, point de départ de la qualification

L’article 3, point 12), définit la destination par l’utilisation prévue par le fournisseur, y compris le contexte et les conditions spécifiques d’utilisation tels qu’ils ressortent notamment de la notice, de la documentation technique, des déclarations et des supports promotionnels ou commerciaux.[10]

La conséquence est importante : la qualification juridique d’un système ne dépend pas seulement de son code ou de ses capacités techniques.

La manière dont il est présenté compte aussi.

Cette question est sensible pour les systèmes polyvalents. Selon le projet de lignes directrices de la Commission, une exclusion formelle de certains usages ne devrait pas suffire lorsque la présentation générale du produit, sa documentation ou ses exemples d’utilisation prévoient ou encouragent précisément ces usages.[11]

Un fournisseur ne peut donc pas nécessairement affirmer, dans une clause générale, qu’un système ne doit pas servir à une activité à haut risque tout en le commercialisant, dans les faits, pour cette activité.

Pour l’entreprise qui achète un outil, la question n’est dès lors pas seulement de savoir ce qu’il peut faire, mais également ce pour quoi il a été conçu et présenté comme pouvant être utilisé.

Une fois cette destination identifiée, l’article 6 ouvre deux voies distinctes vers le haut risque.

B. Identifier les deux voies vers le haut risque

a) La première voie : les produits réglementés par le droit de l’Union

Deux conditions doivent être réunies.

Le système d’IA doit d’abord être destiné à être utilisé comme composant de sécurité d’un produit couvert par l’une des législations énumérées à l’annexe I, ou constituer lui-même un tel produit.

Ensuite, ce produit doit être soumis, en vertu de la législation sectorielle applicable, à une évaluation de conformité faisant intervenir un tiers avant sa mise sur le marché ou sa mise en service.[12]

La présence d’intelligence artificielle dans un produit réglementé ne suffit donc pas à faire entrer le système dans le haut risque.

L’Omnibus de 2026 a précisé la notion de composant de sécurité. Un système utilisé uniquement pour l’assistance aux utilisateurs, l’optimisation des performances, l’automatisation ou le contrôle qualité n’acquiert pas cette qualification pour cette seule raison.

Mais l’analyse change lorsque sa défaillance ou son dysfonctionnement peut mettre en danger la santé ou la sécurité.

Deux situations doivent alors être distinguées :

Dans la première, le système possède une fonction de sécurité par destination : il est conçu pour prévenir ou atténuer un risque.

Dans la seconde, sa fonction première peut être étrangère à la sécurité, mais les conséquences de sa défaillance lui donnent cette dimension.

Le projet de lignes directrices fournit un exemple : un système peut optimiser la combustion d’un appareil à gaz essentiellement pour améliorer son efficacité énergétique. Sa fonction première n’est donc pas de protéger l’utilisateur. Mais si son dysfonctionnement est susceptible de provoquer une émission dangereuse de monoxyde de carbone, une explosion ou un incendie, l’analyse ne peut s’arrêter à son objectif affiché. À l’inverse, une défaillance qui n’entraînerait qu’un inconfort ou une consommation énergétique supérieure n’appelle pas le même raisonnement.[13]

Il faut donc regarder à la fois ce que le système est censé faire et ce qui peut se produire s’il échoue.

Une réserve demeure pour certains produits relevant de la section B de l’annexe I, pour lesquels l’Omnibus organise une articulation particulière avec la législation sectorielle. La qualification de haut risque n’entraîne donc pas, dans tous les cas, l’application uniforme de l’ensemble du chapitre III.[14]

C. La seconde voie : les cas d’usage de l’annexe III

La seconde voie repose sur l’article 6, paragraphe 2, et l’annexe III.

Cette seconde voie recense des utilisations de l’IA dans huit grands domaines : biométrie, infrastructures critiques, éducation et formation professionnelle, emploi et gestion des travailleurs, accès à certains services essentiels, activités répressives, migration et contrôle des frontières, administration de la justice et processus démocratiques.[15]

Toutefois, l’annexe III ne qualifie pas des secteurs entiers de « haut risque ». Elle vise des cas d’usage déterminés.

Utiliser de l’IA dans les ressources humaines, le crédit, l’assurance ou l’éducation ne suffit donc pas. Il faut identifier la fonction exacte confiée au système et vérifier si elle correspond à l’une des fonctions énumérées par l’annexe.

La qualification porte sur un usage, non sur une étiquette sectorielle.

L’assurance en fournit une illustration.

L’annexe III vise les systèmes destinés à l’évaluation des risques et à la tarification concernant des personnes physiques en matière d’assurance-vie et d’assurance maladie.[16]

Le projet de lignes directrices en précise les frontières. L’évaluation du risque recouvre notamment l’analyse du profil d’une personne en vue de déterminer son accès à l’assurance ou les conditions de la couverture ; la tarification concerne la détermination de la prime.

Les autres branches, telles que l’assurance automobile ou habitation, ne sont pas visées par ce cas d’usage. Certains outils de gestion des sinistres ou de conception des produits peuvent également rester en dehors de son champ lorsqu’ils remplissent une fonction distincte de l’évaluation individuelle du risque et de la tarification.[17]

Un même système peut donc exercer plusieurs fonctions dont toutes ne relèvent pas nécessairement du haut risque.

Il faut toutefois se méfier d’un découpage trop artificiel. Selon le projet de lignes directrices, un module qui paraît étroit ou préparatoire lorsqu’il est examiné isolément peut contribuer substantiellement à une décision lorsqu’il est intégré à une architecture plus complexe. Cette difficulté prend une importance particulière avec le développement des systèmes interconnectés et agentiques.[18]

L’analyse doit donc descendre jusqu’aux fonctions du système sans perdre de vue ce que produit leur combinaison.

C) Appliquer le filtre de l’annexe III

L’identification d’un cas d’usage de l’annexe III ne clôt pas toujours le raisonnement.

L’article 6, paragraphe 3, permet d’écarter la qualification de haut risque lorsqu’un système ne présente pas de risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux des personnes physiques, notamment parce qu’il n’influence pas de manière significative le résultat de la décision.

Encore faut-il qu’il remplisse au moins l’une des quatre situations prévues par l’AI Act :

• accomplir une tâche procédurale étroite ;
• améliorer le résultat d’une activité humaine déjà réalisée ;
• détecter des constantes ou des écarts dans une décision antérieure sans remplacer l’évaluation humaine ;
• accomplir une tâche préparatoire à une évaluation relevant de l’annexe III.[19]

Aussi, un outil qui prépare ou organise des informations sans peser substantiellement sur l’évaluation finale n’occupe pas nécessairement la même place qu’un système qui recommande directement le candidat à recruter, la personne à assurer ou la décision à prendre.

Mais le filtre comporte une limite nette : le profilage ferme cette porte. Lorsqu’un système relevant de l’annexe III effectue un profilage de personnes physiques, il demeure considéré comme étant à haut risque.[20]

Il faut également écarter l’idée selon laquelle ajouter un humain dans la boucle suffit, à lui seul, à faire sortir un système du haut risque.

La supervision humaine constitue précisément l’une des exigences applicables aux systèmes à haut risque. Elle peut participer à l’analyse du rôle réellement exercé par le système, mais elle ne constitue pas un mécanisme autonome de déclassement.[21]

Enfin, écarter la qualification n’équivaudra pas à s’affranchir de toute justification. Lorsque ces dispositions deviendront applicables, le fournisseur qui estimera qu’un système relevant de l’annexe III bénéficie du filtre devra documenter son appréciation avant la mise sur le marché ou la mise en service et respecter les obligations d’enregistrement prévues par l’AI Act.[22]

Conclure qu’un système n’est pas à haut risque constitue donc déjà une décision de conformité qu’il faudra pouvoir expliquer.

I. Déterminer le régime applicable

A. Qui porte la qualification ?

L’AI Act ne distribue pas ses obligations à « l’entreprise » prise abstraitement. Il raisonne par rôles.

Fournisseur, déployeur, importateur, distributeur, mandataire ou fabricant : la position occupée dans la chaîne détermine les obligations qui incomberont à chacun.[23]

Une même société peut être déployeur d’un système et fournisseur d’un autre. Elle peut aussi changer de rôle en cours de route.

L’article 25 prévoit notamment qu’un distributeur, un importateur, un déployeur ou un autre tiers devient fournisseur lorsqu’il commercialise sous son propre nom ou sa propre marque un système à haut risque déjà mis sur le marché, lorsqu’il lui apporte une modification substantielle ou lorsqu’il modifie la destination d’un système qui ne relevait pas du haut risque de telle sorte qu’il y entre.[24]

Une entreprise qui adapte une solution généraliste afin de l’intégrer à un processus de recrutement, de crédit ou de tarification d’un risque d’assurance ne peut donc pas partir du principe qu’elle restera nécessairement un simple utilisateur.

Cette répartition possède également une dimension contractuelle.

L’Omnibus a renforcé l’article 25, paragraphe 4, en prévoyant, dans certaines relations entre le fournisseur d’un système à haut risque et les tiers qui lui fournissent systèmes, modèles, outils, services, composants ou processus, un accord écrit précisant les informations, capacités, accès techniques et formes d’assistance nécessaires à la conformité.[25]

La cartographie réglementaire doit ainsi être doublée d’une cartographie contractuelle : qui fixe la destination du système, qui peut le modifier, qui détient la documentation, qui maîtrise les données et les journaux, et qui pourra fournir les informations nécessaires en cas de contrôle ?

La conformité commence souvent dans le contrat avant de se révéler dans l’audit.

B. Conséquences de la qualification

Lorsqu’elles deviendront applicables, les exigences du chapitre III imposeront notamment, selon les systèmes concernés, une gestion des risques, des règles de gouvernance des données, une documentation technique, des capacités de journalisation, une information du déployeur, une supervision humaine ainsi que des exigences d’exactitude, de robustesse et de cybersécurité.[26]

Le fournisseur supportera également des obligations organisationnelles et procédurales, notamment en matière de gestion de la qualité, d’évaluation de conformité, de déclaration, d’enregistrement, de surveillance après commercialisation et de signalement des incidents graves.

Le déployeur devra, de son côté, utiliser le système conformément à la notice, mettre en œuvre les mesures de supervision humaine appropriées, surveiller son fonctionnement et conserver certains journaux. Dans les cas prévus par l’AI Act, des obligations d’information ou une analyse d’impact sur les droits fondamentaux pourront également s’ajouter.[27]

Pour une entreprise, la première mesure de conformité n’est donc pas de rédiger une politique générale sur l’intelligence artificielle.

Elle consiste d’abord à savoir quels systèmes elle utilise, à quelles fins, sous la responsabilité de qui et sous quel régime.

C. Où l’AI Act s’applique-t-il ?

La qualification suppose également de vérifier que le système et les opérateurs considérés relèvent du champ d’application territorial de l’AI Act.

Celui-ci vise notamment les fournisseurs qui mettent des systèmes d’IA sur le marché ou en service dans l’Union, qu’ils soient ou non établis sur son territoire, ainsi que les déployeurs établis dans l’Union.

Il peut également s’appliquer à des fournisseurs ou déployeurs établis dans un pays tiers lorsque les sorties produites par le système sont utilisées dans l’Union.[28]

La localisation du serveur ou du développeur ne suffit donc pas à trancher la question.

Plusieurs exclusions tempèrent néanmoins cette portée, notamment pour certaines activités militaires, de défense ou de sécurité nationale, certains systèmes développés et utilisés exclusivement à des fins de recherche scientifique et l’usage strictement personnel et non professionnel.[29]

II. Anticiper l’application du régime

A. À partir de quand ?

Le calendrier est essentiel, car une partie importante du régime décrit dans cette chronique n’est pas encore applicable.

Le règlement Omnibus du 8 juillet 2026 a reporté l’entrée en application des dispositions consacrées aux systèmes à haut risque.[30]

Certaines règles de l’AI Act sont déjà applicables. Les chapitres I et II le sont depuis le 2 février 2025, ce qui comprend notamment la définition du système d’IA, les obligations de maîtrise de l’IA et les premières pratiques interdites. Le régime des modèles d’IA à usage général et plusieurs dispositions de gouvernance sont applicables depuis le 2 août 2025. Les obligations de transparence de l’article 50 s’appliquent, sous réserve de dispositions transitoires, depuis le 2 août 2026.[31]

Pour le haut risque, deux dates sont désormais centrales :

• les dispositions concernées du chapitre III s’appliqueront à compter du 2 décembre 2027 aux systèmes qualifiés à haut risque sur le fondement de l’article 6, paragraphe 2, et de l’annexe III ;
• elles s’appliqueront à compter du 2 août 2028 aux systèmes relevant de l’article 6, paragraphe 1, et de l’annexe I.[32]

Les systèmes déjà mis sur le marché ou en service avant la date pertinente bénéficient d’un régime transitoire et ne sont, hors cas particuliers, saisis par les nouvelles obligations que s’ils font ensuite l’objet de modifications importantes de leur conception. Les systèmes à haut risque destinés à être utilisés par des autorités publiques devront en tout état de cause être mis en conformité au plus tard le 2 août 2030.[33]

La période qui s’ouvre peut être employée à inventorier les systèmes, clarifier leur destination, identifier les cas d’usage, documenter les choix de qualification et vérifier que les contrats donneront accès aux informations nécessaires lorsque les obligations deviendront applicables.

B. Conséquence d’une mauvaise qualification

L’AI Act ne sanctionne pas, en tant que telle, une « mauvaise qualification » du système. L’erreur devient problématique lorsqu’elle conduit l’opérateur à méconnaître les obligations qui auraient dû lui être applicables.

Un système à haut risque traité à tort comme un système ordinaire peut ainsi échapper aux mesures de gestion des risques, à la documentation, à l’évaluation de conformité ou aux obligations imposées à son fournisseur ou à son déployeur. Ce sont ces manquements que l’AI Act sanctionne. L’article 99 prévoit notamment, pour plusieurs obligations des opérateurs, des amendes pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial.[34]

Les conséquences peuvent toutefois apparaître bien avant une procédure de sanction : documentation insuffisante, fournisseur incapable de remettre les éléments requis, déploiement retardé, responsabilités mal réparties ou contrats à renégocier dans l’urgence.

L’enjeu de la qualification est donc moins d’éviter une sanction attachée au classement lui-même que de déterminer, suffisamment tôt, quelles obligations doivent être respectées et par qui.

Conclusion : Vers une conformité par l’intelligibilité

La qualification du système n’est qu’un point de départ. Lorsque l’IA intervient dans des usages à haut risque, l’enjeu est aussi de pouvoir comprendre, contrôler et auditer les résultats qu’elle produit.

La conformité de demain ne pourra pas reposer uniquement sur la performance statistique d’un modèle. Dans les décisions sensibles, l’entreprise devra pouvoir disposer d’éléments suffisamment intelligibles pour comprendre ce qui fonde le résultat, en apprécier la cohérence et les limites, et le soumettre à un contrôle effectif.

L’enjeu dépasse la conformité réglementaire. Il touche à la capacité de l’entreprise à assumer, contrôler et, demain, défendre les décisions prises avec l’appui de systèmes d’intelligence artificielle.

Lorsque les données, les règles et les facteurs déterminants d’un résultat peuvent être identifiés et audités, la conformité cesse d’être une déclaration pour devenir une démonstration.

Grenier Avocats accompagne les entreprises dans la définition d’un cadre juridique et éthique pour leurs usages de l’intelligence artificielle, afin d’articuler conformité réglementaire, maîtrise des risques, gouvernance des systèmes et réflexion sur les conditions dans lesquelles certaines décisions peuvent être confiées, assistées ou influencées par l’IA.

Références

[1] P. Amselek, Cheminements philosophiques dans le monde du droit et des règles en général, Paris, Armand Colin, coll. « Le temps des idées », 2012, p. 446.

[2] Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024 établissant des règles harmonisées concernant l’intelligence artificielle (« AI Act »), notamment art. 1er, § 2, c), et art. 6. L’AI Act distingue expressément les interdictions, les exigences applicables aux systèmes à haut risque, les règles de transparence et le régime des modèles d’IA à usage général.

[3] Commission européenne, Draft Commission guidelines on the classification of high-risk AI systems under Article 6 of Regulation (EU) 2024/1689, 19 mai 2026. La Commission indique que le projet vise à faciliter l’application uniforme de l’article 6 et expose son interprétation de plusieurs notions pertinentes ; la consultation ciblée s’est achevée le 23 juillet 2026.

[4] AI Act, art. 5, tel que modifié par le règlement (UE) 2026/1744 du Parlement européen et du Conseil du 8 juillet 2026 (« Digital Omnibus on AI »). L’article 113 modifié fixe au 2 décembre 2026 l’application des nouvelles interdictions ajoutées en 2026.

[5] AI Act, art. 50, notamment § 2. L’obligation de marquage s’applique dans les conditions et sous les réserves prévues par cet article. Les obligations de transparence sont applicables depuis le 2 août 2026 ; la Commission a également publié un Code de bonnes pratiques consacré au marquage et à l’étiquetage des contenus générés par IA.

[6] Anthropic, « How Claude’s text watermark works », 14 août 2026. Anthropic indique que ses futurs modèles Claude intégreront un filigrane textuel destiné à satisfaire à l’AI Act, invisible au lecteur et sans caractères cachés ; le procédé est une variante de SynthID-Text. Anthropic souligne que sa détection mesure seulement la probabilité d’une intervention de Claude et présente des limites pour les passages courts, factuels ou simplement corrigés. Anthropic précise par ailleurs appliquer des content credentials C2PA à certains fichiers compatibles.

[7] AI Act, art. 50, § 6, et chapitre V.

[8] AI Act, art. 3, point 1).

[9] Commission européenne, Guidelines on the definition of an artificial intelligence system established by Regulation (EU) 2024/1689 (AI Act), publiées le 6 février 2025. La Commission précise qu’elles sont non contraignantes et destinées à faciliter l’application pratique de la définition.

[10] AI Act, art. 3, point 12), relatif à la « destination ».

[11] Commission européenne, projet de lignes directrices préc., partie consacrée aux principes généraux et à la destination du système.

[12] AI Act, art. 6, § 1. Les deux conditions sont cumulatives : lien avec un produit ou composant de sécurité couvert par l’annexe I et exigence d’une évaluation de conformité par un tiers. Le projet de lignes directrices reprend expressément cette structure.

[13] AI Act, art. 6, tel que modifié par le règlement (UE) 2026/1744, et Commission européenne, projet de lignes directrices préc., section consacrée à l’annexe I. L’Omnibus a précisé la prise en compte des fonctions étrangères à la sécurité et des conséquences d’une défaillance.

[14] AI Act, art. 2, § 2, dans sa rédaction issue du règlement (UE) 2026/1744, pour les systèmes liés aux produits relevant de la section B de l’annexe I. Le régime organise une articulation particulière avec les législations sectorielles concernées.

[15] AI Act, art. 6, § 2, et annexe III. Le projet de lignes directrices de la Commission confirme que cette seconde voie repose sur les cas d’usage énumérés à l’annexe III.

[16] AI Act, annexe III, point 5, c), concernant les systèmes destinés à l’évaluation des risques et à la tarification concernant des personnes physiques en matière d’assurance-vie et d’assurance maladie.

[17] Commission européenne, projet de lignes directrices préc., partie consacrée aux cas d’usage de l’annexe III dans le domaine de l’assurance.

[18] Commission européenne, projet de lignes directrices préc., partie consacrée à l’application du filtre de l’article 6, § 3, dans les architectures complexes.

[19] AI Act, art. 6, § 3, a) à d).

[20] AI Act, art. 6, § 3.

[21] AI Act, notamment art. 14, et Commission européenne, projet de lignes directrices préc. La supervision humaine constitue une exigence applicable au système à haut risque ; sa présence ne crée pas, en elle-même, une exclusion autonome de la qualification.

[22] AI Act, art. 6, § 4, et art. 49, § 2. Leur application doit être lue à la lumière du calendrier modifié par le règlement (UE) 2026/1744.

[23] AI Act, art. 2 et art. 3, points 3) et suivants.

[24] AI Act, art. 25, § 1.

[25] AI Act, art. 25, § 4, dans sa rédaction issue du règlement (UE) 2026/1744. L’exception prévue pour certains outils, services, processus ou composants rendus accessibles sous licence libre et ouverte ne s’étend pas aux modèles d’IA à usage général.

[26] AI Act, art. 8 à 15, notamment gestion des risques, gouvernance des données, documentation technique, journalisation, transparence envers le déployeur, supervision humaine, exactitude, robustesse et cybersécurité.

[27] AI Act, notamment art. 16, 17, 26, 27, 43, 47 à 49, 72 et 73. L’analyse d’impact sur les droits fondamentaux prévue à l’article 27 ne concerne pas indistinctement tous les déployeurs de tous les systèmes à haut risque.

[28] AI Act, art. 2, § 1. L’AI Act vise notamment les fournisseurs situés dans ou hors de l’Union mettant un système sur le marché dans l’Union, les déployeurs établis dans l’Union et certains opérateurs de pays tiers lorsque les sorties sont utilisées dans l’Union.

[29] AI Act, art. 2, notamment §§ 3, 6, 8 et 10.

[30] Règlement (UE) 2026/1744 du Parlement européen et du Conseil du 8 juillet 2026 modifiant notamment le règlement (UE) 2024/1689 en ce qui concerne la simplification de sa mise en œuvre, JOUE L, 2026/1744, 24 juillet 2026, entré en vigueur le 27 juillet 2026.

[31] AI Act, art. 113, dans sa rédaction issue du règlement (UE) 2026/1744. Les obligations de transparence de l’article 50 sont applicables depuis le 2 août 2026, sous réserve notamment du régime transitoire prévu pour certains systèmes déjà mis sur le marché.

[32] AI Act, art. 113, troisième alinéa, c), tel que modifié : 2 décembre 2027 pour les systèmes de l’article 6, § 2, et de l’annexe III ; 2 août 2028 pour ceux de l’article 6, § 1, et de l’annexe I.

[33] AI Act, art. 111, § 2, dans sa rédaction issue de l’Omnibus. Le texte prévoit notamment une échéance au 2 août 2030 pour les systèmes à haut risque destinés à être utilisés par des autorités publiques.

[34] AI Act, art. 99, dans sa rédaction applicable après le règlement (UE) 2026/1744. Les plafonds sont fonction de la nature du manquement et non d’un « niveau de risque » abstrait du système. Le régime prévoit des adaptations pour les PME et, pour certaines amendes, les petites entreprises à moyenne capitalisation.