Auditabilité d’une réponse IA : constituer le dossier de preuve

Une réponse IA peut être lisible, convaincante et accompagnée de références tout en restant impossible à contrôler. Le document cité a changé, les droits de l’utilisateur ne sont plus connus et la configuration du système a été remplacée. La question de l’auditabilité commence ici : quels éléments permettent encore de vérifier cette réponse, dans les conditions où elle a été produite ?

Je propose un dossier de preuve centré sur une réponse et sur ses effets éventuels. C’est une méthode de travail, pas un compte rendu de tests réalisés chez un client. Elle complète l’audit IA et les exercices de contrôle d’un agent face à l’injection indirecte. L’objectif est de rendre les constats vérifiables sans conserver inutilement les données sensibles.

Une réponse est auditable lorsque l’on peut retrouver son contexte pertinent, les sources réellement accessibles, la configuration utilisée et les contrôles appliqués à ses effets. L’auditabilité décrit cette capacité de vérification. Elle ne signifie ni que la réponse est vraie, ni que le système respecte automatiquement toutes ses obligations.

Il faut distinguer trois questions. La réponse est-elle soutenue par les documents disponibles ? Ces documents étaient-ils autorisés pour cette personne ? Les actions éventuellement déclenchées étaient-elles permises et correctement exécutées ? Une seule note de qualité ne répond pas à ces trois questions. Le dossier doit conserver des observations différentes pour chacune.

Le NIST AI RMF relie gouvernance, contexte, mesure et traitement des risques. Il fournit un cadre volontaire ; le dossier ci-dessous traduit ces préoccupations en contrôles d’une réponse particulière. Il ne doit pas être présenté comme un formulaire officiel du NIST ni comme une preuve universelle de conformité.

Il faut réunir une demande identifiée, la réponse produite, les références des sources retenues et les versions pertinentes du système. Pour une application documentaire, ajoutez le contexte effectivement transmis au modèle ou une référence permettant de le retrouver sous contrôle d’accès. La liste de tous les documents indexés ne prouve pas ce que le modèle a reçu.

Chaque pièce doit répondre à une question. L’identifiant de version situe le document dans le temps. Le passage retenu permet de vérifier l’affirmation. Le résultat du filtre d’accès explique pourquoi ce passage pouvait être utilisé. La configuration décrit les contraintes imposées au système. Les événements d’outil montrent les effets réellement observés.

Si une pièce manque, indiquez « non disponible » et limitez la conclusion. Ne reconstituez pas rétroactivement une trace à partir du souvenir d’un développeur. Une reconstruction peut aider à diagnostiquer le système, mais elle doit être distinguée de la preuve contemporaine de l’exécution. Cette séparation évite qu’un dossier propre donne une fausse impression de certitude.

Le modèle de dossier téléchargeable organise ces éléments. Il contient des champs à renseigner et des questions de contrôle, sans résultat fictif prérempli. Utilisez des références internes protégées pour les pièces confidentielles, plutôt que de recopier les données dans un fichier largement partagé.

Il faut comparer chaque affirmation importante au passage invoqué et à ses conditions de validité. Un lien vers une documentation générale ne suffit pas si la réponse annonce une disponibilité, un prix, une obligation ou une performance précise. Le passage peut soutenir une partie de la phrase tout en laissant une autre partie sans preuve.

Commencez par les affirmations qui influencent la décision. Décomposez les phrases longues, puis notez pour chacune le passage correspondant, la date de la source et les réserves applicables. Une annonce fournisseur doit rester une annonce fournisseur ; un test indépendant doit identifier ses conditions. Lorsque la source ne permet pas de conclure, le résultat attendu du contrôle est une réserve ou une correction.

Dans un exemple fictif, un assistant affirme qu’une fonctionnalité est disponible pour tous les utilisateurs. La documentation annonce seulement un déploiement progressif sur un périmètre limité. La citation existe, mais elle ne soutient pas la portée de l’affirmation. Le dossier doit rendre cet écart visible, puis relier la correction à la version de réponse concernée.

Il faut observer le contrôle d’autorisation et l’effet de l’outil, séparément du texte produit par le modèle. Pour les documents, vérifiez le filtrage avant transmission du contexte. Pour une action, retrouvez l’identité technique, la règle évaluée, l’objet ciblé et le statut final. Une proposition acceptée par un humain n’est pas encore une opération exécutée.

Le guide sur les droits d’accès dans un RAG distingue les filtres appliqués au bon endroit des protections seulement affichées dans l’interface. Dans le dossier, une permission retirée doit produire un comportement observable : aucun passage interdit transmis, aucune action non autorisée accomplie. Une phrase de refus ne suffit pas à établir ces deux résultats.

La recommandation W3C Trace Context fournit un format de propagation du contexte de trace entre services. Un identifiant commun peut aider à retrouver les événements d’une requête. Il ne garantit pas que tous les événements ont été collectés ni qu’un contrôle métier a été correctement conçu. Ces limites doivent rester explicites dans la conclusion.

On peut tenter de reproduire ses conditions, mais une formulation identique n’est pas toujours attendue d’un système non déterministe. Le contrôle utile porte sur les propriétés pertinentes : faits soutenus, accès respectés, action autorisée, abstention correcte et réserves conservées. Définissez ces critères avant de rejouer le cas.

Un rejeu avec le modèle actuel et les documents actuels peut mesurer le comportement présent. Il ne démontre pas ce qui s’est produit avec une ancienne version. Conservez donc deux résultats distincts : le constat sur les pièces de l’exécution initiale et le résultat du rejeu. Cette distinction devient essentielle après une migration de modèle ou une correction du moteur de recherche.

Les essais doivent inclure les contenus malveillants dans des documents externes. OWASP décrit l’injection de prompt indirecte parmi les scénarios de risque. Le dossier doit permettre de relier la présence de l’instruction, la décision de contrôle et l’absence ou la présence d’un effet interdit. Il ne s’agit pas de demander au modèle s’il estime avoir été prudent.

On peut publier une conclusion limitée au périmètre et aux pièces vérifiés. Indiquez la version, les critères, les éléments manquants et la date du contrôle. « Aucun écart observé sur ces cas » est une conclusion différente de « système fiable dans toutes les situations ». Une limite documentée protège la décision de l’utilisateur.

Pour une équipe, le dossier devient aussi une ressource de recette. Un incident vérifié peut être transformé en cas de régression, avec une attente explicite et des données autorisées. Il rejoint alors le jeu de tests du système. La progression vient de cette boucle de correction, pas de l’accumulation de justificatifs que personne ne relit.