Point-in-time compliance is dood: waarom AI-systemen continue assurance vereisen

Synthese-analyse van arXiv:2609.35266 (Lupo et al., 2026) en arXiv:2609.35316 (Pan et al., 2026).

---

1. Het probleem: de audit veroudert voordat het rapport is afgedrukt

Traditionele security-assurance werkt op basis van een impliciete aanname: een control die vandaag correct werkt, werkt morgen ook correct. Deze aanname houdt stand voor deterministische systemen, statische analyse-tools, handtekening-gebaseerde detectie, rule-based firewalls. Ze falen voor AI-gedreven systemen, waar het bewijs zelf verandert zonder dat de operator dit merkt.

Twee onafhankelijke studies, gepubliceerd op dezelfde dag (28 september 2026), beschrijven hetzelfde fenomeen vanuit verschillende hoeken:

• Lupo et al. (2609.35266) tonen dat LLM-based repository auditors in CI/CD-pijplijnen niet-deterministisch zijn, dezelfde scan produceert verschillende bevindingen per run. Na een model-update (achter de schermen, zonder melding) zijn eerdere "pass"-uitslagen mogelijk niet langer geldig.
• Pan et al. (2609.35316) stellen dat klassieke reliability engineering (FMEA, accelerated testing, field monitoring) weliswaar bruikbaar is voor AI-systemen, maar dat zelf-evoluerende systemen nieuwe meetmethoden vereisen die de reasoning-processen zelf monitoren.

De gemene deler: point-in-time evaluatie is onvoldoende voor systemen waar het bewijs zelf verandert.

2. Paper 1: Policy-Evidence-Execution Separation

Lupo et al. introduceren het Policy-Evidence-Execution Separation Pattern, geïmplementeerd door de Trustworthy AI Posture (TAIP) Assurance Engine en geopereerd als Continuous Control Posture Assurance (CCPA).

De drie gescheiden lagen

1. Policy, definieert de condities waarbij een control mag worden vertrouwd en de consequenties van elke posture-state.
2. Evidence, registreert observaties, provenance en configuratie.
3. Execution, past stabiele assurance-semantiek toe.

Dit patroon representeert een assurance-claim als een versioned Posture Tree, waarbij bladeren toegelaten bewijs binden en interne knooppunten resultaten aggregeren via een uniform Composite interface. Modellen, operationele contexten en policy-profielen kunnen veranderen zonder dat de assurance-engine zelf moet worden aangepast.

Empirische resultaten

Evaluatie met 80 RepoAudit-executies over twee OpenAI-modelconfiguraties (gpt-4o-mini en gpt-4.1):

Metric	Resultaat
Policy-to-posture latency	1,1 ms (maximum)
1.000 contexts, full recomputation	1,62 s (maximum)
Decision Gateway budget	5 s (predeclared)

Het systeem blijft binnen het beslisbudget van een software-delivery gate, zelfs bij 1.000 onafhankelijke assurance-contexten.

3. Paper 2: Reliability Engineering voor AI-systemen

Pan et al. herschrijven reliability engineering voor het AI-tijdperk. Ze onderscheiden vier niveaus van falen:

1. Component-falen, individuele subsystemen (encoder, classifier, generator).
2. Operational-loop-falen, interactie tussen perceptie, besluitvorming en actuatie.
3. Agentic-conduct-falen, gedrag dat niet direct voortvloeit uit een component maar uit emergente interactie (tool use, planning, multi-agent handoffs).
4. Network/governance-falen, collectief gedrag van meerdere systemen onder gedeelde governance.

Het framework integreert etabliërde methoden:

• FMEA (Failure Mode and Effects Analysis) voor risico-identificatie.
• Accelerated testing om falen te versnellen in gecontroleerde omgevingen.
• Field monitoring en FRACAS (Failure Reporting, Analysis, and Corrective Action System) voor operationeel leren.
• SMART (Statistical Methods for AI Reliability Testing) voor meetplanning.
• NIST AI RMF voor governance, evaluatie, monitoring en mitigatie.

Drie cases illustreren het programma: adversarial testing van een CNN, perceptiefout-propagatie, en autonome-voertuig disengagements.

4. De synthese: twee antwoorden op één vraag

Dimensie	Lupo et al. (CI/CD focus)	Pan et al. (systeembreed)
Core inzicht	Point-in-time audits falen omdat AI-controls niet-deterministisch zijn	Point-in-time benchmarks falen omdat AI-systemen zelf evolueren
Oplossing	Policy-Evidence-Execution scheiding + versioned Posture Tree	Vier-level diagnostiek + klassieke reliability engineering
Schaal	CI/CD decision gates	Volledige systeemlevenscyclus
Snelheid	1,1 ms latency	TEVV-sequentiën over tijd
Governance	Versioned policy profiles	NIST AI RMF + FRACAS

Beide papers concluderen hetzelfde: average benchmark accuracy meet capability, niet reliability. Een systeem dat 99% scoret op een benchmark kan alsnog falen in productie, niet ondanks, maar juist omdat de benchmark een momentopname was.

5. Nederlandse context: NIS2 en BIO2 onder druk

Voor Nederlandse overheidsorganisaties hebben deze bevindingen directe implicaties:

NIS2 artikel 21 vereist "passende en proportionele technische en organisatorische maatregelen". De vraag is: wat is "passend" voor een niet-deterministisch systeem? Een jaarlijkse PEN-test die een momentopname levert, is ontoereikend wanneer het onderliggende model maandelijks wordt bijgewerkt. Dit is geen theoretisch probleem: OpenAI, Anthropic en Google updaten hun modellen continu zonder altijd expliciete release notes.

BIO2 controleobject 7.2 (patchmanagement) en 7.4 (kwetsbaarheidsbeheer) veronderstellen dat controls stabiel zijn tussen updates. Voor AI-gedreven security-controls is die veronderstelling onjuist. Een "gepatchte" AI-auditor kan na een model-update nieuwe blind spots introduceren die de vorige versie niet had.

EU AI Act artikel 15 (robustheid, cybersecurity) vereist "aantoonbare" maatregelen voor high-risk AI-systemen. Aantoonbaarheid impliceert traceerbaarheid over tijd, niet alleen wat er is getest, maar wanneer, onder welke configuratie, en met welke policy.

6. Wat te doen

Organisaties die AI-gedreven systemen onder NIS2/BIO2 brengen:

1. Evalueer uw assurance-mentaliteit. Test u op momentopnames (point-in-time) of op trends over tijd (continuous)? Als het antwoord het eerste is, is uw compliance-aanpak achterhaald.

2. Scheid policy, evidence en execution. Het Policy-Evidence-Execution Separation Pattern van Lupo et al. is direct toepasbaar: definieer wat u vertrouwt (policy), registreer wat u hebt gemeten (evidence), en scheid dit van hoe het systeem werkt (execution).

3. Implementeer versioned posture trees. Een assurance-claim zonder versiebeheer van de onderliggende configuratie is geen claim maar een veronderstelling.

4. Adopteer vier-level diagnostiek. Pan et al. tonen dat falen op verschillende niveaus verschillende oorzaken heeft. Een component-test die slaagt, garandeert niets over agentic conduct.

5. Monitor de reasoning, niet alleen de output. Voor generatieve systemen is het redeneerproces zelf een falingsmodus. Een correct antwoord via een onjuist redeneerpad is een latent defect.

7. Conclusie

De twee papers van 28 september 2026 beschrijven onafhankelijk het einde van point-in-time compliance. Lupo et al. tonen dat CI/CD-pijplijnen met AI-auditors een continue assurance-laag vereisen; Pan et al. tonen dat klassieke reliability engineering moet evolueren naar reasoning-monitoring. Samen vormen ze een coherent beeld: compliance is geen momentopname maar een proces.

Voor de Nederlandse publieke sector betekent dit dat de traditionele auditcyclus (jaarlijkse PEN-test, kwartaalreview, incidentanalyse) ontoereikend is voor AI-gedreven systemen. NIS2 en BIO2 vereisen herhaalbare, aantoonbare maatregelen, maar "herhaalbaar" impliceert nu "continue recomputable", niet "jaarlijks herhaald".

De vraag is niet of uw organisatie klaar is voor continue assurance. De vraag is of uw compliance-framework überhaupt kan omgaan met systemen die veranderen terwijl u ze audit.

---

Bronnen: Lupo, G., Nguyen, N.H., Vo, V., Chamikara, M.A.P., Bai, G., Sultan, N.H. & Abuadbba, A. (2026). Continuous Assurance of Agentic Security Auditors for Software Delivery Decision Gates. arXiv:2609.35266. Pan, R., Hong, Y. & Xie, M. (2026). Reliability Engineering for AI Systems: Challenges, Methods, and Directions. arXiv:2609.35316.