Une liste des décisions d'oversight n'est pas un nouveau formulaire ni une nouvelle réunion. C'est un endroit fixe où l'on consigne quelle application d'IA a été évaluée, par qui, sur la base de quelle évaluation des risques, et avec quelle décision. Approuvée, rejetée, sous conditions, ou temporairement autorisée en attendant un examen plus approfondi. Sans cette liste, une décision n'existe que dans la mémoire de ceux qui étaient présents, et elle disparaît dès que quelqu'un change de fonction ou que la discussion n'a pas été consignée dans un procès-verbal.
La liste comporte, pour chaque application, une brève description de la tâche, la classification selon le rôle et le niveau de risque, le nom du responsable du processus, la date de l'évaluation, la décision prise et sa justification. Pas de spécification technique, pas de documentation fournisseur : cela relève du dossier de l'application elle-même, pas de la liste des décisions. La liste constitue un aperçu à un niveau supérieur — qui a décidé quoi, et quand cette décision a été confirmée pour la dernière fois. Une application approuvée il y a un an pour une tâche à risque limité peut désormais être utilisée pour autre chose. Sans confirmation périodique, une ancienne décision continue de s'appliquer à une situation qui n'existe plus.
La raison pour laquelle des registres d'IA distincts restent souvent vides n'est pas la mauvaise volonté, mais l'ordre des priorités. Chaque organisation dispose déjà d'un endroit où les risques sont discutés et consignés : un comité des risques, un comité d'audit, une réunion de direction avec un point fixe à l'ordre du jour sur le risque opérationnel. Créer en plus un journal d'IA séparé revient à demander aux gens de tenir une seconde administration pour quelque chose qui, sur le fond, relève déjà de la première. Ce second processus perd, structurellement, face aux urgences du quotidien. La liste des décisions d'oversight ne fonctionne que si elle est intégrée dans ce qui existe déjà — comme élément fixe d'une concertation existante, avec une place fixe à l'ordre du jour, plutôt que comme nouvelle obligation à côté.
Cela signifie aussi que la liste utilise la même échelle et le même langage que le reste de la structure de risque. Une application présentant un niveau de risque élevé reçoit le même type d'attention qu'un autre dossier à niveau de risque élevé : fréquence de reporting fixe, responsable fixe, ligne d'escalade fixe. La manière dont ce lien se concrétise en pratique dépend de la gouvernance existante de l'organisation et est décrite sur la page relative à l'articulation avec la structure de risque existante.
Une liste des décisions est inutile sans une procédure prévoyant ce qui se passe lorsque quelqu'un n'est pas d'accord, ou lorsqu'une application évolue sans que personne ne le signale. Cette procédure ne fait pas partie de la liste elle-même, mais doit s'y raccorder : qui peut contester un rejet, qui doit prolonger une autorisation temporaire, et à qui revient une affaire lorsque le responsable du processus et la fonction de risque ne s'accordent pas. La manière dont ces lignes fonctionnent sans que chaque question ne remonte au sommet de l'organisation est décrite dans des voies d'escalade qui fonctionnent.
La liste des décisions constitue la mémoire ; le conseil d'administration a en outre besoin d'un résumé qui ne doit pas être recomposé chaque trimestre à partir de procès-verbaux séparés. Ce que ce résumé doit contenir — et ce qu'il ne doit précisément pas contenir, parce que cela figure déjà dans la liste des décisions — est décrit sur la page consacrée à un rapport au conseil d'une page. Sans cette étape, la liste des décisions reste un document que seuls les responsables de processus lisent, alors que le conseil d'administration demeure juridiquement responsable de ce qui est décidé.
Consigner une décision n'est pas la même chose que savoir si cette décision est respectée. Une application rejetée peut malgré tout rester en usage si personne ne vérifie que le rejet a bien été appliqué. C'est la raison pour laquelle une liste des décisions sans suite produit peu de résultats : elle documente des intentions, pas des comportements. Ce qui est nécessaire pour voir si une décision tient réellement, et quels signaux y correspondent, est décrit sur la page relative au suivi qui apporte des résultats.
Une liste des décisions ne peut contenir que ce qui a été signalé. Qui dépend des signalements du service informatique ne voit qu'une fraction de ce qui est réellement utilisé : la plus grande partie de l'usage de l'IA dans une organisation naît en dehors des filières formelles d'acquisition, dans des équipes qui essaient un outil parce qu'il fonctionne. Que ces applications finissent un jour sur la liste des décisions dépend de la question de savoir si les collaborateurs osent dire ce qu'ils utilisent — et cela n'arrive que si les questions à ce sujet ne ressemblent pas à l'antichambre d'une sanction.
La première question qui aide en la matière n'est pas « quelle IA a été approuvée » mais « quelle part de ce travail est déjà effectuée, ou pourrait être effectuée, par l'IA ». C'est un point d'entrée différent d'une liste des décisions, et un point de départ plus complet : le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, et pose ainsi une base qui ne dépend pas de ce qui a été signalé par hasard. À partir de ce résultat, on voit apparaître les applications qui fonctionnent en réalité déjà, avant même que la liste des décisions n'en ait connaissance.
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.