re-ai-gov Sur la liste d'attente

Kennisbank

Que doit savoir un risk manager sur le risque lié à l'IA

Le risque qui ne figure pas dans le registre

Vous gérez un registre des risques construit autour de risques que l'on peut identifier, pondérer et attribuer. Risque opérationnel, risque de crédit, risque de conformité : chacun a un propriétaire, une mesure de contrôle, une ligne de reporting. Le risque lié à l'IA ne s'intègre pas naturellement dans ce schéma, car le premier problème n'est pas la pondération. Le premier problème est que vous ne savez pas ce que vous pondérez. Une équipe qui utilise un modèle de langage pour rédiger des avis provisoires, un service qui a souscrit un abonnement IA externe en dehors des achats informatiques, une macro de tableur devenue entre-temps un modèle prédictif : ce ne sont pas des cas marginaux, c'est là que se situe le risque, et il ne figure nulle part.

La question que vous posez, et la réponse que vous n'acceptez pas

Votre question n'est pas « l'IA est-elle risquée ». Votre question est : qu'est-ce qui fonctionne, qui en est responsable, et sur la base de quelles informations puis-je en rendre compte au conseil d'administration et au régulateur. La réponse que vous n'acceptez pas, c'est le réconfort sans justification. « Il ne se passe rien de particulier » n'est pas une réponse à une question de risque, c'est l'absence de réponse. Un risk manager qui transmet cela au conseil d'administration transmet le fait qu'aucune vérification n'a eu lieu, pas qu'il n'y a rien.

La deuxième réponse que vous n'acceptez pas, c'est la liste issue de la gestion des systèmes informatiques présentée comme une vue complète. Cette liste montre ce qui a été demandé et approuvé. L'usage de l'IA naît en grande partie précisément en dehors de cette demande, car un abonnement isolé, une extension de navigateur ou une fonctionnalité intégrée dans un logiciel existant n'est pas reconnu comme « nouveau système ». Celui qui veut connaître le risque ne doit donc pas seulement consulter le paysage des systèmes, mais aussi les personnes qui font le travail, ce qui exige une approche différente d'un audit informatique.

Pourquoi interroger sans sanctionner est la seule méthode

En tant que risk manager, vous connaissez le schéma de sous-déclaration observé pour tout thème de risque où un collaborateur a quelque chose à perdre en répondant honnêtement. L'usage de l'IA en est un exemple frappant : si signaler l'utilisation d'un outil entraîne le retrait de l'accès, plus personne ne le signale. L'inventaire qui donne des résultats est celui qui interroge sans associer de conséquences à la réponse. C'est une compétence différente de celle que requiert habituellement la gestion des risques, et c'est pourquoi un inventaire de l'IA fantôme ne se conçoit pas comme un contrôle, mais comme un sondage.

Classification : le niveau de risque découle du rôle, pas du nom

Une fois l'usage identifié, l'étape suivante n'est pas d'évaluer le fournisseur ou le modèle. C'est d'évaluer le rôle que le système joue dans un processus. Une application d'IA qui reformule un texte porte un risque différent d'une application qui pèse dans une décision concernant un client, un collaborateur ou un investissement. Cette même technologie, employée dans un rôle différent, relève d'une classe de risque différente. Cette distinction est précisément ce dont un registre des risques a besoin pour pouvoir positionner le risque lié à l'IA aux côtés des risques qui y figurent déjà, sans créer un chapitre IA isolé, distinct, que personne ne consulte.

S'aligner sur la structure déjà en place

Un risk manager n'a aucun intérêt à un nouveau cadre parallèle à l'existant. L'intérêt réside dans un ensemble de gouvernance qui s'aligne sur la structure de risque déjà en place : la même logique de propriétaire, les mêmes chemins d'escalade, le même cycle de reporting vers le conseil d'administration. Un risque lié à l'IA traité comme un thème isolé disparaît entre les rapports habituels. Un risque lié à l'IA intégré dans la taxonomie des risques existante reste visible là où le conseil d'administration regarde déjà.

Démontrabilité, pas exhaustivité

À un moment donné, on vous demandera ce que vous savez de l'usage de l'IA dans l'organisation, par un régulateur, un auditeur ou le conseil d'administration lui-même. La réponse qui tient, ce n'est pas « tout est cartographié », car cela est rarement vérifiable pour un usage aussi dynamique. La réponse qui tient, c'est un processus démontrable : comment l'inventaire a été réalisé, quelle classification a été appliquée, quels accords de gouvernance en découlent, et à quelle fréquence cela est répété. C'est un critère différent de l'exhaustivité, et c'est le critère sur lequel la gestion des risques est déjà habituellement évaluée.

Cette question ne se pose pas de manière identique pour chaque rôle dans l'organisation. Ce dont un compliance officer a besoin de cet inventaire, vous le lirez dans ce qu'un compliance officer doit savoir sur le risque lié à l'IA, la question de pilotage de celui qui dirige le programme figure dans ce qu'un responsable de programme IA doit savoir sur le risque lié à l'IA, et la manière dont ce sujet se décline au niveau du conseil d'administration lui-même est décrite dans ce qu'un dirigeant doit savoir sur le risque lié à l'IA. Pour la gestion des risques dans des secteurs spécifiques, avec leurs propres chaînes et formes de contrôle, la perspective est encore précisée dans à quoi ressemble la gouvernance de l'IA dans le secteur de la construction et dans à quoi ressemble la gouvernance de l'IA dans le secteur de l'installation.

Le texte des règles en vigueur, avec leurs définitions et délais précis, ne figure pas sur cette page et est tenu à jour ailleurs. Ce qui est décrit ici, c'est le mécanisme : comment passer d'un usage inconnu à un risque classifiable et rapportable.

De l'inventaire des risques à l'inventaire des tâches

Un inventaire du risque lié à l'IA met inévitablement en lumière autre chose : quelle part du travail est déjà effectivement réalisée par l'IA, et quelle part pourrait l'être. C'est une question différente de la gestion des risques, mais elle en partage la source. Le scan de travail de FTE TO AI calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA, et s'inscrit ainsi précisément dans l'inventaire dont la gestion des risques a déjà besoin aujourd'hui.

L'outil est en cours de développement

Le Responsible AI Scan est actuellement en développement. Ceux qui souhaitent l'utiliser dès qu'il sera disponible peuvent s'inscrire sur la liste d'attente.

Andrewde assistent van de Responsible AI Scan

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.