Le registre de passation que nous recommandons pour un service d'IA privé

Le cadre de gestion des risques de l'IA du NIST aborde la fiabilité tout au long de la conception, du développement, de l'utilisation et de l'évaluation des systèmes d'IA.[1] La période d'exploitation mérite ses propres preuves. Pour un pilote d'IA privé passant à une utilisation courante, nous recommandons un registre de passation permettant à l'équipe réceptrice d'identifier l'installation, de comprendre ses limites et de réagir lorsqu'un dysfonctionnement survient.

Voici notre format de passation proposé, non un rapport d'un déploiement client audité. Il complète les informations techniques et les limites des données dans le centre de confiance Software Tailor. Chaque organisation doit attribuer les responsabilités selon son propre modèle opérationnel.

Nommer le propriétaire récepteur et les travaux autorisés

Commencez par un rôle nommé qui accepte la responsabilité du service. Enregistrez son mode de contact et l'arrangement alternatif lorsque le propriétaire habituel est indisponible. Une adresse de support fournisseur est utile, mais l'organisation a aussi besoin de quelqu'un pouvant décider si le service doit continuer à fonctionner lors d'un incident.

Décrivez les tâches approuvées pour l'utilisation courante et celles encore limitées au pilote. Incluez les groupes autorisés à utiliser le service et les horaires d'exploitation prévus. Une anomalie non résolue du pilote doit rester visible avec un propriétaire et une date de décision planifiée ; elle ne doit pas disparaître parce que le statut de l'installation a changé.

Conservez les hypothèses de capacité et d'échéance utilisées lors de la décision d'achat. Cela donne à l'équipe réceptrice une raison d'enquêter lorsque la charge de travail évolue.

Conservez la configuration effectivement vérifiée

Enregistrez les versions de l'application et du serveur, le runtime et la référence exacte du modèle. Conservez la source de l'installation et la configuration pertinente via le processus normal de gestion documentaire contrôlée de l'organisation. Stockez les identifiants via son processus de gestion des identifiants, avec des références dans la passation plutôt que des valeurs secrètes copiées.

Les fiches modèles Hugging Face fournissent une documentation sur les usages, limites et évaluations des modèles.[2] Liez la fiche et la révision pertinentes, puis ajoutez les constats locaux du pilote. La description de l'éditeur et les résultats des tests de l'organisation répondent à des questions différentes ; l'équipe réceptrice doit pouvoir localiser les deux.

Lorsque le système dispose de fournisseurs externes optionnels, enregistrez les routes activées. Décrivez la limite de données prévue pour chaque route et qui peut approuver un changement. Évitez une étiquette vague telle que « local » lorsque la configuration opérationnelle nécessite une explication plus précise.

Attribuer la responsabilité des actions et des permissions

Pour une intégration d'agent, joindre la liste d'outils convenue ainsi que l'identité utilisée par chaque connexion. OWASP recommande de limiter les capacités et permissions de l'agent, et de faire respecter l'autorisation dans les systèmes en aval.[3] Notre proposition de transfert transforme cette recommandation en une question de propriété : qui peut examiner ou révoquer chaque attribution ?

Inclure le résultat des vérifications d'intégration des appels d'outils, avec les restrictions restantes éventuelles. Distinguer la permission de proposer une opération de la permission de l'exécuter. Si une personne doit approuver une action, identifier où cette approbation a lieu et comment est gérée une approbation échouée ou abandonnée.

Le propriétaire receveur doit également savoir quels enregistrements de diagnostic existent, qui peut y accéder et combien de temps ils sont conservés. Utiliser la politique configurée et un exemple vérifié. Ne pas déduire que les invites sont absentes de chaque composant connecté simplement parce qu'un composant a une conception d'audit sans contenu.

Répéter une interruption avant le transfert

Choisir une interruption convenue et non destructive dans un environnement de test. Faire suivre les instructions de récupération par l'équipe receveuse pendant que l'implémenteur original observe. Enregistrer les informations manquantes rencontrées et mettre à jour les instructions avant la validation finale.

L'exercice doit établir comment reconnaître le problème, qui peut arrêter le travail affecté et comment vérifier le service récupéré. Si le retour arrière fait partie du plan, identifier la version conservée et le moment où le retour arrière est approprié. Garder les hypothèses de récupération non testées étiquetées comme non testées.

Pour une discussion de service Software Tailor, un enregistrement de configuration expurgé et un compte rendu clair de l'étape échouée sont plus utiles qu'une affirmation non étayée que l'ensemble du système est défaillant. Le transfert doit expliquer comment collecter ces informations via la voie de support approuvée par l'organisation.

Faire de la validation un enregistrement exploitable

Terminer par l'acceptation du propriétaire receveur, la date et les points non résolus. Nommer les changements qui devraient déclencher une revue, tels qu'un modèle différent, un nouveau connecteur ou une tâche autorisée plus large. Il s'agit d'une discipline opérationnelle proposée plutôt que d'un schéma de certification.

L'enregistrement est prêt lorsque l'équipe receveuse peut l'utiliser pour prendre une décision sans reconstituer le pilote de mémoire.

Références

[1] NIST. AI Risk Management Framework. Version 1.0 publiée en 2023 ; guide de référence. Consulté le 26-09-2026.

[2] Hugging Face. Fiches de Modèle. Guide permanent de documentation des modèles. Consulté le 26-09-2026.

[3] Projet de sécurité OWASP Gen AI. LLM06:2025 Agence excessive. Édition 2025. Consulté le 26-09-2026.