Un auditeur pose deux questions : que s'est-il passé, et peut-on prouver que personne n'a modifié le registre ensuite ? Navin Enterprise AI répond aux deux par une télémétrie unifiée. Chaque appel qui passe par une gateway porte un traceparent W3C, émet des spans OpenTelemetry, produit un Usage Event et écrit un événement d'audit chaîné par hash au précédent.
Une chaîne de hash par tenant
Chaque événement d'audit est lié par son hash à l'événement qui le précède dans la même chaîne : modifier, insérer ou supprimer un événement casse tous les maillons suivants. La chaîne est stockée dans PostgreSQL sous RLS et peut être vérifiée à tout moment par le service de vérification de l'API d'audit. Les événements de sécurité sont écrits dans la chaîne d'audit du tenant, dans leur propre transaction.
Le scellement suit une règle stricte : le sceau n'est jamais antérieur aux événements qu'il couvre. Si l'horloge murale recule entre l'ingestion et le scellement, après une correction NTP par exemple, le sceau prend la date de la dernière ingestion scellée, et la vérification garde le contrôle strict qui exige que chaque événement ait été ingéré avant son sceau.
Des preuves que l'on ne peut pas réécrire
Les preuves d'audit sont archivées dans un stockage objet avec Object Lock en mode WORM : une fois archivées, elles ne peuvent être ni modifiées ni supprimées avant la fin de leur rétention. Dans une installation pilotée par le Navin Manager, SeaweedFS est le stockage objet qui accueille cette archive d'audit WORM, à côté des documents, des médias, des exports et des sauvegardes.
- Traceparent W3C sur chaque appel, propagé entre gateways et runtimes.
- Spans OpenTelemetry collectés par l'OTel Collector, traces IA dans Opik.
- Usage Events pour les tokens, les secondes et le temps GPU, base du FinOps.
- Événements OpenLineage pour le lignage des données, par exemple à chaque requête RAG.
Rejouer une exécution
Les runs d'agent écrivent un checkpoint à chaque étape. Le rejeu d'exécution (brique C15) s'appuie sur eux pour reconstituer ce qu'un agent a fait, étape par étape, et le contrat d'exécution du run, disponible par GET /v1/runs/{id}, décrit son déroulement. La corrélation d'audit (brique G14) rapproche ensuite les enregistrements des différents services.