EU AI Act, article 14 : supervision humaine des agents IA

L’article 14 en une page¶

L’article 14 figure au chapitre III, section 2 du règlement (UE) 2024/1689. Son champ d’application couvre les systèmes d’IA à haut risque. Le système doit être conçu et développé avec des outils d’interface homme-machine appropriés afin que des personnes physiques puissent le superviser efficacement pendant son utilisation.

L’objectif est de prévenir ou de réduire au minimum les risques résiduels pour la santé, la sécurité ou les droits fondamentaux lorsque le système fonctionne conformément à sa destination ou dans des conditions de mauvaise utilisation raisonnablement prévisible. Les mesures doivent être proportionnées aux risques, au niveau d’autonomie et au contexte d’utilisation du système. Le fournisseur peut intégrer les mesures dans le système, définir des mesures que le déployeur mettra en œuvre, ou combiner les deux approches.

Le paragraphe 4 définit le test pratique de capacité. La personne désignée doit disposer d’une visibilité et d’une autorité suffisantes pour comprendre, surveiller, interpréter, ignorer, passer outre, annuler, intervenir et interrompre. Un responsable désigné et un document de politique relèvent de la gouvernance de soutien. Les contrôles déployés doivent, eux, rendre ces actions réellement possibles.

La conception du fournisseur et l’exploitation par le déployeur forment un seul contrôle¶

L’article 14 répartit la mise en œuvre entre le fournisseur et le déployeur. Le fournisseur identifie les mesures, intègre les contrôles techniquement réalisables et les décrit dans la notice d’utilisation. L’article 13(3)(d) exige que cette notice couvre les mesures de supervision humaine et les mesures techniques qui aident les déployeurs à interpréter les sorties.

L’article 26(2) rend le déployeur responsable de confier la supervision à des personnes physiques disposant des compétences, de la formation, de l’autorité et du soutien nécessaires. Le déployeur configure également les contrôles en fonction de ses propres personnels, données, politiques, flux de travail et environnement d’exploitation.

Choisir l’intensité de la supervision selon le risque de l’action¶

L’article 14 nomme trois variables de proportionnalité : le risque, l’autonomie et le contexte d’utilisation. Il laisse aux organisations le soin de les traduire en seuils de contrôle. Human-in-the-loop, human-on-the-loop et human-in-command sont des étiquettes opérationnelles utiles pour cette conception. Il ne s’agit pas de termes définis par l’article 14.

Classez chaque action individuelle en plus du système d’IA dans son ensemble. Un même agent peut rédiger un résumé, interroger un enregistrement, mettre à jour un statut et déclencher un paiement au cours d’une même exécution. Chaque action présente un profil de conséquence et de réversibilité différent.

Construire les points de contrôle d’approbation autour de l’effet de bord¶

L’article 14(4)(d) donne au superviseur, dans une situation donnée, l’autorité de refuser l’utilisation, d’ignorer une sortie, d’y passer outre ou de l’annuler. Pour une action d’outil irréversible, un point de contrôle préalable à l’exécution constitue généralement la mise en œuvre la plus robuste. Le système construit l’action proposée, évalue les règles applicables et retient l’effet de bord jusqu’à la décision de la personne autorisée.

Le réviseur a besoin du contexte de décision en un seul endroit. Affichez l’action, la cible, les paramètres significatifs, l’agent et l’identité à l’origine de la demande, la règle applicable et son motif, les preuves sources, les incertitudes et limites connues, la conséquence, le chemin d’annulation et l’échéance de décision. Un simple bouton d’approbation placé à côté d’une phrase générée donne au réviseur trop peu d’informations pour exercer une supervision réelle.

Traitez l’expiration du délai, l’indisponibilité du réviseur, l’obsolescence des preuves et l’échec de l’évaluation de la politique comme des états explicites. Chaque état nécessite un résultat sûr défini. Une demande en attente ne doit jamais devenir une approbation implicite parce qu’une file d’attente, un webhook ou un réviseur est indisponible.

• Avant le point de contrôle : lier un identifiant de demande stable à l’action proposée exacte et à son jeu de paramètres.
• Au point de contrôle : vérifier l’éligibilité du réviseur et les règles de séparation des tâches au moment de la décision.
• Pendant la revue : présenter les preuves actuelles, les limites, le motif de la politique, la conséquence et les alternatives disponibles.
• À la décision : enregistrer l’approbation, le rejet, la demande de modifications ou l’escalade avec identité, autorité, justification et horodatage.
• Avant la reprise de l’exécution : confirmer que l’action, la politique, les preuves et l’instantané d’autorité restent à jour.
• Après l’exécution : rattacher le résultat réel en aval, ou l’échec, au même enregistrement.

Concevoir la dérogation, l’annulation et l’arrêt sûr comme des contrôles distincts¶

Les articles 14(4)(d) et 14(4)(e) décrivent des capacités liées mais aux effets différents. Une dérogation modifie l’utilisation d’une sortie donnée. Une annulation rétablit la situation antérieure ou compense une action déjà exécutée. Une intervention modifie une opération en cours. Une interruption arrête le système au moyen d’un bouton d’arrêt ou d’une procédure similaire et l’amène dans un état sûr.

Un contrôle d’arrêt mérite ce nom lorsque la demande atteint chaque worker, appel d’outil, agent délégué, tâche en file d’attente et chemin de nouvelle tentative concernés. Le système doit définir quelles opérations en cours peuvent se terminer, lesquelles sont annulées, quels identifiants ou baux sont révoqués et quelles données restent fiables. Il a également besoin d’un chemin de reprise contrôlé.

Testez la propagation et l’état final dans des conditions de défaillance réalistes. Incluez une API externe lente, la perte du signal de vie d’un worker, une nouvelle tentative en file d’attente, une action multi-étapes partiellement achevée et un service de preuves indisponible. Enregistrez le délai entre l’action de l’opérateur et le confinement, ainsi que chaque opération restée en cours.

Donner aux superviseurs compétence, formation, autorité et soutien¶

L’article 26(2) fixe la norme de personnel côté déployeur. Les personnes physiques désignées doivent disposer des compétences, de la formation, de l’autorité et du soutien nécessaires pour exercer la supervision. Le considérant 73 relie également l’efficacité de la supervision à la compétence, à la formation et à l’autorité.

La compétence couvre la décision métier et le système d’IA. Un analyste crédit peut maîtriser la politique de prêt tout en manquant de la connaissance du système nécessaire pour reconnaître une dérive de distribution, des données sources manquantes ou une demande hors périmètre. Un opérateur de plateforme peut comprendre le système tout en n’ayant pas l’autorité de décider du résultat pour le client. La conception du rôle doit combler ces deux lacunes.

L’article 26(2) pose une norme de résultat sans imposer d’intervalle de formation. Définissez une cadence à partir du risque de l’action, du rythme d’évolution du système, du volume d’exploitation, de l’historique des incidents et de la performance des réviseurs. Déclenchez une nouvelle formation après toute modification significative du modèle, de la politique, des données, de l’interface ou de la destination prévue.

• Compétence : règles métier, droits affectés, capacités et limites du système, qualité des entrées et modes de défaillance connus.
• Formation : biais d’automatisation, outils d’interprétation, critères d’escalade, exercices d’arrêt et de reprise, et gestion des preuves.
• Autorité : capacité de refuser, de passer outre, d’annuler, d’interrompre, d’escalader et de différer une action sans subir de pression opérationnelle pour approuver.
• Soutien : temps suffisant, effectifs, escalade vers des spécialistes, interfaces utilisables, instructions à jour et assistance en cas d’incident.
• Assurance continue : charge de la file d’attente, qualité des décisions, taux de dérogation, désaccords, demandes obsolètes, performance aux exercices et renouvellement de la formation.

Concevoir pour contrer le biais d’automatisation¶

L’article 14(4)(b) vise expressément la tendance à se fier, voire à se fier excessivement, aux sorties de l’IA, en particulier lorsque le système fournit des informations ou des recommandations pour une décision humaine. Un réviseur qui approuve chaque recommandation ajoute de la latence et une apparence trompeuse de contrôle.

L’interface et la procédure opérationnelle doivent rendre possible un jugement indépendant. Présentez les preuves sources et les limites significatives avant la justification de la recommandation. Distinguez les faits observés des inférences du modèle. Évitez les valeurs par défaut qui présélectionnent l’approbation. Pratiquez la rotation ou l’échantillonnage de cas qui exposent les réviseurs à des erreurs. Mesurez l’accord et les dérogations par type d’action, réviseur, politique et version du système, puis examinez tant les conformités inhabituelles que les désaccords inhabituels.

• Exiger un motif lié aux preuves pour les approbations et dérogations à fort enjeu.
• Masquer la recommandation du modèle lors d’une première revue indépendante lorsque le risque le justifie.
• Insérer des cas de test connus et des contrefactuels contrôlés dans les exercices d’assurance des réviseurs.
• Alerter sur les décisions rapides, les justifications identiques répétées, la charge élevée des réviseurs et un accord quasi parfait prolongé.
• Donner aux réviseurs un moyen clair de contester les données sources, de demander l’avis d’un spécialiste ou de suspendre le flux de travail.

Constituer des preuves qui démontrent que le contrôle a fonctionné¶

L’annexe IV place les mesures de supervision humaine, y compris les mesures techniques d’interprétation, dans la documentation technique du fournisseur. L’article 13 reprend ces mesures dans la notice d’utilisation. L’article 12 impose aux systèmes à haut risque de permettre l’enregistrement automatique des événements tout au long de leur cycle de vie, tandis que l’article 19 et l’article 26 attribuent les obligations de conservation des journaux placés sous le contrôle du fournisseur et du déployeur.

Un dossier de preuves pratique au titre de l’article 14 puise donc dans plusieurs obligations connexes. Il doit montrer la conception, les personnes désignées, les décisions et interventions en conditions réelles, l’état résultant et les tests des contrôles. L’intégrité cryptographique peut montrer si un enregistrement exporté a été modifié. Elle ne peut pas établir que chaque événement pertinent a été capturé ni que le contrôle choisi était juridiquement suffisant.

Comment KLA met en œuvre le parcours de contrôle gouverné¶

Le KLA Control Plane gouverne les actions d’agents instrumentées aux points de décision. Le KLA Policy Engine évalue un appel d’outil proposé au regard des règles publiées et renvoie allow, warn, require_approval ou block. Un résultat require_approval retient l’appel proposé et crée une Decision Request pour Decision Desk. Un block empêche l’appel gouverné d’atteindre l’outil.

Pour les Decision Requests du plan de contrôle, Decision Desk vérifie la permission de décider, le rôle de réviseur requis, l’état en attente, l’identité du demandeur et de l’initiateur, ainsi que l’échéance. Il empêche les demandeurs et initiateurs enregistrés de décider de leur propre demande et rejette les actions d’approbation ou de rejet après l’échéance. Un vérificateur éligible peut escalader une demande en retard. Il enregistre l’acteur de la décision, l’instantané du rôle, la décision, le motif et l’heure. Ces contrôles de séparation et d’expiration reposent sur le fait que la demande porte les identités d’initiateur à jour et une échéance. Assurez-vous que chaque chemin producteur les fournit et testez l’intégralité du parcours de contrôle. Lineage Explorer et Audit Trail exposent les enregistrements de politique et de décision humaine rattachés à l’exécution gouvernée. Evidence Room peut assembler les enregistrements sélectionnés dans un Sealed Evidence Bundle dont les signatures de service et de tenant, les hachages d’artefacts et la racine de Merkle du bundle peuvent être vérifiés hors ligne.

Ces capacités mettent en œuvre des parties d’un modèle opérationnel de l’article 14. L’organisation reste responsable de la classification juridique, de la proportionnalité, de la répartition fournisseur-déployeur, de la compétence des réviseurs, des effectifs, des procédures opérationnelles et de l’ingénierie de l’état sûr propre à chaque système. Un blocage avant action à un point de contrôle n’arrête pas chaque worker et n’annule pas chaque effet de bord externe. Instrumentez chaque chemin d’action à fort enjeu et testez l’interruption sur l’ensemble du système déployé.

Une séquence de mise en œuvre de l’article 14 en 10 étapes¶

Commencez par une seule action d’agent à fort enjeu et prouvez le parcours complet. Étendez ensuite, une fois que le contrôle fonctionne en conditions nominales, de défaillance et de reprise.

• 1. Confirmer le périmètre. Consigner la classification du système, votre rôle de fournisseur ou de déployeur, la destination prévue, le contexte et la date applicable.
• 2. Inventorier les actions. Lister chaque lecture, recommandation, écriture, communication externe, action financière, changement de permission, délégation et action de reprise.
• 3. Coter le risque des actions. Utiliser la conséquence, la réversibilité, les droits affectés, le volume, la détectabilité, l’autonomie et la mauvaise utilisation prévisible.
• 4. Attribuer la supervision. Choisir la revue avant exécution, la surveillance active avec intervention, ou l’exploitation bornée avec échantillonnage et escalade.
• 5. Concevoir la vue du réviseur. Présenter l’action proposée, les preuves, la politique, l’incertitude, les limites, la conséquence, les alternatives et l’échéance.
• 6. Mettre en œuvre l’autorité. Faire respecter l’éligibilité du réviseur, la séparation des tâches, l’escalade, le comportement en cas d’expiration et l’invalidation des demandes obsolètes.
• 7. Concevoir l’intervention. Construire les chemins permettant d’ignorer une sortie, de passer outre, d’annuler, d’interrompre, d’atteindre l’état sûr et de redémarrer de façon contrôlée.
• 8. Préparer les personnes. Évaluer les compétences, former au système et au biais d’automatisation, accorder l’autorité et fournir un soutien opérationnel.
• 9. Capturer l’enregistrement. Corréler la demande, le résultat du contrôle, l’action humaine, le résultat en aval et les preuves d’intégrité.
• 10. Tester l’efficacité. Mener des exercices de contournement, de panne, de surcharge, d’action partielle, de perte de worker, de preuves obsolètes, de propagation d’arrêt et de reprise ; suivre la remédiation.