Aperçu

Le Registre Sannvit est un journal d'audit à ajout seul et chaîné par empreintes pour l'activité des agents d'IA. Chaque appel LLM, invocation d'outil et consultation qu'effectue un agent est scellé dans une chaîne d'empreintes SHA-256 par organisation — vérifiable de façon indépendante par n'importe qui, pas seulement par le système qui l'a écrite. Il fonctionne entièrement au sein de votre propre infrastructure : autohébergé via Docker Compose ou Kubernetes, aucune donnée ne sort de vos murs.

Le problème qu'il résout

Les journaux d'application sont une affirmation, pas une preuve — un administrateur peut modifier une ligne, la conservation se mesure en jours, et rien ne distingue ce qu'une IA a affirmé de ce qui a été enregistré de façon indépendante. Un régulateur, un auditeur ou la partie adverse qui demande « qu'a fait votre IA, et sur quoi s'est-elle appuyée ? » a besoin de davantage : des enregistrements scellés que personne ne peut réécrire en silence, une conservation en années, et une chaîne de possession remontant de la décision jusqu'à ce sur quoi elle reposait.

Comment ça fonctionne

• Capturer — un SDK léger observe les actions de votre agent dans le processus, sans s'y interposer. Rien ne se place entre votre code et votre fournisseur de modèle, et le SDK ne peut pas mettre votre application à l'arrêt : la capture est un ajout synchrone et non bloquant dans un tampon, et la livraison vers l'API du registre se fait de façon asynchrone. Voir SDK.
• Sceller — le chaînage des empreintes se produit côté serveur, dans l'API du registre, pas dans le SDK — des écrivains concurrents ne peuvent pas connaître « l'enregistrement précédent », donc l'invariant d'écrivain unique vit dans une seule fonction de base de données. Chaque enregistrement se scelle sur celui qui précède, dans une chaîne par organisation.
• Vérifier — la chaîne est vérifiable de façon indépendante : recalculez l'empreinte de chaque enregistrement et parcourez les liens, en dehors du service en cours d'exécution, sans avoir à faire confiance à l'opérateur.
• Examiner — un tableau de bord reconstitue la chaîne de possession de toute décision, gère les alertes et exporte des dossiers de preuves pour un examinateur.

Propriétés de l'architecture

• Observateur, pas passerelle. Le SDK ne se place jamais dans le chemin de la requête — si le registre devenait injoignable, votre agent ne le remarquerait pas. Les échecs sont signalés à un callback on_error plutôt que de se propager.
• Scellement côté serveur. Les enregistrements se sérialisent en entrées canoniques RFC 8785, chaînées par empreintes SHA-256 (une paire record_hash / prev_hash par enregistrement). Le SDK se contente de signaler ce qui s'est passé ; le serveur calcule chaque empreinte.
• Ne perd jamais de données en silence. Si le tampon d'ingestion déborde, les événements écartés sont comptabilisés et scellés sous forme d'enregistrement lifecycle — le vide lui-même fait partie de la piste d'audit, au lieu d'être un trou silencieux.
• Autohébergé. Postgres classique, Keycloak pour l'authentification, et un stockage d'objets compatible S3 pour le contenu des charges utiles (pointeur + empreinte seulement, adressé par le contenu) — le tout fonctionnant dans votre propre VPC ou sur site, sans backend géré auquel il faille faire confiance.

Ce que contient la pile

Où aller ensuite

• Premiers pas — déployez la pile avec Docker Compose ou Kubernetes.
• SDK — instrumentez un agent pour commencer à sceller son activité dans le registre.