Toute organisation d'une certaine taille dispose déjà d'une structure de risque. Un comité des risques, une fonction d'audit, une ligne de rapportage vers le conseil d'administration, un format dans lequel les risques sont classés et suivis. Quiconque met en place un nouveau processus à côté de cela, spécifiquement pour l'IA, avec son propre comité, son propre calendrier et son propre langage, se retrouve en moins d'un an avec un processus que plus personne ne remplit. Non pas parce que l'IA n'est pas jugée importante, mais parce qu'une seconde structure entre en concurrence avec la première pour le temps, l'attention et le mandat. La structure existante l'emporte presque toujours, car elle est intégrée dans les évaluations, les cycles de fonctionnement et les agendas du conseil d'administration. La nouvelle structure reste en dehors.
La question n'est donc pas de savoir comment construire une structure de gouvernance de l'IA. La question est de savoir comment l'IA trouve sa place dans la structure qui existe déjà.
La plupart des structures de risque comportent déjà un certain nombre d'éléments fixes : un inventaire des risques mis à jour périodiquement, une classification par gravité et probabilité, un propriétaire par risque, une ligne d'escalade vers un niveau supérieur en cas de dépassement d'une limite, et un rapportage au conseil d'administration à intervalles fixes. C'est la structure dans laquelle l'IA doit s'insérer, pas à côté.
Cela signifie qu'une application d'IA ne doit pas figurer dans un registre d'IA séparé, mais comme élément de risque dans le registre existant, avec les mêmes champs que tout autre risque : propriétaire, gravité, probabilité, mesure d'atténuation, date de statut. La classification par niveau de risque appliquée à un inventaire d'usage de l'IA doit s'aligner sur l'échelle déjà utilisée pour le risque opérationnel, et non sur une nouvelle échelle inventée uniquement pour l'IA. Qui lit ce qu'un CIO doit savoir sur le risque lié à l'IA constate que ce rattachement est précisément là où cela dérape souvent : un score de risque IA techniquement correct que personne ne peut comparer au reste du registre des risques.
Deux choses rendent l'intégration difficile. La première est le langage. Les gestionnaires de risques travaillent avec des notions telles qu'impact, probabilité et mesure d'atténuation. Les fournisseurs d'IA et les équipes techniques travaillent avec des versions de modèles, des données d'entraînement et des indicateurs de performance. Un ensemble de gouvernance rédigé uniquement dans le langage technique ne sera pas lu par le comité des risques. Un ensemble de gouvernance rédigé uniquement dans le langage du risque ne sera pas rempli par le propriétaire technique. L'ensemble doit être lisible dans les deux sens : suffisamment technique pour être exact, suffisamment institutionnel pour être compris. Ce principe se retrouve dans une politique d'IA qui est lue : un document qui se rattache à la manière dont les gens lisent et décident déjà, plutôt que d'imposer une nouvelle façon de lire.
La seconde est le rythme. Un comité des risques se réunit selon un cycle fixe, souvent trimestriel ou mensuel. L'usage de l'IA évolue plus rapidement : une équipe commence cette semaine à utiliser un nouvel outil, sans qu'une réunion l'ait précédé. L'ensemble de gouvernance ne doit donc pas dépendre du cycle de réunions pour fonctionner. Il doit exister un mécanisme plus léger qui absorbe les écarts entre les échéances fixes, et qui n'est confirmé formellement qu'au cycle suivant. Le fonctionnement concret de ce mécanisme est décrit dans des voies d'escalade qui fonctionnent : un parcours suffisamment court pour être utilisé avant la réunion du prochain comité trimestriel.
Un ensemble de gouvernance rattaché à une structure de risque existante contient, dans ses grandes lignes : un élément d'inventaire par application d'IA avec propriétaire et classe de risque, un lien vers la voie d'escalade existante afin qu'un écart ne disparaisse pas dans un canal séparé, et une place fixe dans le rapportage périodique au conseil d'administration. Pas comme un chapitre séparé sur l'IA, mais comme une ligne dans le tableau que le conseil connaît déjà. La manière dont ce rapportage peut se présenter sans introduire un nouveau format est décrite dans comment obtenir un rapport de conseil d'une page intégré dans ce qui circule déjà.
Le contenu des règles elles-mêmes, ce qui relève précisément de tel ou tel niveau de risque et les délais qui s'y rattachent, est fixé ailleurs et évolue ; cette page traite du mécanisme qui donne à ce contenu une place dans la structure existante, pas du texte de ces règles.
L'intégration ne réussit que si l'inventaire est exact au départ. Et il n'est exact que si les personnes osent dire ce qu'elles utilisent. Quiconque, en remplissant l'élément de risque, sent qu'une réponse honnête entraînera une remarque dans une évaluation, ne la remplira pas honnêtement. L'ensemble de gouvernance doit donc, dès sa première version, indiquer clairement que l'objectif est la visibilité, pas la sanction. Sans cet engagement, une partie de l'usage reste hors de vue, et le rattachement à la structure de risque repose sur une liste incomplète. Ce qu'un administrateur doit savoir à ce sujet avant le début du premier inventaire est décrit dans ce qu'un administrateur doit savoir sur le risque lié à l'IA.
Cette intégration porte sur le risque, la responsabilité et le rapportage : elle fait en sorte que ce que fait l'IA soit visible et maîtrisable au sein de la structure déjà en place. Une autre question, qui découle logiquement de celle-ci une fois la visibilité assurée, est de savoir ce que l'IA peut effectivement reprendre au sein de ce travail. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, comme étape suivante une fois le volet gouvernance en ordre.
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.