prEN 18229-1: AI-logging en claimcontrole

Je moet per logcategorie vastleggen hoe lang je AI-eventlogs bewaart, welke claims je controleert en wie daarover beslist — en dit koppelen aan EU AI Act en AVG in plaats van op een universele norm te wachten.

De aanleiding is een analyse van 29 september 2026 van AI-eventlogging en claimcontrole, die stelt dat de Europese ontwerpnorm prEN 18229-1 de structuur van AI-logging concretiseert, maar geen universele bewaartermijnen vastlegt en geen hallucinatiedetectie voorschrijft. Het voorbeeld is een FAQ-workflow waarin een model antwoorden genereert en je moet aantonen dat deze zijn geverifieerd. In onze beoordeling betekent dit dat je zelf moet bepalen welke logvelden je aan elkaar koppelt, hoe lang je ze bewaart en welke verificatiestappen je inbouwt — de norm geeft het raamwerk, maar de governance moet je invullen.

Welke logvelden moet je aan elkaar koppelen voor claimcontrole?

Een bruikbaar eventlog bewijst meer dan dat er een antwoord verscheen. De ontwerpnorm structureert logging als onderdeel van het AI trustworthiness framework, maar het loskoppelen van logvelden maakt reconstructie onmogelijk. Zonder claim- en besliscontext blijft een log een verzameling losse antwoorden zonder aantoonbare keten. Je moet vastleggen welk model welke vraag beantwoordde, welke gegevens het gebruikte, welke claims het maakte, wie die claims controleerde, wat die controle opleverde en welke actie daaruit volgde.

Deze velden vormen samen een governanceobject. Prestatie-metingen, modelbeslissingen, waarschuwingen en verificatie-uitkomsten moeten traceerbaar zijn naar elkaar. Alleen dan kun je later aantonen dat een gevoelige uitkomst niet alleen is gegenereerd, maar ook is gecontroleerd.

Hoe bepaal je de bewaartermijn per logcategorie?

De ontwerpnorm legt geen universele bewaartermijn vast, en het zou onjuist zijn die eruit af te leiden. De bewaartermijn per logcategorie volgt uit andere kaders: de EU AI Act bepaalt welke risicoclassificatie van toepassing is, de AVG bepaalt hoe lang je persoonsgegevens mag houden, en je eigen incidentrisico bepaalt hoe lang je bewijs van controle moet kunnen tonen.

De praktische keuze is dus geen enkel getal, maar een classificatie per categorie. Wie menselijke controle bij een hoogrisicobesluit wil kunnen aantonen, houdt de besliscontext langer beschikbaar. Wie alleen prestatiemetingen logt, kan die sneller verwijderen. Dit betekent dat je per workflow en per logcategorie een risicogebaseerde retentie moet kiezen:

• Logs van hoogrisicobeslissingen — minstens zolang als de AVG vereist voor het onderliggende geval, doorgaans langer.
• Logs van claimcontrole en verificatie — minstens zolang als nodig om menselijke controle aan te tonen bij geschillen.
• Logs van modelprestatie en kalibratie — korter, tenzij ze nodig zijn voor incidentonderzoek.
• Logs van persoonsgegevens in prompts en outputs — onderworpen aan AVG-retentieregels, onafhankelijk van andere categorieën.
• Logs van escalatie en handmatige interventie — minstens zolang als de onderliggende zaak actief is.
• Logs van modelversies en configuratie — zolang het model in productie staat, plus een periode voor forensische analyse.

Hoe controleer je claims op hallucinaties?

De academische literatuur toont aan dat detectie betrouwbaarder wordt wanneer je een antwoord opsplitst in atomische, verifieerbare claims en die apart toetst. Dit proces verloopt in vier stappen: je splitst het antwoord in claims, je zoekt onafhankelijk bewijs, je beoordeelt dat bewijs en je bepaalt waar precies de fout zit. Dit maakt het mogelijk niet alleen te weten dat een antwoord fout is, maar ook waar.

Een tweede waarschuwing uit onderzoek is dat standaard-modellen als detectoren in realistische situaties onvoldoende presteren. Prestaties op kunstmatige benchmarks gelden niet automatisch voor echte FAQ-interacties. Dit betekent dat je niet kunt vertrouwen op een model dat zijn eigen output beoordeelt — confirmation bias is een erkend probleem. Je moet de scheiding tussen genereren en controleren zelf organiseren, met onafhankelijke verificatiestappen.

Welke verificatiestappen moet je kunnen aantonen?

Een geverifieerde FAQ is geen eindpunt maar een versieerbaar governance-object. Je moet kunnen aantonen dat je deze stappen hebt uitgevoerd:

1. Splits het antwoord in verifieerbare claims — documenteer welke atomische stellingen het model deed.
2. Zoek onafhankelijk bewijs — controleer bronnen zonder het oorspronkelijke antwoord als uitgangspunt.
3. Beoordeel het bewijs — leg vast wie de beoordeling deed en op welke gronden.
4. Bepaal de hallucinatielocatie — als er fouten zijn, documenteer waar en waarom.
5. Log de verificatieuitkomst — koppel dit terug aan de claim, het bewijs en de beslissing.
6. Controleer onderliggende verwijzingen — volg citaten terug naar hun bron.

Wat kan tooling doen en wat blijft jouw verantwoordelijkheid?

Eventlogging-tooling kan de structuur afdwingen en de velden vastleggen. Verificatietools kunnen claims opsplitsen en bronnen zoeken. Maar de scheiding tussen genereren en controleren, de keuze welke claims risicovol zijn, de beoordeling van bewijs en de beslissing wat je doet met een hallucinatie — dat blijft jouw professionele oordeel. Tooling kan je helpen aantonen dat je dit oordeel hebt geveld en vastgelegd; het kan je oordeel niet vervangen.