Inference-governance: 20 mechanismen geëvalueerd, geen volstaat tegen een sterke aanvaller

Inference-governance vraagt om aantoonbare werking van maatregelen tijdens gebruik. Een beperking van technische handhaving is geen bewijs van een juridisch vacuüm.

Correctie, 14 september 2026. Een eerdere versie stelde te breed dat de AI Act de inference-pipeline niet reguleert, dat fine-tuning alle interne beveiliging laat verdwijnen en dat sprake was van een onontdekt gat in Artikel 15. Die conclusies waren niet gerechtvaardigd. Hieronder onderscheiden we het onderzoeksresultaat, het wettelijke kader en onze praktische aanbevelingen.

Wat het onderzoek wel vaststelt

Samar Ansari onderzoekt twintig mechanismen voor monitoring, verificatie en enforcement tijdens inference. De taxonomie gebruikt een readiness-schaal met vier niveaus en een gedocumenteerde evidencebasis van vier vendors. Vijftien mechanismen hebben volgens het onderzoek commercieel technisch substraat. Dat is iets anders dan bewezen toereikendheid onder ieder dreigingsmodel.

Binnen de adversary-analyse krijgt geen afzonderlijk mechanisme het oordeel toereikend tegen een zeer capabele statelijke deployer. De auteur beschrijft ook verlies van model-interne enforcement-componenten door fine-tuning, terwijl platform-externe maatregelen kunnen blijven bestaan. Dit is een afgebakende analyse van mechanismen en tegenstanders, geen bewijs dat iedere fine-tuningstap alle beveiliging uit ieder model verwijdert.

Het onderzoek verbindt inference- en hardwaremaatregelen via een voorwaardelijk substitutieprincipe: vergelijkbare dekking vergt expliciete voorwaarden. We nemen dit niet over als universele uitwisselbaarheid van maatregelen. Bron: Beyond Training, versie 1, ingediend op 9 september 2026.

De AI Act omvat meer dan trainingscompute

De AI Act bevat zowel regels voor modellen voor algemene doeleinden als verplichtingen rond AI-systemen. Artikel 15 beschrijft nauwkeurigheid, robuustheid en cyberbeveiliging van hoogrisicosystemen gedurende hun levenscyclus. Lid 5 behandelt onder meer aanvallen via systeemkwetsbaarheden. De stelling dat inference als geheel buiten de verordening valt, is daarom te ruim.

De Europese Commissie licht de GPAI-verplichtingen afzonderlijk toe. Een criterium voor modelclassificatie mag niet worden verward met de volledige reikwijdte van de wet.

Wie een systeem wijzigt, moet ook zijn rol beoordelen. Artikel 25 beschrijft omstandigheden waaronder een derde, waaronder een deployer, als aanbieder van een hoogrisicosysteem wordt aangemerkt. Niet iedere aanpassing veroorzaakt automatisch die rolwisseling. Toepasselijkheid, ingangsdata, systeemclassificatie en verantwoordelijkheden moeten per toepassing worden vastgesteld. Deze analyse stelt geen algemene compliance-deadline vast.

De praktische vraag: wat blijft aantoonbaar werken?

Onze aanbeveling is om na een relevante wijziging bewijs te verzamelen over de werking van maatregelen. Leg eerst vast wat is gewijzigd: modelgewichten, prompts, beschikbare tools, toegangsrechten, logging of configuratie. Beschrijf vervolgens welke beveiligingsclaim daarvan afhankelijk is. Een ongewijzigde toegangspoort bewijst bijvoorbeeld nog niet dat een gewijzigde tooltoewijzing geen extra bevoegdheden geeft.

Maak drie verschillende verklaringen toetsbaar wanneer een controle faalt:

1. Modelgedrag is veranderd. Onderzoek dit met een vastgezette configuratie van de externe maatregelen en vergelijk de uitkomsten vóór en na de modelwijziging.
2. Externe handhaving is veranderd. Houd de modelversie gelijk en onderzoek afzonderlijk wijzigingen aan rechten, routing en controles.
3. De evaluatie meet iets anders. Controleer verschillen in testgevallen, beoordelingscriteria en uitvoeringscondities voordat u een causaal effect toeschrijft aan fine-tuning.

Dit zijn onderzoekshypothesen, geen door het paper bewezen verklaring van een incident in uw organisatie. Verander bij een vergelijking zo weinig mogelijk andere factoren. Bewaar de configuraties en de mislukte testgevallen, zodat een tweede beoordelaar dezelfde vergelijking kan uitvoeren.

Tegenbewijs en grenzen

De sterke werkhypothese “fine-tuning veroorzaakt verlies van de onderzochte controle” wordt zwakker wanneer dezelfde fout ook zonder fine-tuning optreedt. Zij wordt eveneens zwakker wanneer het verschil verdwijnt nadat een gewijzigde toegangsregel is hersteld. Dat zijn concrete mogelijkheden voor tegenbewijs.

Het omgekeerde verdient dezelfde zorg: succesvolle tests op bekende voorbeelden bewijzen geen bescherming tegen iedere aanvaller. Noteer welke rollen, toegangen en mogelijkheden buiten de test vielen. Het oordeel uit een taxonomie over een statelijke deployer is bovendien geen gemeten incidentfrequentie voor Nederlandse organisaties.

We trekken uit deze publicatie geen conclusie dat toezichthouders geen tooling hebben, dat bestaande assessments nooit naar inference kijken, of dat een organisatie door één aanvullende test aan Artikel 15 voldoet. Zulke uitspraken vragen ander bewijs. De relevante onzekerheid blijft of de gekozen maatregelen onder het concrete dreigingsmodel voldoende weerstand bieden.

Een uitvoerbare controle voor de volgende wijziging

Gebruik dit als werkdocument voor een wijzigingsbesluit:

Vast te leggen	Concrete vraag
Wijziging	Welke versie en configuratie worden vervangen, en wat blijft gelijk?
Beveiligingsclaim	Welke handeling moet onmogelijk, beperkt of aantoonbaar zichtbaar zijn?
Tegenstander	Welke toegang en mogelijkheden nemen we in de test aan?
Bewijs	Welke positieve én negatieve testgevallen zijn uitgevoerd?
Tegenbewijs	Welke uitkomst zou onze verklaring onhoudbaar maken?
Verantwoordelijkheid	Wie beoordeelt de technische uitkomst en de juridische rolverdeling?
Herstel	Hoe wordt de vorige werkende configuratie teruggezet als de controle faalt?

Het voorgestelde besluit is eenvoudig: accepteer de wijziging pas wanneer de verantwoordelijke expliciet kan uitleggen welke controle is getest, welke grenzen het bewijs heeft en welk restrisico wordt geaccepteerd. Dit is onze operationele aanbeveling, geen nieuwe wettelijke verplichting die uit de taxonomie volgt.

Voor verdere uitwerking van bevoegdheden en controles: Authority Decomposition voor AI-agenten en MCP Security Control Plane.