Un collaborateur colle un morceau de texte dans une fenêtre de chat gratuite parce que cela va plus vite que le système interne. Une équipe souscrit un abonnement à un outil d'IA parce que la demande pour quelque chose d'officiel prendrait des semaines. Un fournisseur ajoute une fonctionnalité d'IA à un logiciel utilisé depuis des années, sans qu'aucune discussion n'ait eu lieu à ce sujet. Aucune de ces personnes ne tente de cacher quoi que ce soit. Elles essaient de faire leur travail.
C'est là le cœur de l'IA fantôme : elle ne naît pas d'une mauvaise volonté, mais d'un écart entre ce dont les gens ont besoin et ce que le processus formel offre. Tant que cet écart existe, l'IA fantôme continuera d'apparaître, quel que soit le nombre de politiques rédigées.
La plupart des organisations disposent d'un aperçu des logiciels approuvés. Cet aperçu est un point de départ, pas un reflet de la réalité. Ce que les gens utilisent réellement le dépasse presque toujours : la question de savoir comment éviter que des données d'entreprise ne se retrouvent dans une fenêtre de chat gratuite illustre à quel point un outil peut facilement échapper à tout contrôle. Il en va de même pour un service qui souscrit de sa propre initiative un abonnement parce que la voie habituelle paraît trop lente, ou pour une extension de navigateur qui obtient accès à la messagerie sans qu'il n'existe d'approbation distincte pour cela. Aucune de ces situations ne figure sur une liste informatique. Elles existent pourtant bel et bien.
Il existe une tendance à traiter l'IA fantôme comme un problème de mise en application : interdire, bloquer, sanctionner. Cela produit l'effet inverse. Quiconque sait qu'une réponse honnête entraîne un problème ne donnera plus de réponse honnête. L'outil ne disparaît pas, il devient plus invisible. Exactement l'inverse de ce dont une organisation a besoin.
Une deuxième raison pour laquelle cela ne se résout pas de lui-même : la gouvernance existante est souvent conçue pour des logiciels que l'on achète et installe, pas pour un service que quelqu'un ouvre dans un navigateur et quitte le lendemain. Une installation d'essai qui devait être temporaire à l'origine montre comment une chose de petite envergure, sans moment clair d'évaluation, peut perdurer pendant des années sans que personne ne s'en sente responsable. Sans un processus qui repère structurellement ce type d'usage, il reste sous le radar, quelles que soient les bonnes intentions.
La seule façon de savoir ce qui se passe est de poser la question. Pas comme un contrôle, mais comme un inventaire. Les collaborateurs qui savent qu'une réponse honnête ne débouche pas sur un entretien avec les ressources humaines donneront cette réponse honnête. Cela exige un ton et un processus qui indiquent clairement dès le départ : il s'agit d'obtenir une vue d'ensemble, pas de s'attaquer à quelqu'un.
Cela implique également une attention à la manière dont de nouveaux processus sont mis en place à côté des processus existants. Un second processus placé à côté de l'existant sans que le premier ne soit adapté ou retiré est souvent ignoré, simplement parce que les gens restent fidèles à leurs habitudes. Un inventaire qui s'ajoute comme une obligation supplémentaire au travail reçoit le même traitement.
Dès qu'il est clair ce qui est réellement utilisé, la question suivante se pose : que fait cet outil, et quel risque cela comporte-t-il ? Un outil qui résume du texte à usage interne demande une approche différente d'un outil qui participe à la décision d'accepter un client ou d'évaluer un employé. Cette classification par rôle et niveau de risque est ce qui transforme un inventaire en quelque chose d'exploitable : une base sur laquelle le conseil d'administration, le CIO ou le General Counsel peut expliquer ce qui se passe et pourquoi cela peut être justifié.
Cette couche de gouvernance s'inscrit dans la structure de risque que l'organisation possède déjà, pas dans un nouveau cadre à côté. Le contenu des règles auxquelles les applications d'IA doivent se conformer évolue et est tenu à jour ailleurs ; ce qui compte ici, c'est que l'organisation dispose d'une manière fonctionnelle de savoir ce qui tourne, qui en est responsable, et comment cela peut être démontré au conseil d'administration ou à l'autorité de contrôle.
Dès qu'il est clair quelle IA est effectivement utilisée et quel risque cela comporte, une autre question surgit naturellement : quelle partie du travail une application d'IA pourrait-elle en réalité reprendre, et quelle partie non. C'est une question différente de celle de l'approbation et du contrôle, mais qui en découle logiquement. Le scan de travail de FTE TO AI calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA, sur la base de ce qu'une fonction implique réellement. Là où le Responsible AI Scan met de l'ordre dans ce qui tourne déjà, le scan de travail révèle ce qu'il reste encore à gagner.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.