Logs, traces et auditabilité des systèmes IA : obligations légales et architecture minimale

25/07/2026

Un système IA en production prend des décisions qui affectent des personnes, des contrats, des risques. Quand un régulateur frappe à la porte — CNIL, autorité nationale de surveillance AI Act, ou client exigeant un audit — la première question est toujours la même : pouvez-vous me montrer ce que votre modèle a fait, quand, pourquoi, et sur quelle base ? La réponse tient en grande partie dans vos logs. Voici ce qu'impose la réglementation, ce qu'il faut construire, et comment éviter les pièges classiques.

Ce que la réglementation exige concrètement

AI Act : journalisation obligatoire pour les systèmes à haut risque

Le règlement européen sur l'IA (AI Act, entré en application progressive depuis août 2024) impose aux systèmes IA à haut risque (Annexe III : recrutement, crédit, contrôle d'accès, justice, etc.) une journalisation automatique des événements pertinents pendant toute la durée d'utilisation. L'article 12 précise que ces logs doivent permettre de retracer le fonctionnement du système et d'identifier les périodes durant lesquelles le système a opéré. La durée de conservation minimale est de 6 mois pour les déployeurs, mais peut atteindre 10 ans pour certains secteurs réglementés.

Pour les systèmes IA à usage général (GPAI) de haute puissance, le fournisseur doit maintenir une documentation technique et des journaux suffisants pour démontrer la conformité à la demande du Bureau de l'IA européen.

RGPD : traçabilité des décisions automatisées

L'article 22 du RGPD encadre les décisions entièrement automatisées produisant des effets juridiques. En cas d'exercice du droit d'accès (article 15) ou de contestation d'une décision, le responsable de traitement doit être capable de fournir la logique sous-jacente à la décision individuelle concernée. Sans logs structurés associant chaque décision à un identifiant de requête, une version de modèle et les données d'entrée, cet exercice devient impossible — et constitue un manquement caractérisé.

Directives sectorielles complémentaires

Finance (DORA, EBA guidelines) : traçabilité des modèles utilisés en scoring et détection de fraude, avec versioning obligatoire.
Santé (MDR, HDS) : journaux d'utilisation des dispositifs logiciels, dont les IA diagnostiques, conservés 10 ans minimum.
Marchés publics : toute décision d'attribution ou de notation assistée par IA doit être reconstituable a posteriori.

Architecture technique minimale pour l'auditabilité IA

Les 5 couches indispensables

Une architecture d'auditabilité ne se résume pas à activer les logs d'un framework. Elle couvre cinq niveaux distincts :

1. Logs d'inférence : horodatage, identifiant de requête unique, version du modèle, hash des données d'entrée (ou données complètes si base légale), sortie brute du modèle, score de confiance.
2. Registre de modèles (Model Registry) : version, date d'entraînement, dataset utilisé, métriques de performance, validation éthique effectuée. MLflow, AWS SageMaker Model Registry ou une solution interne font l'affaire.
3. Logs applicatifs contextuels : qui a déclenché l'inférence (ID utilisateur ou système), dans quel flux métier, quelle action a suivi la décision IA.
4. Logs d'accès et de modification : qui a consulté, modifié ou supprimé les logs eux-mêmes — pour garantir l'intégrité de la piste d'audit (WORM storage recommandé).
5. Alertes et anomalies : dérive de distribution (data drift), pic de latence, taux d'erreur anormal — signaux précoces d'un comportement inattendu du modèle.

Exemple concret : scoring de crédit automatisé

Une fintech utilise un modèle XGBoost pour pré-scorer des demandes de crédit. Chaque appel à l'API d'inférence génère automatiquement un enregistrement JSON immuable contenant : request_id, model_version, input_hash, score, decision_threshold, timestamp, applicant_id_pseudonymisé. Ces logs sont stockés dans un bucket S3 avec Object Lock (WORM) pendant 7 ans. Lors d'une contestation client, l'équipe conformité retrouve en moins de 5 minutes la décision exacte, le modèle actif à cette date et les valeurs d'entrée pseudonymisées — suffisant pour répondre à une demande RGPD ou à l'autorité de supervision bancaire.

Pseudonymisation et minimisation : ne pas tout loguer

Attention au réflexe inverse : loguer trop crée un risque RGPD supplémentaire. Les données personnelles brutes dans les logs constituent un traitement à part entière, avec sa propre base légale et sa durée de conservation. La bonne pratique consiste à loguer des hash ou identifiants pseudonymisés, couplés à une table de correspondance chiffrée accessible uniquement en cas de procédure formelle. Documentez cette architecture dans votre registre des traitements.

Se préparer à un contrôle : le checklist opérationnel

Ce que le contrôleur va demander

Qu'il s'agisse d'un audit CNIL, d'un contrôle AI Act par l'autorité nationale désignée, ou d'un audit client, les demandes convergent autour de quatre axes :

Démontrer qu'une décision spécifique a bien été prise par votre système à une date donnée.
Prouver quelle version du modèle était en production à cette date.
Montrer que les logs n'ont pas été modifiés après coup (intégrité).
Présenter votre politique de conservation et les accès aux journaux.

Les erreurs qui font échouer un contrôle

Logs écrasés après 30 jours par défaut de configuration (très fréquent sur les environnements cloud mal paramétrés).
Absence de versioning de modèle : impossible de savoir quel modèle a produit quelle décision.
Logs dispersés dans 4 outils différents sans corrélation possible par request_id commun.
Aucune séparation des rôles : les développeurs peuvent modifier les logs de production.
Documentation de conformité qui décrit une architecture différente de ce qui est réellement déployé.

Le rôle du DPO et du RSSI dans la gouvernance des logs IA

La gouvernance des logs IA ne relève pas uniquement de l'équipe data engineering. Le DPO doit valider la base légale du logging, la durée de conservation et les droits d'accès. Le RSSI assure l'intégrité, le chiffrement au repos et la détection d'accès non autorisés. Le responsable conformité IA (ou le RSSI en double casquette) doit maintenir à jour la cartographie des systèmes IA et leur niveau de risque AI Act pour déterminer les obligations de journalisation applicables à chacun.

Dans les organisations sans shadow AI maîtrisé, ce travail commence par un inventaire : combien de systèmes IA tournent en production sans logging structuré ? La réponse surprend souvent les équipes dirigeantes.

FAQ

Quelle est la durée minimale de conservation des logs IA imposée par l'AI Act ?

L'AI Act impose aux déployeurs de systèmes à haut risque de conserver les logs au moins 6 mois. Certains secteurs (santé, finance) ont des obligations sectorielles pouvant aller jusqu'à 10 ans. Il est recommandé de se caler sur la durée la plus contraignante applicable à votre secteur.

Doit-on loguer les données personnelles des utilisateurs pour satisfaire au RGPD en cas de décision automatisée ?

Non, et c'est même déconseillé. La bonne pratique consiste à loguer des identifiants pseudonymisés ou des hash, couplés à une table de correspondance sécurisée. Cela permet de répondre à une demande d'accès RGPD sans stocker de données personnelles brutes dans les journaux de production.

Comment démontrer qu'un log n'a pas été falsifié a posteriori ?

Utilisez un stockage de type WORM (Write Once, Read Many), comme S3 Object Lock ou Azure Immutable Blob Storage. Ajoutez un hash cryptographique de chaque entrée de log et sééparez les droits : les équipes applicatives ne doivent pas pouvoir modifier les logs de production.

Les systèmes IA à faible risque sont-ils exemptés d'obligations de journalisation ?

L'AI Act n'impose pas d'obligations formelles de journalisation aux systèmes à faible ou minimal risque. Cependant, le RGPD s'applique dès qu'il y a traitement de données personnelles, et les bonnes pratiques de traçabilité restent fortement recommandées pour tout système en production.

Qu'est-ce qu'un registre de modèles (Model Registry) et pourquoi est-il indispensable pour la conformité ?

Un Model Registry est un référentiel centralisé qui stocke pour chaque version de modèle : les métadonnées d'entraînement, les métriques, la date de déploiement et les validations effectuées. Il permet de répondre à la question clé lors d'un audit : 'Quel modèle exact était en production à la date de cette décision ?'