L'article 12 du règlement européen sur l'IA exige que les systèmes d'IA à haut risque permettent techniquement l'enregistrement automatique des événements (journaux) tout au long de leur durée de vie. Les journaux doivent rendre le système traçable à un niveau adapté à sa destination (finalité prévue) et permettre la détection des risques, la surveillance après commercialisation et la surveillance par le déployeur. L'article 19 impose ensuite aux fournisseurs une obligation de conservation des journaux générés automatiquement qui sont sous leur contrôle. Pour un agent IA, une mise en œuvre défendable relie l'exécution, l'agent et la Release, les décisions de politique, les appels d'outils, les décisions humaines, les résultats et les preuves d'intégrité. Ce guide distingue le texte du règlement de la spécification technique utilisée pour produire des enregistrements examinables. Il fournit des repères pratiques et ne constitue pas un avis juridique.
Ce qu'exigent les articles 12 et 19
L'article 12 figure au chapitre III, section 2, qui définit les exigences applicables aux systèmes d'IA à haut risque. Sa portée dépend de la classification du système et de sa finalité prévue. Un agent de service client ou un assistant interne n'entre pas dans le champ de l'article 12 au seul motif qu'il utilise un modèle d'IA ou peut appeler des outils. Commencez par le socle des exigences du règlement européen sur l'IA et documentez la décision de classification.
Le règlement (UE) 2026/1744 a modifié les dates d'application de ces dispositions relatives aux systèmes à haut risque. Les sections 1 à 3 du chapitre III s'appliquent à compter du 2 décembre 2027 aux systèmes classés au titre de l'article 6(2) et de l'annexe III, et à compter du 2 août 2028 aux systèmes liés à des produits, classés au titre de l'article 6(1) et de l'annexe I. Ces dates plus tardives dégagent du temps pour la mise en œuvre. Elles laissent intacte la conception des contrôles prévus par les articles 12 et 19.
| Source | Exigence du règlement | Spécification opérationnelle | Test de preuve |
|---|---|---|---|
| Article 12(1) | Le système d'IA à haut risque permet techniquement l'enregistrement automatique des événements (journaux) tout au long de sa durée de vie. | Émettre des enregistrements depuis le chemin d'exécution pour chaque exécution gouvernée et chaque action conséquente. Éviter une conception qui dépend d'une personne chargée d'assembler l'enregistrement après l'événement. | Exécuter un Process représentatif et rapprocher la population des exécutions avec les enregistrements créés automatiquement. |
| Article 12(2)(a) | Les journaux enregistrent les événements pertinents pour identifier un risque au sens de l'article 79(1) ou une modification substantielle. | Enregistrer les défaillances, les blocages et avertissements de politique, les accès anormaux aux outils, les dérogations, les changements de Release, les sorties inattendues et les effets qui en résultent, au moyen d'identifiants stables. | Déclencher chaque signal de risque défini et confirmer que l'enregistrement identifie l'exécution, la version, l'événement, l'heure et le résultat concernés. |
| Article 12(2)(b) | Les journaux facilitent le système de surveillance après commercialisation prévu par l'article 72. | Utiliser des champs d'événement permettant les requêtes sur la population, l'analyse des tendances, la corrélation des incidents et les liens vers le plan de surveillance du fournisseur. | Reproduire une métrique de surveillance à partir des enregistrements sources et suivre une exception jusqu'au plan de surveillance après commercialisation. |
| Article 12(2)(c) | Les journaux permettent la surveillance par le déployeur au titre de l'article 26(5). | Exposer l'état opérationnel, le contexte de la notice d'utilisation, le signal de risque, la référence de notification au fournisseur, l'événement de suspension et la référence de l'incident grave, le cas échéant. | Suivre un risque simulé depuis sa détection jusqu'à la suspension ou au traitement, et vérifier les références de notification au fournisseur et à l'autorité. |
| Article 12(3) | Pour les systèmes d'identification biométrique à distance couverts par l'annexe III, point 1(a), les journaux comprennent chaque période d'utilisation, la base de données de référence, les données d'entrée ayant abouti à une correspondance et les personnes qui ont vérifié les résultats au titre de l'article 14(5). | Créer des champs dédiés pour l'enregistrement biométrique minimal. Appliquer aux données sensibles les contrôles d'accès et les règles de protection des données. | Sélectionner une utilisation et vérifier que les heures de début et de fin, la référence de la base de données, l'entrée ayant abouti à une correspondance et les identités des vérificateurs sont présentes et autorisées. |
| Article 19(1) | Un fournisseur conserve les journaux de l'article 12 qui sont sous son contrôle pendant une période adaptée à la finalité prévue et d'au moins six mois, sauf disposition contraire d'un autre droit applicable. | Attribuer à chaque enregistrement contrôlé par le fournisseur une classe de conservation, une source, une finalité, une durée minimale, un comportement de gel juridique (legal hold), une règle d'accès et un chemin de suppression vérifié. | Inspecter la politique de stockage, prouver que les enregistrements concernés restent disponibles pendant toute la période requise de six mois, puis tester le gel juridique et la suppression autorisée après l'expiration configurée. |
| Article 26(6) | Un déployeur applique la même règle minimale de six mois aux journaux générés automatiquement qui sont sous son contrôle, sous réserve d'un autre droit applicable. | Définir le passage de relais entre fournisseur et déployeur : quelle partie contrôle chaque enregistrement, comment le déployeur le collecte et l'interprète, et comment les contrats préservent l'accès. | Suivre un enregistrement de production depuis sa génération jusqu'au stockage contrôlé par le déployeur et confirmer sa récupération, sa conservation et sa propriété. |
Une spécification concrète de piste d'audit pour les agents IA
L'article 12 énonce les finalités de la journalisation et donne une liste minimale précise de champs pour les systèmes d'identification biométrique à distance visés à l'article 12(3). Pour les autres systèmes à haut risque, le fournisseur définit un ensemble de champs qui rend le système traçable pour sa finalité prévue. La spécification ci-dessous constitue un point de départ défendable pour un agent capable de récupérer des données, de prendre des décisions gouvernées par une politique, de demander un examen humain et d'appeler des outils. Le schéma de journal d'audit des agents IA téléchargeable transforme ces familles d'événements en un contrat versionné, indépendant des éditeurs, accompagné d'enregistrements témoins pour les cas complet, refusé et altération détectée.
Capturez des références ou des hachages lorsqu'une charge utile complète entrerait en conflit avec les exigences de minimisation des données, de confidentialité ou de sécurité. Un enregistrement utile conserve le sens de l'événement et un chemin d'accès contrôlé vers les preuves sous-jacentes.
| Famille d'événements | Champs à capturer | Finalité du contrôle | Test d'acceptation |
|---|---|---|---|
| Identité de l'exécution | Tenant, identifiants d'exécution et de corrélation ; identifiant de l'agent ; identifiant, version et hachage de la Release ; identifiant et version du Process ; environnement ; principal initiateur ; sujet pour le compte duquel l'agent agit ; horodatages de début et de fin | Définir le système, la version, l'autorité et la période concernés par une exécution. | Relier chaque événement d'une exécution échantillonnée à un seul enregistrement d'identité sans dépendre des seuls horodatages. |
| Entrée et récupération | Référence de l'entrée ou charge utile protégée ; références des sources et des enregistrements ; requête ou hachage de récupération ; version du modèle et du gabarit de prompt ; état de caviardage ; heure de l'événement | Montrer quelles informations sont entrées dans l'exécution et quelle version les a interprétées. | Reconstruire l'ensemble des entrées approuvées et prouver que les champs protégés restent soumis à des contrôles d'accès. |
| Demande d'outil | Nom de l'outil ; identifiants d'appel et de gate ; destination ; arguments ou hachage des arguments ; autorité demandée ; clé d'idempotence ; heure de la demande | Identifier l'action conséquente proposée par l'agent avant qu'un effet externe ne se produise. | Faire correspondre la demande à son résultat de politique et prouver qu'une livraison en double ne peut pas créer un second effet inexpliqué. |
| Décision de politique | Identifiant de décision ; type de gate ; résultat allow, warn, require_approval ou block ; identifiant et version de la politique, hachage du pack ; identifiants des règles correspondantes ; codes de motif ; heure de la décision | Montrer quel contrôle a gouverné l'action et la version exacte évaluée. | Réévaluer un échantillon épinglé avec les faits enregistrés et expliquer toute différence par un changement de version. |
| Décision humaine | Identifiant de la Decision Request ; rôle requis ; identité et autorité de l'examinateur ; résultat (approbation, rejet ou escalade) ; justification ; accusé de réception ; heures de demande et de décision | Relier un jugement déterminant à une personne responsable et à l'action retenue pour examen. | Prouver que l'examinateur disposait de l'autorité au moment de la décision et que la demande d'outil est restée en pause jusqu'à la résolution. |
| Résultat de l'outil et effet métier | Statut ; référence ou hachage du résultat ; erreur ; décision de politique de sortie ; références des états avant et après ; identifiant de transaction en aval ; heure d'achèvement | Distinguer une proposition d'une action qui a atteint le système cible. | Rapprocher l'enregistrement du système en aval et couvrir les cas de succès, d'échec, de blocage, d'annulation et de nouvelle tentative. |
| Signal de surveillance et d'incident | Type de signal ; gravité ; exécution et Release concernées ; version du seuil ou du détecteur ; traitement ; responsable ; références de notification et d'incident | Appuyer la surveillance prévue par l'article 72 et la réponse opérationnelle prévue par l'article 26(5). | Reproduire le signal à partir des enregistrements sources et le suivre jusqu'à un traitement documenté. |
| Intégrité et conservation | Hachage de l'enregistrement ; hachage de l'enregistrement précédent, le cas échéant ; signature et identifiant de clé, le cas échéant ; référence du registre ou du manifeste ; classe de conservation ; expiration ; état de gel juridique ; événement de suppression | Détecter les modifications ultérieures et prouver que l'enregistrement est resté disponible pendant la période approuvée. | Modifier un octet exporté et exiger l'échec de la vérification ; tester séparément les contrôles de conservation, de gel juridique et de suppression. |
La conservation est un contrôle du fournisseur et du déployeur
L'article 19(1) impose aux fournisseurs de conserver les journaux de l'article 12 générés automatiquement qui sont sous leur contrôle. L'article 26(6) impose une obligation équivalente aux déployeurs pour les journaux sous leur contrôle. Les deux dispositions suivent la même structure : une période adaptée à la finalité prévue, un minimum de six mois et une exception lorsque le droit de l'Union ou le droit national applicable prévoit une autre règle. Les établissements financiers conservent ces journaux dans la documentation tenue au titre du droit de l'Union applicable aux services financiers.
La période de six mois constitue un plancher pour les journaux couverts par ces dispositions. L'article 18 impose séparément aux fournisseurs de conserver pendant dix ans les documents techniques et de conformité qu'il énumère. Ces périodes couvrent des enregistrements différents. Les règles de protection de la vie privée, de droit du travail, les règles sectorielles, les gels contentieux et le droit national peuvent modifier la durée applicable ou les données pouvant être conservées.
Établissez un registre de conservation avant de choisir une durée de vie (TTL) de stockage. Pour chaque classe de preuves, consignez sa source juridique ou métier approuvée, sa finalité, la partie responsable, le système de référence, les durées minimale et maximale, la date de déclenchement, les rôles d'accès, la règle de gel juridique, la méthode de suppression et les preuves de test. Le modèle de politique de conservation des journaux d'audit fournit une structure opérationnelle.
- Répartir le contrôle : nommer les enregistrements contrôlés par le fournisseur et ceux contrôlés par le déployeur, y compris les copies créées par un éditeur d'observabilité ou un opérateur de runtime.
- Aligner les couches : le magasin de traces, le registre de preuves, le bundle exporté, l'index, la sauvegarde et le cycle de vie des clés de chiffrement doivent avoir des durées compatibles.
- Protéger le contenu : minimiser les données à caractère personnel, séparer les charges utiles sensibles des métadonnées largement interrogeables et appliquer un accès limité à la finalité.
- Tester la récupération : un enregistrement conservé a de la valeur lorsqu'un examinateur autorisé peut le localiser, l'interpréter et l'exporter dans le respect du niveau de service requis.
- Tester l'expiration : prouver que le système respecte un gel juridique, consigne la suppression autorisée et supprime chaque copie gouvernée à la fin de la période approuvée.
La détection des altérations et le rejeu sont des contrôles d'assurance
L'article 12 mentionne l'enregistrement automatique et la traçabilité. Il ne prescrit aucun mécanisme cryptographique ni point de terminaison de rejeu. La détection des altérations et le rejeu sont des contrôles de mise en œuvre qui aident un fournisseur à démontrer que l'enregistrement est suffisamment complet pour être utilisé et qu'il est resté inchangé.
Par rejeu, entendez la reconstruction du chemin de contrôle enregistré. Réexécuter un modèle ou un outil externe peut produire une sortie différente ou répéter un effet de bord. Un rejeu sûr lit la séquence, les versions, les faits de politique, les décisions humaines et les références de résultat stockés. Une simulation de politique distincte peut réévaluer les faits enregistrés avec une version de politique épinglée sans déclencher l'action.
| Test | Résultat attendu | Signal d'échec |
|---|---|---|
| Rapprochement de la population | Chaque exécution dans le périmètre et chaque action conséquente possède un enregistrement, y compris les autorisations ordinaires, les blocages, les échecs et les annulations. | Le nombre d'exécutions dépasse le nombre d'enregistrements, ou des enregistrements non rapprochés n'ont aucune exécution source. |
| Ordre causal | La décision de politique précède l'action gouvernée ; une décision humaine requise précède la libération de l'action ; le résultat suit l'exécution. | Un effet de bord ne possède aucun enregistrement de contrôle antérieur, ou les horodatages ne permettent pas d'établir la séquence. |
| Contexte épinglé | L'enregistrement résout la Release de l'Agent et du modèle, la version du Process, la version de la politique, les identités et l'autorité actives au moment de l'événement. | Un examinateur ne voit que la configuration actuelle ou doit déduire quelle version a été exécutée. |
| Rapprochement du résultat | Le résultat de l'outil et l'effet métier correspondent à la source en aval, y compris le comportement des nouvelles tentatives et de l'idempotence. | La piste d'audit indique un achèvement alors que la cible ne possède aucune transaction correspondante, ou des effets en double n'ont pas de causes distinctes. |
| Vérification de l'intégrité | Les hachages, signatures, liens de chaîne, preuves de registre et contrôles du manifeste se vérifient là où ils sont configurés ; une mutation contrôlée fait échouer la vérification. | Un artefact modifié passe encore la vérification, ou le vérificateur ne peut pas identifier le fichier ou l'enregistrement concerné. |
| Reconstruction sûre | Un examinateur peut lire la séquence complète sans réexécuter un effet de bord conséquent. | Le seul chemin de reconstruction déclenche l'appel d'outil d'origine ou dépend d'une réponse de modèle indisponible. |
Comment les preuves du runtime KLA correspondent à la spécification
KLA crée un Lineage Record pour une exécution gouvernée et utilise des identifiants d'exécution et de tenant stables pour relier les événements du runtime. Les spans d'exécution peuvent porter la version et le hachage du Process, les identifiants de Release de l'Agent, l'environnement, le principal initiateur, le sujet pour le compte duquel l'agent agit et l'identité du client appelant enregistrée pour l'exécution. Les spans de workflow enregistrent les résultats des nœuds, les résultats de politique, les identifiants et règles de politique, les Decision Requests, les identités des examinateurs, les horodatages et les erreurs.
La passerelle de gouvernance KLA évalue les gates d'entrée et de sortie des outils via le KLA Policy Engine lorsque les opérateurs activent KLA_GOVERNANCE_GATEWAY pour un environnement. La configuration de production de l'execution-worker versionnée dans le dépôt n'active pas actuellement ce chemin. Lorsque ce chemin est activé, un résultat de gate utilise les quatre valeurs allow, warn, require_approval et block. Les reçus de décision comprennent l'exécution, le gate, l'outil, la version de politique, le hachage du pack de politiques, les codes de motif, la Decision Request, la trace et le hachage de sortie, le cas échéant. La passerelle scelle le reçu du gate d'entrée avant d'exécuter l'outil gouverné et scelle le reçu du gate de sortie avant de renvoyer ou de retenir le résultat. Une défaillance d'écriture de preuve empêche le gate de progresser.
| Besoin de contrôle | Brique KLA | Preuve produite | Limite à vérifier |
|---|---|---|---|
| Identité stable de l'exécution | Agents, Releases, Processes et Lineage Records | Identifiants d'exécution, de tenant, de Release de l'Agent, d'environnement, de principal et de corrélation ; version et hachage du Process | Confirmer que chaque intégration propage les identifiants et que les champs d'identité facultatifs sont présents pour le Process examiné. |
| Séquence automatique des événements | KLA Runtime et spans d'exécution OpenTelemetry | Événements d'exécution, de nœud, de politique, d'approbation, d'erreur, d'horodatage et de résultat ordonnés dans un même Lineage Record | Rapprocher la population des exécutions et confirmer que les outils sélectionnés émettent les références d'entrée, de résultat et d'effet en aval requises par la finalité prévue. |
| Contrôle de la politique et de l'outil | Passerelle de gouvernance KLA activée par environnement | Type de gate, version de politique, décision, motifs, Decision Request, hachage des arguments, hachage de sortie et état d'idempotence ; identifiants des règles correspondantes lorsque la décision require_approval évaluée fournit les règles correspondantes | Confirmer que la passerelle est activée dans l'environnement examiné. Tester les quatre résultats, les preuves facultatives de règles correspondantes, la défaillance du service de politique, la modification des arguments après approbation, les nouvelles tentatives et l'annulation. |
| Décision humaine | Decision Desk et enregistrements d'approbation durables | Rôle requis, identité de l'examinateur, décision, justification, horodatages, contexte de politique et exécution corrélée | Tester l'autorité de l'examinateur, les règles de double contrôle (maker-checker) lorsqu'elles sont configurées et la séquence complète de la mise en pause à la libération. |
| Enregistrement à altération détectable | Registre de preuves append-only et reçus de gouvernance | Écritures vérifiées dans le registre ; signatures Ed25519 et liens de chaîne de hachage lorsque la signature des reçus est activée | Traiter l'état de signature comme un fait observé du déploiement. Alerter en cas de dégradation de la signature et exécuter un test d'altération contrôlé. |
| Dossier de revue portable | Evidence Room et Sealed Evidence Bundles | Enregistrements de lignage, de politique, d'approbation et de registre sélectionnés, avec un manifeste, des hachages, des données d'inclusion Merkle et des signatures pour une vérification hors ligne | Confirmer la population exportée, le profil de caviardage, le résultat du vérificateur, la disponibilité des clés et l'enregistrement de chaîne de traçabilité. |
| Conservation | Conservation des tâches de l'Evidence Factory et configuration du stockage des bundles | Métadonnées de conservation des tâches d'export, expiration et conservation configurée du stockage des bundles | Rapprocher ces contrôles d'export de la conservation des Lineage Records sources et des enregistrements du registre. Définir et tester la période requise pour le système classé et le secteur. La capacité du produit ne fixe pas à elle seule la durée légale approuvée. |
Liste de contrôle de mise en œuvre
Faites de la spécification un gate de release pour chaque système d'IA à haut risque. Conservez ensemble la fiche de classification, la finalité prévue, le schéma d'événements, le registre de conservation, la revue de protection des données, les tests et le plan de surveillance dans le dossier de documentation de l'annexe IV.
- Nommer le fournisseur, le déployeur, la finalité prévue, le fondement de la classification à haut risque, le périmètre du système, les Releases de l'Agent et du modèle, et chaque partie qui contrôle une copie des journaux.
- Définir la population d'exécutions dans le périmètre et les actions conséquentes qui nécessitent des enregistrements complets d'outil, de politique, de décision humaine et de résultat.
- Publier un schéma d'événements versionné avec les champs obligatoires, les classifications de données, les règles de caviardage, les identifiants, l'ordre d'événements autorisé et le comportement en cas d'échec.
- Rendre la création des enregistrements automatique dans le chemin d'exécution et adopter un échec fermé (fail closed) lorsqu'un reçu de contrôle manquant laisserait une action conséquente sans gouvernance.
- Rapprocher les exécutions des enregistrements et tester les autorisations ordinaires, les avertissements, les approbations requises, les blocages, les erreurs, les nouvelles tentatives, les annulations et la défaillance du service de politique.
- Définir la conservation du fournisseur et du déployeur à partir du registre approuvé, avec un test de six mois minimum lorsque l'article 19 ou l'article 26(6) s'applique.
- Exécuter des tests de reconstruction sûre, de rapprochement des résultats, de contrôle d'accès, de gel juridique, de suppression, d'export et d'altération d'un octet.
- Alimenter le plan de surveillance de l'article 72 avec les événements définis et relier les signaux aux responsables, aux traitements, aux incidents et aux actions correctives.
Foire aux questions
L'article 12 du règlement européen sur l'IA s'applique-t-il à tous les agents IA ?
L'article 12 s'applique aux systèmes d'IA à haut risque. Un agent a d'abord besoin d'une classification et d'une finalité prévue documentées. Les organisations peuvent appliquer les mêmes contrôles de journalisation aux agents à risque plus faible par choix de gouvernance.
Quels événements un agent IA doit-il journaliser au titre de l'article 12 ?
L'article 12 exige la journalisation des événements pertinents pour la détection des risques, l'identification d'une modification substantielle, la surveillance après commercialisation et la surveillance par le déployeur. Il donne une liste minimale explicite de champs pour les systèmes d'identification biométrique à distance visés à l'article 12(3). Les autres systèmes ont besoin d'un schéma adapté à leur finalité. Pour un agent utilisant des outils, l'identité de l'exécution, les versions, les entrées ou leurs références, les demandes d'outils, les résultats de politique, les décisions humaines, les résultats, les erreurs et les horodatages forment une base défendable.
Combien de temps faut-il conserver les journaux de l'article 12 ?
L'article 19(1) impose aux fournisseurs de conserver les journaux générés automatiquement qui sont sous leur contrôle pendant une période adaptée à la finalité prévue et d'au moins six mois, sauf disposition contraire du droit de l'Union ou du droit national applicable. L'article 26(6) impose la même règle aux déployeurs pour les journaux sous leur contrôle. D'autres enregistrements et des règles sectorielles peuvent prévoir des durées différentes.
L'article 12 exige-t-il des journaux à altération détectable ?
L'article exige la journalisation automatique et la traçabilité, sans nommer de mécanisme cryptographique. Le stockage append-only, les hachages, les signatures et la vérification indépendante sont des contrôles d'assurance qui aident à détecter les modifications et à soutenir un processus de preuve défendable.
L'article 12 exige-t-il un rejeu ?
L'article ne contient aucune exigence expresse de rejeu. La reconstruction sûre constitue un test d'acceptation utile : un examinateur doit pouvoir lire la séquence enregistrée, les versions, les décisions et les résultats sans relancer un modèle ni répéter un effet de bord.
Les journaux applicatifs ordinaires peuvent-ils satisfaire à cette exigence ?
Ils peuvent y contribuer lorsqu'ils sont automatiques, complets pour la finalité prévue, corrélés dans l'ensemble du système, interprétables, soumis à des contrôles d'accès, conservés pendant la période approuvée et disponibles pour la surveillance. Les messages de débogage propres à un service ne contiennent souvent ni les versions de politique, ni l'autorité humaine, ni les résultats métier, ni le rapprochement de la population.
Comment KLA soutient-il une conception de journalisation conforme à l'article 12 ?
KLA relie les spans de runtime, les résultats de politique, les gates d'outils, les Decision Requests et les résultats d'exécution dans des Lineage Records. Evidence Room exporte les enregistrements sélectionnés avec des métadonnées d'intégrité pour une vérification hors ligne. Le fournisseur et le déployeur restent responsables de la classification, de la suffisance des champs, de la conservation, de la protection des données, de la surveillance et de l'évaluation finale de conformité.
Points clés à retenir
Une mise en œuvre utile de l'article 12 commence par la classification et la finalité prévue, puis enregistre automatiquement chaque exécution dans le périmètre et chaque action conséquente. Les articles 19 et 26(6) font de la conservation un contrôle doté d'un responsable. Un schéma d'événements versionné, des identités stables, le contexte des politiques et des décisions humaines, les références des résultats en aval, le rapprochement de la population, les tests d'altération et la reconstruction sûre rendent ces journaux utilisables pour la surveillance et la revue. Consultez le guide des pistes d'audit des agents IA pour l'architecture globale des preuves, le guide de documentation de l'annexe IV pour le dossier technique et le plan de surveillance après commercialisation pour la boucle opérationnelle.