Journaliser les décisions d’un AI Agent n8n pour l’audit : tool calls, raisonnement et traçabilité

Le node AI Agent de n8n décide seul quels outils appeler, dans quel ordre, et avec quels arguments. C’est précisément ce qui en fait un outil puissant — et ce qui pose un problème dès qu’une décision doit être expliquée après coup. « Pourquoi l’agent a-t-il remboursé ce client ? », « Sur quelle base a-t-il classé cet email comme non urgent ? » : sans trace structurée, la seule réponse possible est de rejouer l’exécution dans l’interface n8n, si elle n’a pas déjà expiré. Ce guide montre comment transformer le raisonnement d’un agent — ses appels d’outils, ses observations, sa décision finale — en une piste d’audit interrogeable, en s’appuyant sur le node AI Agent et sur le patron de journalisation déjà détaillé dans notre guide de piste d’audit RGPD avec n8n et Supabase.

Le problème : les données d’exécution n’sont pas une piste d’audit

n8n conserve les données d’exécution de chaque run, consultables dans l’interface — mais cette trace a trois limites pour un usage d’audit. Elle est soumise à une politique de rétention (souvent quelques jours ou semaines en self-hosted, moins en cloud selon le plan) : au-delà, elle disparaît. Elle n’est pas interrogeable par un tiers ou un outil de reporting : impossible de faire « montrez-moi tous les remboursements décidés par l’agent le mois dernier » sans ouvrir chaque exécution une par une. Et elle mélange la trace technique (nodes, timings, erreurs réseau) avec la décision métier qui intéresse un auditeur. Ce qu’il faut, c’est une table dédiée, alimentée à chaque exécution, qui isole les décisions et leur justification — exactement le rôle que joue déjà le workflow « Enregistrement d’audit dans Supabase » du Pack Conformité & Audit, qu’on adapte ici aux décisions d’un agent plutôt qu’aux réponses d’un questionnaire.

Ce que révèle réellement l’option Return Intermediate Steps

Le node AI Agent alterne raisonnement et action selon le schéma ReAct — nous détaillons ce mécanisme dans notre guide du RAG agentique. Dans les options du node, l’option Return Intermediate Steps fait sortir ce cheminement plutôt que la seule réponse finale : un tableau intermediateSteps, où chaque élément contient l’action décidée (nom de l’outil, arguments passés) et l’observation renvoyée par cet outil. C’est la matière première de la piste d’audit : sans elle, on ne connaît que la réponse de l’agent, jamais le chemin qui y a mené.

Étape 1 — Activer la trace sur le node AI Agent

Dans les paramètres du node AI Agent, section Options, cochez Return Intermediate Steps. La sortie du node change de forme : au lieu d’un simple champ output, vous obtenez output (la réponse finale) et intermediateSteps (le tableau des cycles réflexion-action). Si l’agent utilise des outils personnalisés ou des Vector Store Tools, chaque appel apparaît comme une entrée distincte du tableau, avec le nom de l’outil et les arguments exacts envoyés.

Étape 2 — Mettre en forme les étapes avant l’insertion

Un node Code juste après l’agent aplatit le tableau en lignes prêtes à insérer :

const steps = $input.first().json.intermediateSteps ?? [];
const rows = steps.map((step, i) => ({
  json: {
    agent_run_id: $execution.id,
    step_order: i,
    tool_name: step.action?.tool ?? null,
    tool_input: JSON.stringify(step.action?.toolInput ?? {}),
    observation: typeof step.observation === "string"
      ? step.observation.slice(0, 4000)
      : JSON.stringify(step.observation).slice(0, 4000),
  },
}));
rows.push({
  json: {
    agent_run_id: $execution.id,
    step_order: steps.length,
    tool_name: "__final_answer__",
    tool_input: null,
    observation: $input.first().json.output,
  },
});
return rows;

La troncature à 4000 caractères évite qu’une observation volumineuse (un document entier récupéré par un outil de recherche) ne fasse exploser la table — dans l’immense majorité des cas d’audit, les premiers caractères d’une observation suffisent à comprendre la décision ; conservez le contenu complet ailleurs (vector store, fichier) si un besoin de relecture intégrale existe.

Étape 3 — Un sub-workflow de journalisation dédié aux décisions d’agent

Comme pour la piste d’audit RGPD, isolez l’insertion dans un sub-workflow appelé via Execute Sub-workflow plutôt que de dupliquer un node Supabase dans chaque workflow contenant un agent. Le schéma Supabase, distinct de la table audit_log générique :

create table if not exists agent_decision_log (
  id bigserial primary key,
  agent_run_id text not null,
  workflow_name text not null,
  step_order int not null,
  tool_name text,
  tool_input jsonb,
  observation text,
  recorded_at timestamptz not null default now()
);
create index if not exists idx_agent_decision_run
  on agent_decision_log (agent_run_id, step_order);

Le node Supabase du sub-workflow reçoit chaque ligne produite à l’étape 2 et l’insère avec Insert. Reconstituer une décision devient une simple requête : select * from agent_decision_log where agent_run_id = '...' order by step_order — l’équivalent d’un débogueur pour une exécution disparue depuis longtemps de l’historique n8n.

Deux cas d’usage concrets

Sur l’agent de triage email du Pack Inbox IA, la piste d’audit montre pourquoi un message a été classé « urgent » plutôt qu’« administratif » : l’outil de scoring appelé, les mots-clés détectés en entrée, le score renvoyé. Sur l’assistant RAG documentaire du Pack Assistant RAG, elle montre quelle base a été interrogée, avec quelle requête reformulée, et quels passages ont réellement fondé la réponse — la garantie, en cas de contestation, que la réponse « n’est pas dans nos documents » n’est pas une invention du modèle mais le résultat d’une recherche réellement infructueuse.

Ce qu’impose vraiment le règlement européen sur l’IA — et ce qu’il n’impose pas

Nicholas Diakopoulos, dans un article de référence publié en 2016 dans Communications of the ACM (« Accountability in Algorithmic Decision Making »), posait déjà le principe qui structure cet article : un système automatisé n’est comptable de ses décisions que s’il existe une trace de son fonctionnement interne, pas seulement de son résultat. Le règlement européen sur l’IA (AI Act) en fait une obligation légale pour les systèmes classés « à haut risque » de l’annexe III (recrutement, scoring de crédit, dispositifs médicaux…) : l’article 12 impose une journalisation automatique tout au long du cycle de vie du système. Une étude de Buscemi et ses co-auteurs, publiée en 2026, propose d’ailleurs une méthode pour traduire ces exigences légales en vérifications techniques concrètes (« Assessing High-Risk AI Systems under the EU AI Act »). Le calendrier de ces obligations pour l’annexe III a toutefois été repoussé à décembre 2027 par la simplification dite « AI Omnibus » adoptée en 2025-2026 — un assistant interne ou un bot de support n’entre généralement pas dans ce périmètre à haut risque, mais la même journalisation reste la meilleure pratique disponible pour démontrer l’accountability exigée par l’article 5.2 du RGPD dès qu’un agent traite des données personnelles.

Aller plus loin : du log brut au rapport lisible

Une table agent_decision_log qui grossit chaque jour n’est utile que si quelqu’un peut en tirer une synthèse sans relire des milliers de lignes JSON. Le principe est le même que celui détaillé dans notre article sur le rapport de synthèse d’audit généré par IA : une Basic LLM Chain avec un Structured Output Parser, alimentée par les lignes d’un agent_run_id donné, qui produit un résumé structuré du raisonnement plutôt qu’un dump technique. Et pour surveiller ce que cette journalisation coûte réellement en appels supplémentaires, notre guide pour suivre le coût des appels IA dans n8n s’applique directement : chaque étape journalisée correspond à un appel déjà facturé par l’agent, la journalisation elle-même n’ajoutant qu’une écriture Postgres quasi gratuite.

Une piste d’audit des décisions d’agent n’est pas une case à cocher réglementaire dans la majorité des cas d’usage — c’est surtout ce qui transforme un agent IA de boîte noire en système dont on peut expliquer, une par une, les décisions passées.