Rejeu déterministe

Le rejeu déterministe (deterministic replay) consiste à réexécuter une décision enregistrée avec les entrées, la version de politique, la sortie du modèle et la configuration en vigueur au moment des faits, et à obtenir de nouveau le même résultat. Pour un agent d'IA, la décision la plus importante se situe au point de contrôle : l'agent a proposé une action, une politique l'a évaluée, et le résultat a été allow, warn, require_approval ou block. Si un auditeur peut rejouer cette évaluation et obtenir le même résultat, l'enregistrement étaye l'affirmation selon laquelle le contrôle a fonctionné comme décrit.

Le rejeu compte parce que le comportement d'un agent est difficile à reconstituer après coup. Un grand modèle de langage peut renvoyer une réponse différente pour la même requête, et le modèle derrière une API peut changer de version. Interroger de nouveau le modèle revient à tester le modèle d'aujourd'hui. Un rejeu fidèle s'appuie sur ce qui a été enregistré. L'article 12 de l'EU AI Act impose aux systèmes d'IA à haut risque de journaliser les événements pour assurer une traçabilité de leur fonctionnement adaptée à leur destination, et le rejeu permet de vérifier en pratique que les journaux sont complets.

Trois éléments d'une décision d'agent peuvent être rejoués à l'identique, à condition d'avoir été enregistrés : l'évaluation de la politique (mêmes règles, même version, mêmes champs d'entrée), l'orientation d'une action retenue vers un réviseur, et tout calcul de seuil ou de limite. Le raisonnement du modèle ne peut être rejoué qu'en réutilisant la sortie enregistrée du modèle. Un rejeu montre comment la décision a été prise. Le résultat de l'outil, la confirmation de paiement ou l'accusé de réception du système, enregistrés après l'exécution, montrent si l'action a eu lieu.

Pour que le rejeu fonctionne, enregistrez pour chaque action : l'action proposée et ses paramètres, la version de la politique et l'empreinte de son contenu, les données lues par la politique, la sortie du modèle à l'origine de la proposition, le résultat et la règle qui l'a produit, l'éventuelle décision humaine, et l'horodatage de chaque étape. S'il manque un élément, le rejeu devient une approximation, et l'enregistrement doit l'indiquer.

Dans KLA, une version de politique peut être rejouée sur les exécutions récentes enregistrées du tenant. Chaque exécution est réévaluée et comparée au résultat enregistré à l'époque, les exécutions enregistrées sans leurs données de décision sont signalées comme non rejouées, et le rejeu ne crée ni approbation ni enregistrement de preuve. Lors de l'un de nos propres cycles de recette sur données synthétiques, une politique en projet rejouée sur 200 exécutions enregistrées en a comparé 195, en a exclu 5 dont des champs étaient masqués ou manquants, et a fait passer le nombre de demandes d'approbation de 37 à 40. Nous avons retenu cette conception après avoir jugé peu praticables, pour des équipes conformité, des cas de test construits à la main avec de nombreux champs.