SecurityTechInsider AI-veiligheid & governance
EN/ NL
Governance

Autorisatiekloof bij AI-agents in de overheid

Een studie in Frontiers in Political Science benoemt de democratic authorization gap: overheden moeten per AI-actie mandaat, verantwoordelijke en herstel kunnen

23 september 2026 3 min
Illustratie bij dit artikel: Autorisatiekloof bij AI-agents in de overheid.
Overheden moeten per AI-actie aantonen welk democratisch mandaat die handeling draagt en wie daarvoor verantwoordelijk is. Beeld: SecurityTechInsider — originele redactionele illustratie

U moet per AI-actie in gevoelige workflows aantonen welk democratisch mandaat die handeling draagt, wie daarvoor verantwoordelijk is, en hoe u die autorisatieketen achteraf kunt reconstrueren. Technische toegangsbeheer volstaat niet.

Een analyse van 23 september 2026 van de democratic authorization gap bij AI-agents in de overheid stelt dat overheden een breuk moeten sluiten tussen legitieme publieke autoriteit en de acties die een AI-agent zelf selecteert of uitvoert. Een agent kan technisch binnen zijn permissies blijven terwijl uw organisatie niet kan aantonen dat zij die handeling mocht delegeren. Een praktijkvoorbeeld: een agent voert een administratieve beslissing uit waarvoor toegangsbeheer en auditlogs registreren dat de agent daartoe bevoegd was — maar geen enkel stuk toont aan op welk wettelijk mandaat die bevoegdheid rustte of wie er bestuurlijk verantwoordelijk voor is. In onze inschatting betekent dit dat u drie afzonderlijke lagen moet kunnen documenteren: het wettelijk en democratisch mandaat voor de handeling, de bestuurlijke verantwoordelijkheid van een naamgenoemde functionaris, en de technische begrenzing van wat de agent mag doen.

Wat is het verschil tussen technische bevoegdheid en democratisch mandaat?

Auditlogs en toegangsbeheer registreren doorgaans wat een agent mocht doen: welke rol, welke rechten, welke tool-aanroepen. Dit zegt niets over de vraag of uw organisatie die permissie mocht verlenen en op welk mandaat dat rustte. Een log dat aantoont dat een agent binnen zijn permissies bleef, is noodzakelijk maar niet voldoende. Het onderscheid is drieledig. Eerst: het wettelijk en democratisch mandaat voor de handeling zelf — welke wet, welk besluit, welk publiek belang rechtvaardigt dat uw organisatie deze actie uitvoert? Tweede: de bestuurlijke verantwoordelijkheid — welke functionaris heeft die bevoegdheid gekregen en kan daarover verantwoording afleggen? Derde: de technische begrenzing — welke permissies heeft de agent gekregen en hoe worden die gehandhaafd? Zonder die koppeling blijft traceerbaarheid beperkt tot techniek en mist het de bestuurlijke laag.

Welke bewijsstukken moet u per workflow kunnen tonen?

  1. Documenteer het wettelijk mandaat — leg vast welke wet, welk besluit of welk publiek belang de handeling rechtvaardigt.
  2. Benoemd een verantwoordelijke functionaris — bepaal wie bestuurlijk verantwoordelijk is voor de autorisatie en kan daarover verantwoording afleggen.
  3. Registreer de gedelegeerde bevoegdheden — documenteer welke permissies de agent heeft gekregen en waarom die begrenzing zo is gekozen.
  4. Traceer elke actie op het niveau van de handeling — log niet alleen dat de agent actief was, maar welke specifieke beslissing hij nam en op welk moment.
  5. Definieer een herstelroute — bepaal hoe u een actie kunt terugdraaien en wie daarvoor bevoegd is.

Welke risico's ontstaan als u deze lagen niet scheidt?

De autorisatiekloof veroorzaakt vier concrete risico's. Ten eerste: delegatie zonder mandaat — u geeft een agent bevoegdheden zonder aan te tonen dat u die mocht delegeren. Ten tweede: verborgen verantwoordelijkheid — geen enkele functionaris kan bestuurlijk verantwoording afleggen voor de actie. Ten derde: onvolledig audit trail — u kunt achteraf niet reconstrueren waarom de agent precies deze handeling uitvoerde. Ten vierde: geen herstelroute — u kunt een actie niet terugdraaien omdat niet duidelijk is wie daarvoor bevoegd is.

Hoe verhoudt leveranciersafhankelijkheid zich tot uw verantwoordelijkheid?

Beperkte transparantie van API-systemen maakt uw verantwoordelijkheid niet kleiner, maar zwaarder. Wie een systeem inzet waarvan de interne werking niet volledig zichtbaar is, moet dat compenseren met scherpere afspraken over inzet, validatie en toezicht. Dit betekent dat de leveranciersafhankelijkheid zelf een governanceonderwerp is dat per workflow moet worden vastgelegd. U moet weten hoe systemen zijn getraind, hoe output wordt gevalideerd, waar data staat, wie toegang heeft en hoe risico's doorlopend worden gemonitord. Die verantwoordelijkheid blijft bij uw organisatie en de bevoegde functionarissen, niet bij de leverancier.

Tooling kan u helpen toegangsbeheer in te richten, auditlogs te genereren en permissies te beheren. Maar de bestuurlijke vraag — welk mandaat draagt deze handeling, wie is verantwoordelijk, hoe stellen we dat achteraf vast — is een oordeel dat u zelf moet vormen en documenteren. Techniek levert de begrenzing; verantwoording is een bestuurlijke taak.

Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van Frontiers in Political Science, AI and Ethics, Springer Nature, United Nations News en Microsoft Cloud Blog.

Marit Halversen

Geschreven door

Marit Halversen

Schrijft over AI-governance en regelgeving, met de nadruk op hoe verplichtingen neerslaan in architectuur in plaats van in papierwerk.