Le 7 avril 2026 est la date donnée par le NIST pour sa note conceptuelle sur un profil du cadre de gestion des risques liés à l'IA pour les infrastructures critiques.[1] La distinction est importante : une note conceptuelle décrit un travail en vue d'une orientation. Ce n'est pas une preuve qu'un produit particulier a passé une évaluation. Pour les acheteurs d'IA privée, la réponse pratique est de rendre le déploiement proposé suffisamment spécifique pour pouvoir l'examiner.

Notre position est que le dossier pilote le plus solide suit une tâche réelle à travers sa limite opérationnelle. Le document doit préciser ce que le système peut faire, ce qu’il ne peut pas faire, et qui prend le relais lorsque la sortie ne peut pas être fiable. Une étiquette telle que « sur site » ne peut pas fournir ces réponses à elle seule.

Séparer la source de l'interprétation

Le NIST décrit le AI RMF comme volontaire et mentionne la publication initiale du cadre en janvier 2023. Son aperçu actuel décrit également les travaux de révision et l’initiative du profil pour les infrastructures critiques.[1] Ce sont des informations utiles à conserver avec leurs dates. Elles ne doivent pas être reformulées comme une nouvelle obligation légale ni comme une garantie que la liste de contrôle existante est complète.

Un briefing interne peut maintenir cette distinction visible avec deux courts paragraphes. Le premier rapporte ce que la source dit réellement et y fait un lien. Le second indique ce que l’organisation propose de faire en réponse. Cela rend les mises à jour ultérieures gérables : une source modifiée ne nécessite pas de deviner quelles parties du briefing étaient des faits et lesquelles étaient des décisions locales.

Cet article propose une méthode pour rassembler des preuves techniques. Il ne détermine pas quelles obligations sectorielles s'appliquent à une organisation ni si un déploiement les respecte.

Tracer la véritable limite opérationnelle

Un assistant de documentation de maintenance et un système qui modifie les réglages des équipements sont des propositions différentes. Décrivez la première tâche autorisée en termes simples avant d’aborder les modèles. Indiquez l’entrée, la personne utilisant le résultat, et l’action que cette personne est autorisée à effectuer. Incluez la conséquence d’une réponse incorrecte dans la même description.

Ensuite, retracez le chemin des données. Une proposition Déploiement d'AI Server appartient à un schéma avec ses clients, systèmes d'identité et stockage. Les téléchargements de modèles, diagnostics et itinéraires optionnels des fournisseurs méritent leurs propres entrées. La question est de savoir où chaque activité s'exécute et qui l'opère, et non si tout peut être regroupé sous une seule étiquette produit rassurante.

Pour un projet pilote uniquement basé sur des documents, l'équipe pourrait interdire que le texte généré déclenche directement une action opérationnelle. Enregistrez cette restriction comme une véritable décision d'intégration. Ajouter simplement une phrase à une diapositive de formation ne définit pas ce que le logiciel peut appeler.

Le aperçu de la plateforme d'entreprise fournit un point de départ pour discuter de la topologie. Un enregistrement d'achat nécessite encore la configuration choisie pour le site particulier.

Conserver l'identité de ce qui a été testé

Hugging Face documente les fiches modèles comme un lieu d'information sur le modèle incluant l'usage prévu, les limitations et l'évaluation.[2] Enregistrez la fiche du candidat avec la référence de révision utilisée lors de l'examen. Enregistrez également les paramètres d'exécution et de déploiement. Un examinateur ultérieur ne devrait pas avoir à deviner quel fichier modèle se cachait derrière un ancien résultat.

Conservez les entrées de test sous les propres contrôles d'accès de l'organisation. Le dossier d'examen peut faire référence à un ensemble de tests approuvé sans copier de documents sources confidentiels dans une présentation d'achat. Indiquez qui peut récupérer les entrées et comment le test peut être répété.

Enregistrez également le flux de travail environnant. Une réponse générée à partir d'une collection de documents différente est un test différent, même si le fichier modèle n'a pas changé. Il en va de même pour une réponse évaluée selon une règle d'acceptation assouplie. Ne versionner que le modèle rend ces changements invisibles.

Testez l'échec et la passation

Choisissez des exemples qui exposent les limites de la tâche. Pour un assistant documentaire, incluez une question sans réponse dans les documents autorisés, deux passages en conflit, et une page scannée dont l'ordre de lecture est maladroit. Convenez à l'avance de la manière dont l'examinateur jugera chaque réponse. Ce sont des cas de test suggérés, pas une suite d'évaluation certifiée.

Les preuves de performance nécessitent également leurs conditions. MLCommons décrit les benchmarks d'inférence utilisant des charges de travail définies, des objectifs de qualité et des scénarios de mesure.[3] Un résultat recueilli dans ces conditions est utile dans son contexte propre. Ce n'est pas un niveau de service observé pour une installation non testée.

Pour le pilote, mesurez le flux de travail réel de l'examen et documentez ce qui se passe lorsque le service s'arrête. Qui reçoit l'échec ? L'utilisateur peut-il revenir au document original ? Quel enregistrement survit à une demande annulée ? Parcourez ces chemins tant que le système est encore assez petit pour que l'équipe puisse le comprendre.

La récupération mérite un propriétaire nommé. Gardez la configuration connue précédente disponible sous le processus de changement de l'organisation, et définissez qui peut approuver le retour à celle-ci. Un repli proposé que personne ne peut exécuter est une partie inachevée de la conception.

Rendez la décision suivante étroite

L'examen doit se terminer par une décision délimitée : continuer cette tâche dans ces conditions, répéter ces tests après un changement, ou arrêter jusqu'à ce qu'une déficience nommée soit corrigée. Évitez de transformer un pilote documentaire réussi en une approbation d'utilisations opérationnelles non liées.

L'enregistrement des coûts doit utiliser la même limite. Notre article sur coût par tâche acceptée explique pourquoi les sorties examinées et rejetées appartiennent à ce calcul. Les examinateurs techniques et financiers peuvent alors discuter de la même unité de travail.

Utilisez les AI Server informations pour identifier les questions de déploiement, puis intégrez la tâche proposée et le dossier d'acceptation dans l'évaluation. Les preuves deviennent utiles lorsqu'une autre personne peut répéter le test et comprendre la décision.

Références

  1. NIST. Cadre de gestion des risques liés à l'IA. Consulté le 12-09-2026.
  2. Hugging Face. Fiches de modèles. Consulté le 12-09-2026.
  3. MLCommons. MLPerf Inference : Centre de données. Consulté le 12-09-2026.

Articles connexes

Get it from Microsoft