La gouvernance de l’IA pour les dirigeants

L’expression « gouvernance de l’IA » a fini par recouvrir trop de choses à la fois. En pratique, elle est beaucoup plus petite qu’un comité d’éthique, et beaucoup plus large qu’une note de politique interne. C’est un ensemble de décisions opérationnelles que tout dirigeant doit prendre, cette année, avant que l’organisation n’apprenne les mêmes leçons par la voie coûteuse. Les risques ne sont pas théoriques : un résumé IA confiant et faux dans un document de conseil, un engagement client généré par un chatbot que personne ne pourra honorer ensuite, un document client sensible discrètement collé dans un modèle public.

Ce qui rend l’IA différente des vagues logicielles précédentes est aussi ce qui rend sa gouvernance plus difficile. Les sorties sont probabilistes, pas déterministes. Le même prompt peut produire une réponse différente le mardi de celle qu’il a donnée le lundi. Le fournisseur peut mettre à jour le modèle sans prévenir, en changeant à la fois son comportement et sa précision. Et les personnes qui l’utilisent le plus ne sont pas à la DSI, elles sont au marketing, au juridique, au commercial et à la direction. Cet article passe en revue les décisions opérationnelles qui comptent, avant qu’aucun document de politique ne soit rédigé.

Cinq décisions, prises ensemble, font l’essentiel du travail de gouvernance de l’IA. Sauter l’une d’entre elles est généralement là où les problèmes s’accumulent.

La première est l’usage acceptable : les catégories de travail dans lesquelles l’organisation est à l’aise d’impliquer l’IA, et celles dans lesquelles elle ne l’est pas. Un cabinet de conseil fiscal qui utilise l’IA pour rédiger des courriers clients n’a pas du tout la même exposition qu’un cabinet qui utilise l’IA pour interpréter le droit fiscal pour ses clients. La plupart des organisations n’ont pas été explicites sur où passe la ligne, ce qui veut dire que les employés la tracent eux-mêmes, par cent petits choix, chaque jour.

La deuxième est la revue humaine : pour quels résultats assistés par IA un humain valide avant que la sortie ne quitte l’organisation, et ce que « valider » veut réellement dire. Un relecteur qui ne peut pas en pratique attraper une erreur ne fournit pas une revue, seulement un tampon.

La troisième est les limites de données : quelles données peuvent être envoyées à un modèle, et lesquelles ne le peuvent pas. Données personnelles clients, informations de salaire, comptes non publiés, projets de contrats, code source contenant des identifiants. Le défaut, dans beaucoup d’organisations, est que la question n’a pas été tranchée, ce qui veut dire qu’elle est tranchée, mal, par celui qui est pressé.

La quatrième est la responsabilité sur les résultats : quand une décision influencée par l’IA est fausse, qui est responsable. La réponse réaliste est la personne ou la fonction qui a validé, ni le modèle ni le fournisseur. Si cette responsabilité n’est pas attribuée à l’avance, elle est attribuée a posteriori, dans une réunion à laquelle personne ne voulait être.

La cinquième est le choix des fournisseurs et des modèles : quels modèles l’organisation a approuvés à l’usage, sur quelles données, avec quelle position contractuelle sur la rétention, l’entraînement et la confidentialité. La prolifération de modèles à travers l’organisation (différentes équipes utilisant différents fournisseurs avec différentes conditions) est l’un des moyens les plus rapides de perdre le contrôle de l’endroit où les données vont réellement.

« Human in the loop » est l’expression la plus utilisée dans les documents de gouvernance de l’IA, et l’une des plus mal définies. En pratique, elle recouvre trois dispositifs très différents, et faire comme s’ils étaient identiques est la manière dont les organisations finissent avec des contrôles qui ne contrôlent rien.

Le premier dispositif est la revue : un humain lit la sortie de l’IA et décide de l’accepter, de la rejeter ou de la modifier avant que quoi que ce soit ne quitte l’organisation. Cela fonctionne quand l’humain peut plausiblement attraper une erreur dans le temps disponible. Pour un brouillon d’e-mail d’un paragraphe, oui. Pour cinquante pages de contrat relues en dix minutes, presque jamais.

Le deuxième est l’escalade : l’IA gère les cas courants seule, et n’escalade vers un humain que lorsqu’elle est incertaine, lorsque le cas franchit un seuil (un remboursement au-dessus d’un certain montant), ou lorsque l’utilisateur le demande. Cela ne marche que si le signal d’incertitude de l’IA est fiable, ce qui est souvent là que les systèmes échouent silencieusement.

Le troisième est l’audit : personne ne relit chaque sortie, mais un échantillon est relu périodiquement, et les incidents sont examinés individuellement quand ils surviennent. C’est le bon dispositif pour un travail à fort volume et faible enjeu, associé à des déclencheurs d’escalade clairs et à un processus d’incident rapide.

La plupart des déploiements d’IA fonctionnent mieux avec les trois, mappés explicitement au type de travail automatisé. La mauvaise réponse est de déclarer « human in the loop » sans préciser duquel des trois il s’agit.

La réalité de gouvernance la plus difficile, c’est que les équipes utilisent déjà l’IA, avec ou sans autorisation. Les équipes marketing rédigent dans ChatGPT. Les commerciaux écrivent leurs propositions avec Claude. Les juristes résument des contrats sur des comptes grand public. Les développeurs collent du code dans des modèles qui s’entraînent dessus. Espérer que cela disparaisse n’est pas une stratégie. L’interdire ne l’est pas non plus : cela pousse l’activité hors des comptes corporate et sur des comptes personnels, où l’exposition de données est pire et où la traçabilité disparaît.

La position réaliste est de supposer l’usage, de sanctionner les parties sûres, de fournir les outils approuvés, et d’être précis sur ce qui est hors limites. Une politique d’usage acceptable courte et écrite, qu’un employé réel peut lire et retenir, vaut beaucoup plus qu’un cadre de cinquante pages que personne n’ouvre. Couplée à une voie discrète pour signaler les presque-incidents sans être pénalisé, l’organisation commence à apprendre de ses propres incidents plutôt que des titres de presse sur d’autres organisations.

C’est structurellement la même discipline de gouvernance qui tient n’importe quel programme de transformation, appliquée à l’IA : un propriétaire nommé, un périmètre clair, une boucle de retour. Les schémas plus larges sont traités dans les modèles de gouvernance qui fonctionnent.

Dans les organisations qui ont dépassé le stade du document de politique, quatre éléments sont généralement en place.

Un propriétaire nommé de la gouvernance de l’IA qui n’est pas la DSI seule, suffisamment proche du métier pour savoir ce qui est réellement utilisé, et suffisamment senior pour faire respecter les conséquences quand la politique est enfreinte.

Une politique courte et écrite (typiquement moins de cinq pages) couvrant l’usage acceptable, les limites de données, les outils approuvés et le chemin d’escalade quand quelque chose tourne mal. Les longs documents ne sont pas lus, les courts le sont.

Un processus de revue d’incidents modélisé sur la manière dont les incidents de sécurité sont traités : quand quelque chose tourne mal, l’objectif est d’apprendre et d’améliorer les contrôles, pas de trouver à qui imputer ce qui était, dans bien des cas, une lacune évidente dans les règles.

Une relecture périodique de la politique à un rythme fixe, parce que la technologie sous-jacente bouge plus vite que la politique ne le fait normalement. Une politique écrite il y a dix-huit mois pour un chatbot qui rédigeait des brouillons n’est pas la bonne politique pour un agent qui prend des actions dans des systèmes de production.

La gouvernance de l’IA n’est pas une question d’éthique déguisée en question opérationnelle. C’est une question opérationnelle aux conséquences éthiques, et elle doit être traitée comme telle. Les dirigeants qui la délèguent entièrement à une équipe technique récolteront des réponses techniques à des problèmes non techniques. Ceux qui la délèguent entièrement à une équipe juridique récolteront une politique que personne ne lit. Les organisations qui réussissent ce point la gardent proche du métier, en langage clair, avec un propriétaire nommé et une courte liste de décisions prises à l’avance.

Le contexte plus large, dont la dimension stratégique et économique de l’IA dans les organisations, est rassemblé dans le cluster stratégie IA et automatisation. Et lorsque la question passe de « devons-nous avoir une politique IA » à « nous en avons une et elle est déjà dépassée, comment faisons-nous tourner un vrai processus de gouvernance sur plusieurs cas d’usage », c’est exactement ce sur quoi mon accompagnement transformation digitale est centré.