Hoe bewaart Event Sourcing een audittrail voor beslissingen van AI-agents?

Event sourcing bewaart een audittrail van een AI-agent door elke geaccepteerde beslissing en statuswijziging als een geordende gebeurtenis vast te leggen, in plaats van één veranderlijke huidige status te overschrijven.

Op een homeserver maakt dat meerstapsautomatisering reconstrueerbaar: een beheerder kan het voorstel, de goedkeuring, de toolaanroep, de fout, de nieuwe poging, de compensatie en de uiteindelijke status traceren nadat de workflow is voltooid.

Event sourcing slaat statuswijzigingen op als primaire registratie

Event sourcing registreert elke geaccepteerde statuswijziging als een gebeurtenis, in plaats van de meest recente veranderlijke rij als enige bron van waarheid te beschouwen. De huidige status wordt afgeleid van de geordende geschiedenis.

Martin Fowler definieert event sourcing als het opslaan van elke wijziging in de applicatiestatus als een reeks gebeurtenissen. De geschiedenis laat zien hoe het systeem een bepaalde status heeft bereikt. Martin Fowler definieert event sourcing vanuit het opslaan van statuswijzigingen als een reeks gebeurtenissen, waarmee het idee van de primaire registratie wordt vastgelegd dat wordt gebruikt in Martin Fowler over event sourcing.

Voor een thuis-AI-agent kunnen ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed en CompensationCompleted afzonderlijke feiten blijven, in plaats van te worden samengevoegd tot één statusveld.

Elke beslissing van een agent wordt een tijdgeordend feit

Een gebeurtenis moet iets beschrijven dat al is gebeurd en voldoende context bevatten om het later te kunnen interpreteren: workflow-ID, tool, hash van de parameters, beleidsresultaat, uitkomst van de beslissing en waar relevant tijdstempels.

Fowler merkt op dat bij event sourcing de event store de belangrijkste bron van waarheid wordt en dat de status kan worden herbouwd door events opnieuw af te spelen. Die geordende reeks creëert een causaal auditpad. Microsoft Azure beschrijft een event store waaraan alleen gebeurtenissen worden toegevoegd; die gebeurtenissen vertegenwoordigen wijzigingen in de applicatiestatus en ondersteunen de tijdgeordende beslisfeiten in het Azure Event Sourcing-patroon.

Het bruikbare auditobject is het waarneembare beslisartefact, niet de verborgen privéredenering: welke actie werd voorgesteld, welk beleid beoordeelde die, welk resultaat werd teruggegeven en welke bijwerking vond daadwerkelijk plaats.

Projecties zetten het eventlog om in actuele weergaven

De volledige geschiedenis voor elk scherm of elk agentverzoek opnieuw afspelen zou inefficiënt zijn.

Systemen met event sourcing bouwen projecties, zoals de huidige workflowstatus, openstaande goedkeuringen of recente fouten.

Event sourcing kan de huidige applicatiestatus reconstrueren uit geregistreerde gebeurtenissen. Een projectie kan daarom opnieuw worden opgebouwd als de logica of database ervan verandert. De richtlijnen van AWS beschrijven hoe de huidige status wordt afgeleid uit bewaarde gebeurtenissen. Dit laat zien hoe projecties leesweergaven kunnen opbouwen zonder de onderliggende geschiedenis te vervangen in de AWS-richtlijnen voor event sourcing.

Op een kleine server kunnen snapshots de afspeeltijd verkorten terwijl de gebeurtenissen gezaghebbend blijven. De snapshot is een prestatie-optimalisatie; de gebeurtenissenreeks is de geschiedenis.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Correlatie-ID's verbinden werk in meerdere stappen tot één beslissingsgeschiedenis

Eén verzoek kan leiden tot ophalen, plannen, goedkeuring, meerdere toolaanroepen, nieuwe pogingen en compensatie.

Een correlatie-ID groepeert die gebeurtenissen tot één samenhangende bewerking.

Dat verschilt van het simpelweg elders opslaan van logs. De isolatie van externe auditlogs van ZimaSpace legt uit hoe bewijsmateriaal behouden blijft bij een gecompromitteerde app; event sourcing legt uit hoe de workflowstatus zelf een geordende geschiedenis wordt. Kurrent benadrukt geordende eventstreams en identificatiegegevens, wat het correleren van gerelateerde stappen tot één traceerbare beslissingsgeschiedenis ondersteunt in de event-sourcingconcepten van Kurrent.

Beide kunnen worden gecombineerd: eventrecords sturen operationeel opnieuw afspelen aan, terwijl kopieën waaraan alleen wordt toegevoegd naar een afzonderlijke logginggrens worden geëxporteerd voor een betere bewaring van bewijsmateriaal.

Correcties voegen nieuwe gebeurtenissen toe in plaats van de geschiedenis te herschrijven

Als later blijkt dat een beslissing van een agent onjuist was, registreert een ontwerp met event sourcing een compenserende of corrigerende gebeurtenis in plaats van de oorspronkelijke gebeurtenis uit het bestaan te wissen.

Fowlers bespreking van bitemporaliteit illustreert het bredere idee dat de geschiedenis van registraties alleen toevoegend kan blijven, zelfs wanneer latere kennis eerdere aannames corrigeert. Marten bewaart gebeurtenissen als een geschiedenis waaraan alleen wordt toegevoegd en bouwt de aggregaatstatus daaruit opnieuw op. Dat illustreert waarom correcties kunnen worden toegevoegd in plaats van eerdere feiten stilzwijgend te herschrijven in de documentatie van Marten over event stores.

Dit is nuttig wanneer beleid of prompts veranderen. Een beheerder kan zien dat een actie onder een bepaalde beleidsversie werd geaccepteerd en later is teruggedraaid, in plaats van alleen de herstelde eindstatus te zien.

Event sourcing maakt bewijsmateriaal niet automatisch fraudebestendig

De betrouwbaarheid van een gebeurtenissengeschiedenis hangt af van de maatregelen rond het aanmaken, opslaan en benaderen van gebeurtenissen, evenals rond klokken en verwijdering.

Een proces dat de store mag herschrijven, kan zijn eigen geschiedenis nog steeds vernietigen.

Fowler benadrukt de voordelen voor audits en historische zoekopdrachten wanneer het eventlog de gezaghebbende informatiestore blijft. Duurzaamheid en toegangscontroles voor toevoegingen blijven afzonderlijke operationele aandachtspunten. Recent onderzoek past gestructureerde gebeurtenissengeschiedenissen waaraan alleen wordt toegevoegd toe op activiteiten van autonome agents, maar maakt ook duidelijk dat applicatielogica met alleen toevoegingen niet hetzelfde is als fraudebestendige opslag; zie event sourcing voor autonome agents.

Het read-only-first-agentontwerp van ZimaSpace beperkt gevaarlijke acties voordat ze plaatsvinden; event sourcing bewaart de beslissingen en acties die daadwerkelijk hebben plaatsgevonden.