ISO 42001 vs NIST AI RMF vs EU AI Act : une gateway, trois référentiels

Trois référentiels, trois audiences, une question sous-jacente commune

Mi-2026, il est courant qu'une même équipe IA doive répondre, au cours d'un même trimestre, à trois demandes de gouvernance distinctes : un questionnaire d'achat client demandant si l'entreprise détient la certification ISO 42001, un comité de risque interne demandant si le programme IA suit le NIST AI RMF, et un responsable conformité demandant la documentation précise qu'exige l'EU AI Act parce que l'entreprise sert des utilisateurs européens. Ces demandes peuvent sembler être trois projets de conformité distincts se disputant le même temps d'ingénierie limité. Ce n'est pas le cas. Ce sont trois audiences qui posent des variantes qui se recoupent d'une même question sous-jacente : pouvez-vous démontrer votre contrôle sur ce que font vos systèmes IA ?

Ce qu'est réellement chaque référentiel

Le NIST AI RMF est une méthodologie volontaire de gestion des risques publiée par le National Institute of Standards and Technology américain. Elle ne donne lieu à aucune certification ; personne ne vous audite ni ne vous délivre de certificat à ce titre, et c'est voulu. Elle offre aux organisations un vocabulaire commun et un processus structuré pour identifier, mesurer et gérer le risque IA — le « quoi » et le « pourquoi » d'un programme de risque — sans imposer une implémentation technique précise.

L'ISO/IEC 42001:2023 est l'inverse sur le plan structurel : un standard international de système de management certifiable, dans la même famille que l'ISO 27001 pour la sécurité de l'information. Elle définit le « comment » : une structure formelle pour établir, mettre en œuvre, maintenir et améliorer un système de management de l'IA, vérifiée par un audit tiers. Parce qu'elle est certifiable, elle produit quelque chose qu'une équipe achats peut réellement cocher, ce qui explique pourquoi elle se diffuse plus rapidement via les processus de qualification des fournisseurs que via les programmes de risque internes.

L'EU AI Act n'est ni volontaire ni un système de management : c'est une loi contraignante. Elle est devenue largement applicable le 2 août 2026, avec des pouvoirs d'enforcement actifs pour l'IA à usage général et des obligations high-risk introduites progressivement sur un calendrier plus long à la suite des ajustements du paquet Omnibus. Nous avons détaillé les dates et obligations précises dans notre guide EU AI Act 2026 ; ce qui compte ici, c'est qu'à la différence des deux autres référentiels, le non-respect de l'EU AI Act entraîne des sanctions légales, et non simplement une vente perdue ou une remarque d'audit peu flatteuse.

Où ils diffèrent réellement, et où les entreprises trébuchent

La confusion pratique ne porte généralement pas sur ce que disent les référentiels, mais sur qui les demande et pourquoi. Un crosswalk publié par le NIST lui-même en 2026 fait correspondre directement les fonctions du AI RMF aux clauses de l'ISO 42001, car les deux ont été conçus pour être compatibles plutôt que concurrents. Les entreprises américaines ayant des opérations en Europe font le plus souvent tourner le NIST AI RMF comme méthodologie interne et la conformité EU AI Act comme socle légal contraignant, l'ISO 42001 venant s'y ajouter spécifiquement parce que les acheteurs d'entreprise des services financiers, de la santé et du secteur public exigent de plus en plus la certification comme condition de qualification des fournisseurs. Ce dernier changement mérite qu'on s'y arrête : la certification ISO 42001 passe du statut de différenciateur à celui de prérequis dans les achats, ce qui signifie que l'argument commercial pour l'obtenir relève désormais autant du cycle de vente que de la gestion des risques — et elle tend d'ailleurs à raccourcir ce cycle de vente pour cette même raison.

Le piège dans lequel tombent les entreprises consiste à traiter chaque référentiel comme un chantier à part, avec son propre outillage, son propre tableur et sa propre préparation d'audit. Cette approche triple l'effort manuel pour un ensemble de référentiels qui, sous la paperasse, demandent tous la même chose : qui peut accéder au système IA, qu'en a-t-il fait, pouvez-vous le prouver a posteriori, et existe-t-il un responsable humain du résultat ?

À quoi ressemble l'exigence commune en termes d'infrastructure

Le contrôle d'accès, le logging, la traçabilité et la supervision ne sont pas de simples formulations de politique : ce sont des propriétés d'infrastructure. C'est pourquoi le chemin le plus rapide pour satisfaire les trois référentiels passe par le même point de contrôle plutôt que par trois initiatives de conformité distinctes.

Le contrôle d'accès correspond directement aux virtual API keys et aux access grants d'Odock : chaque appel à un model ou à un outil MCP nécessite un grant explicite rattaché à une organisation, une équipe ou un principal utilisateur, documenté dans scope and principals. Cela répond à la question « qui peut accéder au système IA » pour les trois référentiels à la fois.

Le logging et la traçabilité correspondent aux usage records : une ligne durable et interrogeable par requête, capturant l'identité, le model résolu, les tokens, le coût, la latency et l'historique de routing, sans jamais stocker le contenu du prompt ou de la completion elle-même — ce qui garde la piste de preuve utile pour les audits sans devenir elle-même un risque de protection des données.

La supervision et la gestion démontrable des risques correspondent aux couches policy inheritance et security engine : policy inheritance montre précisément quelles règles d'organisation, d'équipe, de clé, de model et de MCP se sont appliquées à une requête donnée, et le moteur SafetySec produit la preuve qu'une requête a été autorisée, redacted, observée ou bloquée. Mis ensemble, ces éléments montrent qu'un auditeur travaillant à partir de n'importe lequel des trois référentiels consulte le même enregistrement sous-jacent, en le demandant simplement dans un vocabulaire différent.

Les limites honnêtes

Rien de tout cela ne remplace les volets de ces référentiels qui relèvent de l'organisationnel plutôt que du technique. La certification ISO 42001 exige toujours un système de management documenté, des rôles définis et un véritable audit par un tiers — une gateway ne s'audite pas elle-même. Le NIST AI RMF exige toujours que vous exécutiez réellement le processus d'identification et de mesure des risques ; un log est une preuve de ce processus, pas un substitut à son exécution. Et l'EU AI Act exige toujours que vous classiez correctement vos systèmes IA par niveau de risque, ce qui relève d'un jugement légal et produit qu'aucune couche d'infrastructure ne peut faire à votre place. Ce qu'une gateway fait, c'est retirer l'excuse selon laquelle la preuve sous-jacente n'existe pas ou est trop dispersée pour être produite — ce qui, en pratique, est l'endroit où la plupart des programmes de gouvernance s'enlisent réellement.

Là où Odock.ai intervient

J'ai conçu Odock pour que les preuves demandées par ces trois référentiels découlent du fonctionnement normal plutôt que de nécessiter un projet de reporting séparé — pondérez donc ce point en conséquence. Chaque requête passant par Odock produit un enregistrement unique avec l'identité, le résultat de la politique et le résultat de sécurité associés, la même structure d'enregistrement que la personne qui la consulte soit un analyste achats vérifiant la compatibilité ISO 42001, un comité de risque appliquant le NIST AI RMF, ou un régulateur européen demandant la traçabilité exigée par l'AI Act.

Si votre équipe maintient actuellement un suivi séparé pour chaque référentiel, la simplification la plus rapide n'est pas de choisir lequel abandonner, mais de placer votre trafic IA derrière une infrastructure qui produit une seule fois la preuve partagée. Demandez une démo ou commencez par la documentation sur la sécurité et les guardrails pour voir à quoi ressemble l'enregistrement avant que votre prochain audit ne vous le demande.

Sources

• AI Governance Frameworks Compared: NIST vs ISO 42001 vs EU AI Act, NeuralTrust
• Global AI Governance Comparison 2026: EU AI Act vs NIST AI RMF vs ISO/IEC 42001, GAICC
• 5 Key Differences Between the NIST AI RMF and ISO 42001, Vanta
• NIST AI RMF to ISO/IEC FDIS 42001 Crosswalk, NIST
• Sécurité et guardrails Odock
• Usage records Odock