Cadres de gestion des risques liés à l’IA : vue d’ensemble

L’IA fait désormais partie du quotidien professionnel, mais les risques qu’elle introduit ne s’intègrent pas toujours aux listes de contrôle de sécurité habituelles. Les cadres de gestion des risques liés à l’IA permettent de structurer et de maîtriser ces risques.

Sommaire

1. Catégories de risques liés à l’IA
2. Règlement de l’UE sur l’IA
3. Cadre de gestion des risques liés à l’IA du NIST (AI RMF 1.0)
4. ISO/IEC 23894:2023 et ISO/IEC 42001
5. Composants clés de la gestion des risques liés à l’IA
6. Quel cadre choisir ?
7. Mise en œuvre d’un cadre de gestion

Points clés à retenir sur les cadres de gestion des risques liés à l’IA

• Les risques propres à l’IA ne sont pas entièrement couverts par les approches traditionnelles de sécurité informatique.
• Des cadres volontaires de gestion des risques liés à l’IA, tels que l’AI RMF du NIST et la norme ISO/IEC 42001, peuvent compléter des textes contraignants comme le Règlement de l’UE sur l’IA.
• Le Règlement de l’UE sur l’IA définit des catégories de risques associées à différentes obligations selon le niveau de risque.
• ISO/IEC 42001 est une norme certifiable pour les systèmes de management de l’IA, en lien avec la norme ISO 27001.
• Une gestion efficace des risques liés à l’IA repose sur une surveillance continue, une gouvernance claire et des formations de sensibilisation structurées

Catégories de risques liés à l’IA : ce à quoi les entreprises sont déjà confrontées aujourd’hui

De nombreuses entreprises utilisent déjà l’IA dans leur travail quotidien, souvent avant que des règles claires ne soient mises en place. Une équipe teste un nouvel outil. Un résultat semble plausible et vient alimenter une décision.

Les risques liés à l’IA ne surviennent pas uniquement dans les systèmes d’IA complexes. Ils apparaissent également dans les flux de travail de routine. La gestion des risques liés à l’IA aide les organisations à identifier ces situations, à les évaluer et à déterminer les contrôles nécessaires.

Risques techniques : quand des résultats erronés semblent fiables

Une équipe commerciale utilise l’IA pour analyser une liste de comptes avant une réunion de suivi des opportunités commerciales. L’outil identifie plusieurs comptes comme susceptibles d’acheter, suggère le bon moment pour les contacter et fournit à l’équipe un ordre de priorité clair. À première vue, ces recommandations semblent utiles plutôt que risquées.

Le problème apparaît lorsque l’équipe compare ce classement aux données commerciales actuelles. Certains secteurs figurent régulièrement en tête de liste, alors que les derniers chiffres des opportunités commerciales ne justifient pas de les privilégier. Des exemples d’entraînement obsolètes semblent avoir donné trop de poids à ces secteurs. L’erreur ne saute pas aux yeux. Le classement semble simplement assez plausible pour être utilisé, tandis que de meilleures opportunités reculent dans la liste des priorités.

L’IA générative introduit le même risque dans le travail quotidien. Un contenu de faible qualité peut tout de même être agréable à lire. Une source peut paraître crédible à première vue, mais ne mener finalement nulle part. Un chiffre peut sembler correct après une vérification rapide, puis se révéler inexact. Une affirmation peut donner l’impression d’avoir été soigneusement nuancée, alors qu’elle ne repose sur aucun élément probant.

La dérive du modèle crée un problème plus insidieux. Le modèle peut avoir bien fonctionné au moment de son lancement, mais le contexte dans lequel il évolue change : produits, données, marchés, comportements clients. D’un point de vue technique, rien ne semble défaillant. Les réponses peuvent néanmoins devenir moins utiles avec le temps. Leur qualité peut aussi se dégrader.

La gestion des risques liés à l’IA nécessite des contrôles opérationnels à cet effet :

• Sélection de résultats à examiner
• Erreurs et schémas récurrents
• Critères clairs de réévaluation d’un modèle

Risques de sécurité liés à l’IA : quand une donnée d’entrée se transforme en attaque

Les risques de sécurité liés à l’IA apparaissent souvent aux interfaces. Un chatbot répond aux questions des clients et utilise pour ce faire des bases de connaissances internes. Un attaquant formule une requête de façon à faire sortir le chatbot du cadre de ses instructions habituelles.

Le chatbot est censé répondre à une question client. Mais la formulation de la requête l’oriente plutôt vers des consignes internes, des notes d’assistance ou des contenus de base de connaissances que les clients ne sont pas censés voir.

L’injection de prompt ne se limite pas à la fenêtre de chat. Elle peut aussi être dissimulée dans des contenus que le système d’IA doit lire. Un collaborateur peut utiliser un outil d’IA pour résumer une page web externe. La page semble ordinaire, mais l’une de ses sections est rédigée pour le modèle plutôt que pour le lecteur. Le résumé peut alors suivre ces instructions masquées, contourner les mesures de protection ou inclure des informations qui n’ont pas leur place dans la réponse.

Avec l’empoisonnement des données, le risque apparaît avant même que le modèle ne soit utilisé. Les retours clients, les tickets d’assistance ou les avis sur les produits peuvent contribuer à améliorer un modèle, mais ils doivent tout de même être examinés avant d’être intégrés aux données d’entraînement. Des entrées manipulées peuvent ensuite influencer la manière dont le modèle classe les cas, les schémas qu’il privilégie ou les exceptions qu’il manque.

Les attaques adverses empruntent une autre voie. Elles concernent particulièrement les systèmes qui reconnaissent des images, la parole ou des schémas, par exemple dans le contrôle qualité. Un fournisseur pourrait modifier l’image d’une pièce défectueuse juste assez pour que le modèle ne détecte pas le défaut. Pour une personne chargée d’examiner l’image, la différence pourrait être presque imperceptible.

La gestion des risques liés à l’IA doit intégrer ces vecteurs d’attaque, en particulier lorsque l’IA est connectée à des données clients, à des systèmes internes ou à des processus métier critiques.

Risques de perte de confidentialité lors de l’utilisation de l’IA : lorsque la rapidité prime sur la protection des données

Les risques de perte de confidentialité lors de l’utilisation de l’IA apparaissent souvent sans intention malveillante. Prenons l’exemple des RH. Un collaborateur souhaite comparer rapidement des candidatures et importe des CV complets dans un outil d’IA public en quelques secondes.

Le service des achats peut faire face à la même pression. Un contrat doit être résumé rapidement, l’échéance approche, et le projet complet se retrouve dans un outil d’IA non approuvé. Ce document peut contenir des prix, des conditions de livraison, des marges de négociation et d’autres informations qui ne devraient pas quitter l’entreprise sans examen préalable.

En marketing, le risque peut être plus difficile à repérer. Des segments de clientèle, des données de campagne ou des analyses internes peuvent être importés dans un outil d’IA parce que le modèle fournit des suggestions utiles presque instantanément. L’équipe obtient une réponse plus rapide, mais perd de vue le parcours des données. Où les informations sont-elles traitées ? Sont-elles stockées ? Qui peut y avoir accès ?

Le Shadow IA accentue encore ce manque de visibilité. Le service informatique de l’entreprise ne peut pas recenser tous les outils utilisés. Le service juridique n’a pas connaissance de tous les cas d’usage. La direction n’apprend souvent qu’avec un certain retard quels outils d’IA les collaborateurs utilisent déjà.

Dans ce contexte, la gestion des risques liés à l’IA doit commencer par les comportements. Les collaborateurs ont besoin de directives claires sur :

• Les outils d’IA approuvés pour un usage professionnel
• Les données qu’il est autorisé d’utiliser dans les outils d’IA
• Le point de contact en cas de doute

Risques opérationnels : quand l’usage de l’IA devient peu à peu systématique

Les risques opérationnels ont tendance à croître progressivement. Une équipe de contrôle de gestion commence par utiliser l’IA pour raccourcir des rapports. Ensuite, l’outil commence à rédiger des commentaires. Au bout d’un certain temps, certains passages de ces commentaires se retrouvent dans des documents de pilotage, après une vérification limitée.

Le processus semble efficace, l’équipe continue donc de l’utiliser. Les hypothèses du rapport font l’objet de moins d’attention. La méthode manuelle reste disponible, mais elle est beaucoup moins utilisée. L’équipe s’exerce de moins en moins à repérer les failles de raisonnement, les éléments de contexte manquants ou les conclusions qui ne sont pas entièrement cohérentes. Si l’IA établit un lien erroné, l’erreur peut se propager à travers plusieurs niveaux avant d’être détectée.

Le même schéma peut apparaître en informatique. Au départ, l’IA sert à classer les tickets plus rapidement. Peu à peu, ce mode de traitement devient une pratique habituelle. Comme la classification est toujours disponible, elle commence à sembler fiable. Si des erreurs s’y glissent, des incidents critiques peuvent être redirigés trop lentement ou traités avec un niveau de priorité inadapté.

Une gestion structurée des risques liés à l’IA devrait définir :

• Les points de contrôle des résultats générés par l’IA
• Les décisions qui restent confiées à une personne
• Les indicateurs de qualité des réponses de l’IA
• L’autorité habilitée à suspendre le traitement en cas de sortie inhabituelle générée par l’IA.

Risques de conformité et risques juridiques liés à l’IA : quand les contenus générés par l’IA peuvent avoir des implications juridiques

« Intégration fluide. » « Résilience maximale. » « Prêt à l’emploi en quelques minutes. » L’IA peut rapidement rédiger des allégations de ce type. Avant publication, une personne doit tout de même vérifier si la formulation est exacte, étayée par des preuves et validée pour cet usage.

Cette vérification devrait avoir lieu avant que l’allégation n’apparaisse sur un site internet, dans une présentation commerciale ou dans la documentation produit. Qui l’a validée ? Quelles preuves permettent de l’étayer ? Qui est responsable de la formulation si elle est contestée par la suite ?

La gestion des risques liés à l’IA devrait permettre de tracer cette vérification, notamment en ce qui concerne la conformité à la directive SRI2 (NIS2) :

• Les outils d’IA utilisés pour la rédaction ou la vérification
• Les utilisateurs autorisés
• Les étapes d’approbation avant publication
• Les preuves à l’appui des allégations relatives aux produits et à la sécurité

Ce suivi aide les services juridiques et d’audit, ou les autorités de régulation, à comprendre ce qui a été vérifié et par qui.

Cadres de gestion des risques liés à l’IA

Les logiciels traditionnels suivent un code défini. Les systèmes d’IA fonctionnent selon des schémas appris à partir de données. Cette différence a des conséquences concrètes. Un bug logiciel peut souvent être rattaché à une ligne de code, à une configuration ou à une dépendance. Une erreur d’IA peut provenir des données d’entraînement, du comportement du modèle, des prompts, du contexte utilisateur ou de changements dans l’environnement.

Un cadre de gestion des risques liés à l’IA donne aux équipes risques, sécurité, juridique et métiers une méthode commune pour prendre des décisions concernant ces systèmes. Il aide à définir ce qui doit être documenté, les contrôles requis, les personnes chargées de valider et les cas d’usage qui nécessitent un nouvel examen. C’est ainsi que la gouvernance de l’IA s’intègre aux opérations quotidiennes.

L’AI RMF du NIST et la norme ISO/IEC 42001 sont des cadres volontaires. Le Règlement de l’UE sur l’IA joue un rôle différent : il fixe des exigences légales contraignantes dans l’UE pour certains systèmes d’IA et certains cas d’usage. De nombreuses organisations ont besoin de ces deux perspectives. La réglementation fixe le périmètre légal ; les cadres volontaires aident les équipes à gérer les risques liés à l’IA en pratique.

Règlement de l’UE sur l’IA

Le Règlement de l’UE sur l’IA classe les systèmes d’IA en fonction du risque qu’ils peuvent présenter pour les droits fondamentaux, la sécurité et les valeurs sociétales. Cette classification détermine les obligations applicables. La gestion des risques liés au Règlement de l’UE sur l’IA ne commence donc pas par le nom d’un outil, mais par son cas d’usage précis.

Cadre de gestion des risques liés à l’IA du NIST (AI RMF 1.0)

Le cadre de gestion des risques liés à l’IA du NIST a été publié en 2023 par le National Institute of Standards and Technology aux États-Unis. Il s’agit d’un cadre volontaire, souvent utilisé comme référence pratique, car il est neutre sur le plan technologique et peut s’appliquer à des organisations de différentes tailles.

Pour résumer le cadre de gestion des risques liés à l’IA du NIST, il faut partir de la structure de base du référentiel, l’AI RMF Core. Celui-ci s’articule autour de quatre fonctions : Gouverner, Cartographier, Mesurer et Gérer.

Gouverner

La fonction « Gouverner » définit la manière dont les responsabilités en matière de risques liés à l’IA sont attribuées au sein de l’organisation. Elle comprend les processus d’approbation, les politiques et les attentes vis-à-vis des collaborateurs. Elle couvre aussi une question concrète : dans quelle mesure les équipes sont-elles préparées à utiliser l’IA au quotidien ? La formation, et notamment les formations de sensibilisation structurées, relèvent de cette fonction, car les collaborateurs influencent les données qui entrent dans les systèmes d’IA, la manière dont les sorties sont utilisées et le moment où les alertes sont signalées et remontées.

Cartographier

La fonction « Cartographier » donne de la visibilité sur les usages de l’IA dans l’organisation. Elle consiste à recenser les systèmes d’IA, à comprendre leur contexte d’utilisation et à identifier les parties prenantes concernées. À ce stade, de nombreuses organisations constatent que l’IA est déjà plus utilisée en interne qu’elles ne le pensaient.

Mesurer

La fonction « Mesurer » évalue la probabilité qu’un risque se concrétise et la gravité de son impact potentiel. Cette évaluation ne doit pas être réalisée une seule fois. Les systèmes d’IA évoluent, tout comme leur environnement. La gestion des risques liés à l’IA doit tenir compte de cette réalité.

Gérer

La fonction « Gérer » transforme les évaluations en actions : réduire les risques, les accepter, les transférer ou continuer à les surveiller. Les responsabilités et les contrôles doivent être clairement définis. Le tableau de bord de gestion du risque humain de SoSafe favorise cette démarche en donnant une visibilité continue sur le facteur de risque humain dans ce processus.

Pour les équipes qui connaissent déjà le cadre de cybersécurité du NIST, la logique de l’AI RMF peut sembler relativement familière.

ISO/IEC 23894:2023 et ISO/IEC 42001

Les organisations qui travaillent déjà avec la norme ISO 27001 disposent d’une base utile pour la sécurité de l’information. L’IA ajoute des questions auxquelles la norme ISO 27001 seule ne répond pas entièrement : comment un modèle se comporte, quelles données l’ont façonné, comment les décisions sont examinées et quel niveau de transparence est nécessaire. Deux normes ISO peuvent aider à étendre les structures existantes à l’IA.

ISO/IEC 23894:2023

La norme ISO/IEC 23894 est un guide pour le management du risque lié à l’IA. Elle décrit de manière structurée comment les organisations peuvent identifier, consigner et gérer les risques liés à l’IA. Ce guide s’appuie sur les principes de la norme ISO 31000. ll n’est pas certifiable, mais fournit aux équipes une méthode plus claire pour analyser les risques liés à l’IA.

ISO/IEC 42001

La norme ISO/CEI 42001 définit les exigences relatives à un système de management de l’IA et est certifiable. Sa structure suit la logique familière des systèmes de management ISO, ce qui peut faciliter son intégration pour les organisations qui travaillent déjà avec des normes ISO. Pour les équipes qui utilisent ISO 27001, les recoupements sont concrets : gestion des risques, documentation, audits internes et contrôles associés.

Du point de vue d’un RSSI

En pratique, il ne s’agit pas de choisir entre ISO/IEC 42001 et ISO 27001. Les systèmes d’IA traitent souvent des données sensibles, se connectent à des systèmes internes et influencent les décisions. La norme ISO 27001 couvre déjà une partie de ce périmètre. Le volet spécifique à l’IA ajoute des questions sur le comportement des modèles, les données d’entraînement, la transparence et la supervision humaine. La norme ISO/IEC 42001 définit la structure du système de management correspondante, tandis que la norme ISO/IEC 23894 apporte une méthode de gestion des risques.

Composants clés de la gestion des risques liés à l’IA

Un cadre apporte une structure. Ce qui compte dans les opérations quotidiennes, ce sont les processus qui permettent de l’appliquer. Quel que soit le cadre choisi par une organisation, plusieurs éléments se retrouvent dans toute approche efficace de gestion des risques liés à l’IA.

Surveillance continue

La dérive d’un modèle se manifeste rarement d’un seul coup. Les données changent, le comportement des utilisateurs se modifie et les marchés évoluent. Un modèle peut donc commencer à produire des résultats moins performants même s’il continue de fonctionner sans erreur technique. Une surveillance automatisée, avec des seuils définis et des procédures claires de remontée d’information, doit faire partie intégrante du modèle opérationnel, et pas seulement de la planification du projet.

Documentation et traçabilité

Un outil d’IA peut entrer rapidement dans un processus : un compte de test, un premier cas d’usage, des résultats initiaux. Quelques mois plus tard, au cours d’un audit, on peut demander qui a approuvé l’outil, quelles données ont été utilisées et si les résultats ont été vérifiés.

L’absence de réponses claires peut alors entraîner un risque de non-conformité en matière d’IA. Les preuves sont importantes, en particulier dans le contexte du Règlement de l’UE sur l’IA. Une bonne documentation commence dès le premier cas d’usage, et non pas juste avant un audit.

Gouvernance des systèmes autonomes

Les systèmes d’IA autonomes peuvent faire bien plus que fournir des réponses. Certains peuvent déplacer des tickets, rédiger des e-mails, déclencher des tâches ou extraire des données d’autres systèmes. Une seule décision erronée peut rapidement déclencher un enchaînement de processus.

Ces systèmes ont besoin de garde-fous concrets. Que peut faire l’agent de son propre chef ? Quand a-t-il besoin d’une autorisation ? Qui peut voir ce qui se passe ? Et qui peut intervenir avant qu’une erreur n’en entraîne plusieurs autres ?

Le facteur humain

La technologie et les processus ne suffisent pas à eux seuls. Ce sont les collaborateurs qui choisissent les outils d’IA qu’ils utilisent, les données qu’ils saisissent et qui décident de remettre, ou non, les résultats en question. Le tableau de bord de gestion du risque humain de SoSafe aide les organisations à développer un pare-feu humain et à mettre en évidence le facteur de risque humain dans la gestion des risques liés à l’IA.

Quel cadre de gestion des risques liés à l’IA choisir ?

Le bon cadre dépend du contexte. L’environnement réglementaire, la maturité de l’utilisation de l’IA et les structures existantes jouent tous un rôle. Le tableau ci-dessous constitue un point de départ pour la discussion, et ne remplace pas une évaluation individuelle.

Ces approches ne s’excluent pas mutuellement. De nombreuses organisations utilisent l’AI RMF du NIST pour structurer les risques et la norme ISO/IEC 42001 pour construire un système de management de l’IA. Le Règlement de l’UE sur l’IA fournit le cadre juridique sur lequel les deux approches peuvent s’aligner.

La bonne combinaison dépend de l’organisation :

• La maturité des processus de gestion des risques existants
• Les systèmes d’IA actuellement utilisés
• Les obligations réglementaires applicables
• Le temps, le budget et l’expertise disponibles pour la mise en œuvre

Mise en œuvre d’un cadre de gestion

Les entreprises devraient commencer la mise en œuvre en s’appuyant sur les structures déjà en place : gestion des risques, sécurité de l’information, protection des données et processus d’approbation internes. À partir de là, la gestion des risques liés à l’IA peut s’intégrer aux processus existants plutôt que de constituer un projet supplémentaire distinct.

1. Inventaire

Commencez par une question simple : quels sont les systèmes d’IA réellement utilisés ? Les systèmes acquis officiellement ne représentent qu’une partie de l’ensemble. Les comptes de test, les outils accessibles depuis un navigateur, les pilotes et les solutions mises en place au niveau des services doivent aussi figurer dans l’inventaire.

C’est souvent à ce stade que le Shadow IA devient visible. Les équipes utilisent l’IA parce qu’elle leur fait gagner du temps, et non parce qu’elles cherchent à contourner la gouvernance. Pour la gestion des risques liés à l’IA, la réponse doit néanmoins être claire : les systèmes inconnus ne peuvent être ni évalués, ni approuvés, ni sécurisés.

2. Clarifier les catégories de risque et la réglementation

Une fois l’inventaire réalisé, les systèmes doivent être classés. Un système relève-t-il du Règlement de l’UE sur l’IA ? S’agit-il d’un système à haut risque ? Des exigences liées à une réglementation sectorielle, à la protection des données ou à des politiques internes s’appliquent-elles ?

Ces questions déterminent le niveau d’examen, de documentation et de contrôle qui peut être nécessaire.

3. Choisir et adapter le cadre

Aucun cadre ne sera parfaitement adapté tel quel. L’AI RMF du NIST aide les équipes à structurer les risques liés à l’IA. La norme ISO/IEC 42001 décrit un système de management de l’IA. Les organisations qui travaillent avec la norme ISO 27001 peuvent souvent s’appuyer sur des rôles, des processus et des contrôles déjà en place.

4. Intégrer la gouvernance

Un cadre de gestion des risques liés à l’IA nécessite des responsabilités clairement assignées, et non pas seulement une responsabilité générale. L’approbation ne peut pas incomber à « l’entreprise » de manière abstraite. L’examen des résultats doit également être attribué à un responsable clairement identifié. Il en va de même lorsqu’il faut interrompre un cas d’usage parce que le profil de risque évolue.

Les collaborateurs ont également besoin de règles et de formations qui reflètent des situations de travail réelles.

5. Surveillance et amélioration continue

L’utilisation de l’IA évolue après la mise en service. Les équipes trouvent des raccourcis, les fournisseurs publient des mises à jour et les données ne ressemblent plus exactement à ce qu’elles étaient lors des tests.

Des revues opérationnelles régulières font donc partie intégrante de la gestion des risques liés à l’IA. En fonction de leurs conclusions, l’étape suivante peut consister à renforcer le processus d’approbation, à effectuer un contrôle technique, à clarifier les consignes ou à proposer une formation complémentaire.