Quand le contrôle humain ne fonctionne pas dans un système d’IA

Quand nous développons un système d’IA pour une organisation, l’une des premières demandes est la validation humaine. Cet article explique comment savoir si cette validation fonctionne réellement dans le système.

Quand on parle de gouvernance de l'intelligence artificielle, la phrase la plus fréquemment entendue est celle-ci. « Il y a une approbation humaine, la décision n'est pas laissée à la machine. »

Quand j'entends cette phrase, je ne pose qu'une seule question. Quel est votre taux d'approbation ?

Aucune réponse n'arrive, parce que ce n'est pas mesuré. Dans les quelques endroits où c'est mesuré, le résultat dépasse généralement quatre-vingt-dix-huit pour cent. C'est-à-dire que la personne chargée de la supervision s'oppose au modèle une fois sur cinquante décisions. Dire qu'il existe une supervision humaine dans ce tableau est formellement exact mais fonctionnellement faux. C'est en réalité le système qui décide, la personne ne fait que signer.

Pourquoi le bouton d'approbation ne fonctionne pas

La cause n'est pas la mauvaise foi, mais la conception.

Si l'on montre à un utilisateur trois cents recommandations par jour en lui demandant d'approuver chacune, cet utilisateur s'automatise rapidement. Si le taux de justesse du modèle est élevé, cela s'accélère encore, car même dans les quelques cas où il rejette, le modèle a généralement raison, et l'utilisateur cesse de faire confiance à son propre jugement.

Cela s'appelle dans la littérature la confiance excessive envers l'automatisation, et c'est un phénomène bien connu. Autrement dit, plus le système fonctionne bien, plus la supervision humaine s'affaiblit. C'est un fait dont il faut tenir compte dans la conception de la supervision.

Les trois conditions qui rendent la supervision significative

Pour que la supervision soit fonctionnelle, trois éléments doivent être réunis simultanément.

La personne chargée de la supervision doit pouvoir voir le fondement de la recommandation. Si l'on ne montre pas à partir de quelles données d'entrée le modèle est parvenu à ce résultat, la personne ne peut évaluer que le résultat, et pour l'évaluer elle devrait tout redécider elle-même depuis le début. Cela rend la supervision pratiquement impossible.

Le rejet doit être sans coût. Un utilisateur à qui le rejet impose de remplir un formulaire supplémentaire, de rédiger une justification et d'obtenir l'accord de sa hiérarchie choisit de ne pas rejeter. Le parcours de rejet doit être au moins aussi simple que celui de l'approbation.

Le rejet doit avoir une conséquence. Si les recommandations rejetées sont simplement notées quelque part sans que personne ne les regarde, la personne chargée de la supervision le remarque et finit par s'en désintéresser. Faire en sorte que les cas rejetés nourrissent l'amélioration du modèle maintient la supervision vivante.

Il n'existe pas de supervision que l'on ne mesure pas

Même une fois ces trois conditions réunies, la mesure reste nécessaire.

Au moins trois indicateurs doivent être suivis. Le taux de rejet, le temps moyen consacré par décision et le taux de justesse ultérieur des décisions rejetées. Si le temps par décision est tombé à l'ordre de la seconde, cela signifie qu'aucune supervision n'est exercée. Si le taux de rejet s'approche de zéro, la conclusion est la même.

Très peu d'organisations ont une réponse lorsque ces indicateurs sont demandés lors d'un audit. Pourtant, ce ne sont pas des mesures difficiles, elles se déduisent de données que le système produit déjà de lui-même.

Le droit de contestation détermine l'architecture

L'article 11 de la loi n° 6698 reconnaît à la personne le droit de contester un résultat défavorable résultant exclusivement de l'analyse par des systèmes automatisés.

La conséquence technique de cette disposition est directe. Lorsqu'une contestation survient, vous devez pouvoir montrer comment la décision a été prise. Si vous ne le pouvez pas, vous ne pouvez pas défendre la décision.

Il en découle cette règle architecturale. Dans un processus produisant des conséquences pour une personne, un modèle qui ne produit pas de justification ne peut pas être utilisé. Cela doit être inscrit dès le départ comme une contrainte dans le choix du modèle. Ajouter l'explicabilité après coup n'est pas possible dans la plupart des architectures.

Conserver des journaux ne suffit pas, il faut enregistrer la bonne chose

Quand on parle de piste d'audit, on pense d'abord à tenir un journal, mais c'est le contenu de ce journal qui est déterminant.

Pour qu'une décision puisse être examinée par la suite, cinq éléments doivent être enregistrés ensemble. Les données entrées dans le système, la version du modèle, le résultat produit, la justification sur laquelle repose ce résultat, et la décision finale prise par la personne. Si ces cinq éléments sont conservés dans des systèmes séparés, ils ne peuvent plus être recoupés par la suite. Si la version du modèle n'a pas été enregistrée, il devient impossible, des mois plus tard, de répondre à la question de ce que disait le modèle à cette date.

La version du modèle non enregistrée est, en pratique, la lacune que je constate le plus souvent. Le modèle est mis à jour, on essaie d'expliquer d'anciennes décisions avec le nouveau modèle, et cela ne colle pas.

Il faut montrer la différence entre la certitude et l'incertitude

Un dernier point. Le système doit montrer de manière distinguable le résultat qu'il produit avec une faible confiance de celui qu'il produit avec une confiance élevée.

En l'absence de cette distinction, l'utilisateur fait confiance à tous de la même manière et ne reçoit aucun avertissement précisément là où l'erreur est la plus probable. Pourtant, l'incertitude propre au modèle peut le plus souvent être mesurée. Porter cette mesure jusqu'à l'interface est l'amélioration la moins coûteuse et la plus efficace de la supervision.

S'il fallait choisir une seule chose à faire aujourd'hui dans un projet d'intelligence artificielle, ce serait celle-là que je choisirais.