Ce n'est plus une échéance à venir. Depuis le 2 août 2026, les articles 12 et 19 de l'IA Act sont pleinement applicables.
Pour tout fournisseur de système d'IA à haut risque, la journalisation et la conservation des preuves ne sont plus un sujet de roadmap : c'est une obligation en vigueur, opposable dès aujourd'hui.
Ce sont d'abord et avant tout les fournisseurs, c'est-à- dire ceux qui conçoivent, développent et mettent sur le marché des systèmes d'IA à haut risque, qui portent ces obligations.
C'est le cœur de cet article.
Depuis le 2 août 2026, tout système d'IA à haut risque que vous mettez sur le marché doit être techniquement capable de journaliser automatiquement son fonctionnement. Ce n'est pas une fonctionnalité optionnelle ajoutable plus tard : c'est une exigence de conception, prévue par l'article 12.
Concrètement, votre système doit permettre l'enregistrement d'événements pertinents pour :
Pour les systèmes d'identification biométrique à distance (annexe III, point 1a), l'obligation est plus précise encore. Vos journaux doivent obligatoirement enregistrer :
Si l'un de ces éléments n'est pas capturé aujourd'hui par votre système, vous êtes actuellement en écart par rapport à une obligation déjà en vigueur, pas par rapport à une échéance future.
L'article 12 impose la capacité technique de logger. L'article 19 impose au fournisseur de conserver ces journaux, sous son propre contrôle, pendant une durée adaptée à la destination du système, afin de pouvoir les produire à la demande d'une autorité compétente.
Cette obligation de conservation est active depuis la même date d'entrée en vigueur que l'article 12. Un fournisseur qui génère des logs mais ne les conserve pas dans des conditions permettant de les exploiter en cas de contrôle n'est pas conforme, même si la capacité technique de journalisation existe par ailleurs.
Si vous êtes fournisseur d'un système d'IA à haut risque déjà sur le marché, trois questions ne peuvent plus attendre :
Si la réponse à l'une de ces questions est non, l'écart de conformité existe maintenant, pas dans un futur calendrier de mise en œuvre.
Le piège classique est de vouloir tout enregistrer, ou au contraire de se limiter au strict résultat final.
L'esprit du texte est différent : logger ce qui permet de comprendre, détecter et corriger une décision a posteriori.
Quatre catégories structurent une journalisation conforme :
Les données d'entrée : nature, source, format, horodatage, transformations appliquées avant traitement.
Le contexte de la décision : version du modèle utilisée, paramètres actifs, règles et seuils appliqués au moment précis de la décision.
La sortie produite : résultat, score associé, degré de confiance, explication fournie si le système en génère une.
L'intervention humaine : qui a validé ou modifié la décision, à quel moment, avec quelle justification, en lien direct avec l'obligation de supervision humaine de l'article 14.
Sans journalisation exploitable, un fournisseur ne peut plus démontrer l'absence de dérive, la réalité de la supervision humaine, ni la bonne gestion des incidents. En cas de contrôle, l'absence de preuve fonctionne comme une présomption de non-conformité, l'obligation étant déjà en vigueur, il n'y a plus de délai de tolérance à invoquer.
Pour vous permettre de vérifier concrètement où vous en êtes, nous mettons à disposition un modèle de fiche de journalisation conforme aux articles 12 et 19, à utiliser système par système : identification du système, éléments de journalisation couverts, responsable de la conservation des logs, durée de rétention prévue, et un exemple rempli pour vous projeter immédiatement.
=> télécharger le modèle gratuit : www.datatreat.fr/fiche-journalisation-ia-act
Lisez nos derniers articles et restez informés sur l'IA.
.png){kind=icon}