Une liste de décisions d'oversight enregistre qui a pris quelle décision concernant quel système d'IA, sur la base de quelles informations, et avec quelle réserve. Cela semble simple. En pratique, la première version échoue souvent parce qu'elle est présentée comme un nouveau processus à côté des réunions existantes. Un deuxième processus à côté de l'existant est ignoré, non pas parce que les gens sont réticents, mais parce que personne ne réserve de temps pour quelque chose qui ne s'inscrit pas dans un agenda déjà complet.
La liste n'est ni un journal d'activités ni un registre des risques. Elle contient des décisions : des moments où une personne dotée d'un pouvoir de décision a approuvé, rejeté, reporté ou laissé se poursuivre quelque chose sous conditions. Chaque ligne doit comporter au minimum quatre éléments : le système ou l'application concerné par la décision, le nom et le rôle du décideur, la date, et la motivation ou la réserve. Sans motivation, une liste de décisions est une liste de présence. Avec motivation, elle devient la preuve qu'une réflexion a eu lieu, pas seulement qu'une case a été cochée.
La liste doit aussi laisser de la place à la révision. Une décision prise il y a six mois sur la base des informations alors disponibles peut être devenue obsolète. Une bonne liste de décisions montre quand une décision a été reconfirmée ou annulée, pas seulement quand elle a été initialement prise.
Les conseils d'administration et les directions ont déjà un rythme : réunions trimestrielles, comités des risques, comités d'audit. Mettre en place une nouvelle structure d'oversight distincte de ce rythme, c'est demander aux gens de trouver du temps supplémentaire pour quelque chose qui n'a pas de place définie. Cela n'arrive rarement de manière structurelle. Les premières fois, cela peut fonctionner, avec effort. Ensuite, cela disparaît de l'agenda dès qu'une chose plus urgente se présente, et il y a toujours quelque chose de plus urgent.
La solution n'est pas de construire un nouveau processus, mais de faire en sorte que la liste de décisions se greffe sur ce qui se passe déjà. S'il existe déjà un comité des risques qui se réunit chaque trimestre, la liste de décisions IA doit devenir un point fixe de cet agenda, pas une session séparée. S'il existe déjà une piste d'audit pour les décisions financières, la logique de cette piste — qui signe, qui contrôle, où c'est archivé — doit être réutilisée pour les décisions relatives à l'IA. C'est aussi la raison pour laquelle s'aligner sur la structure de risque existante constitue un sujet à part : une liste de décisions qui ne s'aligne pas sur la manière dont le risque est déjà discuté ailleurs reste un document isolé que personne ne consulte.
Une liste de décisions ne fonctionne pas isolément. Elle alimente le rapport dont un conseil d'administration a besoin pour pouvoir affirmer qu'il a une vue sur le risque IA, et elle présuppose qu'il existe une voie pour le cas où une décision ne s'avère plus tenable. Sans un rapport au conseil d'une page qui résume la liste de décisions, l'information disparaît dans une archive que personne ne parcourt. Sans des voies d'escalade qui fonctionnent, une décision devenue obsolète reste simplement en place, parce que personne ne sait à qui la signaler.
Les trois éléments sont liés : la liste de décisions consigne ce qui a été décidé, le rapport rend cela visible au niveau où cela a du poids, et l'escalade permet de rouvrir une décision si la situation change. Si l'on en construit un sans les deux autres, on crée une apparence de vue d'ensemble qui, au premier test — un incident, une question d'un régulateur, un journaliste — ne parvient pas à couvrir ce qui se passe réellement.
Une liste de décisions vaut ce que valent les informations qui y entrent. Si personne ne sait quels systèmes d'IA sont réellement utilisés — y compris ce qui a été acquis ou mis en place en dehors de l'informatique — alors la liste n'enregistre que les décisions concernant les applications visibles et formellement approuvées. Le reste reste sans décision, non pas parce qu'aucune décision n'était nécessaire, mais parce que personne ne savait qu'il y avait quelque chose à décider. C'est pourquoi un inventaire précède toujours une liste de décisions, et n'arrive jamais après. Ce qu'un administrateur doit savoir à ce sujet est décrit dans ce qu'un administrateur doit savoir sur le risque IA ; ce qu'un CIO doit reconnaître dans cet inventaire figure dans ce qu'un CIO doit savoir sur le risque IA.
Ce qui est établi : une liste de décisions sans lien avec une réunion existante n'est pas maintenue, et une liste de décisions sans vue complète de ce qui est en cours n'enregistre qu'une partie de la réalité. Ce qui dépend de l'organisation : quelle réunion constitue le point d'ancrage désigné, à quelle fréquence cette réunion se tient, et qui a le pouvoir de prendre une décision qui figurera sur la liste. Cela varie selon le secteur, la structure de gouvernance et la culture du risque, et c'est pourquoi il n'existe pas de modèle fixe qui fonctionne partout sans adaptation.
Le Responsible AI Scan est en cours de développement. Toute personne ayant actuellement besoin d'une liste de décisions qui s'aligne sur la structure existante peut s'inscrire sur la liste d'attente ; rien n'est encore proposé qui n'existe pas encore.
Une liste de décisions indique qui a décidé, pas quelle part de travail un système reprend effectivement ou pourrait reprendre. Pour cette question — quelle part d'une tâche peut être transférée à l'IA, et quelle part ne le peut pas — un autre regard est nécessaire que celui que la gouvernance seule peut offrir. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise, en complément de la vue d'ensemble qu'offrent une liste de décisions et la structure d'oversight qui l'accompagne.
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.