ISO/IEC 42001:2023, annexe A
Ce qu'ISO 42001 exige comme journaux d'événements pour les systèmes d'IA, et ce que Logsiegel y apporte
ISO 42001 est le système de management de l'IA, pensé comme le pendant d'ISO 27001 pour la sécurité de l'information. Il exige expressément des journaux d'événements pour les systèmes d'IA. Logsiegel est un tel journal, avec ceci en plus que son inaltération est démontrable.
Qui est concerné
Organisations qui mettent en place ou font certifier un système de management de l'IA selon ISO/IEC 42001, en tant que fournisseur ou en tant qu'utilisateur de systèmes d'IA. De plus en plus aussi comme preuve envers des clients qui exigent une gouvernance de l'IA dans leurs appels d'offres, et comme brique pour la conformité à l'AI Act.
Ce que la réglementation exige en matière d'enregistrements
Les mesures pertinentes de l'annexe A :
| Référence | Exigence |
|---|---|
| A.6.2.8 | Enregistrement des journaux d'événements du système d'IA : l'organisation détermine dans quelles phases du cycle de vie des journaux d'événements sont tenus, au minimum pendant l'utilisation du système d'IA. |
| A.6.2.6 | Exploitation et surveillance : le fonctionnement du système d'IA est surveillé conformément à la documentation ; les écarts doivent être détectés. |
| A.6.2.5 | Déploiement : exigences relatives au déploiement, y compris les conditions dans lesquelles le système est exploité. |
| A.8.4 | Communication des incidents : des procédures pour communiquer les incidents liés au système d'IA aux utilisateurs, aux personnes concernées et aux autorités ; cela suppose des enregistrements solides. |
| A.9.4, A.10.3 | Utilisation responsable et fournisseurs : exigences relatives à l'utilisation responsable et aux fournisseurs, dont le respect doit être démontrable. |
| Chap. 9.1, 9.2 | Surveillance, mesure, analyse ; audit interne. L'auditeur a besoin d'enregistrements auxquels il peut se fier. |
Ce que Logsiegel y apporte aujourd'hui
- Journal d'événements pendant l'utilisation (A.6.2.8). L'adaptateur LiteLLM journalise chaque requête au modèle avec horodatage, modèle, nombre de jetons et empreintes ; changements de modèle, interventions humaines et anomalies sont des types d'événements distincts. Les attributs suivent les conventions OpenTelemetry GenAI.
- 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. Pour l'auditeur au sens du chap. 9.2, cela signifie : il vérifie l'enregistrement au lieu d'y croire. - Démontrer les écarts (A.6.2.6). Erreurs et valeurs aberrantes sont enregistrées comme
anomalyet font donc partie de la chaîne probante, et non d'une liste d'erreurs séparée et modifiable. - Communication des incidents (A.8.4).
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. - 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.
- 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. - 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.
Ce qui est en préparation prévu
- Taxonomie d'événements pour agents avec correspondance vers ISO/IEC 24970 (journalisation des événements d'IA, en cours d'élaboration) et prEN 18229-1, pour que les journaux parlent la langue des normes à venir.
- Proxy MCP pour les appels d'outils, témoin indépendant pour les points de contrôle.
Ce que Logsiegel ne fait pas
- Le système de management. Politique d'IA, rôles, appréciation des risques et des impacts (A.5), gestion des données (A.7), documentation du cycle de vie (A.6.2.2 à A.6.2.4) : travail propre.
- La surveillance comme activité. A.6.2.6 exige que quelqu'un regarde. Logsiegel fournit des enregistrements inaltérés, pas l'analyse.
- 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 l'exploitant 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 l'exploitant.
- 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 événements du cycle de vie
A.6.2.8 parle de phases du cycle de vie. Journalisez, en plus de l'utilisation, les changements de modèle et les déploiements comme événements propres : la phase devient alors lisible dans le journal.
logsiegel log ./trail --event model_change \
--attr gen_ai.request.model=gpt-5 --attr previous=gpt-4.1 --attr approved_by="ml-board"
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 : AI Act RGPD DORA NIS 2 ISO/IEC 27001 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.