Contrôle humain des systèmes d'IA : encore faut-il pouvoir le prouver. Par Mohand Ouidja, Avocat.
Le contrôle humain est souvent résumé par une formule simple : la machine propose, l'humain décide. En cas de contestation, cette formule ne suffira pas.
Le règlement (UE) 2026/1744 a repoussé l'application de certaines parties du AI Act (règlement européen sur l'intelligence artificielle) pour les systèmes à haut risque. Les sections 1 à 3 du chapitre III, initialement prévues pour 2026, s'appliqueront désormais le 2 décembre 2027 pour les systèmes relevant de l'article 6, paragraphe 2, et de l'Annexe III, puis le 2 août 2028 pour ceux de l'article 6, paragraphe 1, et de l'Annexe I. Cette modification ne résout pas le problème central : comment prouver qu'un contrôle humain effectif a été exercé lors d'une décision assistée par IA, notamment en cas de contestation ? La question est déjà présente dans le RGPD (règlement général sur la protection des données) pour les décisions automatisées, mais elle devient cruciale avec les exigences renforcées du AI Act pour les systèmes à haut risque.
L'article 14 du AI Act ne se contente pas d'exiger la présence théorique d'un humain dans le processus décisionnel. Il impose que les systèmes à haut risque soient conçus pour permettre une supervision effective par des personnes physiques. Cette supervision implique plusieurs obligations : comprendre les capacités et limites du système, surveiller son fonctionnement, interpréter ses résultats, éviter une dépendance excessive (automation bias), et pouvoir ignorer, remplacer ou inverser une sortie. L'opérateur doit également disposer de la compétence, de la formation, de l'autorité et du soutien nécessaires, comme le précise l'article 26, paragraphe 2. Ces exigences ne sont pas encore applicables au 3 septembre 2026, mais elles montrent que le contrôle humain attendu va bien au-delà d'un simple clic de validation. Une validation symbolique, sans réelle marge de manœuvre, ne suffit pas.
Imaginons un système d'IA évaluant la solvabilité d'un client, produisant une recommandation défavorable, puis validée par un collaborateur. Un an plus tard, le client conteste cette décision. L'établissement répond qu'une validation humaine était systématiquement prévue. Cette réponse peut être exacte sans suffire à prouver un contrôle réel. Il faudra alors vérifier quelle version du système a produit le résultat, quelles informations étaient présentées au collaborateur, qui a examiné le dossier, s'il pouvait s'écarter de la recommandation et quelle action il a finalement menée. L'arrêt SCHUFA Holding du 7 décembre 2023 illustre cette difficulté : la Cour de justice a jugé qu'un établissement automatisé de probabilité de solvabilité peut relever du RGPD si un tiers s'appuie de manière déterminante sur cette valeur pour prendre sa décision. Ainsi, une décision formellement humaine peut rester fortement influencée par l'IA.
Une organisation peut avoir mis en place une procédure de contrôle robuste : responsables identifiés, formations, règles d'escalade, droit de surcharge (override), documentation des limites du système. Ces éléments prouvent comment le contrôle devait fonctionner, mais pas nécessairement comment il a fonctionné dans un cas précis. Il existe une distinction essentielle entre preuve de conception et preuve d'exécution. La première décrit le dispositif prévu, tandis que la seconde permet de reconstruire ce qui s'est réellement passé pour une décision donnée. Les traces utiles peuvent inclure l'identité de l'opérateur, la date de la revue, la version du système, le résultat présenté, les éléments consultés, l'action réalisée ou l'existence d'un écart par rapport à la recommandation. L'objectif n'est pas de conserver toutes les actions des salariés, mais de déterminer à l'avance quelles traces sont nécessaires pour reconstruire une décision importante en cas de contestation.
L'article 12 du AI Act impose, pour les systèmes à haut risque, des capacités d'enregistrement automatique d'événements (logs) pendant toute la durée de vie du système. Ces journaux participent à la traçabilité, mais leur portée probatoire est limitée. Par exemple, une ligne indiquant « utilisateur_184 – validation – 14:32:06 » prouve qu'un événement qualifié de validation a été enregistré, mais pas que l'utilisateur a compris les limites du système, consulté les informations pertinentes, disposé du temps nécessaire ou exercé librement son pouvoir de refus. Le log fournit un fait technique qui doit être complété par d'autres éléments : conception de l'interface, procédure applicable, habilitation de l'opérateur, formation reçue, informations disponibles au moment de la décision ou justification d'un override. L'arrêt Dun & Bradstreet Austria du 27 février 2025 rappelle que les informations fournies sur une décision automatisée doivent permettre à la personne concernée de comprendre la procédure et les principes appliqués pour exercer ses droits.
Le contrôle humain peut perdre sa substance sans volonté de contournement. Un système fonctionne correctement, ses recommandations sont presque toujours confirmées, la confiance s'installe et le temps consacré à chaque dossier diminue. Le collaborateur reste dans la boucle, mais celle-ci peut devenir formelle. L'article 14, paragraphe 4, du AI Act vise précisément le risque de dépendance excessive aux résultats d'un système. Ce problème est particulièrement visible lorsque l'opérateur traite des volumes importants, dispose de quelques secondes par dossier ou doit franchir plusieurs niveaux hiérarchiques pour contredire la recommandation automatique. Des indicateurs peuvent alerter : temps moyen de revue, taux d'acceptation, fréquence des overrides, concentration des validations ou impossibilité technique d'écarter certains résultats. Aucun de ces indicateurs ne permet à lui seul de conclure à une défaillance, mais leur évolution peut signaler qu'un examen humain plus approfondi est nécessaire.
L'article 11 et l'Annexe IV du AI Act imposeront, pour les systèmes concernés, une documentation technique détaillée. Celle-ci doit porter sur la conception, les performances, les limites, le contrôle humain ainsi que certains éléments de validation et de test. Cette documentation est indispensable, mais elle ne raconte pas automatiquement l'histoire de chaque décision individuelle. Elle peut démontrer qu'un opérateur est censé pouvoir écarter une recommandation, tandis qu'une procédure précise quand il doit le faire. Des traces d'exécution peuvent ensuite établir qu'une personne déterminée a examiné un résultat et choisi une action à un moment donné. Ces trois niveaux – documentation technique, procédure et traces d'exécution – ne sont pas interchangeables. La technologie peut automatiser une partie de cette chaîne (versioning, horodatage, journalisation, contrôle de complétude), mais elle ne peut pas conclure seule qu'un contrôle humain était juridiquement suffisant. Cette appréciation dépend du contexte, des risques, de l'autorité réelle de l'opérateur et des informations dont il disposait.
Le délai supplémentaire créé par le règlement (UE) 2026/1744 peut être utilisé pour rédiger des politiques de contrôle humain. Il devrait surtout permettre de tester leur réalité opérationnelle. Une question simple suffit pour évaluer leur efficacité : si une décision est contestée dans deux ans, pourrons-nous retrouver le système utilisé, le résultat présenté, la personne qui l'a examiné et l'action qu'elle a réellement accomplie ? Le contrôle humain ne se prouvera pas par l'existence d'un bouton « Valider ». Il faudra pouvoir reconstruire une intervention suffisamment concrète pour être appréciée, puis qualifiée, par des humains. Les organisations doivent donc anticiper les besoins en traçabilité et en documentation pour répondre aux exigences du *AI Act* et du *RGPD* en cas de litige.
