Journalisation EU AI Act : les articles 12 et 19 expliqués

Ce que l'article 12 exige vraiment

L'article 12 du règlement IA (UE 2024/1689) est court et concret : un système d'IA à haut risque doit permettre techniquement l'enregistrement automatique des événements — les « logs » — tout au long de son cycle de vie. « Automatique » est le mot clé : une page wiki mise à jour à la main ne suffit pas, c'est le système lui-même qui doit produire l'enregistrement.

Ces logs servent à rendre possibles trois choses (article 12(2)) :

• identifier les situations où le système peut présenter un risque ou subir une modification substantielle ;
• faciliter la surveillance après commercialisation (article 72) ;
• surveiller le fonctionnement du système côté déployeur (article 26(5)).

Pour l'identification biométrique à distance, il existe un minimum explicite (article 12(3)) : la période de chaque utilisation, la base de référence, les données d'entrée ayant produit une correspondance, et qui a vérifié le résultat. La plupart des features LLM ne sont pas biométriques, mais le principe se généralise — journalisez assez pour reconstituer ce qui s'est passé, pas seulement qu'il s'est passé quelque chose.

Ce que l'article 19 ajoute : les conserver

L'article 12 dit générer les logs ; l'article 19 dit les conserver. Les fournisseurs conservent les logs générés automatiquement « dans la mesure où [ils] sont sous [leur] contrôle … pendant une durée appropriée à la finalité prévue, d'au moins six mois », sauf disposition contraire. Les déployeurs héritent d'une obligation parallèle (article 26).

Six mois est un plancher, pas une cible. Un modèle de recrutement ou de scoring crédit dont les décisions peuvent être contestées des années plus tard a besoin d'un horizon de rétention aligné sur la fenêtre de contestation, pas sur le minimum.

Ce que ce n'est pas : l'article 15

Confusion fréquente : la tenue de registres n'est pas l'article 15. L'article 15 couvre l'exactitude, la robustesse et la cybersécurité — dont la résilience aux tentatives d'altérer l'usage, les sorties ou la performance (15(5)). Vos défenses anti-injection et la propriété « les logs ne peuvent pas être réécrits en silence » relèvent de la cybersécurité de l'article 15. L'existence et la conservation du registre d'audit relèvent des articles 12 et 19. Gardez les deux distincts dans votre documentation technique — un auditeur le fera.

L'échéance a bougé — pas la demande

Fin 2025, le « Digital Omnibus » de la Commission a proposé de reporter les obligations haut-risque pour les systèmes de l'annexe III. Un accord provisoire a été trouvé en mai 2026, approuvé par le Parlement en juin 2026 ; sous réserve d'adoption formelle, la nouvelle date pour les systèmes annexe III autonomes est le 2 décembre 2027. C'est un report d'application, pas une abrogation — et cela ne dit rien de vos clients. Un acheteur régulé qui déroule un questionnaire fournisseur vous demandera ce que vous journalisez, et comment vous le prouveriez, bien avant qu'une échéance ne vous y oblige.

À quoi ressemble un audit log LLM défendable

En traduisant les articles en ingénierie, un log que vous pouvez assumer est :

• Par appel, automatique — émis sur le chemin de la requête, pas reconstitué après coup.
• Métadonnées d'abord — rarement besoin des prompts et réponses bruts pour être utile : timestamps, modèle et configuration en vigueur, verdicts des shields, comptes de tokens, classification. Stocker moins, c'est aussi une meilleure hygiène RGPD.
• Conservé selon un calendrier — au moins six mois ; plus longtemps si la décision peut être contestée.
• Exportable — un régulateur ou un auditeur doit obtenir un export structuré et lisible dans un délai raisonnable.
• Vérifiable indépendamment — la partie que la plupart des stacks oublient.

Le déficit de confiance de la plupart des logs

Le point gênant : dans la plupart des stacks IA en production, l'enregistrement d'audit est écrit par l'application qui fait tourner le modèle. L'application qui peut écrire le log peut aussi le réécrire. Quand un régulateur demande « pouvez-vous prouver que cet enregistrement n'a pas été modifié après coup ? », les contrôles d'accès seuls ne répondent pas — un initié compromis ou motivé est à l'intérieur du périmètre de confiance.

La solution est cryptographique, pas procédurale : chaînez chaque enregistrement au précédent par un hash pour que tout changement soit détectable, et ancrez la tête de chaîne à un horodatage indépendant pour ne pas pouvoir antidater l'historique en silence. C'est la différence entre un log qu'on vous demande de croire et un log qu'on peut vérifier. Nous l'expliquons en détail ici : tamper-evident vs tamper-proof.

Voyez-le — ne nous croyez pas sur parole

Vous pouvez vérifier vous-même un vrai dossier d'audit Senthex (synthétique) : recalculez la chaîne de hachage dans votre navigateur, changez un octet, et regardez la vérification échouer. Une note d'honnêteté — la chaîne vérifiable et tamper-evident de Senthex (avec l'ancre RFC 3161 et le vérifieur offline) est une capacité pilote ; la version publiée fait de la journalisation de métadonnées. Nous vous dirons toujours laquelle est laquelle.

Sources : article 12 du règlement IA, article 19. Ceci n'est pas un conseil juridique.