ISO 42001, NIST AI RMF et AI Act : articuler les rôles

La gouvernance de l’IA peut combiner un système de management, un cadre de gestion des risques et des obligations légales. Le défi pour l’ingénierie consiste à les relier sans prétendre qu’ils sont interchangeables. Une politique, un rapport d’évaluation et une décision de classification juridique peuvent concerner le même service d’IA, mais chacun répond à une question différente.

L’ISO/IEC 42001 établit la manière dont une organisation gère l’IA. Le cadre de gestion des risques liés à l’IA du NIST (AI Risk Management Framework) aide les équipes à examiner et à gérer les risques dans leur contexte. Le règlement européen sur l’intelligence artificielle (AI Act) fixe des obligations légales en fonction du système, de sa destination et du rôle d’opérateur de l’organisation.

Pour un CTO, le résultat utile est une chaîne de gouvernance unique et vérifiable : un cas d’usage défini, des responsables identifiés, des garde-fous mis en œuvre, des preuves de tests, des décisions de mise en production et une surveillance. Les correspondances entre référentiels doivent renvoyer à cette chaîne tout en conservant les exigences qui nécessitent encore un travail technique, juridique ou lié à la conformité.

Comprendre ce que chaque instrument établit

ISO 42001 : rendre la gouvernance reproductible

L’ISO/IEC 42001 spécifie les exigences relatives à l’établissement, à la mise en œuvre, à la tenue à jour et à l’amélioration continue d’un AIMS. Ses exigences de système de management couvrent le contexte de l’organisation, le leadership, la planification, le support, les activités opérationnelles, l’évaluation des performances et l’amélioration.

Cette structure compte lorsque plusieurs équipes développent ou achètent de l’IA. Elle fournit une base pour décider qui autorise le déploiement, comment les analyses d’impact et de risques sont menées, comment les dépendances envers les fournisseurs sont gérées et comment les défaillances donnent lieu à des actions correctives.

La norme comprend également des mesures de référence à l’annexe A ainsi que des recommandations de mise en œuvre. La sélection des mesures repose sur les risques et exige une justification documentée ; recopier l’annexe dans une liste de contrôle n’établit pas que le système de management fonctionne.

Un organisme de certification indépendant peut évaluer l’AIMS dans son périmètre. L’ISO elle-même ne certifie pas les organisations. La certification apporte une assurance sur ce système de management dans les limites déclarées, et non une affirmation sans réserve selon laquelle chaque modèle ou chaque résultat est sûr.

NIST AI RMF : examiner le risque réel

Le NIST AI RMF organise le travail sur les risques autour de quatre fonctions : Govern, Map, Measure et Manage. Govern est transversale ; ces fonctions ne constituent pas simplement quatre phases de projet successives.

Ses caractéristiques de fiabilité comprennent la validité et la fiabilité, la sûreté, la sécurité et la résilience, la responsabilité et la transparence, l’explicabilité et l’interprétabilité, la protection renforcée de la vie privée, ainsi que l’équité avec maîtrise des biais préjudiciables. Ces caractéristiques peuvent impliquer des arbitrages. Des explications plus détaillées, par exemple, peuvent divulguer des informations qui doivent être protégées au titre de la vie privée.

Les lignes directrices du NIST aident les équipes à traduire des objectifs généraux en questions et évaluations propres à chaque cas d’usage. Elles traitent aussi de la responsabilité ; la gouvernance n’est pas l’apanage de l’ISO 42001. Il n’existe pas de schéma de certification NIST AI RMF comparable à la certification ISO des systèmes de management. Une évaluation externe peut contribuer à l’assurance, mais son périmètre et sa méthodologie doivent être précisés.

L’AI Act : déterminer les obligations, pas seulement les risques

L’AI Act de l’UE encadre, au moyen de dispositions distinctes, certaines pratiques, les systèmes d’IA et les modèles d’IA à usage général. L’applicabilité juridique ne se détermine pas à partir d’un seul score de risque technique. La destination, le champ d’application territorial, le rôle d’opérateur et les règles de classification spécifiques sont déterminants.

Les obligations d’un fournisseur diffèrent de celles d’un déployeur. Un modèle n’est pas la même chose que l’application qui l’intègre, et qualifier un logiciel d’« agent » ne règle ni son rôle juridique ni sa classification.

Commencer par le périmètre et l’applicabilité juridique

Tenez un inventaire de l’IA au niveau des cas d’usage opérationnels, et pas seulement des noms de fournisseurs. Un même modèle sous-jacent peut alimenter à la fois un assistant de rédaction interne et un outil de présélection pour le recrutement. Ces déploiements concernent des personnes différentes et diffèrent quant aux conséquences, aux mesures et aux obligations potentielles.

Pour chaque cas d’usage, consignez :

• La destination, les décisions soutenues, les usages interdits et les lieux de déploiement.
• Le responsable du système, le responsable technique, les utilisateurs et les personnes concernées.
• Les fournisseurs du modèle et de l’application, les modalités d’hébergement et les dépendances.
• Les sources de données, les résultats, les intégrations et les actions autorisées.
• Le rôle d’opérateur de l’organisation et le raisonnement qui le fonde.
• La classification, les obligations applicables, la date de revue et les questions en suspens.

Une organisation située hors de l’UE peut tout de même relever du champ d’application du règlement dans certaines circonstances. À l’inverse, avoir des clients dans l’UE ne justifie pas d’attribuer toutes les obligations possibles à chaque produit. Examinez les conditions territoriales et de rôle réelles.

Distinguez les pratiques interdites, les exigences relatives aux systèmes à haut risque, les obligations de transparence particulières et les obligations applicables aux modèles d’IA à usage général. Ce ne sont pas des niveaux interchangeables sur une échelle unique de gravité technique. Un chatbot en apparence peu impactant peut être soumis à des obligations de transparence ; un cas d’usage à fort impact exige une analyse juridique plus approfondie.

Utiliser le calendrier d’application actuel

La présentation de l’AI Act par la Commission européenne, consultée au 7 octobre 2026, indique le calendrier suivant :

Évaluez séparément les dispositions modifiées, les régimes transitoires et le système concerné. Ne reportez pas des obligations déjà applicables au motif qu’une date ultérieure existe pour le haut risque. Datez l’analyse juridique et consultez notre guide de préparation à l’AI Act pour le contexte relatif au calendrier et à l’évaluation des rôles.

Construire une seule chaîne de preuves, pas trois bibliothèques documentaires

Une chaîne de gouvernance pratique commence par le cas d’usage et se termine par une décision revue :

Destination → impacts et risques → exigences → garde-fous → évaluations → approbation → surveillance.

Chaque lien doit être suffisamment détaillé pour qu’une personne extérieure à l’équipe de mise en œuvre puisse l’examiner. « Contrôle humain mis en place » ne suffit pas si l’évaluateur ne peut pas déterminer qui peut intervenir, ce que cette personne voit et si l’intervention fonctionne.

Utilisez un registre des exigences qui distingue l’exigence source de sa mise en œuvre. Un schéma minimal utile comprend la source et sa version, le périmètre, le texte ou la référence de l’exigence, l’interprétation locale, le responsable de la mesure, les preuves liées, l’évaluateur, le statut et l’écart résiduel.

Considérez ce tableau comme une aide à la mise en œuvre, et non comme une table d’équivalence faisant foi. Les relations sont de plusieurs à plusieurs : une évaluation peut étayer plusieurs exigences, tandis qu’une exigence peut nécessiter plusieurs mesures et enregistrements.

Avant de réutiliser une preuve, vérifiez son périmètre, sa date, la version du système et sa conclusion. Un test réalisé sur une configuration de modèle ne peut pas étayer automatiquement une autre configuration. Une politique d’entreprise prouve qu’une règle documentée existe ; des enregistrements opérationnels sont nécessaires pour démontrer son application.

Utiliser les fonctions du NIST pour définir le travail d’ingénierie

Les fonctions du NIST offrent un moyen utile d’organiser les questions de mise en œuvre au sein de l’AIMS. Elles doivent produire des artefacts concrets plutôt que de simples champs de questionnaire remplis.

Govern : établir l’autorité de décision

Définissez qui est responsable du système, qui examine de manière indépendante les risques importants et qui peut approuver des exceptions ou arrêter un déploiement. Précisez les exigences de compétence et les voies d’escalade. Reliez ces responsabilités aux processus existants de sécurité, de protection des données, d’achats et de gestion des incidents.

Un livrable utile est une procédure de mise en production qui identifie les évaluateurs et les preuves requis. L’acceptation d’un risque doit nommer le décideur, la justification, les conditions et le déclencheur de revue, plutôt que de se contenter d’indiquer « accepté ».

Map : décrire le contexte et les conséquences

Documentez le processus avant de choisir des indicateurs. Identifiez où l’IA influence les décisions, qui en subit les conséquences et ce qui se passe lorsque les résultats sont erronés, indisponibles ou détournés.

Incluez les usages abusifs prévisibles et les défaillances des dépendances. Pour un agent capable d’exécuter des actions, cartographiez les outils, les identifiants, les données accessibles, les limites d’approbation et les chemins de récupération. Pour une IA tierce, consignez ce que le fournisseur contrôle et ce qui reste de votre responsabilité.

Measure : tester les affirmations qui comptent

Choisissez des évaluations liées aux risques identifiés. Selon le cas d’usage, elles peuvent porter sur l’exactitude dans l’exécution des tâches, les performances par sous-groupe, la robustesse, les fuites de données personnelles, l’injection de prompts, les actions non autorisées et la compréhension par les opérateurs.

Documentez la provenance et la représentativité des jeux de données, les conditions de test, les indicateurs, les limites et les seuils d’acceptation. Évaluez l’application complète lorsque c’est possible : la recherche documentaire, les prompts, les autorisations, les interfaces et le processus humain peuvent modifier les résultats même lorsque le modèle sous-jacent reste identique.

Manage : mettre en œuvre le traitement et le suivi

Traduisez les constats en garde-fous, en restrictions, en remédiation ou en décision de ne pas déployer. Il peut s’agir, par exemple, de réduire les autorisations des outils, d’exiger une approbation pour les actions lourdes de conséquences, d’exclure les usages non pris en charge ou de prévoir une solution de repli fiable sans IA.

Définissez des seuils de surveillance et des procédures de réponse. Un indicateur sans responsable ni règle de réponse n’est que de la télémétrie. Consignez les événements qui déclenchent une réévaluation, notamment les mises à jour des fournisseurs, les changements de sources de données, l’extension des usages et les incidents.

Rendre l’ISO 42001 auditable grâce aux enregistrements opérationnels

Si la certification est un objectif, définissez le périmètre de l’AIMS avant de préparer un audit externe. Le périmètre peut couvrir un produit, une unité opérationnelle ou un ensemble d’activités du cycle de vie, mais il doit décrire clairement les activités et interfaces incluses. Un périmètre étroit ne doit pas être présenté comme une assurance couvrant toute l’organisation.

Réalisez une analyse des écarts au regard des exigences du système de management et des mesures applicables. Établissez la politique, les objectifs, les méthodes d’appréciation des risques et d’analyse d’impact, l’applicabilité documentée des mesures, les responsabilités et les procédures opérationnelles. Produisez ensuite des preuves que ces processus fonctionnent réellement.

Parmi les enregistrements utiles figurent les évaluations réalisées, les revues des fournisseurs, les registres de formation, les approbations de mise en production, les revues de surveillance, les actions correctives, les constats d’audit interne et les décisions de revue de direction. L’audit interne et la revue de direction sont des activités distinctes : l’un évalue la conformité et l’efficacité ; l’autre permet à la direction d’apprécier et d’orienter le système de management.

Un processus de certification indépendant comprend généralement une étape d’évaluation de l’état de préparation et une étape d’évaluation de la mise en œuvre. Convenez du périmètre et des modalités d’audit avec l’organisme de certification plutôt que de traiter la certification comme un simple dépôt de documents. Poursuivez la surveillance, la revue interne et l’amélioration après la certification.

Ni un certificat ni une évaluation selon le RMF ne remplacent une évaluation de la conformité applicable au titre de l’AI Act. La procédure d’évaluation de la conformité dépend du système et des dispositions pertinentes ; tous les systèmes à haut risque ne nécessitent pas la même procédure faisant intervenir un tiers. Les exigences de déclaration, d’enregistrement, de marquage et de notification doivent elles aussi être vérifiées pour le rôle et le système concernés.

Exemple concret : déploiement d’une IA dans le recrutement

Hypothèses illustratives : un employeur de l’UE achète une application qui classe les candidats en vue de la sélection pour un entretien. Le fournisseur livre l’application, tandis que l’employeur configure les critères des postes et utilise les classements. Les recruteurs prennent les décisions finales d’embauche. Supposons que l’analyse juridique identifie un usage à haut risque dans le domaine de l’emploi relevant de l’annexe III et qualifie dans un premier temps l’employeur de déployeur.

Affirmer qu’« un humain prend la décision finale » ne règle pas la question. Le classement peut influencer de manière déterminante les candidats qui sont pris en considération. L’évaluation doit examiner le processus réel, notamment si les recruteurs ignorent systématiquement les candidats situés sous un seuil.

Établir l’enregistrement propre au système

Le responsable technique consigne les champs d’entrée, les informations sur la logique de classement disponibles auprès du fournisseur, la version de l’application, la configuration, les utilisateurs et les destinations des exports. Les achats demandent au fournisseur ses instructions, les limites du système, les preuves d’évaluation pertinentes, les notifications de changement et son soutien aux obligations de l’organisation.

L’analyse juridique documente les hypothèses de classification et de rôle, notamment si une modification ultérieure ou une commercialisation sous sa propre marque pourrait changer le rôle. L’analyse de la protection des données évalue séparément le traitement des données des candidats. La gouvernance de l’IA ne se substitue pas à l’analyse au titre de la protection des données.

Tester et mettre en œuvre des garde-fous

À l’aide des fonctions Map et Measure du NIST, l’équipe évalue des scénarios de recrutement représentatifs, le comportement en cas de données manquantes et les écarts de performance entre les groupes pertinents, lorsque cela est licite et réalisable. Elle documente l’incertitude et les limites de l’échantillon plutôt que de présenter un indicateur d’équité comme la preuve que tout biais préjudiciable a disparu.

Le contrôle humain comprend la formation des recruteurs, des limites visibles, une voie de réexamen des candidatures écartées et la possibilité de suspendre le classement. L’équipe vérifie que les évaluateurs comprennent les résultats et peuvent les outrepasser sans obstacle opérationnel.

Les mesures de sécurité restreignent l’accès aux dossiers des candidats et empêchent les exports non approuvés. La gestion des changements exige une réévaluation lorsque les critères de classement, les modèles ou les modalités de traitement du fournisseur changent.

Garder les trois conclusions distinctes

L’enregistrement de l’AIMS démontre comment les évaluations, les responsabilités, la revue des fournisseurs et les processus d’approbation ont fonctionné. L’enregistrement RMF explique les risques contextuels, les tests, le traitement et l’incertitude résiduelle. L’enregistrement juridique identifie les obligations applicables au déployeur, leur calendrier et le travail restant.

Supposons que le fournisseur n’ait pas fourni d’instructions suffisantes pour un contrôle humain fiable. L’enregistrement de mise en production doit faire apparaître cette lacune, son responsable et la décision de retarder ou de restreindre le déploiement, et non un statut vert hérité du certificat ISO de l’employeur.

Fixer les priorités et maintenir les preuves après la mise en production

Donnez la priorité aux obligations légales applicables et aux risques opérationnels inacceptables. La certification ISO peut avancer en parallèle de la remédiation, mais un objectif d’audit ne doit pas évincer des mesures urgentes.

Si les équipes manquent de responsabilités et de processus de revue cohérents, construisez les fondations de l’AIMS. Si la gouvernance existe mais que les évaluations des systèmes sont faibles, utilisez le RMF pour améliorer l’analyse contextuelle et les tests. Si un client exige une certification, confirmez le périmètre attendu avant d’établir le budget.

Évitez les hypothèses universelles de coût ou de durée. L’effort dépend du nombre de systèmes, de la gouvernance existante, des besoins d’évaluation, de la visibilité sur les fournisseurs et de la remédiation. Le RMF est disponible gratuitement, mais sa mise en œuvre mobilise du temps de travail ; la certification ISO ajoute des considérations liées à l’accès à la norme et à l’évaluation externe.

Après la mise en production, associez des déclencheurs de revue aux artefacts. Une mise à jour du modèle du fournisseur peut invalider des résultats d’évaluation ; une nouvelle autorisation d’action peut modifier le modèle de menace ; un nouveau marché peut exiger une réévaluation juridique. Conservez les versions et décisions antérieures afin que les évaluateurs puissent reconstituer ce qui a été approuvé à l’époque.

Les erreurs courantes consistent à assimiler les correspondances à la conformité, à collecter des politiques sans preuves opérationnelles, à accepter les affirmations des fournisseurs sans analyse propre au déploiement et à consigner un risque résiduel sans décideur identifié. Une autre consiste à mesurer la qualité du modèle en ignorant les autorisations de l’application et le comportement humain.

Secani peut soutenir le processus de gestion des preuves en reliant les exigences, les mesures, les sources, les responsables, les tâches et les décisions revues. Commencez par un périmètre défini, rattachez les preuves à ce qu’elles étayent et transformez les éléments manquants ou obsolètes en tâches attribuées. Traitez les suggestions assistées par l’IA comme des brouillons : une personne doit revoir les correspondances et les conclusions, en conservant les sources et le raisonnement de l’approbation. Le fondement de la gouvernance reste ainsi vérifiable, sans remplacer le jugement technique ou juridique.

Questions qui influencent la mise en œuvre

Les mesures de sécurité existantes peuvent-elles être réutilisées ?

Oui, lorsque leur mise en œuvre et leurs preuves couvrent le déploiement de l’IA. Le contrôle d’accès, la réponse aux incidents et la gestion des fournisseurs y contribuent souvent. Ils ne répondent pas, à eux seuls, aux questions relatives aux biais préjudiciables, à la destination ou à l’efficacité du contrôle humain.

Que faire si un fournisseur refuse de divulguer le fonctionnement interne du modèle ?

Consignez cette limite de visibilité. Recherchez des preuves proportionnées au cas d’usage, évaluez l’application déployée et déterminez si des garanties contractuelles, des restrictions ou d’autres fournisseurs sont nécessaires. Un manque de visibilité n’est pas automatiquement acceptable au motif que le service est disponible dans le commerce.

Par quoi l’équipe doit-elle commencer ?

Choisissez un cas d’usage lourd de conséquences et rassemblez son responsable, sa destination, l’évaluation du rôle, l’enregistrement des risques, les garde-fous, les tests et l’approbation. Examinez les lacunes au regard des trois instruments. Cet exercice circonscrit révèle si l’organisation a besoin d’une meilleure gouvernance, de meilleures preuves techniques ou d’un travail juridique encore à mener avant toute extension.