Van "passend" naar een getal: wat Governance-as-Code wel en niet oplost voor de AI Act

Compliance als test in plaats van document

De meeste AI Act-compliance bestaat vandaag uit documenten: een risicoanalyse in Word, een modelkaart in Confluence, een auditspoor dat pas wordt gereconstrueerd als iemand erom vraagt. Paul en Nandy (arXiv:2609.20016, 17 september 2026, AI4Law Workshop ICML 2026) stellen iets anders voor.

Hun vertrekpunt: de artikelen 8 tot en met 15 zijn geschreven met voorspellende AI in gedachten en laten bij generatieve systemen zeven technische gaten. Die lopen van niet-deterministische datagovernance en herkomst van trainingsdata tot continue conformiteit, menselijk toezicht, robuustheid, emergente risico's en generatieve fairness.

Hun antwoord is een raamwerk van 43 machine-controleerbare acceptatiecriteria, verdeeld over zes modules. Het draait in een CI/CD-pipeline en levert auditbewijs op dat per artikel is geïndexeerd, met de echte Rego-code erbij.

Dat laatste is belangrijker dan het klinkt. Rego is de policytaal van Open Policy Agent: open source en al in gebruik voor Kubernetes-admission en infrastructuurpolicies. Wie OPA in zijn platform heeft, kan dit on-premise draaien zonder een compliance-SaaS met CLOUD Act-exposure. Voor een soevereine AI-stack is dat een serieus voordeel.

De zeven gaten en de bijbehorende modules, geverifieerd uit de paper:

Gap	Artikel	GaC-module
G1: Output non-determinisme	Art. 10	Data Lineage
G2: Trainingsdata-provenance	Art. 11/53	Data Lineage
G3: Continue conformiteit	Art. 9	Risk Registry
G4: Oversight op productiesnelheid	Art. 14	Oversight Hooks
G5: Open-ended robuustheid	Art. 15	Robustness Testing
G6: Emergent risico	Art. 9	Risk Registry
G7: Generatieve eerlijkheid/framing-bias	Art. 10	Output Monitoring

De 43 criteria verdelen zich over zes modules (7+5+7+9+8+7 = 43), elk met eigen doelartikelen: Data Lineage (7, Art. 10/11/53), Output Monitoring (5, Art. 10/13), Oversight Hooks (7, Art. 14), Robustness Testing (9, Art. 15), Risk Registry (8, Art. 9), Audit Logging (7, Art. 12). Ze lopen in de CI-, CD- en runtime-fasen en produceren per controlepunt evidence die aan een specifiek artikel is gekoppeld.

De kernzet: open normen worden gedeclareerde getallen

Het interessantste idee is juridisch, niet technisch. Open normen als "passend niveau" en "mogelijke vertekeningen" worden omgezet in gedeclareerde, auditeerbare getallen. Robuustheidsdrempels volgen uit de gedocumenteerde baseline van de provider plus een state-of-the-art-ondergrens.

Framing-bias wordt teruggebracht tot acht meetbare proxies, getest met contrafeitelijke demografische probes. Hieronder een eigen illustratie van het principe, niet de code van de auteurs.

package gac.art15.robustness
import rego.v1

threshold := max([
    input.declared.baseline - input.declared.tolerance,
    input.declared.sota_floor,
])
deny contains msg if {
    input.eval.adversarial_pass_rate < threshold
    msg := sprintf("Art. 15: pass rate %.3f < drempel %.3f (policy %s)",
        [input.eval.adversarial_pass_rate, threshold, input.declared.version])
}

Drie dingen zijn daarbij belangrijk om te zien:

Een getal maakt een oordeel controleerbaar, niet vanzelf correct. Een open norm is bewust open: de toezichthouder of rechter beoordeelt achteraf of iets passend was, gegeven doel, context en stand van de techniek. Een gedeclareerd getal maakt het eigen oordeel expliciet, versioneerbaar en aanvechtbaar. Dat is echte winst, maar een groene pipeline is geen conformiteit.

Een drempel op basis van de eigen baseline is zelfreferentieel. Alles hangt dan af van de state-of-the-art-ondergrens en van wie die vaststelt. Zolang dat de provider zelf is, levert de pipeline geen vermoeden van conformiteit op. Dat doen alleen geharmoniseerde normen (art. 40). GaC is dus een implementatiemiddel, geen vervanging voor het normalisatiespoor.

De afleiding in de paper is hier transparant over: τ_deploy = max(τ_floor, τ_baseline − δ), waarbij τ_baseline de door de provider geclaimde robuustheid in zijn Artikel 11-technische documentatie is, δ een gedeclareerde maximaal toelaatbare degradatie, en τ_floor een domeinvloer uit de "state of the art" die Artikel 8 invoept. Alle drie de waarden worden met hun bronnen naar het evidence-store geschreven. De tijdcomplexiteit van elke drempelafleiding is triviaal, constante tijd O(1) per controle; de traceerbaarheid is het punt: een assessor ziet geen magische constante maar een verdedigbare afleiding die hij kan betwisten. Die transparantie maakt de zelfreferentialiteit inzichtelijk en daarmee aanvechtbaar.

Acht proxies voor fairness is een validiteitsclaim. Contrafeitelijke probes meten gevoeligheid voor demografische markers in de prompt, geen verdelingseffecten in de gebruikspopulatie. De bekende onmogelijkheidsresultaten rond fairnessmaten verdwijnen niet door er acht te kiezen, en een drempel in een gate nodigt uit tot optimaliseren op de proxy. Wie dit overneemt, moet de proxykeuze zelf onderbouwen, inclusief wat er niet wordt gemeten.

Wie is wat verschuldigd

De tweede bijdrage is de rolcorrectie. Onder artikel 25 en hoofdstuk V leunt een downstream partij op de trainingsdatasamenvatting van de upstream provider (art. 53) en documenteert zij alleen de lagen die ze zelf beheerst. GaC verifieert daarom die samenvatting in plaats van per-sample documentatie te eisen die de partij nooit had.

Dat is praktisch juist, en veel compliance-checklists gaan hier de mist in. Wie een RAG-toepassing bouwt op een ingekocht foundation model kan artikel 10 niet naleven voor pretrainingdata die hij nooit heeft gezien. Hij kan het wel voor zijn eigen fine-tuningset, retrievalcorpus en evaluatiedata.

De paper spreekt hier van "deployer". De AI Act noemt wie een hoog-risicosysteem op een GPAI-model bouwt een downstream provider. Artikel 25 lid 1 maakt een deployer juist tot provider bij substantiële wijziging of een gewijzigd doel. Dat terminologische verschil is juridisch betekenisvol.

Dat verschil doet ertoe voor de publieke sector. Wie alleen deployer is, valt primair onder artikel 26 en, als overheidsorgaan, onder de grondrechteneffectbeoordeling van artikel 27. Geen van beide zit in een pipeline voor de artikelen 8 tot en met 15. GaC wordt pas relevant als je zelf bouwt en daarmee provider wordt. Bij interne generatieve toepassingen gebeurt dat eerder dan veel organisaties denken, ook bij een ministerie of een overheidsorgaan als DUO dat een RAG-assistent op een ingekocht foundation model bouwt. Voor de rechtspleging (bijlage III, punt 8) is dat geen theoretisch scenario.

De validatie vraagt om nuance

De validatie omvat twee enterprise-deployments: een hoog-risico advieschatbot en een contentgenerator met beperkt risico. De maatstaf is een handmatige expert-audit. GaC reproduceert alle bevindingen daarvan, waaronder drie overtredingen die een boete zouden uitlokken, en bespaart ruwweg 75% auditarbeid.

Daar horen vier kanttekeningen bij:

De steekproef is twee. Het gaat bovendien om een workshop-paper. Twee deployments, waarvan één hoog-risico chatbot onder Annex III Area 5(b) (kredietwaardigheid), zeggen weinig over de generalisatie naar de tien Annex III-categorieën of naar klassieke rules-based systemen binnen die scope.

Er is alleen recall gemeten. Alle bevindingen reproduceren zegt niets over false positives, en niets over wat de handmatige audit zelf heeft gemist. Recall zonder precision kan een pipeline zijn die bijna alles flagt; de 75%-besparing is dan deels het gevolg van een lage drempel, niet van efficiënte detectie. Het paper geeft geen precision-cijfer en geen analyse van het resterende deel van de auditarbeid.

"Boete-uitlokkend" is de kwalificatie van de auteurs. Er bestaat nog geen handhavingspraktijk. De Digital Omnibus, Verordening (EU) 2026/1744, in werking sinds 27 juli 2026, verschuift de hoog-risicoverplichtingen voor bijlage III naar 2 december 2027 en voor bijlage I naar 2 augustus 2028. De GPAI-verplichtingen van de artikelen 51 tot en met 56 gelden al sinds 2 augustus 2025, dus de artikel 53-kant is nu al actueel. Het is een nuance die in een compliance-debat vaak verloren gaat: wat een paper "penalty-triggerend" noemt, is een claim over een nog niet bestaande handhavingspraktijk, niet een vastgestelde boeteverwachting.

De besparing zegt iets over wat overblijft. De 25% die niet wordt geautomatiseerd, is waarschijnlijk het deel waar het oordeel zit. Het bestaan van een toezichtsmechanisme (art. 14) kun je machinaal controleren, de effectiviteit tegen automation bias niet. De pipeline kan meten dat er een mens op de kritieke acties zit, niet of die mens zijn eigen automatiseringsvooroordeel beheerst.

Wat je ermee doet

Architectonisch is GaC een herbruikbaar bouwblok in de delivery-architectuur, naast SAST, DAST en SBOM-generatie. Wie het invoert, moet vier ontwerpbeslissingen nemen die een paper niet voor je neemt:

1. Eigenaarschap van de drempels. Dat hoort niet bij het ontwikkelteam te liggen. Drempels zijn risicoacceptatie en horen bij de tweede lijn, met een wijzigingsproces dat aansluit op het risicobeheersysteem van artikel 9 en het kwaliteitssysteem van artikel 17.
2. Integriteit van het bewijs. Artikel-geïndexeerde evidence is pas auditwaardig als die onveranderbaar is: gesigneerde attestaties, een append-only opslag, en een koppeling aan modelversie, datasetversie en policyversie.
3. Juridische versionering. Elke regel codeert een interpretatie. Als richtsnoeren of geharmoniseerde normen verschijnen, moet je kunnen aantonen welke interpretatie op welke release van toepassing was.
4. Doorwerking na de release. Niet-deterministische systemen driften. Dezelfde criteria horen periodiek tegen productie te draaien, als invulling van post-market monitoring (art. 72) en logging (art. 12). Voor de praktische vragen over de AI Act-klassen, zie ook de EU AI Act-zelftest.

Hypothesen en toetsing

Hypothese H1: Open normen in de Artikelen 8-15 van de EU AI Act zijn niet rechtstreeks handhaafbaar op generatieve systemen en vereisen een expliciete, betwistbare operationalisatie in getallen. Falsifieerbaar: H1 is te falsifiëren wanneer een toezichthouder aantoont dat "passende niveaus" en "mogelijke vertekeningen" zonder operationele vertaling direct op generatieve systemen kunnen worden beoordeeld, zonder arbitraire drempels. De paper levert steun door te tonen dat de wet deze normen openlaat, maar dat is op zichzelf geen bewijs dat de vertaling noodzakelijk is: de wet laat open normen bewust aan de toezichthouder, en de noodzaak van een getal is een ontwerpclaim van deze auteurs, geen vereiste van de verordening.

Hypothese H2: Governance-as-Code produceert audit-evidence van minstens gelijke kwaliteit als een handmatige expertaudit, tegen materieel lagere kosten. Falsifieerbaar: H2 is te falsifiëren wanneer een onafhankelijke evaluatie aantoont dat het raamwerk bevindingen mist die de expertaudit wel vond (recall ＜ 1), of dat de 75%-reductie niet opgaat buiten de twee door de auteurs geselecteerde deployments. De huidige validatie meet alleen recall en geen precision; de claim is vooralsnog niet meer dan een casuïstische aanwijzing. De onzekerheid is hier expliciet: de steekproef is twee, en er is geen externe toets op wat de handmatige audit zelf miste.

Counterfactual: wat als de open norm een dicht getal was

Tegenfeitelijk beschouwd: stel dat de EU AI Act 'passende niveaus' direct in dichtgetallen was gegoten in plaats van open te laten. Dan was de ruimte weg geweest voor een toezichthouder om doel, context en stand van de techniek te wegen, en elk systeem had tegen een uniforme, maar daardoor willekeurige lat afgerekend. De kracht van de open norm is juist dat de interpretatie het voorwerp van toetsing is; het gedeclareerde getal verschuift die toets naar het moment van afleiding. Maar zonder een externe vloer blijft de tegenfeitelijkheid een leemte: een provider die zijn eigen baseline laag stelt, declareert het getal dat de pipeline vervolgens als 'passend' markeert.

Beperkingen van deze analyse

Deze analyse verenigt de juridische lezing van rollen en verantwoordelijkheden met de geverifieerde feiten uit de primaire PDF van arXiv:2609.20016. De kwantitatieve claims van de paper, waaronder de 75%-arbeidsreductie en de drie 'boete-uitlokkende' overtredingen, zijn niet onafhankelijk hercontroleerd en berusten op twee door de auteurs geselecteerde deployments; dit artikel beoordeelt het raamwerk en de centrale juridische correctie, niet de validatie-kwantificatie. De AI Act-uitleg (Artikelen 25, 26, 27, 53 en bijlage III) is een technische duiding, geen juridisch advies.

Slot

De opschuiving naar december 2027 is ruimte om dit goed te doen. De verschuiving die de paper markeert is reëel: compliance gaat van een document dat je schrijft naar een eigenschap die je test.

Het risico is dat organisaties de test gaan aanzien voor de norm. De toezichthouder zal niet vragen of de pipeline groen was, maar waarom je dacht dat dit getal "passend" was. Governance-as-Code maakt dat gesprek beter voorbereid en vervangt het niet.

Het nieuw inzicht dat hieruit volgt, en dat niet rechtstreeks uit de bron voortkomt: de open normen van de AI Act zijn geen regelgevende leemte maar een operationalisatie-plicht, met een handelingsoptie buiten de papercontext. De borging van hoog-risico AI verschuift van het oordeel van een auditor naar de kwaliteit van een door de organisatie onderhoudbare, machine-checkbare drempelafleiding.

Deze analyse verenigt een juridische lezing met de geverifieerde feiten uit arXiv:2609.20016 (primair abstract en volledige PDF). De rolcorrectie (deployer vs. downstream provider, Art. 25 lid 1, 26, 27, Annex III punt 8, Digital Omnibus-data) is geverifieerd tegen de AI Act-tekst en de paper. De Rego-illustratie is een eigen representatie van het principe, niet de code van de auteurs. Juridische duiding, geen juridisch advies.