Article 12 AI Act : enregistrement automatique des événements pour les systèmes d'IA à haut risque

L'essentiel en 30 secondes

• L'Article 12 impose que les systèmes d'IA à haut risque permettent techniquement l'enregistrement automatique d'événements (logs) tout au long de leur cycle de vie.
• Les logs permettent d'identifier les situations à risque ou les modifications substantielles, de faciliter la surveillance après commercialisation (Art. 72) et de suivre le fonctionnement du système (Art. 26(5)).
• Le contenu minimal détaillé de l'Art. 12(3) vise uniquement l'identification biométrique à distance (Annexe III, point 1 a).
• Le fournisseur (Art. 19) et le déployeur (Art. 26(6)) conservent les logs sous leur contrôle au moins six mois, sauf disposition contraire du droit de l'Union ou national, notamment en matière de données personnelles.
• Ces obligations s'appliquent aux systèmes de l'Annexe III à partir du 2 décembre 2027 et à ceux de l'Annexe I à partir du 2 août 2028, selon le règlement (UE) 2026/1744 (« Omnibus IA »).
• Un manquement du fournisseur relève de l'Art. 16 : amende jusqu'à 15 M€ ou 3 % du chiffre d'affaires mondial (Art. 99(4)), le plus bas des deux montants pour une PME.

L'Article 12 impose aux systèmes d'IA à haut risque de pouvoir enregistrer automatiquement des événements (logs) pendant toute leur durée de vie. Les logs servent à repérer les situations à risque, à surveiller le système après sa mise sur le marché et à suivre son fonctionnement. Le fournisseur et le déployeur conservent les logs sous leur contrôle au moins six mois (Art. 19 et 26(6)), à partir du 2 décembre 2027 pour les systèmes de l'Annexe III.

L'Article 12 du Règlement (UE) 2024/1689, couramment appelé EU AI Act, concerne les PME qui développent ou intègrent des systèmes d'IA à haut risque. Il impose une traçabilité automatique des événements survenus pendant l'exploitation du système. Cette obligation conditionne la capacité du fournisseur à démontrer sa conformité en cas de contrôle, à investiguer un incident et à répondre aux demandes des autorités de surveillance du marché.

Cet article détaille le périmètre de l'Art. 12, les informations à enregistrer, la durée de conservation, la mise en œuvre technique, les obligations connexes et les sanctions encourues. Il s'adresse aux dirigeants, DPO, RSSI et responsables IA de PME qui doivent traduire le règlement en actions concrètes.

1. Qu'est-ce que l'Article 12 de l'AI Act ?

L'Article 12 du Règlement (UE) 2024/1689 porte le titre « Record-keeping » dans la version anglaise et « Tenue de registres » dans la version française. Il impose que les systèmes d'IA à haut risque soient conçus et développés avec des capacités techniques permettant l'enregistrement automatique d'événements (logs) tout au long de leur cycle de vie.

Principes fondateurs

Trois principes structurent cette exigence :

1. Automaticité : la journalisation doit être intégrée au système et ne dépend pas d'une action manuelle de l'opérateur ou de l'utilisateur final.
2. Traçabilité adaptée à la finalité : le niveau de traçabilité du fonctionnement du système doit être adapté à sa finalité (Art. 12(2)).
3. Surveillance du fonctionnement : les logs doivent permettre d'identifier les situations susceptibles d'entraîner un risque au sens de l'Art. 79(1) ou une modification substantielle du système, et de suivre le fonctionnement par le déployeur (Art. 26(5)).

Objectifs poursuivis par le législateur

L'Art. 12(2) explicite l'objectif : garantir un niveau de traçabilité du fonctionnement du système d'IA adapté à sa finalité. Concrètement, l'Art. 12 vise à :

• Faciliter le monitoring post-commercialisation (Art. 72) en fournissant la matière première à l'analyse des dérives.
• Permettre aux autorités de surveillance du marché d'investiguer un incident.
• Soutenir la gestion des risques (Art. 9) et la supervision humaine (Art. 14).

Le guide AI Act pour les PME françaises donne une vue d'ensemble du règlement.

2. Quels systèmes d'IA sont concernés ?

L'Art. 12 s'applique aux systèmes d'IA à haut risque : ceux de l'Annexe III (Art. 6(2)) et ceux liés aux produits de l'Annexe I (Art. 6(1)). La page sur les systèmes à haut risque détaille la classification.

Catégories couvertes

Catégorie Annexe III	Exemples concrets	Secteur typique
1. Biométrie	Identification biométrique à distance, catégorisation biométrique	Sécurité, contrôle d'accès
2. Infrastructures critiques	Gestion du trafic routier, eau, gaz, électricité	Énergie, transports
3. Éducation et formation	Admission, évaluation des apprenants, détection de fraude aux examens	EdTech
4. Emploi et RH	Tri de CV, évaluation de candidats, attribution de tâches	Recrutement, intérim
5. Accès aux services essentiels	Scoring crédit, éligibilité aux aides publiques, tarification assurance	Banque, assurance, secteur public
6. Application de la loi	Évaluation du risque de récidive, polygraphes	Forces de l'ordre
7. Migration et contrôle aux frontières	Examen des demandes d'asile, de visa et de titre de séjour	Administration
8. Justice et processus démocratiques	Aide d'une autorité judiciaire à la recherche et à l'interprétation des faits et du droit	Tribunaux

Les systèmes relevant de l'Art. 6(1) (composants de sécurité de produits déjà soumis à une législation d'harmonisation européenne, listée à l'Annexe I et exigeant une évaluation de conformité par un tiers) sont également concernés. Cela inclut par exemple les dispositifs médicaux IA (Règlement (UE) 2017/745).

Systèmes exclus

Sont hors champ de l'Art. 12 :

• Les systèmes à risque limité (Art. 50) — chatbots, deepfakes : obligations de transparence uniquement.
• Les systèmes à risque minimal (filtres anti-spam, par exemple) : l'Art. 12 ne s'y applique pas.
• Les systèmes à risque inacceptable (Art. 5) — qui sont purement et simplement interdits, et pour lesquels la question de la journalisation ne se pose donc pas.

3. Quelles informations doivent être enregistrées ?

L'Art. 12(2) et (3) précise le contenu des logs, en distinguant les systèmes à haut risque en général et les systèmes d'identification biométrique à distance en particulier.

Exigences générales (Art. 12 §2)

Les capacités de journalisation doivent permettre l'enregistrement d'événements pertinents pour :

• Identifier les situations pouvant conduire à un risque au sens de l'Art. 79 §1 (systèmes présentant un risque pour la santé, la sécurité ou les droits fondamentaux).
• Identifier les modifications substantielles du système.
• Faciliter le monitoring post-commercialisation prévu à l'Art. 72.
• Suivre le fonctionnement du système par le déployeur (Art. 26(5)).

Exigences renforcées pour la biométrie à distance (Art. 12 §3)

Pour les systèmes d'identification biométrique à distance visés à l'Annexe III, point 1 a, les logs doivent au minimum inclure :

Élément à enregistrer	Finalité
Période d'utilisation de chaque exploitation (date et heure de début et de fin)	Traçabilité temporelle
Base de données de référence utilisée	Vérifier la légitimité de la source
Données d'entrée ayant produit une correspondance	Reconstruire le contexte d'une décision
Identification des personnes ayant vérifié les résultats	Imputabilité de la supervision humaine (Art. 14)

Bonnes pratiques pour les autres systèmes à haut risque

Le texte laisse aux fournisseurs une marge d'appréciation pour les autres catégories. Une journalisation adaptée peut inclure :

• Entrées : horodatage, identifiant utilisateur, données soumises au modèle (ou leur empreinte si données sensibles).
• Sorties : résultat produit, score de confiance, explication éventuelle.
• Conditions opérationnelles : version du modèle, version des données d'entraînement, paramètres d'inférence.
• Performances : latence, taux d'erreur, signaux de dérive (drift detection).
• Événements de supervision humaine : validation ou rejet par un opérateur, motif.

La norme ISO/IEC 42001:2023 (contrôle A.6.2.8 sur l'enregistrement des journaux d'événements) et la norme ISO/IEC 27001:2022 (sécurité de l'information) fournissent un cadre pour structurer ces journaux. Ces normes volontaires ne donnent pas de présomption de conformité à l'AI Act.

4. Durée de conservation des logs

L'Article 12 ne fixe pas lui-même de durée. Celle-ci est définie à l'Article 19 du Règlement (UE) 2024/1689.

Règle générale

L'Art. 19(1) dispose que les fournisseurs de systèmes d'IA à haut risque conservent les logs générés automatiquement par leurs systèmes, dans la mesure où ces logs sont sous leur contrôle, pour une période appropriée à la finalité visée du système, d'au moins six mois, sauf dispositions contraires du droit de l'Union ou du droit national applicable, notamment en matière de protection des données à caractère personnel.

Tableau récapitulatif

Acteur	Obligation	Durée minimale
Fournisseur du système à haut risque	Conservation des logs générés automatiquement (Art. 19 §1)	6 mois
Déployeur établissement financier soumis au droit UE	Conservation au titre de la documentation interne	Selon la législation sectorielle (Art. 19(2) pour le fournisseur, Art. 26(6) pour le déployeur)
Déployeur autre (Art. 26 §6)	Conservation des logs sous son contrôle	6 mois minimum, sauf disposition contraire du droit de l'Union ou national

Articulation avec le RGPD

Si les logs contiennent des données à caractère personnel, ce qui est fréquent pour les systèmes biométriques, RH ou de scoring de crédit, le principe de limitation de la conservation (Art. 5(1), point e, du RGPD) s'applique. La durée doit être strictement nécessaire aux finalités poursuivies.

En pratique, il convient de définir une politique de conservation différenciée :

• Logs techniques anonymisés : conservation plus longue possible pour le monitoring.
• Logs contenant des données identifiantes : au moins six mois (Art. 19 et 26(6)), la durée étant justifiée par la finalité.
• Logs liés à un incident : conservation jusqu'à clôture de l'investigation et expiration des délais de prescription.

La CNIL publie des fiches pratiques sur l'IA et le RGPD. La page Sources recense les références utilisées dans les guides.

5. Comment mettre en œuvre la journalisation ?

La mise en œuvre concrète mobilise des compétences techniques, juridiques et organisationnelles. Voici un séquencement opérationnel pour une PME.

Étape 1 : Cartographier les systèmes concernés

1. Lister tous les systèmes d'IA développés ou déployés.
2. Classer chacun selon l'Art. 6 et l'Annexe III.
3. Pour chaque système à haut risque, désigner un responsable conformité IA (par exemple le DPO ou un responsable IA) ; un registre des systèmes d'IA sert de base.

Étape 2 : Définir le périmètre des événements à journaliser

Type d'événement	Niveau de détail	Sensibilité
Entrée du modèle	Empreinte ou donnée brute	Variable selon RGPD
Sortie du modèle	Résultat + score	Faible
Configuration et version	Identifiant version	Faible
Erreur d'inférence	Stack trace + contexte	Moyenne
Action de supervision humaine	Identité opérateur + décision	Élevée (données RH)

Étape 3 : Choisir une architecture de journalisation

Trois options principales s'offrent aux PME :

• Pile open source : coût maîtrisé mais expertise technique requise.
• Solution SaaS : démarrage rapide, coût récurrent.
• Service managé cloud : cohérent si l'IA est déjà hébergée chez le même fournisseur.

Étape 4 : Sécuriser les journaux

Les journaux contiennent souvent des données personnelles : leur sécurité relève du RGPD (Art. 32). Les mesures recommandées :

• Chiffrement au repos (AES-256) et en transit (TLS 1.3).
• Contrôle d'accès basé sur les rôles (RBAC), avec journalisation des accès aux logs eux-mêmes.
• Horodatage signé ou ancrage cryptographique (par exemple WORM storage) pour garantir l'intégrité.
• Séparation des environnements : les logs de production ne doivent pas être accessibles depuis les environnements de développement.

Étape 5 : Documenter et former

La documentation technique (Art. 11, Annexe IV) comprend notamment les journaux et rapports de test ; décrire le dispositif de journalisation dans le dossier technique est une bonne pratique. Les équipes opérationnelles doivent être formées à la consultation et à la non-altération des logs.

6. Obligations supplémentaires pour les fournisseurs

L'Art. 12 ne se lit pas isolément. Il s'articule avec plusieurs autres obligations du règlement.

Mise à disposition aux autorités (Art. 21)

L'Art. 21(1) impose aux fournisseurs, sur demande motivée d'une autorité compétente, de fournir toutes les informations et la documentation nécessaires pour démontrer la conformité du système à haut risque, dans une langue facilement compréhensible par l'autorité. Les logs sous le contrôle du fournisseur en font partie.

Conservation par le déployeur (Art. 26 §6)

Les déployeurs (entreprises utilisatrices du système) doivent eux aussi conserver les logs générés par le système, dans la mesure où ils sont sous leur contrôle, pour une période appropriée à la finalité, au minimum six mois, sauf disposition contraire. Voir les obligations du déployeur (Art. 26).

Documentation technique (Art. 11 + Annexe IV)

La documentation technique du système à haut risque (Annexe IV) comprend les journaux de test. C'est un livrable que les autorités peuvent demander dans le cadre du contrôle de conformité (Art. 21).

Coopération en cas d'incident grave (Art. 73)

En cas d'incident grave, le fournisseur notifie les autorités de surveillance du marché au plus tard 15 jours après en avoir eu connaissance, 2 jours en cas d'infraction généralisée ou de perturbation grave et irréversible d'une infrastructure critique, 10 jours en cas de décès (Art. 73). Les logs sont l'élément central de l'investigation à conduire.

Obligation connexe	Article	Délai / fréquence
Documentation technique	Art. 11 + Annexe IV	Avant mise sur le marché
Conservation des logs	Art. 19	6 mois minimum
Mise à disposition aux autorités	Art. 21	Sur demande motivée
Conservation par le déployeur	Art. 26 §6	6 mois minimum
Notification d'incident grave	Art. 73	2, 10 ou 15 jours selon la gravité
Monitoring post-commercialisation	Art. 72	Continu

7. Sanctions pour non-conformité

Les manquements aux obligations sur les systèmes à haut risque relèvent de l'Article 99 du Règlement (UE) 2024/1689, et non de l'Article 83 du RGPD, qui concerne les violations du RGPD.

Plafonds d'amende administrative

Type de manquement	Article	Plafond
Pratiques interdites	Art. 5	35 M€ ou 7 % du CA mondial
Manquement aux obligations des opérateurs (Art. 12 et 19 via l'Art. 16, Art. 26)	Art. 99 §4	15 M€ ou 3 % du CA mondial
Information inexacte aux autorités	Art. 99 §5	7,5 M€ ou 1 % du CA mondial

Pour une grande entreprise, le montant retenu est le plus élevé des deux. Pour les PME (au sens de la recommandation 2003/361/CE), l'Art. 99(6) retient le montant le moins élevé, ce qui constitue une atténuation notable. Les petites entreprises de taille intermédiaire en bénéficient pour les paragraphes 4 et 5 (Art. 99(6a)).

Critères d'appréciation

L'Art. 99(7) liste les critères pris en compte par l'autorité, notamment :

• Nature, gravité et durée de l'infraction.
• Caractère intentionnel ou négligent.
• Mesures prises pour atténuer le dommage.
• Coopération avec l'autorité.
• Degré de responsabilité au regard des mesures techniques et organisationnelles mises en œuvre (Art. 99(7), point g).
• Manière dont l'infraction est connue des autorités, notamment sa notification par l'opérateur.

Conséquences indirectes

Au-delà de l'amende, les conséquences peuvent inclure :

• Retrait du marché du système non conforme.
• Interdiction de mise à disposition dans l'Union.
• Atteinte réputationnelle auprès des clients professionnels.
• Recours civils des personnes affectées par une décision automatisée mal documentée.

Pour calculer le plafond d'amende de votre entreprise, le calculateur applique les plafonds de l'Art. 99 et la règle du montant le plus bas pour les PME.

8. Ressources pour les PME

Plusieurs ressources officielles aident à structurer la démarche.

Ressources institutionnelles

• AI Act Service Desk : point d'entrée de la Commission européenne pour les questions sur l'application du règlement.
• CNIL : fiches pratiques sur l'IA et le RGPD.

Normes techniques mobilisables

Norme	Apport pour l'Art. 12
ISO/IEC 42001:2023	Système de management de l'IA : clause 8 (fonctionnement), contrôle A.6.2.8 (journaux d'événements)
ISO/IEC 23894:2023	Gestion du risque IA — traçabilité des risques
ISO/IEC 27001:2022	Sécurité de l'information : contrôle de journalisation de l'Annexe A
ISO/IEC 27037:2012	Identification, collecte et préservation des preuves numériques

Autorités sectorielles

Selon le secteur d'activité, d'autres autorités peuvent être compétentes. La page Sources liste les références.

FAQ

Quels sont les risques pour une PME qui ne respecte pas l'Article 12 ?

Les manquements du fournisseur aux obligations applicables aux systèmes à haut risque (Art. 12 et 19 via l'Art. 16) sont sanctionnés par l'Article 99(4) du Règlement (UE) 2024/1689, et non par l'Art. 83 du RGPD. Les amendes peuvent atteindre 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Pour les PME, l'Art. 99(6) prévoit que le montant le moins élevé s'applique. S'y ajoutent le retrait possible du marché et des recours civils des personnes affectées.

Comment choisir un outil de journalisation adapté à ma PME ?

Évaluez d'abord vos besoins en volume (nombre d'événements par jour), en latence (temps réel ou différé), en rétention (au moins six mois, Art. 19 et 26(6)) et en budget. Trois familles de solutions coexistent : pile open source, maîtrisée mais exigeante en compétences ; SaaS spécialisé, rapide à déployer mais à coût récurrent ; service managé cloud, cohérent si l'IA est déjà hébergée chez le même fournisseur. Privilégiez les solutions offrant chiffrement, contrôle d'accès par rôle et horodatage signé.

Dois-je enregistrer les logs pour tous mes systèmes d'IA ?

Non. L'Art. 12 s'applique aux systèmes d'IA à haut risque : ceux de l'Annexe III et ceux liés aux produits de l'Annexe I (Art. 6). Les systèmes soumis à l'Art. 50 (chatbots, hypertrucages) n'ont que des obligations de transparence. Les systèmes à risque minimal ne sont pas concernés. La première étape consiste donc à qualifier chaque système avant de déployer un dispositif de journalisation.

Comment sécuriser les logs ?

La sécurisation s'articule autour de cinq mesures : chiffrement au repos (AES-256) et en transit (TLS 1.3) ; contrôle d'accès basé sur les rôles avec journalisation des consultations ; horodatage signé ou stockage WORM pour garantir l'intégrité ; séparation stricte entre environnements de production et de développement ; audits réguliers. Ces mesures sont alignées sur la norme ISO/IEC 27001:2022, annexe A, et sur l'obligation de sécurité du RGPD (Art. 32) lorsque les logs contiennent des données personnelles.

Où puis-je obtenir de l'aide pour la mise en conformité avec l'Article 12 ?

L'AI Act Service Desk de la Commission européenne est un point d'entrée pour les questions sur l'application du règlement. La CNIL publie des fiches pratiques sur l'IA et le RGPD. regulia propose un pack de documents de conformité (registre des systèmes d'IA, évaluations de risques, procédure d'incidents) personnalisé par questionnaire.

Sources officielles

• Règlement (UE) 2024/1689 — texte officiel EUR-Lex
• Règlement (UE) 2026/1744 (« Omnibus IA ») — EUR-Lex
• AI Act Service Desk — Commission européenne
• CNIL — fiches pratiques IA
• ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system
• ISO/IEC 23894:2023 — Artificial intelligence — Guidance on risk management
• ISO/IEC 27001:2022 — Information security management systems

---

Disclaimer

Cet article fournit des informations générales sur l'EU AI Act applicables aux PME françaises. Il ne constitue pas un conseil juridique. Pour toute décision opérationnelle, faites valider votre démarche par votre DPO ou conseil juridique. regulia décline toute responsabilité quant à l'usage qui peut être fait de ces informations.