NIST AI Risk Management Framework 1.0 — correspondance d'alignement
Cette page est générée à partir de la table d'exigences que le moteur AiSSAY livre pour ce référentiel. Quand le moteur produit un dossier de preuves, chaque ligne ci-dessous reçoit un statut calculé à partir des propres enregistrements de l'opérateur à ce moment-là. Cette page montre la table, pas les résultats de qui que ce soit.
Mise en correspondance à titre informatif, établie par les propres outils de l'opérateur. Ce n'est ni un avis juridique, ni une certification, ni un substitut au conseil d'un avocat. Elle organise les enregistrements de l'opérateur au regard des exigences citées ; la question de savoir si ces enregistrements satisfont aux exigences relève de l'appréciation de l'opérateur, de son conseil juridique et du contrôleur.
Le NIST AI RMF est un référentiel volontaire. Aucune certification NIST n'existe et aucune ne peut être revendiquée ; la déclaration publique exacte est que l'opérateur S'ALIGNE sur le référentiel, par auto-évaluation, cette correspondance pouvant être régénérée à tout moment à partir du stockage de preuves.
La table d'exigences
11 lignes : 7 mécanismes, 3 organisationnelles, 1 lacune nommée
| Exigence | Mécanisme, obligation ou lacune | Type |
|---|---|---|
| GOVERN 1.1–1.4 — politiques, structures de responsabilité et tolérance au risque documentées tout au long du cycle de vie de l'IA | organisationnel : une politique écrite de gouvernance de l'IA désignant les enregistrements AiSSAY comme mécanisme de preuve | organisationnel |
| GOVERN 2.1 — les rôles et responsabilités relatifs aux risques liés à l'IA sont définis | PARTIEL, et pas du fait du logiciel. Les enregistrements nomment un réviseur lorsque quelqu'un a contresigné, et le point de contrôle nomme qui peut lever une action retenue — mais le système n'a ni rôles, ni permissions, ni notion de qui a le droit de faire quoi. Définir les responsabilités est un acte organisationnel ; le stockage ne peut que l'enregistrer après coup. | organisationnel |
| GOVERN 4.3 — les incidents et les erreurs sont partagés et documentés | enregistrements scellés des défaillances, enregistrements de lacunes de capture et mécanisme de bifurcation reconnue : les incidents deviennent des entrées de la chaîne, jamais des e-mails | mécanisme |
| MAP 1.1/2.3 — contexte, finalité et hypothèses de l'usage de l'IA documentés | chaque enregistrement porte le mandat de la tâche, les hypothèses déclarées par l'agent, les ambiguïtés et les conditions de validité | mécanisme |
| MEASURE 2.5 — performance du système d'IA suivie au moyen d'indicateurs | constats de rapprochement, couverture du livrable et analyse de dérive par type de tâche, calculés pour chaque exécution | mécanisme |
| MEASURE 2.7(a) — évaluation adverse du système d'IA | pots de miel, épreuves d'enregistrements falsifiés, analyse des injections et arbitrage croisé entre modèles exécutés sur chaque exécution mesurée | mécanisme |
| MEASURE 2.7(b) — sécurité et résilience du système déployé | PARTIELLEMENT IMPLÉMENTÉ, et les parties sont nommées. Les tests adverses évaluent ici le compte rendu que l'IA fait de son travail, pas la sécurité du logiciel qui le porte. Côté logiciel : les dépendances sont analysées à chaque publication avec un contrôle d'ancienneté, un vérificateur statique restreint s'exécute sur cette arborescence, et les analyseurs qui lisent des entrées extérieures font l'objet de fuzzing — chacun éprouvé sur un défaut introduit plutôt que tenu pour fiable. Il n'existe toujours ni test d'intrusion ni revue de la cryptographie par un tiers. | lacune nommée |
| MEASURE 2.8 — tenue d'enregistrements de transparence et de responsabilité | chaîne de hachage en ajout seul, journal d'accès complet, ancrage externe | mécanisme |
| MEASURE 3.1–3.3 — risques suivis dans le temps ; la mesure elle-même est évaluée | le profil d'instrument : un registre signé et versionné de ce que le vérificateur a appris, estampillé sur chaque enregistrement qu'il a jugé | mécanisme |
| MANAGE 2.3/2.4 — mécanismes de réponse aux incidents et de rétablissement | PARTIEL. La restauration du registre, le diagnostic des bifurcations, le scellement des lacunes de capture et les mesures de conservation à des fins juridiques sont des MÉCANISMES de rétablissement, et ils fonctionnent ; qui est alerté, dans quel délai, et qui décide de les déclencher relève d'une procédure de réponse aux incidents qu'aucun logiciel ne fournit. | organisationnel |
| MANAGE 4.1 — suivi après déploiement avec contrôle humain | signalement « à revoir », contre-signatures des réviseurs alimentant la calibration, et briefings avant exécution issus de corrections vérifiées | mécanisme |
Comment un statut s'obtient
- Étayé
- une vérification déterministe a été exécutée sur vos enregistrements et les décomptes étayent la ligne. Un stockage ne contenant aucun enregistrement pertinent apparaît comme non étayé — une affirmation vraie, pas une validation. Vide ne compte jamais comme conforme.
- Délégué
- le mécanisme est appliqué par un système auquel vous faites déjà confiance — un stockage scellé par votre propre gestionnaire de clés lui délègue le contrôle d'accès, et le dossier indique que le journal qui fait foi est celui de votre gestionnaire de clés, pas le nôtre. Le dossier nomme le point de terminaison par lequel le gestionnaire de clés a été joint. Un point de terminaison AWS autre que celui qu'AWS utilise par défaut pour la région apparaît comme délégué à ce point de terminaison, avec une demande de confirmation qu'il s'agit bien de votre service de gestion des clés. Un seul backend — AWS KMS — a été exécuté sur le service AWS KMS réel ; aucun autre backend ne l'a été.
- Point d'intégration de test
- scellé par un backend de test interne au processus — un bouchon (stub), ou un substitut du client AWS — et le statut précise lequel. Aucun gestionnaire de clés n'applique le contrôle d'accès. Le point d'intégration est construit et testé, et le dossier refuse d'appeler cela une délégation.
- Partiellement étayé
- le mécanisme est construit et certaines de vos exécutions en portent la preuve, mais pas toutes — généralement parce qu'elles ont été scellées avant que le mécanisme n'existe. Le dossier indique combien d'exécutions se trouvent dans chaque groupe, et ne compte jamais celles qui manquent comme validées.
- Organisationnel
- l'exigence est une procédure que seules des personnes peuvent accomplir. Le dossier la désigne comme la vôtre au lieu de déguiser une politique en mécanisme.
- Lacune nommée
- le dossier ne peut pas l'étayer — soit le mécanisme n'est pas construit, soit aucun logiciel ne peut le fournir — et il précise lequel des deux. La lacune est imprimée, parce qu'un examinateur doit la lire ici plutôt que la découvrir.
Aucun statut n'est saisi à la main : chaque statut est recalculé à partir du stockage chaque fois qu'un dossier est produit, le texte des exigences et des mécanismes est rédigé et relu dans le cadre du moteur, et les preuves relatives aux dépendances proviennent de notre analyse de version. Un mécanisme en échec ne peut jamais être lu comme la preuve que le contrôle fonctionne.