Beaucoup de monitoring de l'utilisation de l'IA naît comme une initiative séparée : un nouveau formulaire, une nouvelle réunion, un nouveau tableau de bord. Cela paraît complet au moment du lancement. Un an plus tard, cela s'est dilué. Pas parce que le contenu était mauvais, mais parce que cela se trouvait à côté de la structure existante au lieu d'en faire partie.
La question n'est donc pas seulement ce qu'il faut surveiller, mais où ce monitoring trouve sa place. Un processus que personne ne doit se rappeler parce qu'il fait déjà partie d'une routine qui fonctionne de toute façon, survit. Un processus qui demande une étape supplémentaire à des personnes déjà surchargées finit par être ignoré. Ce n'est pas de la mauvaise volonté. C'est une conséquence prévisible de la façon dont les organisations gèrent le temps et l'attention.
Chaque organisation a déjà un rythme : rapports trimestriels, comités de risque, cycles d'audit, réunions d'équipe. Si le monitoring de l'utilisation de l'IA introduit un nouveau rythme, il entre en concurrence avec tout ce qui existe déjà — et perd généralement. Il n'y a pas de point à l'ordre du jour pour cela, pas de responsable qui le considère comme un élément central de sa fonction, pas de moment où cela vient naturellement sur le tapis.
Si, en revanche, le monitoring devient une question qui est déjà posée — dans le comité de risque existant, dans le contrôle interne existant, dans la ligne de rapport existante vers le conseil — alors personne n'a besoin de se rappeler quelque chose de nouveau. La question « quelles applications d'IA ont été ajoutées ou modifiées » devient alors tout aussi naturelle que « y a-t-il de nouveaux fournisseurs » ou « y a-t-il eu des incidents ». La façon exacte dont cette articulation prend forme dépend de la manière dont l'articulation avec la structure de risque existante est déjà organisée chez vous — cette structure est le point d'ancrage, pas quelque chose à côté.
Un document de monitoring qui fonctionne est suffisamment court pour être utilisé de manière répétée et suffisamment spécifique pour signaler quelque chose lorsqu'un changement survient. Il contient au minimum :
La valeur du document ne réside pas dans son exhaustivité le premier jour. Celle-ci est rarement atteignable et n'est pas non plus nécessaire. La valeur réside dans le fait qu'il est tenu à jour, et que cette mise à jour ne demande pas d'effort séparé en plus de ce qui se fait déjà.
Le monitoring dépend de ce que les gens sont disposés à signaler. Dès que signaler équivaut à courir le risque d'être sanctionné pour quelque chose, l'information s'arrête. Quelqu'un qui accomplit une tâche plus rapidement que prévu grâce à un outil d'IA ne le signale pas si la conséquence en est un retrait de budget ou une conversation difficile. La liste reste alors formellement complète et vide sur le fond — exactement le problème que l'IA fantôme entretient.
La conséquence est que le monitoring ne fonctionne que si les questions sont posées sans sanction. Pas parce que l'utilisation devrait rester sans conséquence, mais parce que la première étape — savoir ce qui se passe — demande une attitude différente de la deuxième étape — évaluer si c'est approprié. Celui qui fait coïncider ces deux étapes n'obtient de réponse honnête à aucune des deux.
Cette distinction est aussi l'endroit où la gouvernance et la reddition de comptes se rencontrent. La visibilité pour le conseil ne doit pas nécessairement signifier que chaque application individuelle soit mise sur la table ; il s'agit d'un niveau de rapport qui permet un jugement sans s'enliser dans les détails, comme décrit dans un rapport au conseil qui tient sur une page. Ce qui se trouve en dessous — la consignation des décisions concernant des applications concrètes — a plutôt sa place dans une liste de décisions de supervision que dans le document qui remonte.
Savoir si un document de politique lui-même est lu est une question similaire : un texte que personne ne consulte n'offre pas plus de repère qu'un processus de monitoring que personne ne remplit. Voir à ce sujet une politique d'IA qui est lue. Et pour ceux qui se demandent quelle part de cette responsabilité relève de la table du conseil et quelle part relève de la gouvernance IT, il existe une distinction entre ce qu'un administrateur doit savoir sur le risque lié à l'IA et ce qu'un CIO doit savoir sur le risque lié à l'IA — les deux demandent des niveaux de détail différents au sein du même processus de monitoring.
Une structure de monitoring qui s'articule avec ce qui existe déjà fournit à un moment donné une image fiable des applications d'IA utilisées et de leur usage. Cet inventaire est une question différente de celle de savoir quelle part du travail sous-jacent est réellement effectuée par l'IA, et avec quel effet. Celui qui souhaite le faire calculer par tâche — quelle part d'une fonction ou d'un processus peut être transférée à l'IA, sur la base des tâches telles qu'elles sont exécutées aujourd'hui — le trouve dans le scan de travail de FTE TO AI.
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.