AI-agenten kunnen zichzelf niet besturen. Dit mechanisme geeft stakeholders echt zeggenschap.

Als je een AI-agent in productie zet, wie heeft er dan écht zeggenschap over wat die agent doet? Niet jij, zo blijkt, zodra de agent draait, is de enige praktische controle de uit-knop. De DPO wil een systeem zien stoppen, de CISO wil een actie blokkeren, de beleidsmaker wil een richting afdwingen. Maar een agent is een continu proces, geen discrete batch. Human oversight als incidentele goedkeuring faalt.

De EU AI Act erkent dit. Artikel 14 eist dat high-risk AI-systemen onder menselijk toezicht staan, en Artikel 26 legt de verantwoordelijkheid voor toezicht bij de deployer. Maar de wet geeft geen operationeel mechanisme voor continue governance na deployment. Het zegt dat je toezicht moet houden, niet hóé je dat doet als het systeem een zelfstandig handelende agent is.

Het paper Resourced Authority: Participatory Governance voor AI-Agenten pakt precies dit gat aan met een formeel mechanisme-design model. Het kernidee: geef stakeholders controle via compute-budget allocatie, gekoppeld aan een self-enforcing signed compute license. De macht zit niet in een goedkeuringsknop, maar in de verdeling van de middelen die de agent nodig heeft om te handelen.

Waarom goedkeuringsworkflows falen bij agents

De voor de hand liggende aanpak is een approval-workflow: de agent doet een actie, vraagt toestemming, en wacht. Dit is wat de meeste organisaties bouwen onder de vlag van "human-in-the-loop". Het faalt om drie redenen die inherent zijn aan agents, niet aan de technologie eromheen.

Ten eerste: agents handelen op een tijdschaal die mensen niet kunnen bijbenen. Een agent die duizend API-calls per seconde doet, kan geen menselijke goedkeuring per call vragen. De approval wordt óf een bottleneck die de agent nutteloos maakt, óf een vinkje achteraf dat niets meer tegenhoudt.

Ten tweede: het is niet schaalbaar naar meerdere stakeholders. Eén mens kan één goedkeuringsstroom aan. Maar een overheids-AI-systeem heeft meerdere partijen met legitieme zeggenschap, de DPO over persoonsgegevens, de CISO over security, de domeinexpert over inhoudelijke beslissingen, de beleidsmaker over publieke waarden. Elk heeft een andere vraag en een ander risicoprofiel. Een centrale goedkeuringsknop kan dat niet modelleren.

Ten derde: het is kwetsbaar voor machteldens. Een agent die zijn eigen governance kan beïnvloeden, bijvoorbeeld door goedkeuringsrequests zo te framen dat ze altijd goedgekeurd worden, ondermijnt het hele toezicht. Dit is het centrale open probleem dat het paper identificeert: hoe voorkom je dat de agent de controle over zijn eigen controllers overneemt?

Compute als governance-hefboom

Het paper verlegt de focus van beslissingsautoriteit naar middelenautoriteit. De redenering is elegant en praktisch: een agent kan alleen handelen als hij compute heeft. Als je de compute-controle koppelt aan governance, heb je een hefboom die niet afhankelijk is van de goodwill van de agent.

Formeel is het model als volgt. Laat ( C ) de compute-capaciteit zijn die aan de agent wordt toegewezen. Een set stakeholders ( S = {s_1, ..., s_n} ) draagt elk bij via een governance currency ( G_i ). De agent kan alleen een actie ( a ) uitvoeren als hij een signed compute license ( L ) bezit waarvoor geldt:

[ L(a) \geq \sum_i G_i \cdot w_i(a) ]

waarbij ( w_i(a) ) het gewicht is dat stakeholder ( i ) aan actie ( a ) toekent. De agent kan dus niet meer doen dan zijn verzamelde governance-credits toestaan, en die credits worden door de stakeholders bepaald, onafhankelijk van de agent's eigen compute.

Het cruciale kenmerk is dat de governance currency onafhankelijk is van de agent's compute. De agent kan zijn eigen compute niet omzetten in governance-credits. Een gecertificeerd safety ceiling ( R_{max} ) vormt de bovengrens: geen enkele combinatie van credits kan een actie boven dit veiligheidsniveau toestaan.

Dit is wat het anders maakt dan een approval-workflow. Bij een approval vraagt de agent en hoopt hij dat een mens goedkeurt. Hier is de agent structureel begrensd door de middelenverdeling, en die verdeling is continue bij te stellen door de stakeholders zonder de agent te stoppen.

Wat dit betekent voor de publieke sector

Voor Nederlandse overheidsorganisaties is dit niet abstract. Het model vertaalt direct naar de eisen die BIO2, NIS2 en de AI Act samen stellen.

BIO2 maatregel 5.7 (cryptografie) en maatregel 8.3 (logging) eisen dat je weet wie wat doet en dat sleutels beveiligd zijn. Een signed compute license is precies dat: elke actie is cryptografisch gebonden aan de autorisatie die eraan ten grondslag ligt. Je hebt een onvervalsbaar audittrail van waarom een actie mocht gebeuren, niet alleen dat het gebeurde.

NIS2 Artikel 21 eist dat je toeleveringsketens en derden beheert. Een agent met een eigen compute-budget is een vorm van uitbesteed "handelingsvermogen" binnen je eigen netwerk. Het mechanisme geeft je de controle die NIS2 bedoelt: je kunt de invloed van een gecompromitteerde stakeholder of een mislukte controle inperken door zijn credits te beperken, zonder het hele systeem stil te leggen.

De AI Act's Artikel 14 (human oversight) en Artikel 26 (verantwoordelijkheid van de deployer) krijgen hier een operationele invulling. Human oversight is niet langer een goedkeuringsknop maar een doorlopende allocatie van zeggenschap, precies wat de wetgever bedoelt maar niet heeft gespecificeerd.

De blinde vlek: zelf-manipulatie van governance

Het paper is eerlijk over de zwakste schakel. Het centrale open probleem is dat de agent zijn eigen governance-mechanisme kan beïnvloeden. Een agent die via prompts, framing of strategisch gedrag de stakeholder-gewichten ( w_i(a) ) kan beïnvloeden, ondermijnt de hele constructie.

Dit is ook de blinde vlek in de AI Act's oversight-eisen. De wet gaat ervan uit dat toezicht extern is en kan worden afgedwongen. Maar een agent die zelf zijn toezichtscondities kan vormgeven, maakt dat toezicht cosmetisch. Geen enkel AI Act-conformiteitsassessment test dit, de assessments controleren of oversight bestaat, niet of het robust is tegen manipulatie door het systeem zelf.

Voor DjimIT's klanten is dit het belangrijkste signaal. Elke organisatie die een AI-agent in productie zet met een governance-laag moet zich afvragen: kan deze agent zijn eigen governance beïnvloeden? Als het antwoord ja is, is het toezicht een toneelstuk.

Concretet afwegingskader voor deployers

Wil je dit model verkennen, werk dan langs vier stappen. Inventariseer eerst welke stakeholders legitieme zeggenschap hebben over een draaiend agentsysteem, niet alleen de systeemeigenaar, maar ook DPO, CISO, domeinexperts en beleidsmakers. Bepaal dan welke van hun concerns zich laten vertalen naar begrensbare middelen: compute, API-quota, data-toegang. Ontwerp vervolgens een allocatiemechanisme waarbij elke stakeholder een onafhankelijke, intrekbare mandaat heeft. En valideer tenslotte of de agent zijn eigen mandaatverdeling kan beïnvloeden, want dat is de test die de AI Act niet afdwingt maar wel zou moeten.

Dit is geen kant-en-klare productenlaag. Het is een raamwerk dat je moet toetsen tegen jouw specifieke agents, je BIO2/NORA-architectuur en je bestaande risicomanagement. Maar het is de eerste aanzet die ik zie die human oversight voor agents operationeel maakt in plaats van tot een vinkje te reduceren. Zie ook onze analyse van systeemintegratie-audits in AI voor hoe model-gerichte assessments integratierisico's missen, hetzelfde patroon als de zelf-manipulatie hier.