AI Act : journalisation automatique d’une IA à haut risque (articles 12, 19 et 26)

L’AI Act (règlement (UE) 2024/1689) impose qu’un système d’IA à haut risque soit capable d’enregistrer automatiquement ses propres événements, puis répartit la conservation de ces journaux entre le fournisseur et le déployeur. Le texte est court, mais ses conséquences d’architecture ne le sont pas : quoi journaliser, comment prouver que rien n’a été réécrit, combien de temps garder des données souvent personnelles. Cette page traite les trois articles ensemble, parce qu’en production ils forment une seule chaîne.

→ Lire l’explication complète de la marmotte

Ce que l’article 12 exige du système d’IA à haut risque

L’article 12 s’adresse au système, pas à son exploitant. Son paragraphe 1 dit que les systèmes d’IA à haut risque « permettent techniquement » l’enregistrement automatique des événements (les journaux) tout au long de leur durée de vie. Trois mots portent l’obligation : techniquement (c’est une capacité de conception, à prévoir dès le départ), automatique (un opérateur qui remplit un tableur ne compte pas), durée de vie (de la mise en service au retrait, mises à jour comprises).

Le paragraphe 2 fixe la finalité. La journalisation enregistre les événements pertinents pour :

a) repérer les situations susceptibles de faire présenter au système un risque au sens de l’article 79, paragraphe 1, ou d’entraîner une modification substantielle ;
b) faciliter la surveillance après commercialisation prévue à l’article 72 ;
c) permettre au déployeur de surveiller le fonctionnement, comme prévu à l’article 26, paragraphe 5.

Le paragraphe 3 est le seul qui donne un contenu minimal, et il ne vise que les systèmes de l’annexe III, point 1 a), c’est-à-dire l’identification biométrique à distance. Pour ces systèmes, il faut au minimum enregistrer la période de chaque utilisation (date et heure de début et de fin), la base de données de référence consultée, les données d’entrée pour lesquelles la recherche a abouti à une correspondance, et l’identification des personnes physiques qui vérifient les résultats au sens de l’article 14, paragraphe 5.

Pour tous les autres systèmes à haut risque, le règlement ne fournit aucune liste de champs. Toute grille de champs, y compris celle proposée plus bas, relève de la recommandation d’architecture et non d’une obligation légale. Les présentations commerciales qui affichent un « schéma de logs conforme AI Act » vendent une interprétation, pas un article. Le texte fixe une finalité, et c’est elle que l’architecte doit pouvoir démontrer : chaque champ journalisé doit se rattacher à a), b) ou c).

Côté calendrier, l’omnibus numérique (règlement (UE) 2026/1744) ne modifie pas les articles 12, 19 et 26. En revanche, il reporte l’application des exigences relatives au haut risque au 2 décembre 2027 pour les systèmes de l’annexe III et au 2 août 2028 pour ceux de l’annexe I (article 113 modifié). Ces obligations ne s’appliquent donc pas encore. Le détail des échéances figure sur la page calendrier de l’AI Act, et la qualification d’un système se fait d’abord via la classification haut risque. Inutile de construire une chaîne de journalisation pour un système qui n’entre pas dans le périmètre.

Côté normes, aucune norme harmonisée sur la journalisation des systèmes d’IA n’est publiée au Journal officiel (JO) à ce jour ; il faut vérifier sur EUR-Lex avant d’affirmer une présomption de conformité. Le projet prEN ISO/IEC 24970 (projet de norme européenne reprenant une norme de l’Organisation internationale de normalisation et de la Commission électrotechnique internationale) traite de la journalisation des systèmes d’IA. Il s’agit de travaux en cours, à suivre sans s’y adosser.

Conservation des journaux, fournisseur (art. 19) et déployeur (art. 26 §6)

L’article 12 crée la capacité, les articles 16 e) et 19 désignent le gardien. Le fournisseur assure la tenue des journaux générés automatiquement dans la mesure où ils se trouvent sous son contrôle, pendant une période adaptée à la destination du système, d’au moins six mois, sauf disposition contraire du droit de l’Union ou du droit national, en particulier en matière de protection des données. Le déployeur porte la même obligation pour les journaux sous son contrôle (article 26, paragraphe 6), avec les mêmes réserves. Pour les établissements financiers, dans les deux cas, les journaux sont tenus dans la documentation exigée par la législation sur les services financiers (article 19, paragraphe 2, et article 26, paragraphe 6, second alinéa).

Le critère de partage tient en trois mots : sous leur contrôle. Un système hébergé par le fournisseur en SaaS (Software as a Service) produit ses journaux chez le fournisseur. Un système installé sur l’infrastructure du déployeur les produit chez le déployeur. La plupart des architectures réelles mélangent les deux : inférence chez le fournisseur, interface et validation humaine chez le déployeur. Le partage doit alors être écrit dans le contrat, champ par champ, avec les modalités d’extraction. La répartition des rôles elle-même est traitée dans rôles fournisseur et déployeur.

Le schéma ci-dessous montre qui produit, qui conserve et qui peut exiger quoi selon l’emplacement du système.

À lire : aucune flèche ne fait circuler automatiquement les journaux du déployeur vers le fournisseur. Si le fournisseur a besoin de ces données pour sa surveillance après commercialisation, il doit l’organiser contractuellement, ce qui pose immédiatement la question du responsable de traitement au sens du RGPD (Règlement général sur la protection des données).

Deux autres articles complètent le dispositif. L’article 13, paragraphe 3, f) impose que la notice d’utilisation décrive, le cas échéant, les mécanismes qui permettent au déployeur de collecter, stocker et interpréter correctement les journaux. Une notice qui se contente de dire « les logs sont disponibles » ne remplit pas cette obligation : il faut le format, la sémantique des champs, les codes d’événement et la procédure d’export. Ce contenu se raccroche à la documentation technique. L’article 21, paragraphe 2 oblige le fournisseur, sur demande motivée d’une autorité compétente, à donner accès aux journaux de l’article 12 §1 sous son contrôle. Un journal qu’on ne sait pas extraire, filtrer et livrer dans un délai raisonnable est un journal qui n’existe pas au moment où il compte.

Journaux, surveillance par le déployeur et incident grave (art. 26 §5 et art. 73)

L’article 26, paragraphe 5, fait du journal un outil d’exploitation, pas une archive. Le déployeur surveille le fonctionnement sur la base de la notice. S’il a des raisons de penser que l’utilisation conforme présente un risque au sens de l’article 79 §1, il informe sans retard injustifié le fournisseur ou le distributeur ainsi que l’autorité de surveillance du marché, et il suspend l’utilisation. En cas d’incident grave, il informe immédiatement d’abord le fournisseur, puis l’importateur ou le distributeur et les autorités ; s’il ne parvient pas à joindre le fournisseur, l’article 73 s’applique à lui mutatis mutandis.

Conséquence d’architecture : le journal doit être exploitable en quelques heures, pas en quelques semaines. Il faut pouvoir reconstituer quelle version du modèle a produit quelle sortie, sur quelle entrée, et qui l’a validée. Les délais de notification et leur articulation avec les autres régimes sont détaillés dans notification d’incident, délais et obligations.

Le non-respect des obligations des fournisseurs (article 16) et des déployeurs (article 26) est passible d’une amende pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu (article 99, paragraphe 4). Pour les PME (petites et moyennes entreprises), c’est le plus faible des deux. La qualification d’un cas particulier relève d’un avocat ; la page s’en tient au texte.

Prérequis de plateforme avant de journaliser

Avant le premier événement, quatre briques doivent exister.

Une horloge de confiance. Tous les composants synchronisés en NTP (Network Time Protocol) sur des sources authentifiées, horodatage en UTC (temps universel coordonné) avec fuseau explicite. Un écart de quelques minutes entre l’inférence et la validation humaine suffit à rendre l’ordre des événements contestable.
Un identifiant de version de bout en bout. Version du modèle, des poids, du prétraitement, des seuils de décision et de la configuration des garde-fous. Sans cela, l’article 12 §2 a) (détecter une modification substantielle) est impossible à satisfaire.
Un identifiant de corrélation par requête, propagé de l’entrée jusqu’à la décision humaine, sur le modèle décrit pour l’observabilité LLM en production.
Un stockage à rétention verrouillable de type WORM (Write Once Read Many), avec une durée de rétention paramétrable par catégorie de journal, et une gestion de clés capable de signer des lots, idéalement dans un HSM (Hardware Security Module).

La brique qui manque est presque toujours l’identifiant de version : tout le monde versionne le code, presque personne ne versionne le seuil de décision modifié « temporairement » un vendredi.

Quoi journaliser, recommandation d’architecture

Le compromis central se formule ainsi : plus le journal est complet, plus l’enquête est facile, et plus il devient lui-même un gisement de données personnelles à protéger, à justifier et à purger. Journaliser les entrées et sorties brutes « au cas où » transforme une obligation de traçabilité en base de données parallèle, souvent moins bien protégée que la base métier. La position retenue ici : journaliser des faits et des références, pas des contenus, sauf là où le texte exige le contenu.

En pratique, la grille suivante, qui reste une recommandation, couvre les trois finalités de l’article 12 §2 :

Contexte d’exécution : horodatage de début et de fin, identifiant de corrélation, version du modèle et de la configuration, environnement.
Entrée : empreinte cryptographique de l’entrée et pointeur vers le stockage source, plutôt que l’entrée elle-même. L’empreinte prouve l’identité de la donnée sans la dupliquer, à condition que la source garde sa propre rétention.
Sortie : décision ou score, seuil appliqué, indicateurs de confiance, déclenchements de garde-fous.
Supervision humaine : identifiant pseudonymisé de la personne qui a vérifié, action effectuée (validation, correction, rejet), horodatage.
Événements de cycle de vie : déploiement de version, changement de seuil, dérive détectée, désactivation, erreurs et dégradations.

Pour l’identification biométrique à distance (annexe III, point 1 a), l’exception est explicite : les données d’entrée ayant donné une correspondance doivent être enregistrées. Une empreinte seule ne suffit pas ; mieux vaut conserver ces données dans un compartiment séparé, chiffré, avec un contrôle d’accès plus strict que le reste du journal et un lien vers l’événement. Les entrées sans correspondance n’ont pas à y figurer, et il vaut mieux ne pas les y mettre.

Le lien avec la gestion des risques est direct : chaque risque identifié devrait correspondre à au moins un événement journalisé qui permet de le détecter. Un risque sans signal dans les journaux est un risque déclaré, pas un risque surveillé. Côté gouvernance des données, la version des jeux d’entraînement et de validation doit être retrouvable depuis la version du modèle inscrite au journal.

Intégrité et horodatage de la chaîne de journalisation

Un journal que l’administrateur du système peut réécrire ne prouve rien contre l’administrateur du système. Or c’est précisément le scénario d’une enquête après incident : l’acteur dont la responsabilité est en jeu détient souvent les droits sur les journaux. La surface d’attaque est connue :

Altération ou suppression ciblée d’événements par un compte privilégié. Contre-mesure : chaînage par hachage, où chaque événement inclut l’empreinte du précédent, puis signature des lots avec une clé hors de portée de l’administrateur.
Réécriture complète de la chaîne. Le chaînage seul ne résiste pas à qui recalcule tout depuis le début. Contre-mesure : ancrage externe, par jeton d’horodatage au format RFC 3161 délivré par une autorité d’horodatage tierce (qualifiée au sens du règlement eIDAS si la date doit bénéficier d’une présomption d’exactitude), ou copie des empreintes de lots chez une autre entité.
Troncature de fin de journal, invisible par chaînage. Contre-mesure : lots numérotés, signature périodique même sans événement, alerte sur trou de séquence.
Falsification d’horloge. Contre-mesure : NTP authentifié, jeton d’horodatage externe sur chaque lot, alerte sur dérive.
Injection dans le journal : une entrée utilisateur contenant des retours à la ligne ou des séquences de contrôle fabrique de faux événements. Contre-mesure : format structuré, échappement à la source, jamais de concaténation de texte libre.
Saturation : disque plein ou collecteur indisponible. Il faut alors trancher entre arrêt et dégradation.

Sur ce dernier point, le texte ne dit rien et la position retenue ici est nette. Pour un système de l’annexe III, point 1 a), dont le contenu minimal est obligatoire : sans journal, pas d’utilisation (fonctionnement en échec fermé). Pour les autres, un tampon local borné, signé, avec alerte immédiate, puis arrêt si le tampon déborde. Un système d’IA à haut risque qui continue à décider sans laisser de trace s’écarte de la finalité de l’article 12, quelle que soit la qualité des décisions.

Le choix entre HMAC (Hash-based Message Authentication Code) et signature asymétrique pour sceller les lots dépend d’une question : qui doit pouvoir vérifier ? Le HMAC impose de partager la clé avec le vérificateur, donc de lui donner aussi le pouvoir de forger. La signature asymétrique permet à une autorité ou à un expert de vérifier sans aucun secret. Pour des journaux destinés à être produits devant une autorité, la signature l’emporte. Les mécanismes sont détaillés dans hachage et systèmes d’intégrité et dans journalisation d’audit immuable.

Le schéma montre l’ordre des opérations, du composant d’inférence jusqu’à la vérification.

À lire : la clé de signature ne quitte jamais le HSM, et le jeton d’horodatage vient d’un tiers. Ces deux points empêchent l’opérateur du système de réécrire l’histoire sans laisser de trace. La normalisation des formats en amont est traitée dans normalisation des logs et pipelines.

Ce que la journalisation ne garantit pas

Un journal intègre prouve qu’un événement a été écrit tel quel à un instant donné. Il ne prouve pas que cet événement était vrai. Si le composant d’inférence est compromis, il journalise proprement des mensonges ; l’intégrité du journal ne remplace pas celle de la source. Le journal ne garantit pas non plus la qualité des décisions, l’absence de biais ni l’effectivité de la supervision humaine : un identifiant de vérificateur inscrit à côté de mille validations en deux minutes atteste d’un clic, pas d’un contrôle. Ce dernier point se détecte justement par l’analyse des journaux, à condition de la faire.

Enfin, un journal ne dit pas qui a lu quoi a posteriori. L’accès aux journaux doit lui-même être journalisé, sinon une consultation abusive des données biométriques ou des identités d’opérateurs passe inaperçue, comme le montre la page fuites de données et journal d’accès après coup.

Minimisation RGPD et durée de conservation des journaux

« Au moins six mois » est un plancher, pas un objectif, et encore moins une autorisation de conservation illimitée. Les principes de minimisation et de limitation de la conservation (article 5 du RGPD) continuent de s’appliquer, et le texte de l’AI Act réserve lui-même le droit de la protection des données. Aucune durée maximale légale n’est fixée par l’AI Act : la durée doit être justifiée par la destination du système, documentée et appliquée techniquement.

Recommandation : définir une durée par catégorie. Les événements de cycle de vie (versions, seuils, dérives) n’ont presque pas de données personnelles et peuvent être conservés aussi longtemps que le système est en service, puisqu’ils servent la surveillance après commercialisation. Les événements d’inférence pseudonymisés suivent la durée justifiée par la destination, six mois minimum. Les données d’entrée en clair (cas biométrique) suivent la durée la plus courte compatible avec l’obligation, dans le compartiment séparé. La purge doit être automatique et elle-même journalisée.

Les identités des personnes qui vérifient les résultats sont des données de salariés. Leur journalisation est exigée pour la biométrie à distance (article 12, paragraphe 3, d) et se justifie ailleurs par la traçabilité du contrôle humain (article 14), mais leur réutilisation pour évaluer la productivité ne l’est pas automatiquement : la frontière est traitée dans surveillance des salariés, cadre légal et limites. Quand une AIPD (analyse d’impact relative à la protection des données, article 35 du RGPD) est requise, et l’article 26, paragraphe 9, invite le déployeur à s’appuyer pour cela sur la notice du fournisseur, elle décrit les journaux comme un traitement à part entière.

Exploitation de la chaîne de journalisation, clés, supervision et reprise

Clés de signature : générées et conservées dans un HSM, rotation planifiée, les clés publiques retirées étant archivées aussi longtemps que les journaux qu’elles ont signés. Sans clé publique, une signature valide redevient une suite d’octets.
Supervision : alertes sur trou de séquence, échec de signature ou d’horodatage, dérive d’horloge, saturation du tampon, volume anormal de validations humaines. Les journaux d’IA alimentent le SIEM (Security Information and Event Management) comme n’importe quelle source, via le pipeline décrit dans ingénierie de la donnée de sécurité.
Sauvegarde : copie sur un second stockage verrouillé, hors du domaine d’administration principal. Un verrouillage WORM administré par le même compte qui pourrait le désactiver ne protège que contre les erreurs, pas contre la malveillance.
Reprise : un exercice de restauration doit inclure la vérification de bout en bout de la chaîne restaurée. Restaurer des journaux dont la chaîne est cassée revient à restaurer une archive inutilisable comme preuve.
Extraction : une procédure documentée et testée pour répondre à une demande motivée (article 21 §2) sur une période et un périmètre donnés, avec les preuves d’intégrité jointes.

Exemple fictif, tri de candidatures en SaaS

Scénario entièrement fictif. La société fictive Tamarin fournit en SaaS un système de présélection de candidatures (emploi, annexe III, point 4 a). L’entreprise fictive Ardoise le déploie ; ses recruteurs valident ou écartent les propositions dans une interface hébergée chez Ardoise. Le contrat prévoit que Tamarin conserve les journaux d’inférence et qu’Ardoise conserve les journaux de validation humaine, avec un export quotidien des événements d’inférence la concernant.

À lire : la détection n’est possible que parce que la version du modèle figure dans les journaux de Tamarin et que l’identifiant de corrélation permet de rapprocher score et décision humaine dans ceux d’Ardoise. Sans version journalisée, impossible de dater le début de l’anomalie ; sans corrélation, impossible de savoir si les recruteurs ont suivi le score ou l’ont corrigé. Le partage contractuel a fixé à l’avance qui détient quoi, ce qui évite de négocier les formats d’export pendant l’incident.

🐝 Ce qui arrive si on s’en passe

Sans journalisation automatique versionnée, une dérive du modèle après mise à jour reste indétectable : aucun signal ne permet de dater le changement ni d’identifier les décisions concernées, donc ni de les reprendre ni de notifier dans les délais. Sans chaînage ni ancrage externe, le journal existant ne vaut rien comme preuve, puisque le détenteur des droits peut le réécrire sans trace. Sans corrélation entre sortie du modèle et validation humaine, la supervision exigée par l’article 14 devient invérifiable. Sans politique de durée par catégorie, le journal grossit en base parallèle de données personnelles, exposée à une fuite et dépourvue de justification de conservation.

🦫 Explication de la marmotte 🍫

Une loi européenne sur l’intelligence artificielle classe certains programmes comme « à haut risque » parce qu’ils prennent des décisions qui comptent pour les gens : trier des candidatures, reconnaître des visages, accorder un prêt. Ces programmes devront écrire automatiquement, pendant toute leur vie, ce qu’ils font : à quelle heure, avec quelle version du programme, sur quelle demande, avec quel résultat, et quelle personne a vérifié ce résultat. Pour la reconnaissance de visages à distance, la loi donne la liste minimale ; pour les autres, elle donne seulement le but : repérer les dangers, suivre le programme après sa vente, permettre à l’utilisateur de le surveiller.

Celui qui fabrique le programme garde les traces qui sont chez lui ; celui qui l’utilise garde celles qui sont chez lui ; chacun au moins six mois, mais pas pour toujours, car ces traces contiennent des informations sur des personnes. Si l’utilisateur voit un problème dans ces traces, il doit prévenir le fabricant et les autorités, puis arrêter d’utiliser le programme.

Pour que ces traces servent de preuve, chaque ligne contient un calcul sur la ligne précédente : modifier une ligne casse toute la suite. Des paquets de lignes sont signés avec une clé enfermée dans un appareil spécial, puis datés par un service extérieur. Si l’enregistrement tombe en panne, le programme doit alerter, puis s’arrêter plutôt que décider sans laisser de trace. Ces règles ne s’appliqueront qu’à partir de fin 2027 ou de 2028, selon le type de programme.

Pages voisines

La citent

AI Act : journalisation automatique d'une IA à haut risque (articles 12, 19 et 26)

Elle cite

: les deux pages se citent l’une l’autre.