Un conseil d'administration reçoit périodiquement des rapports : financiers, opérationnels, sur des risques qui ont déjà une place dans la structure existante. Un rapport sur l'IA qui se tiendrait à part, avec son propre rythme et son propre format, est en pratique laissé de côté. Pas parce que le sujet n'est pas important, mais parce qu'un second processus à côté d'un processus existant demande un effort distinct qui entre en concurrence avec tout ce qui figure déjà à l'ordre du jour. Ce qui est effectivement lu, c'est ce qui s'insère dans la ligne de reporting existante : le même rythme, la même longueur, la même place dans la réunion.
Un rapport au board sur l'IA n'a pas besoin d'un inventaire technique complet. Le conseil a besoin d'une réponse à un nombre limité de questions : quelles applications d'IA existent, dans quelle catégorie de risque se situent-elles, qu'est-ce qui a changé depuis le rapport précédent, et y a-t-il eu des escalades. Ce dernier point est celui où la plupart des rapports restent vides — non pas parce qu'il ne se passe rien, mais parce qu'il n'existe aucune voie par laquelle un signal atteint le conseil. Sans chemins d'escalade qui fonctionnent opérationnels, un rapport n'est qu'un instantané sans histoire : il montre ce qui existe maintenant, pas ce qui s'est mal passé ou a presque mal tourné en cours de route.
Le rapport s'appuie sur ce qui est déjà établi. Une liste des décisions de supervision indiquant qui a approuvé quoi est la source à partir de laquelle la page est synthétisée, et non un document séparé qui existerait à côté. Ce qui figure sur la page est une condensation de décisions déjà prises ; ce n'est pas une nouvelle évaluation que le conseil devrait effectuer lui-même à partir de données brutes.
Les organisations disposent déjà d'une structure de gestion des risques : un comité d'audit, un comité des risques, une place fixe à l'ordre du jour du conseil pour les risques opérationnels. Un rapport sur l'IA qui introduit son propre comité, son propre calendrier ou son propre modèle demande à tous ceux qui y participent déjà de faire quelque chose en plus de ce qu'ils font déjà. Ce travail supplémentaire est reporté dès que l'agenda se remplit, et l'agenda se remplit toujours. Le résultat est que le rapport disparaît après quelques fois, non pas parce que quelqu'un a décidé que le risque IA n'était pas important, mais parce que personne n'a décidé qu'il était plus important que ce qui existait déjà.
La solution ne réside pas dans une insistance accrue sur le sujet, mais dans une moindre friction lors de son intégration. Une page qui apparaît selon le même rythme trimestriel que les autres rapports de risque, qui utilise la même mise en page et occupe la même place dans le dossier, est lue parce que sa lecture ne demande pas d'acte distinct. Ce qui ne fonctionne pas, c'est un cycle de gouvernance IA séparé qui fonctionne indépendamment du cycle existant — celui-ci est ignoré dès l'arrivée du premier mois chargé.
Un rapport d'une page ne peut être court que si la structure sous-jacente est complète. Elle présuppose un aperçu des rôles et responsabilités du type ce qu'un administrateur doit savoir sur le risque IA, afin que la page n'ait pas à expliquer à chaque fois qui est responsable de quoi. Elle présuppose un inventaire qui ne contient pas seulement ce que l'IT a approuvé, mais aussi ce que les départements ont commencé à utiliser eux-mêmes sans le signaler — l'IA fantôme, qui ne devient visible que lorsque les personnes peuvent dire ce qu'elles utilisent réellement sans en subir de conséquences. Un rapport qui ne montre que la liste approuvée rend compte d'une fiction.
La page présuppose également qu'il se passe quelque chose entre les rapports : une surveillance qui produit des résultats plutôt qu'un journal que personne ne consulte. Sans cette couche intermédiaire, la page trimestrielle constitue une surprise à chaque édition, au lieu d'être le résumé de quelque chose qui a été suivi tout au long du trimestre. Et elle présuppose que la politique sous-jacente n'est pas une documentation de façade, mais une politique d'IA qui est lue par les personnes qui utilisent les systèmes au quotidien — car un rapport sur le respect d'une politique que personne ne connaît rend surtout compte de lui-même.
La page destinée au conseil est une condensation ; la justification se trouve un niveau plus bas, chez celui qui connaît les systèmes. Ce qu'un CIO y apporte est décrit sur ce qu'un CIO doit savoir sur le risque IA, et ces deux niveaux — vue d'ensemble au niveau du conseil et connaissance opérationnelle — doivent s'articuler avant que la page qui se lit en un quart d'heure ne dise réellement quelque chose sur ce qui se passe dans l'organisation.
Cette structure est en construction, elle n'est pas proposée comme un produit achevé. Quiconque souhaite le scan qui produit cet inventaire, cette classification et cette structure de reporting est placé sur une liste d'attente ; c'est en cours de développement et ce n'est pas vendu comme un outil prêt à l'emploi avant qu'il ne le soit réellement.
Une fois qu'il est clair quelles IA sont en fonctionnement et dans quelle catégorie de risque elles se situent, une autre question se pose, qui ne porte pas sur le risque mais sur l'organisation du travail lui-même : quelle part des tâches actuellement exécutées se prête à une reprise par l'IA. C'est un calcul distinct, qui ne se fonde pas sur le risque mais sur les tâches. Le scan de travail de FTE TO AI calcule, tâche par tâche, quelle part du travail se prête à une reprise, comme étape suivante une fois qu'il est clair ce qui existe déjà en matière d'IA dans l'organisation.
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.