Pistes d'audit cryptographiques : des preuves qu'un régulateur peut inspecter

Demandez à une équipe comment elle expliquera après coup la décision d'un agent, et la réponse habituelle est « on journalise tout ». Les journaux ressemblent à de la responsabilité. Il y a un enregistrement horodaté, il part dans un stockage central, et quand quelqu'un demande ce qui s'est passé vous allez le lire. Pour beaucoup de systèmes, c'est réellement suffisant.

Sauf qu'un journal ordinaire ne survit pas au seul moment pour lequel il existe : un régulateur, un auditeur ou un tribunal qui demande « prouvez que cet enregistrement n'a pas été altéré après la décision, et prouvez qu'il ne manque rien ». Un journal standard ne peut pas répondre. Il est modifiable, donc les entrées peuvent être changées. Il est souvent écrit après l'action, donc il peut prendre du retard ou perdre des entrées. Et il n'a aucune structure interne qui révélerait une altération, donc une entrée supprimée ou modifiée ne laisse pas de trace. Quand l'enjeu est une action d'exécution, « faites confiance à nos journaux » n'est pas une preuve. C'est une affirmation, et tout l'exercice consiste précisément à mettre votre affirmation en question.

Le recadrage consiste à cesser de penser journalisation et à commencer à penser preuve : un enregistrement construit pour que sa propre intégrité soit prouvable, produit de façon à rendre « nous l'avons modifié après » ou « une entrée a disparu » détectable plutôt que niable. C'est une cible d'ingénierie différente, et elle a une forme bien comprise.

Append-only et chaîné par hachage : l'altération devient visible

Deux propriétés transforment un journal en preuve, et elles fonctionnent ensemble.

La première est l'append-only. Les enregistrements peuvent être ajoutés mais jamais modifiés ni supprimés sur place. Il n'y a pas d'opération de mise à jour ni de suppression, seulement l'ajout. Cela seul supprime la façon la plus courante dont un enregistrement devient indigne de confiance, la modification discrète après coup, parce que l'opération qui le ferait n'existe pas.

La seconde est le chaînage par hachage, et c'est ce qui rend l'append-only prouvable plutôt que simplement promis. Chaque enregistrement inclut un hachage cryptographique de l'enregistrement précédent, de sorte que les entrées forment une chaîne où chaque maillon s'engage sur son prédécesseur. Organisez ces hachages en structure de Merkle, un arbre où chaque nœud est le hachage de ses enfants, et vous obtenez une racine unique qui résume tout l'historique. Changez un champ dans un enregistrement, et son hachage change, ce qui change tous les hachages au-dessus, ce qui change la racine. L'altération ne peut pas se cacher. Quiconque détient l'ancienne racine peut prouver, mathématiquement, que l'historique a été modifié, et le prouver sans vous faire confiance du tout.

C'est le passage de « croyez notre journal » à « vérifiez nos preuves ». L'intégrité de l'enregistrement ne repose plus sur votre parole ni sur vos contrôles d'accès. Elle repose sur une cryptographie qu'un tiers peut vérifier de façon indépendante.

Stockage WORM : le support applique ce que le logiciel promet

L'append-only logiciel est une discipline forte, mais un opérateur suffisamment privilégié, ou un attaquant suffisamment déterminé, peut parfois passer en dessous. Pour des preuves qui doivent tenir sous un examen adverse, le support de stockage lui-même devrait appliquer la propriété.

Le stockage WORM, write-once-read-many, fait exactement cela. Une fois un enregistrement validé, la couche de stockage empêche physiquement son écrasement ou sa suppression pendant une période de rétention définie, quels que soient les privilèges de l'appelant. La garantie ne dépend plus seulement du bon comportement de l'application. Elle est appliquée sous l'application, là où même un administrateur ne peut pas réécrire l'histoire en silence. Combinez WORM et chaînage par hachage et vous avez ceinture et bretelles : le support refuse de laisser l'enregistrement changer, et la cryptographie le révélerait si le support venait à céder.

Écrit avant que la décision ne s'engage : pas de preuve, pas de décision

Voici le choix de conception qui sépare la vraie preuve d'une reconstitution, et c'est celui que la plupart des équipes prennent à l'envers.

La preuve doit être écrite avant que la décision ne prenne effet, pas après. Cela inverse l'ordre habituel, où un système agit puis, en effet de bord, enregistre ce qu'il a fait. Dans cet ordre habituel, l'enregistrement est une arrière-pensée, et les arrière-pensées peuvent échouer : l'action réussit, l'appel de journalisation lève une exception, et vous voilà avec une décision sans preuve derrière. Dans un processus réglementé, c'est le pire des deux mondes : une conséquence dans le monde et aucun enregistrement du pourquoi.

La séquence est donc imposée dans l'autre sens. Le système assemble l'enregistrement de décision et le valide d'abord dans le stockage de preuves. Ce n'est qu'une fois cette écriture réussie que la décision est autorisée à prendre effet. Si le stockage de preuves est indisponible, ou que l'écriture échoue, la décision ne se poursuit pas. Pas de stockage de preuves, pas de décision. Le système échoue en fermé : quand il ne peut pas prouver ce qu'il s'apprête à faire, il refuse de le faire. Cette seule règle garantit une propriété à laquelle les régulateurs tiennent profondément. Dans cette architecture, il n'existe pas d'action à conséquence sans enregistrement inviolable correspondant, parce que l'enregistrement est une condition préalable de l'action, pas un sous-produit.

Ce qu'un enregistrement de décision doit contenir

L'intégrité ne vaut rien si l'enregistrement est vide de sens. Un journal inviolable de « décision prise : accordé » prouve seulement que vous ne pouvez pas altérer un enregistrement qui ne dit rien d'utile. Le contenu compte donc autant que la cryptographie. Un enregistrement de décision apte à l'inspection devrait capter, au minimum :

• La décision et son verdict. Ce qui a été décidé, et sous quel résultat explicite (autoriser, autoriser sous conditions, refuser, ou exiger une personne).
• Les entrées. Les documents, données et contexte précis sur lesquels la décision a été prise, référencés pour que la base de preuves exacte puisse être reconstituée.
• L'autorité. Quelle identité d'agent a agi, à quel niveau d'autonomie, et sous quelle version de politique.
• L'évaluation de politique. Quelles règles ont été appliquées et ce que chacune a renvoyé, pour que le « pourquoi » soit explicite plutôt que déduit.
• Le raisonnement et l'ancrage. La justification de l'agent et les sources citées derrière chaque affirmation matérielle.
• La personne, s'il y en avait une. Si la décision exigeait une personne, qui elle était et ce qu'elle a approuvé, fermant la boucle de responsabilité.
• Le temps et la position dans la chaîne. Quand cela s'est produit et où cela se situe dans la chaîne de hachage, pour pouvoir le localiser et le vérifier.

Un enregistrement avec ces champs répond à la question qu'une inspection pose vraiment : non pas seulement « qu'a décidé le système ? » mais « sur quelle base, sous quelle autorité, contre quelle politique, et pouvez-vous prouver que ce récit est intact ? ».

L'article 12 de l'EU AI Act, et pourquoi ce n'est pas optionnel

Cette architecture n'est pas du plaqué or. Pour les systèmes d'IA à haut risque, elle devient la base que la loi attend.

L'article 12 de l'EU AI Act exige que les systèmes d'IA à haut risque tiennent des registres, en journalisant automatiquement les événements sur la durée de vie du système à un degré adapté à sa finalité, pour que le fonctionnement du système soit traçable et ses risques surveillés après coup. Confrontez cette exigence à un journal ordinaire, modifiable et au mieux-effort, et l'écart saute aux yeux. « Traçable » et « tenue de registres appropriée » ne sont pas satisfaits par un stockage dont vous ne pouvez démontrer ni l'intégrité ni la complétude. Des preuves append-only, chaînées par hachage, adossées à du WORM et écrites avant l'engagement de la décision ne sont pas une interprétation plus stricte que nécessaire de cet article. C'est une lecture directe de ce que « des registres sur lesquels un superviseur peut s'appuyer » doit vouloir dire quand le système est probabiliste et que les décisions pèsent.

La question à apporter à votre prochaine revue n'est donc pas « journalisons-nous nos agents ? ». Tout le monde journalise quelque chose. C'est : pouvons-nous remettre à un régulateur l'enregistrement de n'importe quelle décision d'agent et prouver, sans lui demander de nous croire, qu'il est complet et n'a pas été altéré après coup ? Si la réponse honnête est non, vous avez des journaux. Vous n'avez pas encore de preuves, et la preuve est ce à quoi sert une inspection.

Si vous voulez voir à quoi ressemble un enregistrement de décision inspectable sur l'un de vos processus réels, prenez rendez-vous.