Concevoir le journal d'audit de l'IA générative : ce qu'exigent le règlement européen sur l'IA, ISO/IEC 42001 et les lignes directrices japonaises, et comment conserver les preuves

Utiliser l'IA générative en interne, intégrer des fonctions d'IA à un produit, confier des tâches à des agents IA : quel que soit l'usage, vous aurez bientôt à expliquer « qui utilise cette IA, pour quoi faire, et comment elle est encadrée ». L'interlocuteur peut être un auditeur, ou le questionnaire de sécurité d'un client.

À ce moment-là, les explications orales et les documents de politique ne suffisent pas : la question est de savoir si vous pouvez le démontrer par des enregistrements. Cet article passe en revue, dans l'ordre, ce qu'exigent les réglementations et les normes, les champs à consigner, l'endroit où enregistrer et les conditions à remplir pour que le journal d'audit de l'IA générative soit recevable comme preuve.

Qu'est-ce que le journal d'audit de l'IA générative ?

Le journal d'audit de l'IA générative consigne, pour chaque exécution d'IA, « quand, qui (ou quel agent), avec quel modèle et quelle décision a été prise », et le conserve sous une forme qu'un tiers peut vérifier après coup.

Son objectif diffère de celui des journaux d'activité ou des journaux applicatifs habituels.

La différence majeure tient au fait que les lecteurs sont extérieurs à l'entreprise. Si vous ne pouvez pas leur montrer que « ce journal n'a pas été retouché après coup », il reste une preuve faible, aussi détaillé soit-il.

Pourquoi la « preuve d'usage de l'IA » est-elle demandée maintenant ?

Il y a trois raisons principales.

• Les questionnaires de sécurité des clients : les questions sur l'usage de l'IA générative (périmètre d'utilisation, données saisies, conservation des journaux) se multiplient
• Les audits SOC 2 Type II et ISMS (ISO/IEC 27001) : il faut démontrer que les contrôles ont fonctionné tout au long de la période d'observation, et l'usage de l'IA fait partie de ce qu'il faut expliquer
• La diffusion des agents IA : de plus en plus de tâches sont accomplies de manière autonome par une IA plutôt que par une personne, d'où le besoin d'enregistrements permettant de retracer « qui a fait quoi » au niveau de chaque IA

Tableau récapitulatif des exigences réglementaires et normatives

Contenu vérifié dans les sources primaires au 31 octobre 2026.

Le point à retenir : dans le règlement européen sur l'IA, c'est la date d'application qui a été reportée, et non l'exigence de journalisation elle-même. Au moment où l'application commencera, il faudra déjà disposer d'« au moins 6 mois » de journaux. Le plus réaliste est donc de mettre en place le dispositif de journalisation dès maintenant, et non juste avant la date d'application.

Sources primaires : Règlement européen sur l'IA, article 12 · article 19 · article 26 · article 113 (dates d'application) (AI Act Service Desk de la Commission européenne) / Lignes directrices japonaises pour les acteurs de l'IA (ministère japonais de l'Économie, du Commerce et de l'Industrie, en japonais) / Entrée en vigueur de la loi japonaise de promotion de l'IA (Bureau du Cabinet du Japon, en japonais)

Que faut-il consigner ?

Pouvoir consigner les champs suivants pour chaque exécution d'IA facilite grandement les explications.

Faut-il conserver le texte des prompts et des sorties ?

Dans la plupart des cas, il n'est pas nécessaire de conserver le texte lui-même : l'empreinte (hachage) et des métadonnées sans contenu suffisent.

Le texte contient facilement des données personnelles de clients ou des informations confidentielles, et plus on en accumule, plus les dommages sont importants en cas de fuite. Si vous conservez le hachage, vous pouvez, en cas de problème, le rapprocher du texte dont vous disposez pour vérifier que « c'étaient bien ces entrées et sorties ».

Les recommandations de l'OWASP sur la prévention des injections de prompt dans les LLM demandent elles aussi, depuis leur révision du 4 octobre 2026, de consigner dans les journaux « les métadonnées et décisions importantes pour la sécurité » et d'en exclure les identifiants d'authentification et les informations sensibles inutiles (OWASP Cheat Sheet).

Où enregistrer ?

Ce que l'on peut enregistrer, et le degré de confiance accordé, varient selon l'endroit où l'on enregistre.

Le plus sûr est de combiner le code et le proxy plutôt que de choisir l'un ou l'autre. Le proxy capte de manière exhaustive « le fait qu'un appel a eu lieu », et la raison d'une décision est enregistrée par la couche de code qui l'a prise.

Autre point important : un journal que vous écrivez et conservez vous-même est, à lui seul, difficilement jugé digne de confiance par des tiers. Il faut un mécanisme qui démontre qu'il ne peut pas être réécrit après coup. C'est l'objet de la section suivante.

Les conditions d'une preuve recevable en audit

Pour qu'un journal soit recevable comme « preuve », cinq conditions sont nécessaires.

1. Pouvoir montrer qu'il n'a pas été réécrit : en chaînant l'empreinte (hachage) de chaque enregistrement à celle du précédent, la modification d'un seul enregistrement intermédiaire rompt la concordance de tous les maillons suivants, ce qui rend toute altération détectable
2. Un tiers peut le vérifier lui-même : le journal doit pouvoir être vérifié localement, sans avoir à faire confiance à l'entreprise ou au service qui l'a produit
3. La durée de conservation est respectée : il doit couvrir le minimum de « 6 mois » du règlement européen sur l'IA ainsi que la période d'observation de l'audit (souvent 6 à 12 mois)
4. On sait qui a agi : avec un compte ou une clé partagés, impossible d'expliquer qui a utilisé l'IA. Enregistrez séparément les personnes et les agents
5. On voit quels champs manquent : indiquer explicitement les « champs non enregistrés » permet d'expliquer honnêtement le périmètre des enregistrements. Un journal dont on ignore ce qu'il ne contient pas perd au contraire en crédibilité

Les enjeux propres aux agents IA

Les agents IA appellent des outils et font avancer le travail de manière autonome, à la place d'une personne. Cela soulève des enjeux différents de ceux de l'IA générative utilisée par des humains.

• Identifier chaque agent : enregistrez séparément quel agent a fait quoi. Si tout tourne avec une seule clé d'API, aucune distinction n'est possible
• Conserver les appels d'outils : le risque n'est pas du tout le même selon que l'agent a seulement généré du texte ou qu'il a agi sur un système externe
• Consigner s'il y a eu une vérification humaine : savoir si une personne a vérifié avant une opération importante est directement lié à l'explication des responsabilités
• Inclure aussi les agents de codage : les agents de codage qu'utilisent quotidiennement les ingénieurs sont eux aussi, au niveau du trafic, des appels d'IA. On les oublie facilement, mais ils doivent faire partie du périmètre d'enregistrement

Ce que permet SPHIOR

La gouvernance de l'IA de SPHIOR est un dispositif conçu pour conserver des enregistrements répondant aux conditions décrites jusqu'ici.

Modes d'enregistrement (4 options)

IA et outils pris en charge

Lorsque l'API de destination appartient à un fournisseur connu, le proxy enregistre son nom ; dans les autres cas (modèle auto-hébergé, passerelle interne, etc.), il enregistre tel quel le nom d'hôte de destination. La destination n'est jamais complétée par une supposition arbitraire. La configuration est décrite dans la documentation.

Traitement des enregistrements

• Le contenu n'est pas envoyé : par défaut, le texte des prompts et des sorties n'est pas transmis ; seules l'empreinte (hachage) et les métadonnées sont enregistrées
• Conservation sous une forme qui rend toute altération détectable : chaque enregistrement est normalisé, haché et chaîné au précédent, puis l'ensemble est horodaté auprès d'une source externe
• Vérifiable par un tiers : avec l'outil de vérification que nous publions, on peut contrôler localement sans avoir à faire confiance à SPHIOR
• La décision reste celle de votre dispositif : l'autorisation ou le refus est décidé par vos propres garde-fous ; SPHIOR enregistre ce résultat
• Les champs non enregistrés sont également indiqués : par exemple, le proxy n'enregistre pas le coût tant qu'aucun tarif unitaire n'est configuré (le tarif réel variant selon les remises et les contrats, il n'est pas deviné). De plus, le proxy ne voit pas les décisions de vos garde-fous : celles-ci doivent être enregistrées depuis la couche de code

Ce que vous pouvez montrer à l'auditeur

• La liste des exécutions (filtrable par agent, modèle, décision et période)
• Le nombre d'exécutions par couple agent × modèle et la répartition des décisions (autorisé, refusé, etc.)
• Les informations de vérification de chaque enregistrement
• Un pack de vérification pour la période choisie (1 000 enregistrements au maximum par export ; au-delà, exportez en découpant la période)

Tarifs

Nous n'avons pas opté pour une facturation au volume. Avec une tarification à l'usage, « moins on enregistre, moins on paie », ce qui contredit l'objectif d'un enregistrement exhaustif. Les offres payantes n'interrompent pas l'enregistrement en cas de dépassement du plafond, et l'offre gratuite ne devient jamais payante à votre insu. Pour plus de détails, consultez les tarifs.

Questions fréquentes

Suffit-il de conserver les journaux 6 mois ?

Les articles 19 et 26 du règlement européen sur l'IA fixent un « minimum de 6 mois ». Une durée plus longue peut être exigée selon la finalité, et les audits tels que SOC 2 Type II imposent de couvrir la période d'observation (souvent 6 à 12 mois). Si d'autres textes prévoient des dispositions différentes, il faut aussi s'y conformer.

Sans conserver le texte des prompts, comment enquêter en cas de problème ?

Si vous conservez l'empreinte (hachage), vous pouvez la rapprocher du texte encore disponible chez vous ou des journaux du fournisseur pour vérifier qu'il s'agissait bien de ces entrées et sorties. Plus on accumule de texte, plus les dommages d'une fuite sont importants : le plus réaliste est de décider de conserver ou non le texte en mettant en balance le besoin d'enquête et le risque de fuite.

Cela peut-il remplacer une certification ISO/IEC 42001 ?

Non. Une certification s'obtient à l'issue de l'audit d'un organisme de certification. Le journal d'audit est l'un des éléments utilisés lors de cet audit et pour vos explications en interne comme à l'externe.

Un journal produit en interne ne convient-il pas ?

Il peut convenir. Mais lorsque vous le présentez à des tiers, vous devez pouvoir expliquer qu'il « n'a pas été réécrit après coup ». Le rendre démontrable, par exemple au moyen d'une chaîne de hachages et d'un horodatage externe, raccourcit l'explication.

En résumé

• Le journal d'audit de l'IA générative est un enregistrement destiné à des tiers. Plus que le niveau de détail, ce qui compte est qu'il n'ait pas été réécrit et qu'on sache qui a agi
• Le règlement européen sur l'IA a reporté sa date d'application, mais l'exigence d'enregistrement automatique des journaux et de conservation d'au moins 6 mois demeure
• Le principe est de ne pas conserver le texte et d'enregistrer l'empreinte et les métadonnées. Indiquez aussi les champs non enregistrés
• Combinez le proxy et la couche de code, et incluez les agents IA et les agents de codage dans le périmètre d'enregistrement

À lire aussi : Gestion des changements sur GitHub : en faire une preuve pour ISO/IEC 27001 (ISMS) et SOC 2