Qu’est-ce que la gestion des risques liés à l’IA ?
La gestion des risques liés à l'IA est un processus structuré et reproductible qu'une organisation utilise pour identifier, évaluer, traiter et surveiller les risques découlant du développement, de la fourniture ou de l'utilisation de systèmes d'IA. Elle couvre l'intégralité du cycle de vie d'un système d'IA, depuis la définition du problème et l'acquisition des données jusqu'à la conception, la validation, le déploiement et la mise hors service du modèle.
Contrairement à la gestion traditionnelle des risques liés à la sécurité de l'information, qui se concentre principalement sur la confidentialité, l'intégrité et la disponibilité des informations, la gestion des risques liés à l'IA doit prendre en compte un ensemble de préoccupations plus large. Les biais des modèles, le manque d'explicabilité, la dérive des données, le mauvais usage des résultats, l'impact sociétal et le comportement des modèles de fondation tiers font tous partie intégrante de ce champ d'application. C'est pourquoi ISO 42001 nécessite un processus d'évaluation des risques liés à l'IA dédié, plutôt que d'intégrer les risques liés à l'IA dans un registre de sécurité informatique existant.
Concrètement, la gestion des risques liés à l'IA répond à quatre questions pour chaque cas d'utilisation de l'IA en entreprise :
- Quels problèmes pourraient survenir avec ce système d'IA, pour qui et à quel point ?
- Quelle est la probabilité de chacun de ces résultats compte tenu des contrôles dont nous disposons déjà ?
- Que pouvons-nous faire face aux risques qui dépassent notre seuil de tolérance ?
- Comment saurons-nous, après déploiement, si notre évaluation est toujours valable ?
Bien fait, cela donne au tableau, le comité de gouvernance de l'IAet aux équipes d'ingénierie une vision partagée des initiatives d'IA qui peuvent être menées en toute sécurité, de celles qui nécessitent des contrôles supplémentaires et de celles qui devraient être suspendues ou redéfinies.
Comment la norme ISO 42001 gère-t-elle les risques liés à l'IA (article 6.1.2 vs article 6.1.4) ?
La norme ISO 42001 distingue deux activités liées mais distinctes dans la gestion des risques liés à l'IA, et les confondre constitue l'une des erreurs de mise en œuvre les plus fréquentes.
Article 6.1.2 — Évaluation des risques liés à l'IA. Il s'agit de l'approche traditionnelle d'analyse des risques, centrée sur l'organisation elle-même. On identifie les risques liés à l'IA, on analyse leur probabilité et leurs conséquences au regard des critères de risque de l'organisation, et on décide des mesures à prendre. C'est ce processus qui alimente le registre des risques liés à l'IA.
Article 6.1.4 — Évaluation de l’impact du système d’IA. Il s'agit d'une approche tournée vers l'extérieur. Elle évalue l'impact potentiel d'un système d'IA sur les individus, les groupes d'individus et la société, en abordant les questions d'équité, de sécurité, de contrôle humain et de droits fondamentaux. L'annexe A.5 définit les mécanismes de contrôle permettant de mettre en œuvre cette approche. Des instructions détaillées sont disponibles dans notre guide dédié. Évaluations d'impact de l'IA .
Les deux sont normatifs. Les deux doivent être documentés. Les deux alimentent votre Déclaration d'applicabilité et Politique d'IAMais elles répondent à des questions différentes, reposent sur des données différentes et impliquent généralement des parties prenantes différentes. Les mener comme un seul exercice combiné tend à occulter l'impact sociétal, qui est pourtant précisément ce que recherchent les auditeurs et les organismes de réglementation.
Les orientations normatives pour les deux activités se trouvent dans Annexe B – OrientationsL’annexe C fournit des indications utiles sur les sources de risques liés à l’IA, ce qui constitue une taxonomie de départ précieuse lors de la constitution de votre registre.
Quel est le lien avec les risques liés à la sécurité de l'information (ISO 27005) ?
La gestion des risques liés à l'IA ne remplace pas la gestion des risques liés à la sécurité de l'information. De nombreux systèmes d'IA stockent, traitent ou transmettent des données personnelles et sont hébergés sur la même infrastructure que d'autres charges de travail réglementées. La norme ISO 27005 demeure la référence pour le processus d'évaluation des risques en sécurité de l'information. Le modèle pratique est le suivant :
- Les risques liés à la sécurité de l'information concernant le système d'IA (confidentialité, intégrité, disponibilité des données d'entraînement, artefacts du modèle, API) sont consignés dans le registre des risques ISO 27001.
- Les risques spécifiques à l'IA (biais, explicabilité, dérive, utilisation non intentionnelle, préjudice sociétal) figurent dans le registre des risques liés à l'IA en vertu de la clause 6.1.2.
- Les références croisées relient les deux afin qu'un seul événement à risque puisse être suivi à travers les deux perspectives sans duplication.
Le déficit de gouvernance de l'IA C’est précisément le lien entre la sécurité de l’information et la gouvernance de l’IA que la clause 6.1.2 de la norme ISO 42001 vise à combler.
Où se situe le NIST AI RMF ?
Le cadre de gestion des risques liés à l'IA du NIST est un cadre américain volontaire organisé autour de quatre fonctions : Gouverner, Cartographier, Mesurer et Gérer. Il est complémentaire à la norme ISO 42001 et non concurrent. Les organisations utilisant déjà le cadre de gestion des risques liés à l'IA du NIST peuvent faire correspondre ses fonctions directement aux articles de la norme ISO 42001 (Gouverner correspond aux articles 4 et 5, Cartographier à l'article 6.1, Mesurer à l'article 9 et Gérer aux articles 8 et 10). Si votre système est destiné à un public international, la norme ISO 42001 vous offre un système de management certifiable. Le cadre de gestion des risques liés à l'IA du NIST vous fournit un vocabulaire largement reconnu et des guides pratiques pour les activités sous-jacentes.
Tout ce dont vous avez besoin pour ISO 42001
Contenu structuré, risques cartographiés et flux de travail intégrés pour vous aider à gouverner l'IA de manière responsable et en toute confiance.
Quelles sont les principales catégories de risques liés à l'IA ?
Une taxonomie pertinente des risques liés à l'IA vous évite d'omettre des catégories entières de risques. L'annexe C de la norme ISO 42001 fournit une liste informative des sources de risques liés à l'IA, que la plupart des organisations adaptent à leur contexte. En pratique, huit catégories couvrent la grande majorité des risques liés à l'IA, et la plupart des entrées de votre registre correspondent à une ou plusieurs d'entre elles.
| Catégories | Exemple | Contrôle(s) ISO 42001 | Traitement typique |
|---|---|---|---|
| Parti pris et équité | Le modèle de notation de crédit sous-estime systématiquement un groupe protégé | A.6.2.2, A.6.2.4, A.7.4 | Atténuer les risques grâce à des données d'entraînement équilibrées, des tests d'équité et une vérification humaine. |
| Explicabilité et transparence | Le modèle de triage médical ne peut justifier ses recommandations aux cliniciens | A.6.2.4, A.8.2, A.8.3 | Atténuer les problèmes grâce à des modèles interprétables, de la documentation et des fiches modèles. |
| Sécurité | Une attaque par injection rapide permet d'exfiltrer des données confidentielles d'un LLM. | A.6.2.3, A.7.3, A.8.4 | Atténuer les risques grâce à la validation des entrées, des garde-fous et la modélisation des menaces. |
| Politique de confidentialité | Les données d'entraînement contiennent des données personnelles utilisées sans fondement légal. | A.7.2, A.7.4, A.8.2 | Atténuer les risques par la minimisation des données, l'anonymisation et l'alignement sur l'analyse d'impact relative à la protection des données (AIPD). |
| Sécurité | Un système autonome peut causer des dommages physiques par un comportement inattendu. | A.6.2.4, A.9.3, A.9.4 | Atténuer les risques par la validation, le déploiement progressif, les interrupteurs d'arrêt d'urgence et la supervision humaine. |
| Sociétal | Le modèle de modération de contenu amplifie la désinformation ou supprime les discours légitimes. | A.5.2, A.5.3, A.5.4 | Atténuer les risques par le biais d'une évaluation d'impact, de la mobilisation des parties prenantes et d'un examen continu |
| Efficacité | La dérive du modèle entraîne une dégradation de la précision des prévisions après six mois de production. | A.6.2.6, A.6.2.7, A.6.2.8 | Atténuer les risques grâce à la surveillance, au réentraînement des déclencheurs et aux seuils de performance. |
| Supply chain | Le fournisseur du modèle de base modifie son comportement sans avertissement, ce qui perturbe un cas d'utilisation en aval. | A.10.2, A.10.3, A.10.4 | Atténuer les risques grâce à une vérification préalable des fournisseurs, des contrats et des fournisseurs de secours. |
La plupart des organisations adoptent cette taxonomie comme base de leur registre des risques liés à l'IA, puis y ajoutent des catégories spécifiques à leur secteur (par exemple, les services financiers ajoutent la gestion des risques liés aux modèles dans le cadre de la norme SR 11-7, et le secteur de la santé, la sécurité clinique). L'essentiel est que chaque cas d'utilisation de l'IA soit examiné au regard de chaque catégorie, même brièvement, afin d'éviter tout risque non identifié.
Comment réaliser une évaluation des risques liés à l'IA ?
Le processus d'évaluation décrit à l'article 6.1.2 suit le cycle PDCA (Planifier-Déployer-Contrôler-Améliorer) classique des systèmes de management ISO, mais avec des apports spécifiques à l'IA à chaque étape. Cette méthode pratique et reproductible comporte six étapes.
Étape 1 : Définir le périmètre et les critères de risque
Avant toute évaluation, définissez ce qui constitue un système d'IA au sein de votre organisation (cette définition devrait déjà figurer dans votre documentation). Système de gestion de l'IA (AIMS) (Énoncé de portée) et les critères de risque que vous utiliserez. Les critères de risque comprennent vos échelles de probabilité et de conséquence, votre seuil d'acceptation du risque et les catégories de conséquences qui vous importent (financières, opérationnelles, réglementaires, de réputation, de sécurité, sociétales).
Étape 2 : Identifier les cas d’utilisation et les ressources en IA
Recensez tous les systèmes d'IA concernés. Pour chacun d'eux, consignez l'usage prévu, les données d'entrée, le type de modèle (propriétaire, optimisé, modèle de base tiers), les utilisateurs, les parties prenantes, l'environnement de déploiement et le niveau de criticité. Cet inventaire constitue la base du reste du processus.
Étape 3 : Identifier les risques à l'aide de la taxonomie
Analysez chaque système d'IA selon les huit catégories de risques mentionnées ci-dessus. Utilisez les sources de risques de l'annexe C, les techniques de modélisation des menaces et un brainstorming structuré avec un groupe pluridisciplinaire (science des données, ingénierie, sécurité, juridique, produit et, le cas échéant, l'unité commerciale qui utilisera les résultats). Décrivez chaque risque comme un événement spécifique avec une cause et une conséquence, et non comme une étiquette générique.
Étape 4 : Analyser la probabilité et la conséquence
Évaluez chaque risque selon vos critères. La probabilité doit tenir compte de l'environnement de contrôle actuel, et non de l'état non contrôlé. Les conséquences doivent prendre en compte toutes les parties concernées, et pas seulement l'organisation ; c'est là que le lien avec l'analyse d'impact prévue à la clause 6.1.4 est essentiel. Documentez votre raisonnement ; un auditeur vous demandera comment vous avez obtenu une note élevée ou faible.
Étape 5 : Évaluation par rapport aux critères de risque
Reportez chaque risque sur votre matrice et comparez-le à votre seuil d'acceptation du risque. Tout risque supérieur à ce seuil nécessite une décision thérapeutique. Tout risque égal ou inférieur à ce seuil peut être accepté avec une justification explicite consignée dans le registre.
Étape 6 : Documenter et réviser
Le registre des risques liés à l'IA est un document d'information conforme à la clause 7.5. Il nécessite des responsables, des cycles de révision, un historique des versions et une approbation. Il alimente directement le système. Déclaration d'applicabilité — Les contrôles de l’annexe A sont sélectionnés et justifiés en fonction des risques figurant dans ce registre.
Comment gérez-vous les risques liés à l'IA ?
Pour chaque risque supérieur à votre seuil d'acceptation, la clause 6.1.3 exige une décision de traitement. Les quatre options classiques s'appliquent, avec des nuances spécifiques à l'IA :
- Éviter Ne pas concevoir, déployer ni utiliser le système d'IA. Son utilisation est appropriée lorsque le risque résiduel est inacceptable, même avec des contrôles rigoureux (par exemple, un cas d'utilisation qui automatise une décision ayant un impact juridique important sur les individus sans intervention humaine).
- Atténuer. Mettre en œuvre des mesures de contrôle pour réduire la probabilité, la conséquence, ou les deux. Il s'agit du traitement le plus courant. Les mesures de contrôle sont issues de Contrôles de l'Annexe ACes mesures sont complétées par des dispositions spécifiques au secteur ou au cas d'usage. Les mesures d'atténuation typiques comprennent des données d'entraînement équilibrées, des tests d'équité, des garde-fous pour les entrées et les sorties, une supervision humaine, un déploiement progressif et une surveillance continue.
- Transfert. Transférer le risque par le biais de contrats, d'assurances ou de la responsabilité du fournisseur. Utile pour les risques liés à la chaîne d'approvisionnement (par exemple, les SLA contractuels avec un fournisseur de modèle de fondation), mais attention : on peut transférer la responsabilité financière, mais rarement la responsabilité, notamment vis-à-vis des organismes de réglementation.
- Accepter Conserver le risque avec une justification explicite et documentée, et un responsable désigné. Convient uniquement aux risques égaux ou inférieurs au seuil d'acceptation, ou lorsque le traitement s'avère manifestement non rentable et que les conséquences sont limitées.
Chaque décision de traitement doit comporter un responsable désigné, une date cible et une preuve de réalisation consignée dans le registre. Un plan de traitement sans preuve d'exécution constitue l'une des non-conformités les plus fréquentes lors des audits de certification ISO 42001.
Démarrez facilement avec une démonstration de produit personnelle
L'un de nos spécialistes de l'intégration vous guidera à travers notre plateforme pour vous aider à démarrer en toute confiance.
Comment surveiller les risques liés à l'IA après son déploiement ?
Le risque lié à l'IA n'est pas statique. Un modèle sûr au lancement peut devenir vulnérable six mois plus tard en raison de la dérive des données, de l'évolution des comportements des utilisateurs, des changements de l'environnement réglementaire ou de la mise à jour du modèle sous-jacent. L'évaluation des performances (article 9) et les contrôles de surveillance opérationnelle (annexes A.6.2.6 à A.6.2.8) exigent une surveillance continue.
Un programme de suivi pragmatique comporte cinq signaux :
- Performances du modèle. Les indicateurs de précision, de rappel, d'étalonnage et d'équité sont comparés aux seuils définis lors du déploiement. Tout dépassement entraîne un réentraînement ou une restauration.
- Dérive des données. Comparaison statistique des distributions des données d'entrée de production avec les distributions d'entraînement. Une dérive significative entraîne une évaluation de la pertinence du modèle.
- Incidents et quasi-accidents. Un canal formel permettant aux utilisateurs, aux parties concernées et au personnel interne de signaler les problèmes liés à l'IA, avec triage, analyse des causes profondes et enregistrement des mesures correctives conformément à la clause 10.
- Efficacité du contrôle. Des vérifications périodiques sont nécessaires pour s'assurer de l'efficacité des mesures d'atténuation prévues dans le plan de traitement. L'annexe A.6.2.6 exige explicitement la vérification des contrôles opérationnels.
- Contexte externe. Nouvelle réglementation, nouveaux types de menaces, évolution des modèles de tiers et émergence de meilleures pratiques : tous ces éléments sont intégrés à l’évaluation des risques lors de chaque revue périodique.
Les résultats alimentent la revue de direction (article 9.3) et permettent de mettre à jour le registre des risques, la déclaration d'applicabilité et la politique en matière d'IA. Ce cycle est continu et non annuel.
Comment ISMS.online structure-t-il la gestion des risques liés à l'IA ?
ISMS.en ligne Il fournit un environnement spécialement conçu pour l'ensemble du processus de gestion des risques liés à l'IA, conforme à la clause 6.1.2 et aux directives normatives de l'annexe B. Vous obtenez un registre des risques liés à l'IA intégré au reste de votre système de gestion des risques liés à l'IA plutôt que d'être stocké dans une feuille de calcul séparée.
La plateforme vous offre :
- Un registre des risques dédié à l'IA distinct de votre registre des risques liés à la sécurité de l'information, avec des champs pour les attributs spécifiques à l'IA (cas d'utilisation, sources de données, type de modèle, parties concernées, catégorie de risque) ainsi que des champs standard de probabilité, de conséquence, de traitement et de responsable
- Une taxonomie des risques liés à l'IA préchargée couvrant les huit catégories ci-dessus ainsi que les sources de risques de l'annexe C, les équipes commencent donc avec une liste exhaustive plutôt qu'une page blanche.
- Évaluations d'impact des systèmes d'IA liés pour la clause 6.1.4, de sorte que la vision de l'impact externe reste connectée à la vision du risque organisationnel sans duplication
- liaison de contrôle direct de chaque risque aux contrôles pertinents de l'annexe A, en passant par les preuves démontrant le traitement, jusqu'à la déclaration d'applicabilité
- Examiner les flux de travail et les rappels automatisés Les risques sont donc évalués selon leur cycle défini, et non pas lorsqu'on s'en souvient.
- Référence croisée avec les risques de la norme ISO 27001 lorsqu'un événement comporte à la fois des dimensions de sécurité de l'information et d'IA, afin d'éviter les doubles comptages et les plans de traitement contradictoires
- Rapports d'opinion pour le conseil d'administration, le comité de gouvernance de l'IA et les auditeurs de certification, à partir des mêmes données sous-jacentes
Il en résulte un processus de gestion des risques liés à l'IA qu'un auditeur peut parcourir de bout en bout en moins de dix minutes, et que l'organisation peut effectivement mettre en œuvre entre deux audits.
Pourquoi choisir ISMS.online pour la gestion des risques liés à l'IA ?
La plupart des outils GRC considèrent le risque lié à l'IA comme une simple formalité ajoutée après coup à un modèle de sécurité de l'information. ISMS.en ligne a été conçu en intégrant la gouvernance de l'IA comme fonctionnalité de premier plan. Voici ce que cela signifie concrètement :
- Registres distincts mais connectés. Les risques liés à l'IA (clause 6.1.2), l'évaluation de l'impact du système d'IA (clause 6.1.4) et les risques liés à la sécurité de l'information (ISO 27005) sont inscrits dans des registres distincts mais référencés, de sorte que chaque perspective reste claire tandis que les données sont partagées là où elles doivent l'être.
- Taxonomie des risques liés à l'IA préétablie. Les sources de risques de l'annexe C et le modèle à huit catégories sont préchargés, ce qui permet à votre équipe d'identifier les risques par rapport à un cadre structuré plutôt que d'en inventer un.
- Cartographie en direct Contrôles de l'Annexe A. Chaque risque est directement lié aux mesures de contrôle qui le traitent, aux preuves qui démontrent l'efficacité du traitement et à la mention dans la déclaration d'applicabilité qui le justifie.
- Conçu conformément aux directives de l'annexe B. Le flux de travail suit les directives de mise en œuvre normatives de l'annexe B, votre processus est donc aligné sur les normes par défaut plutôt que de nécessiter une configuration sur mesure.
- Intégré au système AIMS complet. Les risques sont liés à votre Politique d'IA, vos évaluations d’impact, votre programme d’audit (article 9.2) et vos actions correctives (article 10), afin que rien ne passe entre les mailles du filet.
- Méthode de résultats assurés. Une méthode de mise en œuvre éprouvée et un soutien humain qui ont permis à des centaines d'organisations d'obtenir leur certification dès la première fois, grâce à une gestion des risques liés à l'IA intégrée dès le départ plutôt qu'ajoutée tardivement.
Que vous soyez en train de créer votre premier registre des risques liés à l'IA ou de faire évoluer un registre existant, ISMS.en ligne vous fournit la structure et les outils nécessaires pour exploiter la clause 6.1.2 comme un processus évolutif. Pour un contexte plus large, consultez notre guide de mise en œuvre.
Prêts à voir la plateforme en action ? Demander demo.
FAQ
Quelle est la différence entre l'évaluation des risques liés à l'IA (article 6.1.2) et l'évaluation de l'impact du système d'IA (article 6.1.4) ?
La clause 6.1.2 porte sur l'analyse des risques internes à l'organisation : quels problèmes pourraient affecter l'organisation, ses objectifs et ses opérations, et comment y remédier ? La clause 6.1.4, quant à elle, porte sur l'analyse des risques externes : quel impact le système d'IA pourrait-il avoir sur les individus, les groupes et la société, notamment en matière d'équité, de sécurité et de droits fondamentaux ? Ces deux analyses sont normatives, doivent être documentées et sont interdépendantes. Les mener conjointement conduit généralement à négliger l'analyse de l'impact sociétal, ce qui constitue une constatation fréquente lors des audits.
Puis-je réutiliser mon registre des risques ISO 27001 pour la gestion des risques liés à l'IA ?
Non, pas sous la forme d'un registre unique et combiné. Les risques liés à la sécurité de l'information (ISO 27005) et les risques liés à l'IA (ISO 42001, article 6.1.2) ont des périmètres qui se chevauchent mais restent distincts. La sécurité de l'information couvre la confidentialité, l'intégrité et la disponibilité des informations. Les risques liés à l'IA couvrent en outre les biais, l'explicabilité, la dérive, la sécurité et l'impact sociétal – des problématiques qui ne s'intègrent pas facilement dans un modèle CIA. La solution optimale consiste en deux registres interconnectés, avec des références croisées, où un même événement englobe les deux dimensions. ISMS.en ligne soutient précisément cet arrangement.
Le référentiel NIST AI RMF est-il une alternative à la norme ISO 42001 pour la gestion des risques ?
Ces deux référentiels sont complémentaires, et non alternatifs. Le NIST AI RMF est un cadre de référence américain volontaire, structuré autour des fonctions Gouverner, Cartographier, Mesurer et Gérer, et accompagné d'excellents guides pratiques. L'ISO 42001 est une norme de système de management certifiable à l'échelle internationale. Les organisations utilisent souvent le vocabulaire et les guides pratiques du NIST AI RMF pour mettre en œuvre les activités requises par l'ISO 42001. Les deux référentiels se complètent parfaitement et de nombreuses organisations les mettent en œuvre simultanément.
Quelles catégories de risques liés à l'IA dois-je inclure dans mon registre ?
Au minimum : biais et équité, explicabilité et transparence, sécurité, confidentialité, sûreté, impact sociétal, aspects opérationnels (dérive, performance, disponibilité) et chaîne d’approvisionnement (modèles tiers, fournisseurs de données). L’annexe C de la norme ISO 42001 fournit une liste informative des sources de risques liés à l’IA, conforme à cette taxonomie. Des catégories sectorielles, telles que la gestion des risques liés aux modèles pour les services financiers ou la sécurité clinique pour les soins de santé, doivent être ajoutées le cas échéant.
À quelle fréquence dois-je consulter le registre des risques liés à l'IA ?
Un examen complet doit être effectué au moins une fois par an, alimentant la revue de direction prévue à la clause 9.3. Chaque risque doit faire l'objet d'un cycle d'examen spécifique, déterminé par sa criticité : généralement trimestriel pour les risques élevés et semestriel pour les risques moyens. Tout changement significatif doit déclencher un examen ad hoc : nouveau cas d'usage de l'IA, mise à jour importante d'un modèle, nouvelle réglementation, incident signalé ou changement de prestataire tiers clé. Le registre est un document évolutif, et non un simple document de conformité annuel.
La norme ISO 42001 exige-t-elle une surveillance automatisée des risques liés à l'IA ?
La norme n'impose pas l'automatisation, mais exige une surveillance continue des performances et de l'efficacité des contrôles des systèmes d'IA (article 9.1 et annexes A.6.2.6 à A.6.2.8). Pour tout système d'IA présentant un risque plus élevé que quelques-uns, la surveillance automatisée des performances des modèles, de la dérive des données et de l'efficacité des contrôles est, en pratique, la seule façon de satisfaire à cette exigence. La surveillance manuelle à grande échelle tend à produire des données obsolètes et à passer à côté d'incidents, qui se traduisent par des non-conformités lors des audits de surveillance.
Qui devrait être responsable de la gestion des risques liés à l'IA au sein de l'organisation ?
La responsabilité incombe à un cadre dirigeant désigné, généralement le RSSI, le directeur des risques ou un responsable dédié à la gouvernance de l'IA, selon la taille de l'organisation et son niveau de maturité en matière d'IA. La gestion quotidienne est assurée par un comité de gouvernance de l'IA ou un groupe transversal équivalent, composé de représentants des services de science des données, d'ingénierie, de sécurité, juridiques, de protection des données et des unités opérationnelles utilisant l'IA. Chaque risque a un responsable désigné, chargé de son traitement et de son suivi. L'article 5.3 exige que ces rôles, responsabilités et pouvoirs soient formellement attribués et communiqués.
