La majorité des architectures de journalisation en entreprise ont été conçues pour des applications déterministes : un utilisateur se connecte, effectue une action, le log enregistre qui, quoi, quand. Un système d’IA générative ou un agent autonome casse ce modèle simple. Le « quoi » devient un prompt en langage naturel, potentiellement modifié en cours de session par une injection, et le « qui » peut être une chaîne de délégation entre un utilisateur, un agent, et les outils que cet agent invoque à son tour. La plupart des piles de journalisation actuelles ne capturent aucun de ces éléments spécifiques.
Journalisation : de quoi parle-t-on ?
Avant d’examiner ce que l’IA change, il faut revenir à la définition de référence en France. La CNIL décrit un système de journalisation comme l’enregistrement, dans des fichiers journaux (les « logs »), de trois familles d’événements : les activités métier des utilisateurs (les traces applicatives), les interventions techniques, y compris celles des administrateurs, et les anomalies et événements liés à la sécurité (les traces techniques ou « système »).
Sa recommandation du 14 octobre 2021 (délibération n° 2021-122) précise la finalité de ces dispositifs : assurer une traçabilité des accès et des actions des utilisateurs habilités à accéder aux systèmes d’information et, par voie de conséquence, aux traitements de données à caractère personnel mis en œuvre au sein de ces systèmes. Autrement dit, savoir qui a accédé à quelle donnée, sur quel système, et à quel moment. Cette conservation n’est pas une bonne pratique optionnelle : elle participe directement au respect du principe de sécurité posé par les articles 5 et 32 du RGPD.
Pour la CNIL, ces données servent à détecter et à investiguer : incident, intrusion, ou détournement d’usage par une personne pourtant habilitée. Un journal n’est pas un artefact de conformité que l’on archive, c’est un instrument d’enquête.
La CNIL recommande que les données de journalisation fassent l’objet d’une analyse automatisée, afin de permettre la détection rapide des utilisations indues. Stocker ne suffit pas, et cette exigence était déjà formulée en 2021, bien avant l’AI Act.
Cette définition a été construite pour des traitements déterministes, où l’utilisateur habilité et l’action tracée sont deux entités clairement identifiables. C’est précisément ce couple que les systèmes d’IA générative et les agents autonomes viennent brouiller, et c’est pourquoi une pile de logs conforme au socle CNIL peut rester structurellement aveugle à ce qu’un agent exécute réellement.
Ce que l’UE AI Act exige réellement
L’article 12 du règlement européen sur l’IA exige que les systèmes d’IA à haut risque disposent de capacités techniques permettant l’enregistrement automatique d’événements pertinents pendant toute leur durée de vie. Ces capacités doivent assurer un niveau de traçabilité adapté à la finalité du système, notamment afin d’identifier les situations susceptibles de présenter un risque, de faciliter la surveillance postérieure à la mise sur le marché et de surveiller le fonctionnement du système par le déployeur.
L’article 19 impose au fournisseur de conserver les journaux générés automatiquement qui sont sous son contrôle pendant une durée adaptée à la finalité du système, d’au moins six mois, sauf si le droit de l’Union ou le droit national prévoit une durée différente ou plus longue. Des règles sectorielles spécifiques peuvent également s’appliquer, notamment dans le domaine des services financiers.
L’article 18 constitue une obligation distincte : le fournisseur doit tenir à la disposition des autorités nationales compétentes, pendant dix ans à compter de la mise sur le marché ou de la mise en service du système, la documentation technique ainsi que plusieurs autres documents de conformité. Il est donc inexact de faire courir ce délai à compter du retrait du système du marché.
Point de vigilance calendaire : le calendrier initial ne prévoyait pas une application uniforme à tous les systèmes à haut risque le 2 août 2026. Le Digital Omnibus sur l’IA, adopté définitivement par le Conseil le 29 juin 2026, prévoit notamment une échéance au 2 décembre 2027 pour les systèmes d’IA à haut risque relevant de l’article 6(2) et de l’Annexe III, ainsi qu’une échéance au 2 août 2028 pour les systèmes relevant de l’article 6(1) et de l’Annexe I.
Ce report ne fait pas disparaître l’intérêt de mettre en place dès maintenant une journalisation structurée et proportionnée : il s’agit d’une mesure de préparation à la conformité, à la surveillance et à un éventuel audit, plutôt que d’une obligation supplémentaire explicitement imposée par l’article 12 avant l’échéance applicable.
Ce qu’un log IA doit contenir
La plupart des piles de logging applicatif classiques capturent une requête HTTP, un utilisateur authentifié, un code retour. C’est insuffisant pour un système d’IA. Un log exploitable doit inclure :
- L’identité complète de la chaîne d’action : l’utilisateur ou le système à l’origine de la requête, l’agent qui l’a traitée, et les éventuels outils ou sous-agents invoqués en cascade.La traçabilité de cette délégation suppose que chaque maillon dispose d’une identité propre et d’une clé API dédiée
- Le prompt et la réponse ou, pour les usages où le contenu intégral est trop sensible pour être conservé en clair, une empreinte permettant de le reconstituer ou de le vérifier sans stocker la donnée source
- L’état de la politique appliquée : quelles règles de filtrage ou de contrôle étaient actives au moment de l’interaction (un champ que la plupart des architectures actuelles omettent, alors qu’il est indispensable pour établir qu’un contrôle était bien en vigueur au moment des faits)
- Les données ou bases consultées, en particulier pour un système RAG, quelles sources ont contribué à la réponse générée, pour permettre de retracer une hallucination ou une fuite jusqu’à son origine
- L’horodatage et la période d’usage, avec une intégrité protégée contre toute modification a posteriori (signature ou chaînage cryptographique des enregistrements).
Pourquoi l’intégrité du log compte autant que son contenu
Un log modifiable après coup n’a aucune valeur probante en cas d’investigation ou de contrôle réglementaire. Les architectures les plus robustes appliquent un principe de append-only (ajout seul, sans possibilité de modification rétroactive) et une protection contre l’altération, par signature cryptographique ou horodatage certifié. C’est ce niveau d’exigence qui distingue un simple fichier de log applicatif d’une preuve d’audit défendable devant une autorité de contrôle.
Exploiter les logs en investigation, pas seulement les stocker
Un volume de logs conservé sans capacité d’exploitation ne sert à rien au moment critique. Deux usages doivent être anticipés dès la conception :
- La détection d’anomalie en quasi temps réel : repérer un comportement d’agent qui s’écarte de son périmètre habituel (accès à des systèmes inhabituels, volume de requêtes anormal) avant qu’un incident ne se propage.
- La reconstitution a posteriori : en cas d’incident avéré, pouvoir répondre rapidement à trois questions : quelles données ont été exposées, par quel chemin, et à partir de quelle identité initiale. Cette capacité dépend entièrement de la granularité des champs capturés au moment de l’interaction ; elle ne peut pas être reconstruite après coup si les logs sont trop pauvres.
Pour les agents connectés à des outils externes via des connecteurs, chaque appel d’outil doit être journalisé comme un événement à part entière, pas seulement l’interaction initiale avec le modèle, sous peine de perdre toute visibilité sur ce que l’agent a réellement exécuté au nom de l’utilisateur.
FAQ : Journalisation IA, logs IA, traçabilité des agents et AI Act
Faut-il conserver l’intégralité des prompts et réponses en clair ?
Six mois de rétention suffisent-ils pour tous les usages ?
C’est un plancher réglementaire, pas un plafond recommandé. Les secteurs financiers, de santé ou soumis à des obligations documentaires spécifiques doivent généralement conserver ces journaux plus longtemps, en cohérence avec leurs obligations sectorielles existantes.
Un fournisseur SaaS intégrant de l’IA journalise-t-il automatiquement pour moi ?
Structurer la journalisation de vos systèmes d’IA
Nos experts évaluent votre couverture de journalisation actuelle et accompagnent la mise en place d’une architecture de logs conforme et exploitable en investigation, en cohérence avec votre gouvernance IA et votre démarche globale de sécurité de l’IA.
Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.