Comment l’Event Sourcing préserve-t-il une piste d’audit des décisions des agents d’IA ?
L’event sourcing préserve une piste d’audit des agents IA en enregistrant chaque décision acceptée et chaque changement d’état sous forme d’événement ordonné, au lieu d’écraser un état courant mutable unique.
Sur un serveur domestique, cela rend les automatisations en plusieurs étapes reconstituables : un opérateur peut retracer la proposition, l’approbation, l’appel d’outil, l’échec, la nouvelle tentative, la compensation et l’état final une fois le flux de travail terminé.
L’event sourcing stocke les changements d’état comme enregistrement principal
L’event sourcing enregistre chaque changement d’état accepté comme un événement, au lieu de considérer la dernière ligne mutable comme l’unique source de vérité. L’état actuel est dérivé de l’historique ordonné.
Martin Fowler définit l’event sourcing comme le stockage de chaque changement de l’état d’une application sous forme de séquence d’événements. L’historique conserve la manière dont le système est parvenu à un état donné. Martin Fowler définit l’event sourcing en s’appuyant sur le stockage des changements d’état sous forme de séquence d’événements, ce qui illustre l’idée d’enregistrement principal utilisée dans l’article de Martin Fowler sur l’event sourcing.
Pour un agent IA domestique, ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed et CompensationCompleted peuvent rester des faits distincts plutôt que d’être regroupés dans un seul champ d’état.
Chaque décision de l’agent devient un fait ordonné dans le temps
Un événement doit décrire quelque chose qui s’est déjà produit et fournir suffisamment de contexte pour être interprété ultérieurement : identifiant du flux de travail, outil, hachage des paramètres, résultat de la politique, issue de la décision et horodatages, le cas échéant.
Fowler indique qu’avec l’event sourcing, le magasin d’événements devient la principale source de vérité et que l’état peut être reconstruit par rejeu. Cette séquence ordonnée crée un chemin d’audit causal. Microsoft Azure décrit un magasin d’événements en ajout uniquement, dans lequel les événements représentent les changements de l’état de l’application, ce qui permet de prendre en charge les faits décisionnels ordonnés dans le temps du modèle Event Sourcing d’Azure.
L’objet d’audit utile est l’artefact décisionnel observable, et non le raisonnement privé dissimulé : quelle action a été proposée, quelle politique l’a évaluée, quel résultat a été renvoyé et quel effet secondaire s’est réellement produit.
Les projections transforment le journal d’événements en vues actuelles
Rejouer l’intégralité de l’historique pour chaque écran ou demande d’agent serait inefficace.
Les systèmes utilisant l’event sourcing construisent des projections telles que l’état actuel du flux de travail, les approbations en attente ou les échecs récents.
L’event sourcing peut reconstruire l’état actuel de l’application à partir des événements enregistrés. Une projection peut donc être reconstruite si sa logique ou sa base de données évolue. Les recommandations d’AWS décrivent la dérivation de l’état actuel à partir d’événements persistants, illustrant la manière dont les projections peuvent créer des vues de lecture sans remplacer l’historique sous-jacent dans les recommandations AWS sur l’event sourcing.
Sur un petit serveur, les instantanés peuvent réduire le temps de rejeu tandis que les événements restent la référence faisant autorité. L’instantané est un raccourci destiné aux performances ; la séquence d’événements constitue l’historique.
Les identifiants de corrélation relient les opérations en plusieurs étapes en un seul historique décisionnel
Une requête peut déclencher une récupération, une planification, une approbation, plusieurs appels d’outils, des nouvelles tentatives et une compensation.
Un identifiant de corrélation regroupe ces événements en une opération cohérente.
Cela diffère du simple fait de stocker les journaux ailleurs. L’isolation externe des journaux d’audit de ZimaSpace explique comment les éléments de preuve peuvent survivre à la compromission d’une application ; l’event sourcing explique comment l’état du flux de travail devient lui-même un historique ordonné. Kurrent met l’accent sur les flux d’événements ordonnés et les identifiants, ce qui permet de corréler les étapes associées au sein d’un historique décisionnel traçable unique dans les concepts d’event sourcing de Kurrent.
Les deux approches peuvent être combinées : les enregistrements d’événements pilotent le rejeu opérationnel, tandis que des copies orientées ajout sont exportées vers une limite de journalisation distincte afin de renforcer la préservation des éléments de preuve.
Les corrections ajoutent de nouveaux événements au lieu de réécrire l’historique
Si une décision d’agent s’avère ultérieurement erronée, une conception fondée sur l’event sourcing enregistre un événement compensatoire ou correctif au lieu de modifier l’événement original pour le faire disparaître.
La discussion de Fowler sur la bitemporalité illustre l’idée plus large selon laquelle l’historique des enregistrements peut rester en ajout uniquement, même lorsque de nouvelles informations corrigent des hypothèses antérieures. Marten conserve les événements dans un historique en ajout uniquement et reconstruit l’état de l’agrégat à partir de ceux-ci, illustrant pourquoi les corrections peuvent être ajoutées plutôt que de réécrire silencieusement les faits antérieurs dans la documentation du magasin d’événements Marten.
Cela est utile lorsque les politiques ou les prompts changent. Un opérateur peut voir qu’une action a été acceptée selon une version donnée de la politique, puis annulée ultérieurement, au lieu de ne voir que l’état final corrigé.
L’event sourcing ne rend pas automatiquement les éléments de preuve inviolables
La fiabilité d’un historique d’événements dépend uniquement des contrôles appliqués à la création des événements, au stockage, aux accès, aux horloges et à la suppression.
Un processus autorisé à réécrire le magasin peut toujours détruire son propre historique.
Fowler souligne les avantages en matière d’audit et de requêtes historiques lorsque le journal d’événements reste le magasin d’informations faisant autorité. La durabilité et les contrôles d’ajout restent des préoccupations opérationnelles distinctes. Des recherches récentes appliquent des historiques d’événements structurés en ajout uniquement à l’activité d’agents autonomes, tout en précisant qu’une logique applicative en ajout uniquement n’est pas équivalente à un stockage inviolable ; voir l’event sourcing pour les agents autonomes.
La conception d’agents privilégiant la lecture seule de ZimaSpace réduit les actions dangereuses avant qu’elles ne se produisent ; l’event sourcing préserve les décisions et les actions qui ont effectivement eu lieu.
Produits recommandés
Centre Tech & IA
Plus à lire
Une passerelle d’IA locale peut-elle imposer une limite stricte de contexte avant l’allocation du GPU ?
Une explication axée sur le mécanisme du hard context gate, de ses compromis en matière de ressources partagées, de trois FAQ sur la duplication...
Un serveur d’IA domestique peut-il mapper en mémoire les poids d’un modèle depuis un NAS distant via 2.5GbE ?
Une explication axée sur les mécanismes du mappage de la mémoire d’un modèle NAS distant, ses compromis en matière de ressources partagées, trois questions...
Plusieurs conteneurs peuvent-ils partager un seul GPU intégré sans fuite de charges de travail ?
Une explication de l’isolation des conteneurs d’iGPU axée sur les mécanismes, de ses compromis liés aux ressources partagées, de trois FAQ sur la diffusion...
