Règlement (UE) 2024/1689 (règlement sur l'intelligence artificielle)
Ce que l'AI Act exige en matière d'enregistrements, et ce que Logsiegel en couvre
L'AI Act est la première réglementation qui impose expressément la journalisation des systèmes d'IA. Il dit qu'il faut enregistrer et combien de temps, mais pas comment prouver ensuite que l'enregistrement est inaltéré. C'est exactement là que Logsiegel intervient.
Qui est concerné
Fournisseurs et déployeurs de systèmes d'IA à haut risque au sens de l'annexe III (par exemple recrutement, solvabilité, infrastructures critiques, éducation, répression pénale, migration) et de l'annexe I (l'IA comme composant de sécurité de produits réglementés). Les délais d'application pour les systèmes à haut risque ont été ajustés en 2026 dans le cadre du Digital Omnibus ; c'est l'état en vigueur qui fait foi. Qui exploite aujourd'hui un agent dans l'un de ces domaines a intérêt à intégrer la journalisation maintenant plutôt qu'à la veille de l'échéance.
Ce que la réglementation exige en matière d'enregistrements
Les obligations se répartissent sur trois articles, auxquels s'ajoute le contrôle humain, qui ne se démontre qu'avec des enregistrements :
| Référence | Exigence |
|---|---|
| Art. 12, par. 1 | Les systèmes d'IA à haut risque doivent permettre techniquement l'enregistrement automatique des événements (journaux) tout au long de leur durée de vie. |
| Art. 12, par. 2 | La journalisation doit permettre la traçabilité du fonctionnement du système, dans la mesure utile à l'identification des situations à risque, au suivi après commercialisation (art. 72) et à la surveillance du fonctionnement par le déployeur (art. 26, par. 5). |
| Art. 12, par. 3 | Pour l'identification biométrique à distance, en plus : au minimum la période de chaque utilisation, la base de données de référence, les données d'entrée ayant donné lieu à une correspondance et l'identité des personnes ayant vérifié le résultat. |
| Art. 19 | Les fournisseurs conservent les journaux générés automatiquement, lorsqu'ils sont sous leur contrôle, pendant au moins six mois (plus longtemps si le droit de l'Union ou le droit national l'exige). |
| Art. 26, par. 6 | Les déployeurs conservent les journaux générés automatiquement, lorsqu'ils sont sous leur contrôle, également pendant au moins six mois. |
| Art. 14 | Contrôle humain : des personnes doivent pouvoir intervenir, arrêter le système ou écarter une sortie. Que cela ait eu lieu ne se démontre qu'avec un enregistrement de l'intervention. |
| Art. 26, par. 5 | Les déployeurs surveillent le fonctionnement sur la base de la notice d'utilisation et informent le fournisseur et les autorités en cas de risque ou d'incident grave ; les journaux en sont le fondement. |
Ce que Logsiegel y apporte aujourd'hui
- Enregistrement automatique à l'interface. L'adaptateur LiteLLM transforme chaque requête au modèle en un événement avec horodatage, modèle, nombre de jetons et empreintes de l'entrée et de la sortie, sans modifier le code applicatif. Les attributs d'événement suivent les conventions OpenTelemetry GenAI, pour que votre observabilité existante les comprenne.
- Enregistrement inaltéré, vérifiable. Chaque entrée est chaînée par empreinte à la précédente ; à intervalles réguliers, une racine de Merkle est calculée et signée en Ed25519 (point de contrôle). Toute modification, réorganisation ou troncature ultérieure fait échouer
logsiegel verify. - Types d'événements pour l'art. 12, par. 2. Outre
inference, le journal connaît les changements de modèle, les interventions humaines (human_override) et les anomalies, c'est-à-dire les événements qu'il faut pouvoir démontrer pour la traçabilité et le contrôle humain (art. 14). - Conservation démontrable. Un point de contrôle signé atteste qu'à un instant donné le journal avait une longueur et un contenu déterminés. Quiconque tronque ensuite se trahit face à tout point de contrôle ou justificatif remis auparavant. L'obligation de six mois des art. 19 et 26, par. 6, n'est ainsi pas seulement remplie, elle est démontrable.
- Justificatifs unitaires pour des tiers.
logsiegel receiptproduit, pour une action précise, un fichier composé de l'entrée, de sa preuve d'inclusion et d'un point de contrôle signé. Un auditeur, un client ou un tribunal le vérifie hors ligne contre votre clé publiée, sans accès à vos systèmes et sans voir le reste du journal. - Dossier lisible.
logsiegel exportécrit le journal sous forme de dossier Markdown, pour les personnes qui ne veulent pas passer par la ligne de commande. Pour les demandes de la surveillance du marché, ou du fournisseur au déployeur. - Uniquement des métadonnées dans le journal. Seules des métadonnées d'événement et des empreintes salées entrent dans la chaîne ; entrées et sorties sont stockées à part, chiffrées entrée par entrée. Une entrée peut être vidée de son contenu par destruction de sa clé (effacement cryptographique), sans que la chaîne se brise. L'art. 12 exige des événements, pas des contenus ; par construction, le journal ne contient aucune donnée personnelle brute.
Ce qui est en préparation prévu
- Taxonomie d'événements pour agents (appels d'outils, délégation, flux de valeurs, intervention humaine), avec correspondance vers les normes en cours d'élaboration prEN 18229-1 et ISO/IEC 24970.
- Proxy MCP qui atteste les appels d'outils des agents à l'interface, comme l'adaptateur LiteLLM atteste les appels de modèles.
- Règles de conservation : effacement à l'expiration du délai, avec preuve signée que rien ne manquait jusque-là.
- Témoin indépendant qui contresigne les points de contrôle, pour que le déployeur lui-même ne puisse pas tenir deux versions.
Ce que Logsiegel ne fait pas
- La classification. Savoir si votre système est à haut risque relève des annexes I et III et de votre propre analyse, pas de Logsiegel.
- La documentation technique et le système de gestion de la qualité (art. 11, annexe IV, art. 17) sont des obligations distinctes. Logsiegel fournit les journaux auxquels ces documents peuvent renvoyer, pas les documents.
- L'exhaustivité. Ce qui est prouvé, c'est que l'enregistré est inaltéré, jamais que tout a été enregistré. C'est une question d'intégration : l'adaptateur doit se trouver à un endroit par lequel chaque action passe obligatoirement (LiteLLM aujourd'hui, proxy MCP en préparation).
- La protection contre le déployeur lui-même. Qui détient la clé de signature pourrait réécrire le journal et le signer à nouveau. Cela se remarque précisément lorsqu'une autre partie détient un point de contrôle ou un justificatif antérieur. Faites donc sortir les points de contrôle de chez vous ; le contreseing par un témoin indépendant est le prochain niveau.
- Les indications de temps. Tant qu'ils ne sont pas contresignés par un témoin ou par un service d'horodatage qualifié, les horodatages du journal restent une affirmation de le déployeur.
- L'appréciation juridique. Savoir si votre système relève de la réglementation, quelles obligations s'appliquent concrètement et si un justificatif suffit dans un cas donné relève de votre analyse juridique ou de votre service conformité, pas de cet outil.
Comment le mettre en œuvre
1. Installer et créer un journal
Le SDK est en Python, sous Apache 2.0, sans serveur et sans compte. L'origine (origin) désigne le système dont l'activité est journalisée.
pip install logsiegel
logsiegel init ./trail --origin "acme.example/support-agent"
2. Brancher l'adaptateur là où chaque action doit passer
Si votre trafic d'IA passe par LiteLLM, chaque complétion devient une entrée inference signable, et les erreurs sont enregistrées comme anomaly. Les interventions humaines, vous les journalisez expressément comme un événement distinct.
import litellm
from logsiegel.integrations.litellm_logger import LogsiegelLogger
litellm.callbacks = [LogsiegelLogger("/var/lib/logsiegel/prod", store_payload=True)]
3. Journaliser expressément les interventions humaines
L'art. 14 exige que des personnes puissent intervenir. Démontrez qu'elles l'ont fait : chaque arrêt, chaque rejet, chaque correction devient un événement à part entière.
logsiegel log ./trail --event human_override \
--attr actor="j.doe" --attr reason="Sortie rejetée, client conseillé manuellement"
4. Poser des points de contrôle et les faire sortir de chez vous
Posez des points de contrôle régulièrement (par exemple via cron) et déposez-les hors de votre infrastructure : chez l'auditeur, chez le client, dans un dépôt tiers. Seul un point de contrôle que vous ne contrôlez plus seul rend le journal probant contre vous-même.
logsiegel checkpoint ./trail
logsiegel verify ./trail
5. Remettre le justificatif en cas de demande
Au lieu d'extraits de base de données, vous remettez un seul justificatif. La partie adverse le vérifie dans le navigateur sur logsiegel.com/verifier ou en ligne de commande, dans les deux cas hors ligne.
logsiegel receipt ./trail --seq 1284 --out receipt.json
logsiegel verify-receipt receipt.json --pubkey logsiegel.pub
Autres réglementations : RGPD DORA NIS 2 ISO/IEC 27001 ISO/IEC 42001 GoBD eIDAS Vue d'ensemble
État du droit : septembre 2026. Cette page est une appréciation technique par le projet, ni un conseil juridique ni une déclaration de conformité. Merci de vérifier les références sur le texte en vigueur. Corrections bienvenues via une issue GitHub.