IETF-conceptnorm voor AI-audittrails

U moet nu vastleggen welke uitvoeringsfeiten, bewijsrelaties en redeneerprovenance u afzonderlijk bewaart, omdat een enkel audittrailformaat niet kan aantonen waarom een autonome agent handelde.

Een analyse van 5 oktober 2026 van het hash-gekoppelde audittrailformaat voor autonome AI-agents stelt voor dat registratie vóór een actie plaatsvindt en dat een onafhankelijke recorder buiten het agentproces werkt. Een werkversie van de Internet Engineering Task Force beschrijft hoe vast te leggen welke agent, onder welke versie en met welke autorisatie, een actie uitvoerde. In onze beoordeling betekent dit dat u niet langer mag aannemen dat één systeem alle bewijseisen dekt; u moet per risicovolle werkstroom kiezen welke reconstructieniveaus u bewaart en hoe u ze organisatorisch scheidt.

Wat bewijst een audittrail niet?

Een record dat na een actie ontstaat, toont niet aan dat er vóór die actie een autorisatie- of beleidscontrole bestond. Dit onderscheid tussen pre-execution en post-execution records is cruciaal: een vastlegging die vóór de handeling ontstaat, laat zien dat de controle kon ingrijpen toen het nog mogelijk was, niet dat ze achteraf is toegevoegd.

Hash chaining detecteert of records achteraf zijn gewijzigd, maar bewijst niet dat de recorder alle gebeurtenissen heeft gezien. Een onvolledige keten die intern klopt, oogt betrouwbaar terwijl dat niet het geval is. Een sessie technisch naspelen zonder vast te leggen waarom de agent een bepaalde actie koos, laat een gat achter dat apart moet worden vastgelegd of het bestaat niet.

Welke drie reconstructieniveaus moet u onderscheiden?

Drie niveaus vullen elkaar aan en volgen niet uit één logtype:

• Uitvoeringsfeiten — welke agent, versie, autorisatie en data-access een actie voorafging.
• Bewijsrelaties — welke externe tool-responses en menselijke escalaties de agent ontving en hoe die de volgende stap bepaalden.
• Redeneerprovenance — intent, planwijziging en delegatieketen die verklaarden waarom de agent handelde.

Zolang u deze drie niet zelf organiseert, blijven ze onaantoonbaar. Een logbestand dat de agent over zichzelf bijhoudt, kan zijn bewijswaarde verliezen zodra die agent zelf faalt of wordt gemanipuleerd.

Welke concrete controles moet u kunnen aantonen?

1. Onafhankelijke recorder buiten het agentproces — vastlegging fysiek en organisatorisch gescheiden van het systeem dat ze registreert.
2. Pre-action autorisatierecord met agentversie en modelidentiteit — registratie vóór de actie als leveringseis in contracten met leveranciers.
3. Vastlegging van intent, planwijziging en delegatieketen — redeneerprovenance apart opgeslagen zodat een bestuurder kan uitleggen waarom de agent handelde.
4. Vastlegging van data- en tooltoegang, menselijke escalaties en onderbrekingen — alle externe inputs die de uitvoering bepaalden.
5. Periodieke integriteit- en volledigheidscontrole van de keten — geen eenmalige acceptatietest, maar vaste controles op wijziging en volledigheid.

Wat kan tooling dragen en wat niet?

Een werkbaar minimum om een autonome AI-handeling later te verantwoorden omvat een onafhankelijke recorder, versie- en modelidentiteit, een autorisatierecord vóór de actie, gebruikte data- en tooltoegang, bewijsrelaties, menselijke escalaties, onderbrekingen en een controle op ketellintegriteit. Zolang het IETF-document een werkversie is, is het een richting, geen keurmerk. Wie het nu overneemt, doet dat als eigen governance-keuze, niet als naleving van een vastgestelde standaard. Tooling kan vastlegging automatiseren en ketellintegriteit controleren. Welke reconstructieniveaus u per werkstroom bewaart en hoe u ze organisatorisch scheidt, blijft uw professionele oordeel.