L'article 12 exige que les systèmes d'IA à haut risque enregistrent automatiquement les événements — les journaux — pendant toute la durée de vie du système, sous une forme capable d'identifier des situations à risque et de résister aux six mois de conservation prévus par l'article 26. En pratique, cela signifie des journaux d'événements en ajout seul, à l'épreuve des falsifications, et non une table de base de données qu'un administrateur pourrait modifier discrètement. Voici ce que cette exigence signifie techniquement, et la couche de journalisation d'audit que VeriSwarm propose pour aider à la satisfaire.
L'article 12 de l'EU AI Act (Règlement (UE) 2024/1689) exige des systèmes d'IA à haut risque qu'ils « permettent techniquement l'enregistrement automatique des événements (les 'journaux') pendant toute la durée de vie du système ». Les journaux doivent permettre au fournisseur d'identifier les situations susceptibles de présenter un risque, et faciliter la surveillance après commercialisation. L'article 26 vient s'y ajouter : les déployeurs de systèmes à haut risque doivent conserver ces journaux pendant au moins six mois, sauf si une autre législation applicable — le RGPD, des règles sectorielles de conservation des registres — exige une durée plus longue.
Le Digital Omnibus on AI (Règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026) a reporté les obligations à haut risque — y compris l'article 12 — au 2 décembre 2027 pour les systèmes de l'annexe III (2 août 2028 pour les produits intégrés de l'annexe I). Ce qui est déjà applicable aujourd'hui, depuis le 2 août 2026, c'est l'article 50 : les obligations de transparence et de divulgation pour l'interaction IA, le contenu synthétique et les deepfakes. Les journaux à l'épreuve des falsifications sont la manière dont un déployeur prouve que la divulgation prévue par l'article 50 a bien eu lieu — une équipe qui attend l'échéance de 2027 pour commencer à journaliser n'aura aucune trace de preuve historique une fois que l'horloge du haut risque se sera mise en marche.
La plupart des équipes qui construisent une journalisation d'agents se tournent vers l'outil évident : une table Postgres avec une colonne occurred_at. Cela satisfait techniquement à l'« enregistrement automatique ». Cela ne répond pas à la question qu'un auditeur, un régulateur ou votre propre équipe de réponse aux incidents finira par poser : comment savez-vous que cet enregistrement n'a pas été modifié ?
Rien de tout cela n'exige de malveillance — un accès opérationnel ordinaire suffit. Un journal modifiable n'est qu'une affirmation. Ce dont une preuve conforme à l'article 12 a réellement besoin, c'est d'un enregistrement vérifiable de façon indépendante : la preuve que le journal n'a pas été altéré, pas seulement l'affirmation qu'il ne l'a pas été.
VeriSwarm Vault est un registre d'événements en ajout seul, chaîné par hash. Chaque événement — décisions de confiance, résultats de scan Guard, vérifications Passport, changements de cycle de vie des agents — est écrit automatiquement une fois Vault activé, le hash de chaque entrée intégrant le hash de l'entrée précédente. Cette structure en chaîne est ce qui rend la falsification détectable au lieu de simplement découragée : modifier, supprimer ou insérer un enregistrement n'importe où dans la chaîne fait que tous les hashes suivants cessent de correspondre.
Une fois activé, Vault ne nécessite aucun appel de journalisation distinct. Tout événement traité par Gate, Guard ou Passport est écrit dans le registre comme effet secondaire du fonctionnement normal — la formulation « permettre techniquement l'enregistrement automatique » de l'article 12, satisfaite par défaut.
GET /v1/suite/vault/verify parcourt la chaîne de hash et renvoie ok: true/false avec un décompte des entrées vérifiées. Une chaîne rompue est détectable immédiatement et mécaniquement — pas seulement découverte des mois plus tard lors d'une enquête sur une violation.
Les exports du registre (JSON ou CSV, filtrables par type d'événement, acteur ou agent) prennent en charge la fenêtre de conservation de l'article 26 et donnent à un auditeur un artefact structuré et à somme de contrôle plutôt qu'un dump brut de base de données.
L'API de conformité de VeriSwarm reflète cela directement : le contrôle de l'article 12 dans GET /v1/compliance/eu-ai-act évalue le volume d'événements de Vault et renvoie pass/warn/fail avec des décomptes de preuves. Le détail technique complet sur la structure du registre, le schéma des événements et les formats d'export se trouve dans la documentation de Vault.
Être direct sur cette limite compte plus que l'argument de vente. Vault est la couche de journalisation et de preuve pour l'article 12. Ce n'est pas une certification, un avis juridique ou une évaluation de conformité. L'activer ne rend pas à lui seul un système conforme à l'EU AI Act. La loi exige un système de gestion des risques (article 9), une documentation technique (article 11), une conception de supervision humaine (article 14) et — pour de nombreux systèmes à haut risque — une évaluation de conformité formelle avant la mise sur le marché. Ce sont des processus organisationnels et juridiques, pas un simple interrupteur de fonctionnalité.
Ce que fait Vault, c'est éliminer le maillon le plus faible de la chaîne de conservation des enregistrements : un journal modifiable dont personne ne peut prouver qu'il n'a pas été modifié. Tout le reste dans une démarche de conformité à l'article 12 — périmètre, politique de conservation, procédure de réponse aux incidents — doit encore être construit par l'équipe qui déploie le système, idéalement avec l'implication d'un conseil juridique pour tout ce qui touche à un dépôt formel.
Pour une auto-évaluation interactive et spécifique au référentiel de l'exposition sur l'ensemble des obligations de la loi, utilisez le vérificateur de conformité à l'EU AI Act — cette page explique le contrôle de journalisation en détail ; le vérificateur évalue un système précis par rapport à celui-ci.
L'article 12 est l'expression réglementaire d'un problème plus général : prouver les actions d'un agent IA après coup, d'une manière qui ne peut pas être discrètement réécrite. Le mécanisme — un registre chaîné par hash, vérifiable de façon indépendante — précède et survit à toute réglementation spécifique. Pour le concept sous-jacent, son fonctionnement, et pourquoi il s'applique au-delà de la conformité européenne, voir Qu'est-ce qu'une piste d'audit immuable pour les agents IA ?
L'article 12 exige des systèmes d'IA à haut risque qu'ils « permettent techniquement l'enregistrement automatique des événements (les 'journaux') pendant toute la durée de vie du système ». Les journaux doivent pouvoir identifier des situations susceptibles de présenter un risque, et ils doivent soutenir l'obligation de conservation des journaux prévue par l'article 26 — les déployeurs de systèmes à haut risque doivent conserver ces journaux pendant au moins six mois, plus longtemps si une autre législation applicable l'exige. L'exigence n'est pas simplement « avoir des journaux quelque part » — c'est un enregistrement automatique qui tient debout comme preuve exploitable plus tard.
Elle satisfait à la lettre de l'« enregistrement automatique », mais pas à l'esprit qu'appliqueront les auditeurs. Une table de journal classique prouve qu'un événement a été écrit ; elle ne prouve pas que l'enregistrement n'a pas été altéré ensuite. Quiconque dispose d'un accès en écriture — un ingénieur, un identifiant compromis, une correction précipitée en réponse à un incident — peut modifier une ligne, et la table paraît exactement identique à avant. L'article 12 n'utilise pas le terme « à l'épreuve des falsifications », mais un auditeur qui demande « comment savez-vous que ce journal est exact » mérite une meilleure réponse que « nous faisons confiance à nos administrateurs ».
Dans un registre chaîné par hash, le hash cryptographique de chaque événement intègre le hash de l'événement qui le précède immédiatement, de sorte que chaque entrée se relie à la précédente dans une chaîne ininterrompue. Modifier, supprimer ou insérer une entrée n'importe où dans cette chaîne fait que tous les hashes suivants cessent de correspondre — la falsification devient mathématiquement détectable au lieu d'être simplement découragée sur le plan procédural. VeriSwarm Vault écrit chaque événement lié aux agents — décisions de confiance, résultats de scan Guard, vérifications Passport, événements de cycle de vie des agents — dans exactement ce type de registre en ajout seul, chaîné par hash, et expose un point de terminaison de vérification de chaîne (GET /v1/suite/vault/verify) qui parcourt toute la chaîne et indique si elle est intacte.
Non, et tout fournisseur qui laisse entendre qu'une seule fonctionnalité y parvient exagère. Vault est la couche de journalisation et de preuve pour l'obligation de conservation des enregistrements de l'article 12 — des journaux d'événements automatiques, à l'épreuve des falsifications et exportables pour chaque action d'agent, avec une intégrité vérifiable de façon indépendante. La loi contient de nombreuses autres obligations — gestion des risques (article 9), documentation technique (article 11), supervision humaine (article 14), transparence (article 13), et une évaluation de conformité — qui exigent des processus organisationnels que VeriSwarm n'exécute pas au nom d'un client. Vault fournit à un programme de conformité la preuve dont il a besoin pour l'article 12 ; ce n'est pas le programme dans son ensemble.
L'EU AI Act est entré en vigueur par étapes : les interdictions de pratiques prohibées ont pris effet en février 2025, et les obligations relatives aux modèles d'IA à usage général en août 2025. Le Digital Omnibus on AI (Règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026) a reporté les obligations relatives aux systèmes à haut risque — y compris l'exigence de journalisation de l'article 12 — au 2 décembre 2027 pour les systèmes de l'annexe III et au 2 août 2028 pour les produits de l'annexe I. Ce qui est déjà applicable aujourd'hui (depuis le 2 août 2026), c'est l'article 50 : des obligations de transparence et de divulgation dont on prouve le respect avec — des journaux. Construire dès maintenant une journalisation au niveau de l'article 12 est la façon dont les déployeurs prouvent que la divulgation prévue par l'article 50 a eu lieu, et arrivent en décembre 2027 déjà conformes.
Non. Vault est une fonctionnalité de l'offre Max. L'offre gratuite de Gate inclut le moteur complet de scoring de confiance et une ingestion d'événements illimitée, mais le registre immuable chaîné par hash, le point de terminaison de vérification de chaîne et les exports d'audit qui étayent la preuve de l'article 12 nécessitent une offre Max. Voir /pricing pour les détails actuels des offres.
Vault est une fonctionnalité de l'offre Max — le registre chaîné par hash, la vérification de chaîne et les exports d'audit ne sont pas inclus dans l'offre gratuite. Découvrez comment il est structuré, ou vérifiez où se situe un système précis par rapport à l'ensemble de la loi.