Quel journal d'audit un agent IA doit-il laisser ?

Un auditeur interne pose une question simple à l'équipe des opérations: pourquoi le traitement nocturne des paiements a-t-il été relancé à 2 h 47 ? Le journal du planificateur indique un redémarrage. Le ticket mentionne « relance suite à une recommandation de l'IA ». Impossible de savoir ce que l'agent d'IA a vu, ce qu'il était autorisé à faire, ni qui a approuvé cette action.

En bref: un agent d’IA doit laisser une trace écrite permettant de reconstituer l’intégralité de la décision, et non seulement la commande. Cette trace doit indiquer quel agent et quelles personnes étaient impliquées, le contexte et les éléments de preuve ayant motivé la recommandation, l’autorité de l’agent, qui a approuvé l’action, le déroulement précis des opérations et les conséquences.

Cet article présente le cadre en huit parties proposé par Rocket Software pour la gestion de cet enregistrement. Il inclut également un exemple d'enregistrement d'audit issu d'un incident réel sur un système mainframe, que vous pouvez adapter à votre environnement.
 

Qu’est-ce qu’une piste d’audit d’agent IA ?

La piste d'audit d'un agent d'IA constitue la preuve qui relie la recommandation d'un agent d'IA à l'autorité, l'approbation, l'action et le résultat qui la sous-tendent. Utilisez cette définition comme point de départ:

La piste d'audit d'un agent d'IA est un enregistrement chronologique et infalsifiable qui relie l'identité de l'agent, le contexte et les éléments de décision utilisés, la recommandation formulée, l'autorité détenue, l'approbation humaine reçue, l'action autorisée exécutée et le résultat validé. Elle permet à un auditeur, un opérateur ou une équipe de gestion des risques de reconstituer les actions entreprises, leurs raisons et les autorisations obtenues.

Le mot clé est « liens ». La plupart de ces informations existent déjà quelque part dans votre environnement. Le journal d'audit de l'agent IA les relie, évitant ainsi à quiconque de devoir reconstituer le dossier à partir de cinq outils différents a posteriori.
 

Pourquoi les journaux système traditionnels ne suffisent-ils pas à l'IA agentive ?

Les journaux système traditionnels enregistrent les événements, mais pas les décisions. Un journal peut indiquer qu'un utilisateur a émis une commande à un moment précis, mais il ne peut pas expliquer pourquoi un agent d'IA a recommandé cette commande, quelles preuves l'ont étayée, ni si une personne habilitée l'a approuvée.

Les journaux système sont nécessaires, mais insuffisants. Il vous faut également les enregistrements SMF (System Management Facilities), les journaux de tâches, les journaux de console et les journaux de sécurité, car ils attestent des événements survenus au niveau du système. Or, un agent d'IA ajoute un niveau de décision supplémentaire entre l'alerte et la commande. Si votre journal d'audit omet ce niveau, la seule explication possible est: « c'est l'IA qui a fait ça ».

Voici en quoi les deux disques diffèrent:

Les dirigeants considèrent déjà cet écart comme un frein à la production. Selon une étude menée en juin 2026 par Rocket Software et Hanover Research auprès de 250 responsables informatiques du secteur financier, 46 % d'entre eux ont déclaré avoir besoin de contrôles de gouvernance et de processus d'approbation rigoureux avant de faire confiance à l'IA en production pour les diagnostics opérationnels. Par ailleurs, 43 % souhaitaient une précision éprouvée, validée par rapport aux incidents historiques. Les répondants ont également cité le manque d'explicabilité et d'auditabilité parmi leurs principales préoccupations concernant l'IA agentielle dans les opérations réglementées.

IDC observe une tendance similaire. Selon IDC, les premiers utilisateurs d'IA agentielle citent systématiquement le manque de visibilité pour répondre aux exigences de conformité et d'audit comme un défi majeur. IDC souligne également que l'instauration d'une relation de confiance repose sur le suivi des informations, des actions et des résultats grâce à des journaux, des pistes d'audit et des politiques claires encadrant la supervision humaine.

Un journal d'audit de l'IA devrait-il enregistrer le raisonnement de l'agent ?

Un journal d'audit d'IA doit consigner les décisions de l'agent et leurs justifications, et non le raisonnement interne du modèle. Les auditeurs doivent vérifier les éléments sur lesquels l'agent s'est appuyé et ses conclusions. Ils n'ont pas besoin, et ne peuvent généralement pas obtenir de manière fiable, le processus interne détaillé, jeton par jeton, d'un modèle de langage complexe.

Concentrez-vous sur ce qui est observable et vérifiable:

• Entrées: les sources de données et les enregistrements récupérés par l’agent
• Preuve: les signaux spécifiques cités, tels qu'un code d'erreur ou une attente de verrouillage
• Recommandation: l'action proposée
• Justification: l’explication en langage clair qu’elle a fournie à l’opérateur
• Incertitude: ce qu'elle n'a pas pu confirmer et les preuves contradictoires

Un examinateur peut vérifier ce document. Il peut consulter le même journal d'activité, confirmer le même code d'erreur et déterminer si la recommandation était justifiée par les éléments de preuve. Cela constitue un fondement plus solide pour la responsabilisation qu'un exposé opaque des motifs.

Comment l'approbation humaine doit-elle figurer dans le compte rendu d'audit ?

L'approbation humaine doit apparaître comme une étape distincte et attribuable entre la recommandation de l'agent et l'action exécutée. Le compte rendu doit rendre la séquence impossible à mal interpréter.

1. L'agent A a recommandé une action précise, preuves à l'appui.
2. La personne B a approuvé cette action précise, sous sa propre identité et dans son rôle.
3. L'agent A a exécuté l'action approuvée, dans le cadre de ses pouvoirs autorisés.
4. Le système C a enregistré le résultat et les résultats de validation.

Chaque étape doit être identifiée et horodatée. Si la personne B a approuvé « redémarrage à partir de l'étape 040 » et que l'agent a exécuté « redémarrage à partir de l'étape 010 », l'enregistrement doit signaler automatiquement l'incohérence.

Cette séquence correspond également à des niveaux d'autorité gradués pour l'IA: Observer, Recommander, Agir avec approbation et Agir de manière autonome. La plupart des actions de production importantes relèvent du niveau « Agir avec approbation ». L'historique des modifications permet de vérifier le niveau appliqué à chaque action.  

Qu’est-ce qui rend une piste d’audit d’IA défendable ?

Une piste d'audit d'IA fiable est complète, attribuable et infalsifiable. Si elle est contestée six mois plus tard, elle doit résister sans dépendre de la mémoire de quiconque.

Vérifiez votre journal d'audit par rapport à ces critères:

• Attribution: Chaque entrée est liée à un agent ou à une identité humaine unique, jamais à un compte partagé.
• Intégrité: Les enregistrements ne peuvent être altérés sans être détectés. Le hachage ou la signature garantissent cette intégrité.
• Immuabilité: L'enregistrement immuable est enregistré dans un espace de stockage que les agents et les opérateurs ne peuvent ni modifier ni supprimer.
• Horodatage: Utilisez des sources de temps synchronisées et fiables sur les systèmes mainframe, distribués et cloud.
• Portée: L'enregistrement indique le périmètre et les autorisations en vigueur au moment de la décision, et non les paramètres actuels.
• Traçabilité: Un examinateur peut suivre un fil conducteur depuis l'incident jusqu'aux preuves, à la recommandation, à l'approbation, à l'action et au résultat.
• Conservation des données: Conservez les documents conformément à vos obligations légales, réglementaires et organisationnelles applicables.

Les durées de conservation varient selon le secteur d'activité, la juridiction et le type de document. Il appartient à vos équipes de conformité, juridiques et de gestion des risques de les définir.

À quoi ressemble un enregistrement d'audit d'IA lors d'un incident de traitement par lots sur un mainframe ?

Un rapport d'audit IA utile se présente comme un court récit d'incident vérifiable. Voici à quoi devrait ressembler le redémarrage de la tâche de règlement à 2 h 47 du matin, tel qu'il apparaît dans le scénario initial.

Scénario: Le traitement nocturne de règlement des paiements, PAYSETL01, s’interrompt anormalement à l’étape 040 avec le code d’erreur SQL Db2^® -911. Une transaction CICS (Customer Information Control System) en ligne a dépassé son délai normal et a bloqué la table de règlement. Un agent d’IA enquête, identifie le conflit de verrouillage et recommande un redémarrage une fois le verrouillage levé. L’opérateur d’astreinte transmet l’information au responsable des opérations par lots, qui donne son accord.

Remarquez l'utilité de cet enregistrement. Un auditeur peut vérifier chaque affirmation sans contacter personne. L'opérateur peut comprendre la raison de l'appel de l'agent. L'équipe en charge de l'application bénéficie d'un suivi clair, sans incertitude.

Où se situe Rocket EVA ?

Rocket^® EVA^™ Elle s'avère particulièrement utile lorsque les équipes opérationnelles ont besoin d'un diagnostic assisté par l'IA qui produise des preuves qu'un humain peut examiner avant toute modification de la production.

D'après IDC, Rocket EVA permet aux opérateurs et développeurs informatiques de poser des questions en langage naturel et de recevoir des recommandations sur l'état des incidents, leurs dépendances et les corrélations entre leurs causes profondes, à partir de sources telles qu'IBM Db2^®, SMF, TMON/SDSF et les données du gestionnaire de charge de travail. IDC précise également que Rocket EVA s'intègre aux systèmes de gestion des tickets comme Jira, ce qui facilite le lien entre une recommandation et l'enregistrement de l'incident, ainsi que la manière dont votre organisation a déjà résolu des problèmes similaires.

Cela correspond directement aux éléments Contexte, Preuve et Recommandation du cadre. Lorsqu'une recommandation est accompagnée des signaux justificatifs, les opérateurs peuvent la valider et les auditeurs peuvent en retracer le cheminement ultérieurement. Cela permet également au personnel moins expérimenté de mener une enquête, tandis que les experts en systèmes mainframe conservent la maîtrise des décisions complexes.

Pour les éléments Identité, Autorité, Approbation humaine et Action, veuillez vérifier les fonctionnalités actuelles à l'aide de la documentation officielle de Rocket Software. L'objectif reste le même: améliorer le diagnostic et la maîtrise des actions au sein des systèmes que vous utilisez déjà, sans perturber les processus auxquels vos équipes font confiance.