A.6.2.8 — Enregistrer les journaux d'événements d'un système d'IA
Une ligne dans l'Annexe A, et l'un des contrôles les plus lourds de conséquences : sans journal, aucune dérive ne s'établit après coup, aucune décision ne se reconstitue, aucun incident ne s'explique.
Le contrôle A.6.2.8 est le dernier du domaine A.6, consacré au cycle de vie. Il porte sur l’enregistrement des journaux d’événements, c’est-à-dire sur la capacité à reconstituer, après coup, ce qu’un système d’IA a fait.
Pourquoi un système d’IA se journalise autrement
Une application ordinaire journalise ses erreurs, ses accès et ses temps de réponse. Cela sert à la réparer et à la sécuriser. ISO/IEC 27001 le couvre déjà, avec son contrôle de journalisation.
Un système d’IA pose une question de plus : pourquoi a-t-il produit ce résultat-là ? Pour y répondre, il faut savoir quelle version du modèle a répondu, avec quelle configuration, à partir de quelles entrées, et ce qu’un humain a fait de la sortie. Un journal de sécurité ne contient rien de tout cela. La journalisation d’A.6.2.8 s’appuie sur la même infrastructure, mais son objet diffère : la traçabilité des décisions, pas seulement des accès.
C’est aussi ce qui la relie au reste du référentiel. La surveillance d’A.6.2.6 ne peut établir une dérive qu’à partir de relevés conservés ; un incident qui révèle une non-conformité appelle, en 10.2, la recherche de ses causes ; une évaluation d’impact rejouée après un changement a besoin de comparer l’avant et l’après.
Ce qu’un journal utile contient
La norme ne fixe aucun contenu. Le tableau qui suit décrit ce que la pratique retient pour pouvoir reconstituer une décision : c’est une base de réflexion, pas une exigence.
| Élément | À quoi il sert |
|---|---|
| Horodatage et identifiant de la requête | Retrouver un cas précis, et le relier à une réclamation |
| Version du modèle et de la configuration — invite système, paramètres, garde-fous actifs | Savoir quel système a réellement répondu, surtout quand un fournisseur met son modèle à jour |
| Entrées, ou leur référence lorsqu’elles sont sensibles | Rejouer le cas, ou comprendre ce que le système a reçu |
| Éléments de contexte récupérés, pour un système qui interroge une base documentaire | Distinguer une erreur du modèle d’une erreur de la source |
| Sortie produite | Constater ce qui a été dit ou décidé |
| Intervention humaine : validation, correction, rejet | Établir qui a décidé en dernier ressort |
| Événements d’exploitation : erreurs, refus, déclenchement d’un garde-fou, franchissement d’un seuil | Alimenter la surveillance et l’analyse des incidents |
À quelles étapes du cycle de vie
Le contrôle laisse à l’organisation le choix des étapes, avec un plancher : l’utilisation. Au-delà, trois moments méritent réflexion.
Pendant le développement, les journaux d’entraînement et d’expérimentation — quels jeux de données, quels paramètres, quels résultats — permettent de reproduire un modèle et de répondre à une question sur un biais constaté plus tard.
Au déploiement, la trace de ce qui a été mis en service, quand et sur décision de qui, relie le journal d’exploitation à une version identifiée.
Au retrait, le sort des journaux se décide : combien de temps les garder après l’arrêt du système, et pour quel usage.
Combien de temps les conserver
ISO/IEC 42001 ne fixe aucune durée. Ses lignes directrices rattachent la conservation des journaux à l’usage prévu du système et à la politique de conservation des données de l’organisme (B.6.2.8, repris en B.9.4), en signalant que des exigences légales de conservation peuvent s’y appliquer — dans un sens comme dans l’autre ; la maîtrise de l’information documentée (7.5.3) s’y ajoute. En pratique, la durée se justifie par l’usage : assez longtemps pour établir une dérive ou instruire une réclamation, pas plus longtemps que nécessaire.
Deux contraintes extérieures pèsent sur ce choix.
Le RGPD, dès que les journaux contiennent des données personnelles — et une invite ou une sortie en contient souvent. Ils deviennent alors un traitement à part entière, soumis à la limitation de la durée de conservation et à la sécurité. Un journal d’IA est fréquemment l’un des jeux de données les plus sensibles de l’organisation, sans que personne l’ait décidé.
L’AI Act, pour les systèmes à haut risque. Le règlement impose que ces systèmes permettent techniquement l’enregistrement automatique des événements tout au long de leur vie (article 12). Il oblige leurs fournisseurs à conserver les journaux qu’ils contrôlent (article 19), et leurs déployeurs à conserver ceux qui sont sous leur contrôle (article 26), dans les deux cas pendant au moins six mois, sauf disposition contraire. Les obligations de haut risque s’appliquent selon un calendrier reporté en juillet 2026, détaillé dans la page consacrée à l’articulation entre la norme et le règlement.
Un contrôle excluable, rarement défendable
A.6.2.8 est un contrôle de l’Annexe A comme les autres : la déclaration d’applicabilité peut l’écarter, avec une justification. Une organisation peut donc rester certifiée sans l’avoir retenu.
La justification tient dans peu de cas : un système sans effet sur quiconque, ou un service tiers dont l’organisation ne maîtrise aucun journal — et même là, l’exclusion est rarement totale, parce que l’usage qu’elle en fait reste journalisable de son côté.
Pour un système à haut risque au sens de l’AI Act, la question ne se pose plus : la journalisation y est une obligation légale. Écarter A.6.2.8 perd alors aussi son appui au regard de la norme, qui rattache l’exclusion d’un contrôle à l’absence d’exigence externe qui l’imposerait (6.1.3 f) et fait engager l’organisme, dans sa politique IA, à respecter les exigences applicables (5.2 c). La norme ne reprend pas pour autant les obligations du règlement : un certificat ne dispense pas de les vérifier une à une.
Ce que le contrôle ne demande pas
Aucun outil, aucun format, aucune durée, aucune liste de champs. Il n’exige pas de plateforme de gestion des journaux ni d’outillage d’apprentissage automatique : un enregistrement structuré, conservé et consultable suffit.
Il n’exige pas non plus de conserver les entrées en clair. Une référence, une empreinte ou une version pseudonymisée satisfont souvent le besoin de traçabilité, et servent mieux la protection des données.