Logs IA conformes RGPD : architecture et rétention pour l'audit

Le cadre réglementaire : la convergence RGPD et AI Act pour les logs IA

Deux régimes juridiques se superposent sur un même objet technique. Le premier, le Règlement général sur la protection des données (RGPD, Règlement (UE) 2016/679), protège la donnée personnelle : il impose la minimisation, la limitation des finalités et une durée de conservation strictement proportionnée. Le second, le Règlement (UE) 2024/1689 sur l'intelligence artificielle — l'AI Act — impose au contraire une traçabilité technique des décisions algorithmiques, matérialisée par des logs. Le log est précisément le pont entre ces deux impératifs : il doit prouver ce qu'a fait le système sans révéler qui étaient les personnes concernées.

La difficulté vient de ce que ces obligations pointent dans des directions opposées. Le RGPD pousse à effacer ; l'AI Act pousse à conserver. Cette tension n'est pas théorique : elle se règle à l'échelle de la donnée, champ par champ, dans l'architecture de logging elle-même.

Les obligations de logging visent au premier chef les systèmes d'IA à haut risque définis à l'annexe III du règlement : scoring de crédit, tri de CV, biométrie, éducation, justice, infrastructures critiques et santé. Ces systèmes concentrent les exigences d'enregistrement automatique parce que leurs décisions affectent directement des droits fondamentaux. Pour le détail des obligations qui pèsent sur ces systèmes et le calendrier applicable, je renvoie au dossier de référence consacré aux systèmes à haut risque, qui tient le rôle informationnel sur ce point.

La Commission européenne rappelle que l'un des enjeux centraux de l'AI Act est justement de rendre explicable une décision algorithmique : comme le souligne le portail officiel de la stratégie numérique de l'UE, il est souvent impossible de savoir pourquoi un système a pris une décision, ce qui rend le log indispensable pour vérifier qu'une personne n'a pas été injustement désavantagée. Le texte consolidé du règlement est disponible sur EUR-Lex.

Les exigences de traçabilité selon l'article 12 du Règlement IA

L'article 12 du Règlement (UE) 2024/1689 pose une obligation d'enregistrement automatique des événements (logs) sur toute la durée de vie du système à haut risque. Le principe est fonctionnel : la journalisation doit assurer un niveau de traçabilité approprié à la finalité du système, de manière à identifier les situations à risque, à soutenir la surveillance après commercialisation et à suivre le fonctionnement de l'outil dans la durée. Le service d'assistance officiel de l'AI Act résume cette exigence sans ambiguïté : les logs doivent aider à repérer les risques et à documenter l'exploitation du système.

Concrètement, une architecture conforme doit capturer quatre familles d'événements :

• Les entrées : les données soumises au système, y compris les prompts pour un modèle conversationnel, avec l'horodatage et le contexte de la requête. C'est le champ le plus sensible au regard du RGPD car il contient fréquemment des données personnelles brutes.
• Les sorties : la décision, le score ou le contenu généré, ainsi que le degré de confiance ou la probabilité associée, indispensable pour rejouer et contester une décision a posteriori.
• Les métadonnées techniques : version du modèle, version des données d'entraînement, identifiant de la session, ressources mobilisées, latence — tout ce qui permet de reconstituer l'état exact du système au moment de la décision.
• Les interventions humaines : validation, correction ou refus d'un opérateur, sans lesquels l'obligation de supervision humaine reste une déclaration d'intention invérifiable.

Pour les systèmes de biométrie visés au point 1 (a) de l'annexe III, l'article 12 exige un socle minimal encore plus précis : périodes d'utilisation, base de données de référence utilisée pour la comparaison, données d'entrée ayant produit une correspondance, et identité des personnes ayant vérifié les résultats. Cette granularité n'est pas un luxe : elle conditionne la capacité à reconstruire une décision lors d'un audit ou d'un contentieux.

Architecture technique d'un système de logging IA conforme

Une architecture de logging robuste se structure en quatre couches, chacune assumant une responsabilité distincte. Cette séparation n'est pas un raffinement d'ingénieur : elle est ce qui rend possible le respect simultané du RGPD et de l'AI Act.

Les quatre couches

• Ingestion : la capture des événements au plus près du modèle, via des collecteurs légers qui n'introduisent pas de latence significative. Cette couche ne fait que recevoir et transmettre ; elle ne stocke rien de façon durable.
• Traitement : le cœur du dispositif de conformité. C'est ici que s'effectue le filtrage, l'anonymisation et la minimisation en temps réel, avant toute écriture disque. Un événement qui traverse cette couche en ressort épuré de ses données personnelles inutiles.
• Stockage : des bases immuables (write-once-read-many) pour les logs de conformité, garantissant qu'aucune modification a posteriori n'est possible, à côté de bases classiques pour les logs opérationnels.
• Visualisation : les tableaux de bord d'audit et de supervision, qui exposent les logs de manière exploitable pour les équipes techniques, le DPO et les auditeurs.

Séparer les deux natures de logs

Le principe architectural le plus important, et le plus souvent négligé, est la séparation entre logs opérationnels et logs de conformité. Les premiers servent à surveiller la performance, la latence et la disponibilité : ils sont volumineux, à durée de vie courte, et n'ont pas vocation à contenir des données personnelles. Les seconds servent la preuve d'audit : ils sont moins volumineux, à durée de vie plus longue, immuables, et strictement encadrés par le RGPD.

Mélanger les deux flux, ce que fait la plupart des stacks par défaut, produit une base unique impossible à gouverner : trop de données personnelles pour le RGPD, pas assez d'intégrité pour l'audit. Chez IAPRO, sur nos installations souveraines on-premise, cette séparation est la première décision d'architecture, avant même le choix de la base de données, précisément parce qu'elle est irréversible une fois le système en production.

Sécuriser le log : techniques d'anonymisation et de minimisation

Le défi central est le suivant : comment journaliser sans stocker de données personnelles ? La réponse ne réside pas dans une purge après coup — juridiquement dangereuse car la donnée aura déjà été traitée illicitement — mais dans un traitement à la volée, dans la couche de traitement, avant l'écriture en base.

Trois techniques concrètes se combinent :

• Le masquage dynamique : les champs identifiés comme sensibles (nom, e-mail, numéro de sécurité sociale, adresse) sont remplacés par des marqueurs génériques dès la capture. Le log conserve la structure de l'événement sans la valeur identifiante.
• Le hachage cryptographique des identifiants : plutôt que de stocker un identifiant utilisateur en clair, on stocke son empreinte (hash salé). Cela permet de corréler plusieurs événements d'une même session — donc de rejouer une décision — sans jamais exposer l'identité réelle.
• La suppression automatique des PII : des règles de détection (expressions régulières, reconnaissance d'entités nommées) repèrent et suppriment les données personnelles présentes dans les champs libres, notamment les prompts, avant l'écriture.

Ces mesures relèvent directement de la protection des données dès la conception (privacy by design), exigence de l'article 25 du RGPD. La CNIL, dans ses recommandations de février 2025 sur l'IA et le RGPD, insiste sur le fait que le règlement permet une IA innovante à condition d'informer les personnes et de faciliter l'exercice de leurs droits — ce que seul un logging pensé en amont rend possible.

Une précision juridique essentielle : l'anonymisation véritable, au sens du RGPD, est irréversible et fait sortir la donnée du champ du règlement. La pseudonymisation, elle — dont relève le hachage salé — reste soumise au RGPD car la ré-identification demeure théoriquement possible. Confondre les deux est une erreur fréquente et coûteuse en audit.

Politiques de rétention : arbitrer entre traçabilité et droit à l'oubli

La durée de conservation est le point de friction le plus explicite entre les deux régimes. L'article 19 du Règlement (UE) 2024/1689 impose aux fournisseurs de systèmes à haut risque de conserver les logs générés automatiquement pendant au moins six mois, sauf disposition contraire du droit de l'Union ou national, notamment en matière de protection des données personnelles. Le service d'assistance de l'AI Act précise en outre que les institutions financières doivent intégrer ces logs à leur documentation de gouvernance interne au titre du droit des services financiers.

Face à cette obligation plancher, le RGPD oppose son principe de limitation de la conservation : une donnée personnelle ne peut être conservée au-delà de ce qui est nécessaire à la finalité poursuivie. La solution n'est pas de choisir un régime contre l'autre, mais de découpler la donnée technique de la donnée personnelle grâce à une rétention différenciée :

• Court terme (jusqu'à quelques mois) : logs détaillés incluant les données pseudonymisées, nécessaires au débogage et à l'analyse d'incident immédiat.
• Moyen terme (six mois et au-delà) : logs de conformité conservés pour l'audit, débarrassés des PII directement identifiantes, avec conservation des seules métadonnées de décision.
• Long terme : métadonnées agrégées et statistiques anonymisées, échappant au RGPD, pour le suivi du drift et de la performance dans la durée.

Cette gradation permet de tenir le plancher des six mois de l'AI Act sur les métadonnées de décision tout en purgeant précocement les données personnelles superflues. Pour projeter le coût de stockage et de traitement associé à ces politiques, notre calculateur de ROI IA aide à dimensionner l'infrastructure avant le déploiement.

Gestion spécifique des logs pour les modèles à usage général (GPAI)

Les modèles d'IA à usage général — GPAI, pour general-purpose AI — obéissent à une logique de traçabilité distincte de celle des systèmes à haut risque. Un modèle de fondation n'est pas rattaché à une finalité unique : il alimente des applications multiples et variées. Les obligations pesant sur ses fournisseurs, effectives depuis août 2025, portent moins sur le log d'exploitation que sur la transparence relative aux données d'entraînement et sur l'identification du contenu généré.

Deux exigences structurent la journalisation côté GPAI. D'une part, la documentation des sources de données d'entraînement, qui relève d'une traçabilité de la conception plutôt que de l'exécution. D'autre part, l'obligation, au titre des règles de transparence applicables à compter du 2 août 2026, de rendre le contenu généré par l'IA identifiable — par marquage ou métadonnée technique. Cette dernière exigence a une conséquence directe sur le logging applicatif : le log doit tracer non seulement la décision, mais aussi le fait qu'un contenu a été produit par une machine, information susceptible d'être exigée lors d'un contrôle.

Pour une entreprise qui déploie une application au-dessus d'un GPAI, la répartition des responsabilités est cruciale. Le fournisseur du modèle porte les obligations de transparence sur l'entraînement ; le déployeur porte les obligations de logging propres à son usage. Confondre ces deux niveaux conduit soit à sur-collecter, soit à laisser des angles morts. Cette distinction fournisseur/déployeur est l'un des points les plus mal maîtrisés que je rencontre en audit ; le glossaire IA d'IAPRO détaille les définitions exactes de ces rôles.

Auditabilité et supervision humaine : transformer le log en outil de pilotage

Un log n'a de valeur que s'il rend la supervision humaine effective. L'AI Act exige que les systèmes à haut risque soient conçus pour permettre une intervention humaine — mais comment un opérateur pourrait-il intervenir utilement si le log ne lui fournit ni le contexte de la décision, ni le degré de confiance, ni l'historique des événements ? La journalisation est la condition matérielle de la supervision, pas un artefact administratif produit après coup.

Un tableau de bord d'audit bien conçu remplit trois fonctions de pilotage :

• Détection des biais : en agrégeant les décisions par catégorie, il révèle les écarts de traitement systématiques — par exemple un taux de refus anormalement élevé sur un sous-groupe — qui signalent une discrimination potentielle.
• Détection du drift : la comparaison des distributions d'entrées et de sorties dans le temps met en évidence la dérive du modèle, moment où ses performances se dégradent parce que la réalité s'éloigne des données d'entraînement.
• Détection des erreurs critiques : l'alerte en temps réel sur les décisions à fort impact ou les anomalies techniques permet une intervention avant que le préjudice ne se matérialise.

La formation à l'IA — obligation de l'article 4 du Règlement (UE) 2024/1689, applicable depuis février 2025 — trouve ici son ancrage concret : les opérateurs doivent savoir lire ces tableaux de bord. Bpifrance, partenaire de France Num, propose d'ailleurs des ressources d'acculturation sur ce point, comme le webinaire « IA et réglementation : faire de la conformité un outil de confiance ».

Cas pratique : déploiement d'un système de scoring de crédit conforme

Prenons une institution financière — un établissement de crédit régional de taille intermédiaire — qui déploie un système de scoring pour l'octroi de prêts. Le scoring de crédit figure explicitement parmi les usages à haut risque de l'annexe III. Voici comment se déroule la mise en conformité de son logging.

Étape 1 — Identification des données sensibles. L'équipe cartographie les champs entrant dans le score : revenus, historique bancaire, situation familiale, éventuelles données de santé indirectes. Chaque champ est classé selon sa sensibilité RGPD et son utilité pour l'audit. Les données non nécessaires au réexamen d'une décision sont écartées du log de conformité dès cette étape.

Étape 2 — Architecture de logging avec filtrage PII. Le nom et le numéro de client sont remplacés par un identifiant haché salé ; les valeurs financières sont conservées sous forme catégorielle (tranches) plutôt qu'en valeur exacte lorsque c'est suffisant. Le score produit, les variables l'ayant le plus influencé et la version du modèle sont enregistrés en base immuable.

Étape 3 — Politique de rétention sectorielle. Conformément à l'article 19, les logs sont conservés au minimum six mois ; mais le droit des services financiers impose ici une intégration à la documentation de gouvernance interne, souvent sur plusieurs années. La rétention différenciée s'applique : données pseudonymisées purgées tôt, métadonnées de décision conservées pour la durée exigée par le droit bancaire.

Étape 4 — Procédure d'audit en cas de contestation. Lorsqu'un demandeur conteste un refus, l'établissement rejoue la décision à partir du log immuable : version du modèle, variables décisives, degré de confiance. Il peut ainsi démontrer que la décision était fondée et non discriminatoire, ou au contraire identifier une erreur et la corriger. C'est la traçabilité qui rend le droit de contestation opérant. Les enjeux sectoriels propres au secteur financier sont approfondis dans notre hub solutions IA par métier.

Roadmap opérationnelle pour les entreprises : du diagnostic à la mise en conformité

Pour une organisation qui part d'une situation non conforme — ce qui est la règle plus que l'exception — voici la séquence que j'applique en mission.

• 1. Audit des flux de données IA existants. Cartographier chaque système d'IA en production, sa qualification (haut risque ou non), les données qu'il traite et les logs déjà générés. Sans cet inventaire, aucune décision d'architecture n'est fiable.
• 2. Choix de la stack technique de logging. Retenir une solution assurant l'immuabilité, l'horodatage et le traitement en temps réel des PII. Pour une IA souveraine, privilégier une stack on-premise ou hébergée dans l'UE, afin d'éviter tout transfert hors Union.
• 3. Rédaction d'une politique de rétention claire. Documenter, champ par champ, la durée de conservation, la finalité et la base légale. Cette politique est le premier document que réclamera un auditeur.
• 4. Formation des équipes techniques. Acculturer développeurs et opérateurs aux principes croisés du RGPD et de l'AI Act, en application de l'article 4. Un ingénieur qui ne distingue pas anonymisation et pseudonymisation reproduira l'erreur en production.
• 5. Mise en place d'un monitoring continu. Déployer les tableaux de bord d'audit et les alertes, puis réviser périodiquement la configuration à mesure que les usages évoluent.

Cette roadmap se déroule sur quelques semaines à quelques mois selon la maturité de l'organisation. Elle mobilise conjointement le DPO, le CTO et les métiers — la conformité du logging n'est jamais un projet purement technique.

Conclusion : la conformité comme levier de confiance et de compétitivité

Maîtriser ses logs IA n'est pas une contrainte défensive, c'est une barrière à l'entrée. Une entreprise capable de rejouer et de justifier chacune de ses décisions algorithmiques protège sa réputation, sécurise son innovation et se présente sereinement à un contrôle. À l'inverse, celle qui découvre son architecture de logging le jour de l'audit paie le retard au prix fort. La traçabilité bien conçue transforme une obligation réglementaire en preuve de sérieux vis-à-vis des clients, des partenaires et des autorités. C'est exactement l'esprit que défend la CNIL lorsqu'elle présente le RGPD comme un facteur de confiance et de sécurité juridique, et non comme un frein à l'IA.

FAQ — Logs IA, RGPD et AI Act

Pour aller plus loin avec IAPRO

La conformité de vos logs IA se décide à l'architecture, pas au moment de l'audit. Chez IAPRO, nous installons des systèmes d'IA souveraine on-premise dont la journalisation est pensée dès la conception pour tenir ensemble le RGPD et le Règlement (UE) 2024/1689. Si vous déployez ou prévoyez de déployer un système à haut risque, parlons de votre architecture de logging avant qu'elle ne soit figée : contactez notre équipe pour un diagnostic de traçabilité.

Liens utiles

• Glossaire IA IAPRO
• Solutions IA par métier
• Calculateur de ROI IA
• Contact IAPRO
• Systèmes d'IA à haut risque — guide de référence
• Article 12 — Record-keeping (AI Act Service Desk)
• Article 19 — Automatically generated logs (AI Act Service Desk)
• Recommandations CNIL IA et RGPD (février 2025)