Une équipe marketing a besoin d'un assistant de rédaction. Un analyste financier veut un outil qui résume des tableaux Excel. Aucun d'eux n'attend un processus d'achat qui dure des mois. Il y a une carte de crédit, une adresse e-mail, et en dix minutes il y a un abonnement que le service paie lui-même, gère lui-même et utilise lui-même. Le service informatique n'en sait rien. Il n'y a aucune raison de le signaler, car rien n'a été fait de mal — un problème a simplement été résolu.
La plupart des cas d'IA fantôme ne commencent pas par une tentative de contourner les règles. Cela commence par une tâche qui doit aller plus vite, une échéance qui n'attend pas un processus d'approbation, et un outil accessible sans intervention de qui que ce soit d'autre. Le service qui s'y abonne ne voit pas cela comme une décision informatique. Cela ressemble à une fourniture de bureau, pas différente d'une licence logicielle que tout le monde utilisait déjà avant qu'une politique d'achat centralisée n'existe. Que le modèle de langage traite des données d'entreprise, lise des informations clients ou génère un texte provisoire destiné à sortir de l'entreprise n'est pas, pour l'utilisateur, une question de gouvernance. C'est simplement du travail.
La même dynamique s'observe chez un fournisseur qui a intégré l'IA dans son produit sans qu'une discussion distincte ait eu lieu à ce sujet : la fonctionnalité apparaît dans une mise à jour, personne ne la valide, et l'organisation l'utilise avant que quiconque ait déterminé qui en est responsable.
Une annonce indiquant que les outils non autorisés ne sont pas permis change peu de choses. Le service qui détient l'abonnement le perçoit comme une solution qui fonctionne, pas comme un risque à signaler. Une interdiction sans alternative produit deux résultats possibles : l'abonnement passe dans l'ombre, ou l'équipe l'arrête et le travail redevient plus lent. Aucun des deux n'est ce qu'une organisation souhaite.
À cela s'ajoute le fait qu'un tel abonnement est rarement une décision ponctuelle. Il devient partie intégrante du flux de travail, relié à d'autres outils, utilisé dans des processus qui en dépendent désormais. Ce qui commence comme un essai devient un élément permanent du fonctionnement de l'équipe — exactement le schéma que l'on observe aussi chez un dispositif d'essai qui n'a jamais été arrêté : personne n'a décidé de le rendre permanent, mais personne n'a non plus décidé de l'arrêter.
Le réflexe consistant à débusquer l'IA fantôme et à en tenir l'utilisateur pour responsable produit l'effet inverse. Qui sait qu'un signalement entraîne une réprimande ne signale rien. L'abonnement continue d'exister, simplement moins visible. Le service devient plus prudent dans ce qu'il rapporte, pas plus rigoureux dans ce qu'il utilise.
Ce qui fonctionne, en revanche, c'est de poser des questions sans qu'une sanction y soit rattachée. Une équipe qui utilise un outil pour accélérer une tâche a généralement une raison que l'organisation a intérêt à connaître : un processus trop lent, une tâche en surcharge, un besoin que l'offre existante ne couvre pas. Voyez comment cela est décrit chez des collaborateurs qui utilisent un outil que personne n'a approuvé — le point d'accroche n'est pas l'infraction, mais le besoin qui se trouve derrière.
La première étape n'est pas la mise en application, mais l'inventaire : quels outils existent, qui les utilise, pour quelle tâche, et avec quelles données. Cela ne passe pas par la liste informatique — celle-ci enregistre ce qui est approuvé, pas ce qui est utilisé. Cela se fait en posant des questions, d'une manière qui ne comporte aucune menace.
Dès qu'il y a une visibilité sur ce qui est en cours, une classification peut suivre : quel rôle joue l'outil, quel niveau de risque lui correspond, et quelle forme de contrôle est appropriée. Chaque abonnement qu'un service a conclu lui-même ne constitue pas un problème. Un outil qui réécrit un texte public relève d'une autre catégorie qu'un outil qui traite des données clients sans que personne ne sache où ces données vont. La distinction entre ces catégories est précisément ce dont il est question dans le contrôle humain en pratique : tout usage ne requiert pas le même degré de contrôle, mais tout usage requiert que l'on sache qu'il existe.
Vient ensuite une structure de gouvernance qui s'inscrit dans ce qui existe déjà — pas un nouveau processus à côté du cadre de risque existant, mais une extension de celui-ci. Une organisation qui traite le risque lié à l'IA séparément du reste de sa gestion des risques court le risque que ce second système soit ignoré, comme on peut le lire chez un second processus à côté de l'existant qui est ignoré. L'approche qui perdure est celle qui s'aligne sur ce que l'organisation fait déjà pour maîtriser le risque.
Un abonnement qu'un service a conclu lui-même est généralement le signe que quelque chose doit aller plus vite que ce que le processus actuel permet. Cette question — quelle partie du travail peut être accélérée, et où cela peut se faire de manière structurée plutôt que de manière invisible — est précisément à laquelle répond le scan de travail de FTE TO AI. Le scan de travail calcule, par tâche, quelle partie du travail peut être reprise par l'IA, afin que le besoin qui a conduit à un abonnement fantôme trouve sa place au sein d'un processus que l'organisation connaît et maîtrise réellement.
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.