Waarom per-actie checks niet volstaan voor AI-agenten: de verschuiving naar trajectorie-borging

Je hebt een AI-agent die zelfstandig taken uitvoert. Een formulier invullen, een database query uitvoeren, een e-mail versturen. Je controleert elke actie apart. Dat lijkt veilig. Nee. De echte veiligheid zit in het hele traject. Wat als onschuldige acties samen een beleidsschending opleveren?

Een nieuw paper uit arXiv pakt dit aan: Securing Agentic AI: From Per-Action Checks to Trajectory Assurance[^1]. Het introduceert een framework dat agent-gedrag continu valideert tegen organisatiebeleid, reguliere eisen en technische invarianten. Dit includes cross-organisatorische taakdelegatie. Dit raakt direct aan de AI Act, met name Art. 14 (human oversight) en Art. 15 (robustness). Voor de Nederlandse publieke sector, overheid, zorg, financieel, is dit geen academische oefening. Het is een operationele noodzaak.

Het probleem met per-actie checks

Stel: een LLM-agent mag alleen documenten ophalen uit een specifieke sharepoint-site. Per-actie check: de query is gericht op die site, dus oké. Maar de agent combineert de output met een andere query, en stuurt het resultaat naar een externe partij. Geen van de losse acties overtreedt een regel. Het traject wel. Informatie wordt ongeautoriseerd gedeeld. Per-actie checks missen context. Ze kijken naar een momentopname. Niet naar de keten. In de praktijk van de overheid, denk aan een UWV- of Belastingdienst-agent die meerdere systemen raadpleegt, is dat een recept voor compliance-incidenten.

Wat het paper voorstelt: trajectory-level assurance

Het framework uit het paper definieert een trajectorie als de volledige reeks acties, inclusief interne toestanden, context en externe effecten. De borging werkt op drie niveaus.

1. Organisatiebeleid, bijvoorbeeld: geen persoonsgegevens naar niet-EU servers.
2. Reguliere eisen, AVG, BIO2, NIS2, AI Act.
3. Technische invarianten, zoals geen privilege-escalatie of geen schrijven naar read-only buckets.

De validatie gebeurt continu, niet alleen bij elke actie. Het framework gebruikt een monitor die het hele traject logt en toetst aan een formeel beleidsmodel. Als een traject een regel overtreedt, wordt de agent gepauzeerd of teruggerold. Wat ik interessant vind: het paper ondersteunt ook cross-organisatorische delegatie. Stel dat een agent van gemeente A een taak uitbesteedt aan een agent van gemeente B. Het framework kan het gecombineerde traject valideren. Dit is nodig voor ketensamenwerking in de publieke sector.

Relevantie voor de AI Act: Art. 14 en 15

De AI Act eist in Art. 14 dat high-risk AI-systemen voorzien zijn van human oversight. Per-actie checks geven een operator een momentopname, maar geen inzicht in het traject. Trajectory-level assurance biedt wat Art. 14 vraagt. Een operator kijkt het gedrag terug. Inclusief afwijkingen van het beleid. Art. 15 (robustness) vereist dat systemen bestand zijn tegen fouten en manipulatie. Een per-actie check kan een prompt-injectie missen die pas later effect heeft. Een traject-monitor ziet het patroon. Een onschuldige query gevolgd door een verdachte output. Voor Nederlandse overheidsorganisaties die vallen onder BIO2 en NIS2 is dit direct toepasbaar. BIO2 eist logging en monitoring van toegang. NIS2 eist incidentdetectie. Trajectory-level assurance levert beide in één.

Praktische implicaties: wat moet je doen?

Je kunt niet zomaar een framework uit een paper implementeren. Maar de principes zijn concreet.

• Log niet alleen acties, maar ook context. Denk aan: input, output, interne redenering (indien beschikbaar), tijdstempel, bron- en doelsysteem.
• Definieer beleid als formele regels. Gebruik bijvoorbeeld OPA (Open Policy Agent) of Rego om regels te schrijven die over trajecten kunnen redeneren.
• Implementeer een monitor die per traject valideert. Dit kan een aparte service zijn die elke agent-actie streamt en toetst.
• Test de monitor met realistische scenario's.