La plupart des organisations disposent déjà de quelque chose qui s'appelle monitoring. Un tableau de bord, un format de rapport, une réunion périodique où les risques sont discutés. Le problème n'est pas que cela fasse défaut. Le problème est que le monitoring de l'IA est ajouté comme un élément séparé, avec son propre rythme, son propre responsable et son propre modèle. Qui a déjà trois processus pour suivre les risques ne va pas remplir fidèlement un quatrième processus. Cela devient une obligation qu'on expédie une fois par trimestre, ou pas du tout.
C'est la raison pour laquelle le monitoring de l'usage de l'IA ne donne si souvent aucun résultat. Non pas parce que les questions sont mal posées, mais parce que le processus lui-même reste un corps étranger au sein d'une organisation qui dispose déjà de processus pour le risque, la conformité et le contrôle interne.
Un monitoring qui donne des résultats ne commence pas par un format mais par une question : qu'est-ce qui change, et qui le remarque en premier ? Pour les systèmes d'IA, cela signifie trois niveaux.
Le premier niveau est l'usage : un système est-il encore utilisé comme prévu, ou l'application a-t-elle dérivé sans que personne ne l'ait signalé ? Un outil qui a commencé comme correcteur de texte et qui sert désormais à formuler des projets de décision représente un risque différent de celui établi au départ.
Le deuxième niveau est l'origine : le système est-il encore le même qu'au moment où il a été classifié ? Les modèles sous-jacents sont remplacés, les fournisseurs modifient leurs conditions, un outil isolé est intégré dans une plateforme plus vaste. Chaque modification peut invalider l'évaluation des risques établie à l'époque sans que personne ne la réexamine.
Le troisième niveau est le signal : y a-t-il des plaintes, des messages d'erreur ou des anomalies indiquant que quelque chose ne fonctionne pas comme supposé ? C'est le niveau qui fait le plus souvent défaut, car personne n'a intérêt à signaler un problème avec un système qui, officiellement, n'existe pas.
Une organisation qui dispose déjà d'un cycle de risques pour les risques opérationnels, financiers ou de protection des données ne va pas lancer un nouveau cycle pour l'IA. Ce n'est pas de la mauvaise volonté ; c'est une question de capacité. Qui essaie voit se produire deux choses. Soit le nouveau monitoring reste vide, parce que personne ne trouve le temps d'alimenter un système que personne ne réclame. Soit le nouveau monitoring est repris par les mêmes personnes qui font déjà tourner le cycle existant, et la distinction disparaît d'elle-même.
La question n'est donc pas de savoir s'il faut créer un processus de monitoring de l'IA distinct. La question est de savoir comment les signaux liés à l'IA s'intègrent dans le cycle existant, de sorte qu'ils soient discutés dans la même réunion, avec le même responsable et selon le même rythme que les autres risques. La manière précise de l'organiser dépend du fonctionnement actuel de ce cycle existant : certaines organisations disposent d'un rapport trimestriel au comité d'audit, d'autres d'une réunion mensuelle sur les risques au niveau de la direction, d'autres encore d'un registre continu mis à jour par incident. Plus d'informations sur la manière d'intégrer le monitoring dans ce qui fonctionne déjà plutôt que d'y ajouter quelque chose figurent sur une page distincte, car ce mécanisme est mis en œuvre différemment selon l'organisation.
Ce qui s'y intègre de façon vraiment universelle, c'est une forme fixe dans laquelle le statut des systèmes d'IA est consigné : ce qui tourne, dans quel rôle, avec quel niveau de risque, et quand cela a été confirmé pour la dernière fois. Non pas comme un document IA isolé, mais comme une annexe ou un élément fixe du rapport qui existe déjà. Cela peut s'articuler avec un rapport d'une page pour le conseil d'administration qui résume les risques sans les occulter, afin que le monitoring ne devienne pas un flux d'informations séparé, mais une ligne dans un tableau que le dirigeant lit déjà.
Cette forme ne fonctionne que si la classification sous-jacente elle-même reste à jour, et cette classification doit à son tour s'articuler avec la structure de risque déjà en place. Sans cette articulation, le monitoring reste une seconde langue à côté de la première, et cette seconde langue est oubliée dès que la pression augmente. La forme que prend cette articulation dépend de la manière dont la structure de risque et la classification IA se rejoignent dans ce qu'une organisation utilise déjà, et ne peut être décrite en termes généraux sans connaître la structure existante.
Un monitoring qui fonctionne bien signale non seulement le risque mais aussi le glissement : des systèmes utilisés autrement que prévu, ou des tâches discrètement reprises sans que personne ne l'ait consigné. Ces mêmes signaux constituent aussi une information sur ce à quoi les gens consacrent réellement leur temps, et sur les endroits où l'IA reprend déjà effectivement du travail sans que cela soit noté nulle part. Qui souhaite rendre cette question plus concrète qu'une classification de risque ne le permet peut consulter le scan de travail de FTE TO AI pour voir quelle part du travail, par tâche, se prête à l'IA, indépendamment de la question de savoir si cela se produit déjà ou reste à décider. Ce scan ne raisonne pas en termes de risque, mais de tâches et d'heures, et rejoint ainsi ce que le monitoring signale sans l'expliquer.
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.