AI Act : obligations du déployeur d’une IA à haut risque (article 26)

L’article 26 du règlement (UE) 2024/1689 fixe ce que doit faire l’organisation qui utilise un système d’IA (intelligence artificielle) à haut risque sous sa propre autorité, sans l’avoir conçu. Le fournisseur porte la conformité du produit ; le déployeur porte celle de l’usage, et c’est lui qui se retrouve face aux personnes concernées, aux représentants du personnel et à l’autorité de surveillance du marché. Cette page détaille les douze paragraphes, la preuve à garder pour chacun et la façon de les tenir en exploitation.

→ Lire l’explication complète de la marmotte

Périmètre de l’article 26 : qui est déployeur d’un système à haut risque

Trois conditions doivent être réunies avant que l’article 26 s’applique. L’organisation utilise le système sous sa propre autorité (et pas à titre personnel non professionnel). Le système est classé à haut risque, soit par l’annexe III (recrutement, crédit, éducation, accès aux services essentiels, etc.), soit comme composant de sécurité d’un produit couvert par l’annexe I : la page classification haut risque détaille ce tri. Enfin, l’organisation n’est pas devenue fournisseur par l’effet de l’article 25 : mettre son nom ou sa marque sur le système, le modifier substantiellement ou changer sa destination fait basculer dans l’autre colonne, avec un tout autre volume d’obligations. La page rôles fournisseur et déployeur traite cette qualification ; elle ne se refait pas ici.

Le schéma suivant se lit de haut en bas : chaque branche écarte ou ajoute un bloc d’obligations, et les trois blocs de droite se cumulent.

Calendrier : d’après la version consolidée intégrant l’omnibus numérique (règlement (UE) 2026/1744), l’article 26 n’est pas modifié, mais son application est reportée au 2 décembre 2027 pour les systèmes de l’annexe III et au 2 août 2028 pour ceux de l’annexe I. Le détail est sur la page calendrier. Le report ne change rien à l’interdiction des pratiques déjà applicables (pratiques interdites), ni au RGPD (règlement général sur la protection des données) qui, lui, s’applique depuis le 25 mai 2018 au même traitement.

Prérequis concrets avant de pouvoir respecter quoi que ce soit : un inventaire des systèmes d’IA utilisés (y compris ceux embarqués dans un logiciel métier qui n’affiche pas le mot « IA » sur sa plaquette, ce qui arrive moins souvent que l’inverse), la notice d’utilisation fournie au titre de l’article 13, un contrat qui donne accès aux journaux et à un canal de signalement vers le fournisseur, et un propriétaire nommé par système.

Les douze paragraphes de l’article 26 et la preuve à garder

L’article 26 est rédigé comme une liste d’obligations de moyens adossées à la notice du fournisseur. Le compromis central est là : le déployeur gagne de ne pas avoir à démontrer la conformité du modèle (documentation technique, gestion des risques, évaluation de conformité restent chez le fournisseur), mais il paie en forte dépendance à la qualité de la notice et en charge de preuve sur son propre usage. Une notice vague donne un périmètre d’usage conforme vague, et c’est le déployeur qui devra expliquer pourquoi son utilisation y entrait.

La position de cette page : traiter l’article 26 comme un processus d’exploitation (propriétaire, registre, boucle de surveillance, procédure d’arrêt), pas comme une clause contractuelle qu’on coche à l’achat. Le tableau ci-dessous associe à chaque paragraphe la preuve qu’il est recommandé de conserver ; la colonne « preuve » est une recommandation de la page, pas une exigence textuelle.

Paragraphe	Obligation	Preuve à garder (recommandation)
§1	Mesures techniques et organisationnelles appropriées pour utiliser le système conformément à la notice (conformément aux §3 et §6)	Notice versionnée, procédure d’usage qui la cite, écarts documentés
§2	Contrôle humain confié à des personnes physiques ayant compétence, formation, autorité et soutien nécessaires	Désignations nominatives, supports de formation, délégation d’autorité écrite
§3	Liberté d’organiser ses ressources pour mettre en œuvre les mesures de contrôle humain indiquées par le fournisseur	Organigramme du contrôle, correspondance avec les mesures de la notice
§4	Données d’entrée pertinentes et suffisamment représentatives, pour autant que le déployeur les contrôle	Description des sources d’entrée, contrôles de qualité, périmètre de contrôle
§5	Surveillance sur la base de la notice ; information du fournisseur ; suspension et signalement en cas de risque ou d’incident grave	Indicateurs suivis, registre des signalements, procédure de suspension
§6	Conservation des journaux sous son contrôle, au moins six mois, durée adaptée à la destination	Politique de conservation, preuve d’accès effectif aux journaux
§7	Employeur : informer représentants des travailleurs et travailleurs concernés avant la mise en service	Procès-verbal ou courrier daté antérieur à la mise en service
§8	Autorités publiques et institutions de l’Union : enregistrement (art. 49), pas d’usage d’un système non enregistré (art. 71)	Référence d’enregistrement, vérification dans la base de l’Union
§9	Utiliser les informations de l’article 13 pour l’AIPD, le cas échéant	AIPD qui cite la notice
§10	Identification biométrique à distance a posteriori à des fins répressives : autorisation, arrêt, rapports	Autorisations, preuves de suppression, rapports annuels
§11	Annexe III et décisions concernant des personnes physiques : informer ces personnes	Texte d’information et canal de diffusion daté
§12	Coopération avec les autorités compétentes	Point de contact désigné, dossier de conformité consultable

Sanction en cas de manquement : l’article 99 §4 e) prévoit jusqu’à 15 000 000 EUR ou 3 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu ; pour les PME, jeunes pousses comprises, l’article 99 §6 retient au contraire le plus faible des deux. Ce que risque une organisation donnée relève du texte officiel sur EUR-Lex et d’un conseil juridique, pas de cette page.

Contrôle humain et données d’entrée : §2 à §4

Le §2 ne se contente pas d’exiger « un humain dans la boucle ». Il exige une personne physique qui a la compétence, la formation, l’autorité et le soutien nécessaires. L’autorité est un critère qui casse souvent : un opérateur qui ne peut pas écarter la recommandation du système sans validation hiérarchique, ou qui est mesuré sur un débit de traitement incompatible avec un examen réel, n’exerce pas de contrôle humain, il valide. Le biais d’automatisation (tendance à suivre la machine par défaut) est une propriété connue des humains, pas un défaut de caractère : il se combat par l’organisation, pas par une charte. La page contrôle humain détaille les mesures côté fournisseur (article 14) que le déployeur doit ensuite rendre opérantes.

Le §3 laisse au déployeur la liberté d’organiser ses ressources. Traduction pratique : la notice dit quoi contrôler, le déployeur décide qui, quand et avec quels moyens. La formation exigée au §2 recoupe l’article 4, que l’omnibus a réécrit en obligation de prendre des mesures pour favoriser la maîtrise de l’IA ; la page maîtrise de l’IA décrit ce qu’il en reste. Le §2, lui, n’a pas été adouci : pour les personnes qui exercent le contrôle d’un système à haut risque, la formation reste une condition explicite.

Le §4 porte sur les données d’entrée, avec une restriction qui compte : « pour autant que le déployeur exerce un contrôle » sur elles. Un champ que le déployeur remplit (critères de poste, pondérations, référentiel interne) est sous son contrôle ; un flux que le fournisseur collecte lui-même ne l’est pas. Recommandation de la page : cartographier explicitement chaque entrée avec son propriétaire, parce que la frontière du §4 se discute le jour d’un contrôle et qu’il vaut mieux l’avoir tracée avant. Le volet qualité côté fournisseur relève de l’article 10, traité dans gouvernance des données.

Surveillance, suspension et incident grave : la boucle du §5

Le §5 est le paragraphe le plus opérationnel, et le plus souvent sous-estimé. Il contient trois mécanismes distincts : la surveillance continue sur la base de la notice (avec information du fournisseur, le cas échéant, pour alimenter sa surveillance après commercialisation de l’article 72) ; la réaction à un risque au sens de l’article 79 §1 ; la réaction à un incident grave.

Le schéma montre l’ordre des notifications, qui diffère entre les deux branches : en cas de risque, fournisseur ou distributeur et autorité sont informés sans retard injustifié et l’usage est suspendu ; en cas d’incident grave, le fournisseur est informé immédiatement et en premier.

Deux précisions du texte. Les données opérationnelles sensibles des autorités répressives sont exclues de cette obligation d’information. Les établissements financiers soumis à des règles de gouvernance interne au titre de la législation sur les services financiers satisfont l’obligation de surveillance en respectant ces règles. Le même aménagement vaut pour la tenue des journaux (§6). Les considérants visent en particulier les établissements de crédit régis par la directive 2013/36/UE ; la résilience opérationnelle numérique de ces mêmes établissements relève par ailleurs de DORA.

Le piège de production : l’obligation de suspendre suppose qu’on puisse suspendre. Un processus métier entièrement recâblé autour du système, sans mode dégradé manuel, transforme une suspension réglementaire en arrêt d’activité. La conséquence est prévisible et se vérifie partout : quand arrêter coûte trop cher, on n’arrête pas. Recommandation de la page : un mode de repli documenté et testé avant la mise en service. Pour les délais et circuits de signalement croisés (RGPD, NIS 2, DORA), voir notification d’incident.

Information des travailleurs et des personnes concernées : §7, §8, §9, §11

Le §7 impose à l’employeur d’informer les représentants des travailleurs et les travailleurs concernés avant la mise en service ou l’utilisation sur le lieu de travail. « Avant » n’est pas une formule : une information donnée après coup ne satisfait pas la lettre du texte. Cette obligation s’ajoute au droit national (consultation des instances représentatives, encadrement de la surveillance des salariés) sans le remplacer ; la page surveillance des salariés pose ce cadre.

Le §11 vise les déployeurs de systèmes de l’annexe III qui prennent des décisions concernant des personnes physiques ou aident à les prendre : ces personnes doivent être informées qu’elles sont soumises à l’utilisation du système. L’obligation est sans préjudice de l’article 50 (transparence de certains systèmes) et s’additionne à l’information exigée par le RGPD. Écrire une seule mention couvrant les deux régimes est la solution la plus économique, à condition qu’elle nomme réellement le système et sa fonction.

Le §8 ne concerne que les autorités publiques et les institutions, organes et organismes de l’Union : enregistrement au titre de l’article 49, et interdiction d’utiliser un système absent de la base de l’Union (article 71), avec information du fournisseur ou du distributeur.

Le §9 renvoie à l’AIPD (analyse d’impact relative à la protection des données) de l’article 35 du RGPD ou de l’article 27 de la directive 2016/680, « le cas échéant » : la notice de l’article 13 doit y être exploitée. La méthode est sur la page AIPD. Distincte de l’AIPD, l’analyse d’impact sur les droits fondamentaux de l’article 27 du règlement vise certains déployeurs seulement : organismes de droit public, entités privées fournissant des services publics, et déployeurs des systèmes de l’annexe III, point 5 b) et c) (évaluation de solvabilité, tarification de l’assurance vie et santé). Elle aura sa propre page.

Le §10 est un régime à part : l’identification biométrique à distance a posteriori à des fins répressives requiert une autorisation judiciaire ou administrative ex ante, ou au plus tard dans les 48 heures (sauf identification initiale d’un suspect potentiel), l’arrêt immédiat et la suppression des données en cas de rejet, et des rapports annuels. Hors du périmètre du lecteur type de cette page.

Surface d’attaque côté déployeur

L’article 26 ne parle pas de sécurité, mais chacune de ses obligations a une surface d’attaque, et un attaquant qui la connaît manipule la décision sans toucher au modèle.

Injection indirecte dans les données d’entrée : du texte caché dans un document soumis (police blanche, métadonnées) peut orienter un système à base de modèle de langage. Contre-mesure : normaliser les documents en texte brut avant traitement et exiger du fournisseur un comportement documenté face à ce cas ; la robustesse et cybersécurité attendue côté fournisseur ne dispense pas du filtrage d’entrée côté déployeur.
Contournement du contrôle humain : un opérateur sous pression de débit valide en masse. Contre-mesure : mesurer le taux de désaccord avec le système ; un taux durablement nul signale un contrôle fictif, pas un modèle parfait.
Dérive des entrées : les données réelles s’écartent de celles pour lesquelles le système a été validé (§4). Contre-mesure : suivre la distribution des entrées sous contrôle du déployeur et la comparer aux conditions de la notice.
Perte ou altération des journaux : en mode SaaS (Software as a Service), les journaux vivent chez l’éditeur, et une résiliation de contrat peut les emporter. Contre-mesure : export périodique et intégrité vérifiable ; détails dans journalisation.
Mise à jour silencieuse : une nouvelle version change le comportement sans que la notice suive. Contre-mesure : clause contractuelle de notification des versions, voir clauses sécurité du contrat fournisseur.

Ce que l’article 26 ne garantit pas

Respecter l’article 26 ne rend pas le système conforme : la conformité du produit (gestion des risques, documentation technique, évaluation de conformité) reste chez le fournisseur, voir gestion des risques et documentation technique. Il ne fournit pas non plus de base légale au traitement de données personnelles : celle-ci vient du RGPD, dont les conséquences d’architecture sont traitées dans ce que le RGPD impose à l’architecture. Il ne garantit pas l’absence de discrimination : le droit de la non-discrimination continue de s’appliquer à la décision finale, que l’humain l’ait prise seul ou en suivant le système. Et il ne sécurise pas l’infrastructure de l’éditeur : un déployeur parfaitement conforme à l’article 26 peut subir une fuite chez son prestataire, ce qui relève du contrat et des obligations de sécurité classiques.

Conditions d’exploitation : contrat, journaux, rotation, mode dégradé

Une conformité à l’article 26 se dégrade avec le temps si rien ne l’entretient. Les points d’exploitation à tenir, présentés comme recommandations de la page :

Notice et versions : conserver chaque version de la notice avec la version du système qu’elle couvre ; un changement de version sans nouvelle notice déclenche une revue d’usage.
Personnes de contrôle : la compétence exigée au §2 est attachée à des personnes qui partent, changent de poste ou s’absentent. Prévoir des suppléants formés et une revue périodique des désignations, au même titre qu’une revue d’habilitations.
Journaux : vérifier l’accès effectif (pas seulement contractuel) et la restauration d’un export ; la durée minimale de six mois fixée au §6 est un plancher, la durée réelle dépend de la destination et des autres textes applicables. Les établissements financiers les tiennent dans la documentation imposée par la législation financière.
Supervision : indicateurs de dérive, taux de désaccord humain, volume de signalements au fournisseur. Un tableau de bord sans destinataire nommé ne surveille rien.
Reprise : mode dégradé manuel testé, procédure de suspension avec décideur identifié, et critère de remise en service documenté.

La leçon est la même que pour les certificats : la procédure d’arrêt d’urgence existe toujours, quelque part, dans un document que personne n’a ouvert depuis la recette.

Exemple : présélection de candidatures achetée à un éditeur

Cas fictif : un établissement privé achète à un éditeur un outil SaaS de présélection de candidatures, qui trie les CV (curriculum vitae) et propose un classement aux recruteurs. Ce système relève de l’annexe III, point 4 a) (recrutement et sélection). L’établissement ne modifie pas le système, ne le commercialise pas sous son nom et ne change pas sa destination : il reste déployeur.

Le schéma suit la chronologie, de l’achat à l’exploitation. Les étapes avant la mise en service sont bloquantes : sans elles, l’utilisation démarre en dehors du texte.

Ce qui tombe sur l’établissement, et pas sur l’éditeur : l’information préalable des représentants des travailleurs et des recruteurs concernés (§7), car l’outil est utilisé sur le lieu de travail ; l’information des candidats (§11), car le système aide à prendre une décision les concernant ; la qualité des critères de poste qu’il saisit lui-même (§4) ; la capacité des recruteurs à contredire le classement (§2) ; la surveillance et la suspension (§5) ; la conservation des journaux qu’il contrôle (§6). Si l’établissement réentraînait l’outil sur ses propres données de recrutement au point d’en modifier substantiellement le comportement, la question de l’article 25 se poserait, et avec elle celle de son rôle.

Le point qui casse le plus souvent dans ce scénario : les critères de poste. Ils sont saisis par l’établissement, donc sous son contrôle au sens du §4, et un critère mal formulé (diplôme exigé sans lien avec le poste, par exemple) biaise le classement sans que l’éditeur y soit pour quoi que ce soit.

🐝 Ce qui arrive si on s’en passe

Sans procédure de suspension ni mode dégradé, un risque détecté ne peut pas être contenu : le système continue de produire des décisions pendant que l’organisation cherche qui a le droit de l’arrêter. Sans journaux exportés, une contestation de décision ne peut plus être reconstituée, et le fournisseur perd les retours dont sa propre surveillance dépend. Sans contrôle humain doté d’autorité, une manipulation des entrées passe directement en décision, puisque personne n’est en position de contredire le classement. Sans information préalable des travailleurs et des personnes concernées, l’usage démarre irrégulièrement et chaque décision rendue devient contestable à ce titre.

🦫 Explication de la marmotte 🍫

Une entreprise qui utilise un logiciel d’intelligence artificielle classé « à haut risque », par exemple pour trier des candidatures, doit suivre des règles fixées par une loi européenne, même si elle n’a pas fabriqué ce logiciel. Le fabricant fournit un mode d’emploi. L’entreprise doit s’en servir uniquement de la façon prévue par ce mode d’emploi. Elle choisit des personnes formées, qui ont vraiment le droit de dire non au logiciel quand son résultat leur paraît faux. Elle vérifie que les informations qu’elle donne au logiciel sont de bonne qualité. Avant de commencer, elle prévient les représentants des salariés et les salariés concernés, et elle prévient aussi les personnes au sujet desquelles le logiciel aide à décider. Pendant l’utilisation, elle surveille les résultats et garde les traces enregistrées automatiquement pendant au moins six mois. Si elle pense que le logiciel peut causer un danger, elle prévient le fabricant et l’autorité de contrôle, puis elle arrête de s’en servir. Si un accident grave arrive, elle prévient d’abord le fabricant, puis les autorités. Pour pouvoir arrêter sans bloquer tout son travail, elle doit avoir prévu une façon de travailler sans le logiciel. Si elle oublie ces règles, elle risque une amende pouvant atteindre quinze millions d’euros ou trois pour cent de son chiffre d’affaires mondial. Ces règles ne garantissent pas que le logiciel lui-même est bien conçu : cela reste le travail du fabricant.

Pages voisines

La citent

AI Act : obligations du déployeur d'une IA à haut risque (article 26)

Elle cite

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