Qu’est-ce que la gouvernance de l’IA ? Guide pratique pour les institutions régulées

Ce qu’est réellement la gouvernance de l’IA#

La gouvernance de l’intelligence artificielle est l’ensemble des droits de décision, des standards et des traces par lesquels un établissement contrôle ce que ses systèmes d’IA ont le droit de faire, établit qu’ils fonctionnent, et demeure capable de répondre ensuite de leurs résultats. C’est un dispositif de contrôle, non une déclaration de valeurs.

On ne l’évalue pas à la justesse des principes qu’il énonce, mais à ceci : lorsqu’une décision automatisée précise est contestée des mois plus tard, l’établissement peut-il dire :

• quel modèle l’a prise
• dans quelle version
• à partir de quelles données
• qui a approuvé ce modèle pour cet usage
• quels tests ont fondé cette approbation
• si un humain aurait pu intervenir ?

Pourquoi la gouvernance de modèle existante ne suffit pas#

Si l’on ne peut pas hériter tel quel du dispositif existant de gestion du risque de modèle, c’est que les systèmes d’IA rompent plusieurs hypothèses sur lesquelles ce dispositif a été bâti. Un modèle classique de crédit ou de capital possède une forme fonctionnelle énoncée, un jeu d’intrants fixe, des paramètres estimés délibérément, et un comportement qui ne change que lors d’une refonte.

Beaucoup de systèmes d’IA n’ont aucune de ces propriétés : la relation entre entrée et sortie est apprise plutôt que spécifiée, l’espace des intrants est bien plus large et souvent non structuré, la performance peut se dégrader à mesure que le monde évolue sans qu’aucune ligne de code ne bouge, et une part croissante de ce que déploient les établissements est un système tiers dont les rouages ne sont pas inspectables.

La gouvernance de modèle existante est la bonne fondation. Elle n’est pas l’édifice entier.

Un périmètre défini par la conséquence, non par la technique#

La première composante d’un dispositif opérant est son périmètre, et c’est là que la plupart échouent discrètement avant même de commencer. Une définition du « système d’IA » assez étroite pour exclure l’outil éditeur qui classe les alertes, la macro de tableur devenue règle de décision et le modèle qu’une ligne métier a construit sans le dire à personne est une définition qui ne gouverne à peu près rien.

L’approche exploitable définit le périmètre par la conséquence plutôt que par la technique : tout système dont le résultat façonne matériellement une décision concernant un client, une contrepartie, un chiffre financier ou une obligation réglementaire entre dans le périmètre, quelle que soit sa construction et quel qu’en soit l’auteur.

La technique détermine les contrôles ; la conséquence détermine si le dispositif s’applique.

Le classement par risque maintient le dispositif proportionné#

Vient ensuite le classement par risque, qui maintient le dispositif assez proportionné pour être respecté.

Un modèle qui rédige des synthèses internes et un modèle qui refuse des demandes de crédit ne doivent pas porter la même charge de validation, et un dispositif qui prétend le contraire sera respecté sur les cas à faible risque et discrètement contourné sur les cas à fort risque, parce que le coût de la conformité se ressent là où la pression à livrer est la plus forte.

Le classement repose généralement sur la conséquence d’un résultat erroné, sur le fait que la décision affecte ou non directement un client, sur l’existence d’une revue humaine avant effet, sur la réversibilité du résultat et sur l’ampleur de l’exposition. Chaque niveau porte ensuite son propre palier d’approbation, sa profondeur de validation, sa fréquence de surveillance et son standard de documentation.

L’inventaire est la colonne vertébrale du dispositif#

L’inventaire est la colonne vertébrale du dispositif et, en pratique, le livrable qui produit la surprise la plus immédiate. Le constituer suppose de demander à chaque fonction ce qui prend ou oriente des décisions en son nom, ce qui fait invariablement apparaître des systèmes que personne n’avait comptés : un module éditeur au cœur d’une plateforme, une règle de score enfouie dans un outil de workflow, un service d’analyse acheté, un modèle départemental ayant survécu à celui qui l’avait construit.

Chaque entrée exige un propriétaire côté métier — non côté technologie —, une finalité énoncée, un niveau de risque, une date de validation et une date de revue. Un établissement incapable de produire cette liste sur demande n’a, en aucun sens utile, de dispositif — quoi qu’en dise sa politique.

La validation passe du mécanisme au comportement#

La validation est le point où l’écart avec le risque de modèle classique est le plus net. Lorsque les rouages ne sont pas inspectables — parce que le système est acheté, ou parce que la relation apprise n’est pas véritablement lisible — la validation passe de l’examen du mécanisme à celui du comportement :

• performance mesurée sur des données que le développeur n’a jamais vues
• tests sur les segments de clientèle et les cas limites où une défaillance compterait le plus
• comparaison à un référentiel plus simple que l’établissement comprend
• tests adverses sur des intrants conçus pour le mettre en défaut
• tests de stabilité dans le temps

L’indépendance conserve son sens habituel : le validateur n’est pas le constructeur et a l’autorité de refuser l’approbation. Lorsqu’un système ne peut réellement pas être validé à la profondeur qu’exige son niveau, le résultat honnête est une restriction d’usage, non une approbation assortie d’une réserve que personne ne lit.

La supervision humaine doit être un mécanisme#

La supervision humaine doit être spécifiée comme un mécanisme, car en tant que principe elle est infalsifiable. Tout le monde s’accorde à vouloir un humain dans la boucle ; presque personne ne définit ce qu’il est censé faire, quelles informations il reçoit, de combien de temps il dispose et ce qui se passe s’il n’est pas d’accord.

Une supervision qui se réduit à un opérateur confirmant une recommandation à l’écran, sans information contradictoire et avec une file d’attente derrière lui, n’est pas une supervision — et un dispositif doit savoir distinguer les deux.

Les spécifications utiles sont concrètes : quelles décisions exigent une revue avant effet, ce que l’on doit montrer au réviseur, y compris le fondement de la recommandation, comment un contournement est consigné, et — la mesure qui révèle tout — quel est réellement le taux de contournement. Un taux nul signifie que le contrôle est décoratif.

La surveillance, car la défaillance est silencieuse#

La surveillance importe davantage pour l’IA que pour les modèles classiques, car la défaillance y est silencieuse. Un modèle exact à l’approbation peut devenir inexact sans qu’une ligne de code ne change, simplement parce que la population qu’il note a évolué, qu’un mix de canaux s’est déplacé, ou que le comportement appris appartenait à des conditions qui n’ont plus cours. Le détecter suppose :

• de suivre l’exactitude des résultats face aux réalisations plutôt que de vérifier seulement que le système tourne
• d’observer la distribution des intrants pour repérer une dérive par rapport à la population de développement
• de suivre les taux de résultats par segment de clientèle là où l’équité est en jeu
• de fixer à l’avance le seuil à partir duquel le modèle est réentraîné, restreint ou retiré

Ce seuil doit être défini avant d’être approché ; décider de continuer à exploiter un modèle qui se dégrade, sous pression commerciale et sans déclencheur convenu, est la défaillance la plus prévisible de tout le dispositif.

Les systèmes tiers et ce qu’il faut contractualiser#

Les systèmes tiers méritent un traitement propre, car ils constituent l’essentiel de ce que déploient réellement la plupart des établissements, et parce que la responsabilité ne se transfère pas avec le logiciel. Un superviseur demandant pourquoi un client a été refusé n’acceptera pas que le fournisseur, lui, le sache.

Ce qui est obtenable — et doit être contractualisé avant l’achat plutôt que réclamé après un incident — comprend :

• la documentation de l’usage prévu et des limites connues
• la preuve des tests réalisés par le fournisseur et sur quelle population
• un droit de tester indépendamment sur les données de l’établissement
• une notification préalable à toute modification du modèle
• un accès aux journaux suffisant pour reconstituer une décision
• une sortie qui ne laisse pas l’établissement bloqué en cours de processus

L’achat est le seul moment où ces clauses sont peu coûteuses.

Là où les dispositifs échouent#

Les dispositifs qui échouent le font de façon reconnaissable.

• Une politique énonçant des principes sans droits de décision attachés, si bien que personne ne peut dire qui approuve quoi.
• Un périmètre défini par la technique, laissant dehors les outils éditeurs et les modèles départementaux.
• Des contrôles uniformes, trop lourds pour les usages anodins et donc contournés sur les usages sérieux.
• Un inventaire constitué une fois pour un audit et jamais tenu.
• Une supervision humaine affirmée mais jamais mesurée.
• Une surveillance qui confirme la disponibilité du système plutôt que sa justesse.
• le plus souvent, un dispositif rédigé par une fonction qui ne détient aucun des modèles, approuvé par un comité qui n’en a jamais rejeté un seul, et consulté par personne parmi ceux qui construisent.

Un dispositif de gouvernance qui n’a jamais arrêté un projet ne gouverne pas.