IA Act: Journalisation et rétention des données pour les systèmes d'IA

À retenir

• L'article 12 est une obligation de conception qui incombe au fournisseur (le système doit générer des journaux automatiquement) ; l'article 26, paragraphe 6, est l'obligation du déployeur de conserver ces journaux sous son contrôle pendant une durée adaptée à la finalité, et d'au moins six mois (analyse détaillée de l'article 26).
• La rétention zéro au niveau du LLM ne vous décharge quasiment d'aucune obligation, car les événements à journaliser (référence de l'entrée, version du modèle, score de confiance, décision de relecture humaine) se trouvent dans votre couche d'orchestration, pas dans le stockage de l'éditeur du modèle.
• Le calendrier a bougé : le règlement (UE) 2026/1744, entré en vigueur le 27 juillet 2026, a reporté du 2 août 2026 au 2 décembre 2027 les obligations applicables aux systèmes d'IA à haut risque autonomes listés à l'Annexe III.
• Journalisez les métadonnées et des empreintes (hashes), pas le contenu brut des documents : vous respectez ainsi l'exigence de traçabilité sans transformer votre piste d'audit en une seconde copie des données personnelles que vous étiez censé minimiser.

La rétention zéro chez mon fournisseur de LLM me dispense-t-elle de la journalisation prévue à l'article 12 ?

Non. La rétention zéro des données est un engagement de l'éditeur du modèle à ne pas conserver vos prompts et vos réponses ; cela ne dit rien de ce que votre pipeline doit enregistrer de son côté. Le ZDR (zero data retention) est volontairement circonscrit : il signifie en général que les prompts et sorties concernés ne sont pas écrits dans le stockage durable du fournisseur après traitement, mais cela ne couvre pas automatiquement les métadonnées, les outils, les journaux clients, les fichiers, les caches, les signaux de sécurité, ni les exceptions légales.

C'est la répartition des responsabilités qui compte ici. L'article 12 est l'obligation de conception, côté fournisseur, en matière de tenue de registres : un système d'IA à haut risque doit être techniquement capable d'enregistrer automatiquement les événements. L'article 26, paragraphe 6, est l'obligation de conservation côté déployeur : celui-ci conserve les journaux sous son contrôle pendant au moins six mois, sauf si une autre disposition légale applicable impose une durée plus longue ou différente. Si vous avez construit le pipeline d'extraction et l'avez mis en service sous votre propre nom, vous êtes le fournisseur de ce système, quel que soit le modèle de fondation qu'il embarque. Le LLM n'est qu'un composant. Personne à Bruxelles n'acceptera comme réponse « OpenAI ne le conserve pas » pour des événements que votre propre orchestrateur a générés puis délibérément effacés.

La rétention zéro est une promesse qui porte sur les disques de l'éditeur du modèle, pas une dispense de tenir votre propre piste d'audit.

Que doit précisément journaliser un pipeline documentaire au titre de l'article 12 ?

L'article 12 ne vous fournit pas de liste de champs toute faite pour l'extraction documentaire. Il fixe trois finalités, dont vous devez déduire le schéma. L'article 12, paragraphe 2, énonce trois finalités : identifier les situations à risque au titre de l'article 79, alimenter la surveillance post-commercialisation au titre de l'article 72, et suivre la performance opérationnelle au titre de l'article 26, paragraphe 5.

La seule liste minimale de champs imposée explicitement concerne l'identification biométrique à distance visée à l'Annexe III, point 1(a) : la période de chaque utilisation avec horodatage de début et de fin, la base de données de référence consultée, les données d'entrée ayant produit une correspondance, et l'identification des personnes physiques ayant participé à la vérification des résultats. Lisez cette liste comme un modèle plutôt que comme une limite. Pour un pipeline documentaire, elle se transpose facilement : un événement par document traité, avec horodatage d'ingestion et horodatage d'achèvement, l'identifiant du document et son empreinte de contenu, le modèle et la version du prompt utilisés, l'ensemble des champs extraits avec un score de confiance par champ, toute règle de validation déclenchée, et l'identité du relecteur ayant validé ou corrigé le résultat.

Les journaux doivent permettre une traçabilité complète du fonctionnement du système, du déploiement jusqu'au retrait, en couvrant chaque décision pilotée par algorithme. Cette formule « chaque décision » est la véritable contrainte de conception : l'échantillonnage de vos journaux n'est pas une option, et l'agrégation au niveau du lot fait perdre la granularité par document qu'un auditeur, ou un demandeur contestant une décision, exigera.

Quels journaux restent sous ma responsabilité quand l'éditeur du modèle ne conserve rien ?

Tout ce qui est généré par votre code et non par celui de l'éditeur. L'API du modèle renvoie une réponse ; la décision sur ce que signifie cette réponse, et sur ce qui s'est passé ensuite, vous appartient, et c'est cette décision qui constitue l'événement à journaliser.

La ligne sur la surveillance des abus est celle où les ingénieurs se trompent le plus souvent. La conservation à des fins de surveillance des abus désigne les données conservées pour permettre au fournisseur d'enquêter sur un usage abusif, et elle survit à la plupart des dispositifs ZDR : OpenAI génère des journaux de surveillance des abus pour toute utilisation de fonctionnalité de l'API et les conserve jusqu'à 30 jours. Avec le ZDR activé, le contenu client est exclu de ces journaux de surveillance des abus, et le paramètre « store » de l'API est toujours traité comme faux pour les points de terminaison concernés, même si une requête tente de le fixer à vrai. Sous ZDR, il n'y a donc rien de récupérable à cet endroit, et même sans ZDR, une fenêtre de 30 jours ne peut de toute façon pas servir de base à une obligation légale de conservation de six mois ou plus. Traitez la télémétrie de l'éditeur comme un outil de surveillance, jamais comme une preuve.

Si vous achetez la couche d'extraction au lieu de la construire, l'accès aux journaux relève d'une clause contractuelle, pas d'un détail accessoire. Des journaux hébergés dans le cloud d'un fournisseur peuvent échapper totalement à votre contrôle, d'où l'importance d'inscrire au contrat des droits d'export et un accès à la demande. Notre checklist d'évaluation des fournisseurs IDP passe en revue les questions à poser avant signature, et notre analyse build vs buy précise où se situe la charge de la journalisation dans chaque modèle.

Combien de temps dois-je les conserver, et le RGPD raccourcit-il cette durée ?

Six mois est un plancher, et pour la plupart des pipelines documentaires, ce n'est pas la bonne réponse. Le texte exige une durée adaptée à la finalité prévue, d'au moins six mois ; dès lors que la finalité suppose un horizon de redevabilité plus long, six mois ne suffit pas : un système de scoring de crédit dont les décisions peuvent être contestées des années plus tard, ou un outil RH alimentant des décisions soumises aux délais de prescription du droit du travail, appelle une durée de conservation plus longue.

Partez de la fenêtre de contestation de la décision en aval. Un refus KYC, un rejet de sinistre, un refus de prêt : chacun est assorti d'un délai de contestation légal ou contractuel, et votre durée de conservation des journaux doit excéder ce délai. Un journal expiré est une lacune probatoire que vous avez vous-même créée, et le principe de limitation de la conservation du RGPD joue en sens inverse, d'où la nécessité d'une justification documentée de la durée de conservation propre à chaque système, et non d'un réglage par défaut appliqué à toute la plateforme.

Cette tension se résout en faveur du droit de la protection des données, ce qui est précisément pourquoi une architecture de journalisation centrée sur les métadonnées est la bonne approche. Stockez des empreintes de contenu, des scores de confiance par champ, les versions de modèle et les identifiants des relecteurs ; conservez le document source sous sa propre règle sectorielle de conservation et référencez-le par ID. Le journal survit alors à la suppression du document sans en reproduire les données personnelles. Notre checklist RGPD pour les projets d'IA documentaire détaille la cartographie minimisation/conservation ; Sygnet documente sur cette même base ses propres options de traitement, de conservation et de résidence des données.

Mon pipeline d'extraction est-il réellement à haut risque, ou l'ai-je surclassé ?

La plupart des extractions documentaires ne sont pas à haut risque en elles-mêmes. La classification s'attache à l'usage, pas à l'analyse syntaxique du document. Les produits dotés de fonctions d'IA qui se contentent d'assister les utilisateurs ou d'optimiser des performances ne seront pas automatiquement soumis aux obligations applicables au haut risque si leur défaillance ou leur dysfonctionnement ne présente pas de risque pour la santé ou la sécurité, ce qui vise précisément à éviter le surclassement de produits dotés d'IA en produits à haut risque.

Une couche OCR ou VLM qui transforme un PDF en JSON structuré, avec un humain qui lit le résultat et prend la décision, est très éloignée de l'Annexe III. La même couche alimentant un score de solvabilité automatisé y entre en revanche de plein droit. L'Annexe III couvre des systèmes autonomes à haut risque tels que le recrutement et l'évaluation des salariés, le scoring de crédit et la biométrie. La question à se poser en premier n'est donc pas « que fait mon extracteur », mais « quelle décision son résultat alimente-t-il, et quelle part de jugement humain s'intercale entre les deux ».

Faites cette cartographie dès maintenant, indépendamment du report de calendrier. Une organisation devrait néanmoins achever sa cartographie de classification dès maintenant, même si les obligations attachées à une classification à haut risque ne s'appliquent qu'à partir de décembre 2027. La classification détermine aussi si vous avez besoin des preuves de précision au niveau des champs décrites dans notre checklist d'évaluation de la précision d'extraction, car les allégations de robustesse de l'article 15 exigent des chiffres mesurés, pas des arguments marketing de fournisseur.

L'extracteur est rarement à haut risque ; c'est en général la décision qu'il alimente qui tranche la question.

FAQ

Si mon fournisseur de LLM pratique la rétention zéro, puis-je ne rien journaliser du tout ?

Non. Le ZDR signifie seulement que l'éditeur ne conserve pas vos prompts et vos réponses. Les événements prévus par l'article 12, horodatages, version du modèle, score de confiance par champ, résultats de validation et actions de relecture humaine, sont produits par votre code d'orchestration et sous votre contrôle, ce qui correspond exactement au critère de l'article 26, paragraphe 6. Un pipeline qui appelle un point de terminaison ZDR sans écrire le moindre enregistrement d'événement ne dispose d'aucune piste d'audit.

Dois-je stocker le contenu du document lui-même dans les journaux ?

Pas en général, et dans la plupart des cas vous ne devriez pas le faire. Conservez un identifiant de document stable ainsi qu'une empreinte de contenu, et gardez le document sous sa propre règle sectorielle de conservation. Cela préserve la traçabilité tout en respectant le principe de limitation de la conservation du RGPD. Considérer l'AI Act comme une autorisation à conserver les journaux indéfiniment est l'une des erreurs les plus fréquentes commises par les entreprises.

Quand ces obligations de journalisation s'appliquent-elles réellement ?

Le règlement (UE) 2026/1744 a modifié le calendrier : les systèmes à haut risque listés à l'Annexe III ne sont concernés qu'à partir du 2 décembre 2027, l'IA intégrée dans des produits réglementés relevant de l'Annexe I étant quant à elle reportée au 2 août 2028. Les schémas de journalisation sont difficiles à reconstituer a posteriori : construisez le modèle d'événements avant l'échéance, pas après.

Le recours à une API d'extraction managée fait-il de l'éditeur le fournisseur ?

En général non. Si vous mettez le système en service sous votre propre nom pour votre propre usage à haut risque, vous êtes le fournisseur de ce système, et l'API d'extraction n'en est qu'un composant. Les obligations de l'éditeur couvrent son propre produit ; les vôtres couvrent le pipeline que vous avez assemblé, journaux compris.