Contrôle humain

Le contrôle humain, souvent appelé supervision humaine, est la capacité de personnes désignées et compétentes à surveiller un système d'IA pendant son utilisation, à interpréter ses sorties, à les ignorer ou à les inverser, et à arrêter le système. Dans l'EU AI Act, l'article 14 en fait une exigence de conception pour les systèmes d'IA à haut risque, et l'article 26, paragraphe 2, impose aux déployeurs de confier ce contrôle « à des personnes physiques qui disposent des compétences, de la formation et de l'autorité nécessaires ainsi que du soutien nécessaire ».

L'article 14, paragraphe 1, exige que les systèmes d'IA à haut risque soient conçus pour permettre un contrôle effectif par des personnes physiques pendant leur période d'utilisation. Le paragraphe 4 énumère ce que ces personnes doivent pouvoir faire, dans la mesure où cela est approprié et proportionné : comprendre les capacités et les limites du système et surveiller son fonctionnement ; avoir conscience du biais d'automatisation, c'est-à-dire la tendance à se fier automatiquement ou excessivement aux sorties du système ; interpréter correctement ces sorties ; décider de ne pas utiliser le système, ou d'ignorer, remplacer ou inverser sa sortie ; intervenir dans son fonctionnement ou l'interrompre au moyen d'un bouton d'arrêt ou d'une procédure similaire. Le paragraphe 3 exige des mesures de contrôle proportionnées aux risques, au niveau d'autonomie et au contexte d'utilisation. Pour l'identification biométrique à distance, le paragraphe 5 exige qu'au moins deux personnes compétentes vérifient et confirment une identification avant que le déployeur agisse sur cette base.

Les notions de human-in-the-loop, human-on-the-loop et human-in-command viennent des lignes directrices en matière d'éthique pour une IA digne de confiance, publiées en 2019 par le groupe d'experts de haut niveau sur l'IA. Le règlement ne les emploie pas. Elles restent utiles pour décrire trois dispositifs : une approbation avant que chaque décision prenne effet, une surveillance en continu avec possibilité d'intervenir, et une autorité sur les politiques, l'échantillonnage et les exceptions.

Pour les agents d'IA, le contrôle s'exerce le mieux au niveau de l'action. L'agent propose une étape ; une politique décide si elle peut se poursuivre, si elle requiert une approbation ou si elle est bloquée ; un réviseur nommé approuve ou rejette l'étape retenue, avec sous les yeux les éléments utilisés par la politique. Enregistrez qui a examiné, ce qu'il a vu, ce qu'il a décidé, quand et pourquoi : cet enregistrement montre que le contrôle a bien eu lieu. Adaptez l'intensité au risque : les étapes à faible impact peuvent s'exécuter sous surveillance, et celles qui déplacent des fonds ou touchent aux droits d'une personne attendent une décision.

Le contrôle échoue aussi lorsqu'un réviseur ne sait pas pourquoi il est bloqué. Lors d'une évaluation interne dans notre propre environnement de développement, un réviseur qui avait effectué tous les contrôles requis a trouvé les boutons d'approbation et de rejet désactivés derrière une simple mention « View only ». Le blocage était justifié, car le réviseur n'appartenait pas au groupe d'approbateurs requis, mais rien ne l'indiquait. Le Decision Desk indique désormais pourquoi un réviseur ne peut pas agir, y compris lorsqu'il est l'auteur de la demande.

En application du règlement (UE) 2026/1744, les exigences applicables aux systèmes à haut risque, articles 14 et 26 compris, s'appliquent à partir du 2 décembre 2027 aux systèmes visés à l'annexe III et à partir du 2 août 2028 aux systèmes relevant de l'annexe I. Dans KLA, un résultat require_approval retient l'action de l'agent sous forme de Decision Request dans le Decision Desk, et la décision est enregistrée avec le nom du réviseur et l'heure.