Vous avez une liste d'outils IA approuvés. La question n'est pas de savoir si cette liste est correcte, mais si elle signifie encore quelque chose. Un collaborateur qui accélère une tâche avec un chatbot ne figurant pas sur la liste ne le signale pas comme un incident. Il ne le signale pas parce que cela ne ressemble pas à un incident. La réponse que vous ne pouvez pas accepter est donc « nous avons une politique IA et une liste approuvée » — car cette phrase ne dit rien sur ce qui se passe en dehors de cette liste, et c'est probablement la plus grande partie.
En tant que CIO, c'est vous qui devrez expliquer pourquoi un incident lié à l'IA n'était pas connu plus tôt, alors que le reste de l'organisation part du principe que l'IT a une vue d'ensemble. Cette vue d'ensemble existe pour les systèmes qui ont été acquis. Elle n'existe pas pour l'extension qu'une équipe a installée elle-même, la version d'essai que quelqu'un a activée, ou le modèle intégré via un outil de service client. Le risque pour vous n'est pas que l'IA soit utilisée — cela se produit de toute façon — mais que vous en soyez informé en dernier, au moment où les choses ont déjà mal tourné.
Un inventaire fiable change votre position. Au lieu de réagir à des incidents que vous n'aviez pas vus venir, vous pouvez indiquer à l'avance où se situent les risques et pourquoi. C'est également la base pour mener, au sein de l'organisation, la discussion avec le General Counsel, qui examine cette même IA fantôme sous un angle différent, et avec le risk manager, qui souhaite l'intégrer dans la structure de gestion des risques existante plutôt que de créer une démarche distincte à côté.
La liste informatique enregistre ce qui a été acquis et approuvé. L'IA fantôme naît là où ces deux étapes sont contournées : un collaborateur trouve un outil, l'utilise, et ne rapporte rien parce qu'il ne lui semble rien y avoir à rapporter. Ce n'est pas de la négligence — c'est la conséquence d'un processus d'acquisition qui n'a pas été conçu pour suivre ce que les gens adoptent eux-mêmes. Plus l'organisation est grande et plus les équipes travaillent de manière autonome, plus l'écart entre la liste et la réalité peut être important. L'ampleur de cet écart dépend de la liberté dont disposent les équipes pour choisir leurs propres outils et de la visibilité déjà acquise par ce comportement — il n'existe pas de chiffre à ce sujet, seulement une tendance.
La seule façon de savoir ce qui se passe réellement est de le demander aux personnes qui l'utilisent. Cela ne fonctionne que si la réponse n'entraîne aucune conséquence pour celui qui la donne. Si vous demandez « utilisez-vous des outils IA non approuvés » sur un ton qui évoque un entretien d'évaluation, vous obtiendrez la réponse que la liste informatique donnait déjà : non. Si vous le demandez indépendamment de toute sanction, dans le but de comprendre plutôt que de corriger, une image se dessine qui correspond réellement à la pratique. Cette distinction — interroger sans conséquences versus interroger avec conséquences — fait la différence entre un inventaire qui a de la valeur et un exercice qui n'apprend rien à personne.
Une liste d'outils utilisés est un point de départ, pas un point d'arrivée. Toutes les applications d'IA ne comportent pas le même risque. Un outil qui reformule du texte à usage interne se situe différemment d'un outil qui participe à la décision d'accepter un client ou d'évaluer un collaborateur. Classer selon le rôle — ce que fait le système — et selon le niveau de risque — quel est l'impact en cas de problème — est nécessaire pour savoir où concentrer votre attention. Sans classification, chaque application d'IA se ressemble dans un rapport, et c'est précisément l'image qui ne convainc pas un conseil d'administration.
En tant que CIO, vous disposez probablement déjà d'un cadre de risque pour les systèmes IT, la sécurité de l'information et les fournisseurs. La gouvernance de l'IA fonctionne mieux si elle s'appuie sur cette structure plutôt que de devenir un cadre distinct à côté. C'est aussi ce à quoi se heurtent le compliance officer et le responsable de programme IA : trop d'initiatives IA isolées qui ne communiquent pas entre elles, alors que le conseil d'administration attend précisément une réponse cohérente et unifiée sur ce qui se passe et sur les mesures prises.
Ce que signifie l'IA fantôme diffère selon le secteur. Dans la construction, la situation n'est pas la même que dans le secteur de l'installation technique, et il est utile de voir comment la gouvernance de l'IA prend forme dans la construction ou à quoi cela ressemble dans le secteur de l'installation technique avant de supposer qu'une approche unique convient partout.
Le Responsible AI Scan qui permet d'obtenir cela — inventaire, classification, un ensemble de gouvernance qui s'appuie sur votre structure existante — est en cours de développement. Ceux qui souhaitent déjà s'y mettre peuvent s'inscrire sur la liste d'attente ; il n'existe pas encore de produit clé en main à proposer, et nous préférons l'écrire honnêtement plutôt que de promettre quelque chose qui n'existe pas encore.
Dès que vous savez quelle IA est utilisée et avec quel risque, la question suivante se pose naturellement : quelle part du travail lui-même pourrait constituer une tâche pour l'IA, et quelle part ne le pourrait pas. C'est une question différente de la gestion des risques — il s'agit de capacité, pas d'exposition — et le werkscan de FTE TO AI calcule cela tâche par tâche, afin que vous sachiez non seulement ce qui fonctionne déjà, mais aussi où l'IA pourrait elle-même reprendre le travail.
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.