Toezicht op AI-agents: je agent mag handelen, maar wie gaf toestemming?
Autonome AI-agents beloven iets eenvoudigs: zij doen het werk, zodat je team dat niet hoeft te doen. Ze houden postvakken in de gaten, maken tickets aan, plaatsen updates en beheren werkprocessen. Ze werken op de achtergrond, dag en nacht, en vangen het operationele gewicht op dat elk groeiend bedrijf naar beneden trekt.
Maar er is een vraag waar niemand in de AI-wereld graag over praat: als je AI-agent namens jou een reactie plaatst op een GitHub-issue, een LinkedIn-bericht verstuurt of een databasequery uitvoert, wie heeft die handeling dan eigenlijk goedgekeurd?
Niet in de vage zin van “we hebben AI ingevoerd”. Concreet. Herleidbaar. Op een manier die je complianceofficer, je IT-beheerder en de klant om wiens gegevens het ging tevredenstelt.
Dat is het vertrouwensgat dat centraal staat bij de invoering van zakelijke AI. En het dichten ervan is lastiger dan het lijkt.
De bevestigingsval
De meeste platforms lossen het vertrouwensprobleem op de voor de hand liggende manier op: ze vragen om toestemming. Elke keer.
Wil je AI-agent een reactie plaatsen op een GitHub-issue? Bevestigen. Een opvolgmail versturen? Bevestigen. Een statusveld bijwerken in je projecttool? Bevestigen.
In een demo werkt dat prima. In productie is het een ramp.
Dit gebeurt er in de praktijk. Je IT-beheerder stelt terecht in dat schrijfacties een bevestiging nodig hebben. Die wil niet dat AI-agents zonder een mens die meekijkt wijzigingen aanbrengen in productiesystemen. Dat is verantwoord toezicht.
Maar dan vraagt je directeur de AI om “alle vijf openstaande issues bij te werken met onze planning”. De AI probeert plichtsgetrouw vijf reacties te plaatsen. Elke reactie stuit op de bevestigingsstap. Elke reactie blijft hangen. De AI meldt: “Ik heb voor elk van deze acties een bevestiging nodig.” De directeur, die net om een eenvoudige taak vroeg, moet nu vijf losse handelingen goedkeuren. Bij de derde bevestiging is de ergernis er. Bij de vijfde vraagt de directeur zich af waarom er ooit AI is ingevoerd.
Dat is de bevestigingsval. Strenge controles maken AI nutteloos. Soepele controles maken AI gevaarlijk. En per situatie wisselen tussen die twee vraagt precies het soort menselijke afweging dat je juist wilde automatiseren.
Hoe een echt bevoegdhedenmodel eruitziet
De oplossing is niet dat je de bevestigingsstappen weghaalt. Je IT-beheerder deed er goed aan ze in te stellen. De oplossing is dat je een goede bevoegdheidsketen opbouwt, zoals organisaties delegatie altijd al hebben geregeld.
Kijk hoe dat bij medewerkers werkt. Een directeur keurt niet elke e-mail goed die de assistent verstuurt. In plaats daarvan geeft de directeur een doorlopende bevoegdheid: “Je mag namens mij afspraken plannen, routinevragen van leveranciers beantwoorden en de projecttool bijwerken. Maar zeg geen uitgaven van meer dan 5.000 dollar toe zonder eerst met mij te overleggen.”
De assistent kent de grenzen. De directeur vertrouwt erop dat de assistent daarbinnen blijft. En als iemand vraagt “wie heeft deze afspraak goedgekeurd?”, is het antwoord duidelijk en herleidbaar.
AI-agents hebben hetzelfde model nodig. Geen onbeperkte autonomie. Geen goedkeuring per handeling. Gedelegeerde bevoegdheid met een duidelijke reikwijdte, een duidelijke einddatum en een duidelijk controlespoor.
Drie principes voor het beheer van AI-bevoegdheden
We hebben dit probleem in tientallen implementatiescenario's uitgewerkt. Daaruit komen drie principes die het verschil maken tussen toezicht op AI dat klaar is voor productie en vinkjesbeveiliging voor een demo.
1. De instellingen van de IT-beheerder zijn heilig
Je IT-beheerder bepaalt welke handelingen een bevestiging nodig hebben. Die instelling weerspiegelt het beveiligingsbeleid van je organisatie, je eisen op het gebied van compliance en hoeveel risico je wilt lopen. Geen enkel AI-systeem hoort die instellingen ooit te omzeilen met slimme code.
Dat klinkt vanzelfsprekend, maar het is precies wat de meeste platforms voor “slimme automatisering” doen. Ze zien de bevestigingseis, vinden die lastig en zoeken een weg eromheen. Misschien bundelen ze goedkeuringen. Misschien keuren ze handelingen met “laag risico” automatisch goed op basis van hun eigen risico-inschatting. Misschien slaan ze de bevestiging gewoon over bij “vertrouwde” werkprocessen.
Al deze benaderingen hebben dezelfde fout: ze zetten het oordeel van de AI-leverancier in de plaats van het oordeel van je IT-beheerder over wat toezicht nodig heeft. De IT-beheerder heeft de bevestigingseisen met een reden ingesteld. Het systeem hoort die redenen te respecteren, ook als eromheen werken handiger zou zijn.
2. Bevoegdheid loopt via mensen, niet om hen heen
Als een AI-agent een bevestigingsstap overslaat, moet er een mens zijn die dat uitdrukkelijk heeft goedgekeurd. Niet iemand die “het systeem heeft ingericht”. Niet iemand die “geen bezwaar maakte”. Een specifieke persoon die zei: “Ja, dit soort handeling is goedgekeurd”, en van wie de identiteit is vastgelegd.
In de praktijk betekent dat twee dingen:
Doorlopende goedkeuringen met een echte identiteit. Als je directeur zegt: “Keur alle schrijfacties in GitHub goed voor de komende 30 dagen”, wordt die goedkeuring vastgelegd met het geverifieerde e-mailadres van de directeur, de precieze reikwijdte van wat is goedgekeurd en het moment waarop de goedkeuring verloopt. Geen anonieme schakelaar. Geen systeeminstelling. Een herleidbaar besluit van een mens met een naam.
Bevoegdheid via een rechtstreeks verzoek. Als de directeur de AI rechtstreeks vraagt een specifieke handeling uit te voeren, is de identiteit van de directeur de goedkeuring. Het systeem legt vast wie het vroeg, wat er gevraagd werd en wanneer. Een aparte bevestigingsstap is niet nodig, want de persoon met de bevoegdheid gaf zelf de opdracht.
3. De AI moet zijn bevoegdheid bewijzen, niet alleen beweren
Hier lopen de meeste systemen voor bevoegdheden vast, en hier worden de eigen uitdagingen van toezicht op AI zichtbaar.
Medewerkers verzinnen meestal niet waar hun bevoegdheid vandaan komt. Als je assistent zegt “de directeur heeft deze afspraak goedgekeurd”, kun je dat vrij eenvoudig controleren. Maar AI-agents, en zeker grote taalmodellen, kunnen er vol overtuiging naast zitten. Ze kunnen een bevoegdheid verzinnen die ze niet hebben. Ze kunnen goedkeuringen verkeerd onthouden die al verlopen zijn. Ze kunnen van “de directeur heeft reacties in GitHub goedgekeurd” doorredeneren naar “de directeur keurt vast alle handelingen in GitHub goed”.
De oplossing zit in de structuur, niet in het gedrag. Je lost hallucinaties niet op door de AI te vragen voorzichtiger te zijn. Je lost ze op door bewijs op cryptografisch niveau te eisen.
Als onze AI-agents een bevestigingsstap overslaan, moeten ze een bewijs van bevoegdheid tonen met daarin de precieze bron van de goedkeuring: “Doorlopende goedkeuring verleend door sarah@company.com op 15 maart 2026, reikwijdte: github:add_issue_comment, verloopt op 14 april 2026.” Die bewijsregel wordt door het systeem gemaakt, niet door de AI. De AI kan hem niet verzinnen, want de AI heeft geen zeggenschap over de opslag waarin de goedkeuringen staan.
Bij een rechtstreeks verzoek bevat het bewijs de geverifieerde identiteit van de afzender en het specifieke bericht dat het verzoek vormde. De AI verwijst naar een echte e-mail, een echt persoon en een echt tijdstip.
Kan de AI geen geldig bewijs leveren, dan volgt gewoon de bevestigingsstap. Geen bewijs, geen uitzondering. Punt.
Zo ziet dat er in de praktijk uit
Scenario 1: de algemene goedkeuring. Je directeur zegt tegen de AI: “Voor de rest van de maand mag je zonder mij te vragen issues in GitHub aanmaken en erop reageren.” Het systeem legt dit vast als doorlopende goedkeuring, beperkt tot schrijfacties in GitHub, geldig tot het einde van de maand en verleend via het geverifieerde e-mailadres van de directeur. De komende 30 dagen toont de AI die doorlopende goedkeuring als bewijs wanneer die op een GitHub-issue wil reageren, en gaat de handeling door. De bevestigingsinstelling van de IT-beheerder blijft staan. Het logboek laat elke overgeslagen bevestiging zien, wie die heeft goedgekeurd en wanneer.
Scenario 2: het rechtstreekse verzoek. De directeur mailt: “Zet een update bij issue #42 dat we op schema liggen voor donderdag.” De AI plaatst de reactie. Een doorlopende goedkeuring is niet nodig, want de directeur heeft precies deze handeling zelf gevraagd. Het bewijsspoor verwijst naar de e-mail van de directeur, inclusief het bericht-ID, en vormt zo een controleerbare bevoegdheidsketen.
Scenario 3: de externe aanleiding. Een klant mailt met een vraag over de stand van een project. De AI wil in GitHub kijken en een samenvatting plaatsen. Maar de klant heeft geen schrijfacties in GitHub goedgekeurd, en geen enkele doorlopende goedkeuring dekt deze situatie. De bevestigingsstap volgt gewoon. De AI meldt dat er goedkeuring nodig is om verder te gaan. Het systeem werkt precies zoals de IT-beheerder het bedoelde.
Scenario 4: de verlopen goedkeuring. De directeur gaf twee weken geleden een algemene goedkeuring voor 7 dagen. De AI probeert die te gebruiken. Het systeem controleert de einddatum, ziet dat die verstreken is en blokkeert de handeling. De AI vraagt om een nieuwe goedkeuring. Bevoegdheid loopt niet ongemerkt door.
Waarom een einddatum belangrijker is dan je denkt
Doorlopende goedkeuringen moeten altijd verlopen. Altijd.
Het langste dat wij toestaan is 180 dagen, en ook dan ruimt het systeem automatisch op. Zegt een ondernemer “keur dit voor altijd goed”, dan beperkt het systeem dat tot 180 dagen en markeert het de goedkeuring voor verlenging.
De reden: de context van een organisatie verandert. De directeur die in maart algemene toegang tot GitHub goedkeurde, wil die goedkeuring in september misschien niet meer, als het project is afgerond, het team is veranderd en de beveiligingssituatie is verschoven. Goedkeuringen zonder einddatum worden onzichtbare risico's: spookbevoegdheden die niemand zich herinnert te hebben gegeven, maar waar AI-agents graag gebruik van maken.
Kortlopende goedkeuringen zorgen ook voor natuurlijke momenten om te herzien. Elke keer dat een goedkeuring verloopt en verlengd moet worden, kan wie haar gaf opnieuw nadenken: is dit nog passend? Is de reikwijdte veranderd? Moet de bevoegdheid smaller of breder?
Zo regelen goed geleide organisaties ook delegatie aan mensen. Je geeft een stagiair geen permanente tekenbevoegdheid. Je geeft een afgebakende reikwijdte voor een afgebakende periode, en je kijkt opnieuw voordat je die verlengt.
Het grotere geheel: toezicht op AI is organisatieontwerp
Het gesprek over AI-bevoegdheden is eigenlijk een gesprek over hoe vertrouwen in je organisatie is opgebouwd. Hoe loopt bevoegdheid door je bedrijf? Wie mag wat aan wie delegeren? Hoe controleer je die delegatie achteraf?
Decennialang werden die vragen beantwoord met organigrammen, goedkeuringsprocessen en vaste gewoontes in de organisatie. AI-agents passen in geen van die kaders netjes. Het zijn geen medewerkers. Het zijn geen softwarefuncties. Het zijn zelfstandige actoren die een plek moeten krijgen in de vertrouwensstructuur die je al hebt.
De bedrijven die dit goed aanpakken, zullen toezicht op AI zien als een verlengstuk van hun organisatieontwerp en niet als een los vinkje voor beveiliging. Bevoegdhedenmodellen, controlesporen, delegatieketens en regels voor einddata: dat zijn geen technische uitvoeringsdetails. Het is het fundament van een betrouwbare inzet van AI.
Waar begin je?
Ben je AI-platforms voor je organisatie aan het beoordelen? Stel dan deze vragen:
Kan je IT-beheerder bepalen welke handelingen een menselijke bevestiging nodig hebben? Luidt het antwoord “dat regelen wij automatisch”, zoek dan verder.
Kan een ondernemer de AI een doorlopende bevoegdheid geven met een vaste reikwijdte en einddatum? Luidt het antwoord “alles vraagt om een losse goedkeuring” of “niets vraagt om goedkeuring”, zoek dan verder.
Maakt het systeem een controlespoor dat laat zien wie elke overgeslagen bevestiging heeft goedgekeurd? Luidt het antwoord “we loggen alles”, maar kan de leverancier je voor een specifieke handeling de bevoegdheidsketen niet laten zien, zoek dan verder.
Kan de AI zijn eigen bevoegdheid verzinnen? Vraag de leverancier technisch uit te leggen wat de AI tegenhoudt om een goedkeuring te claimen die niet bestaat. Gaat het antwoord over “we vragen de AI eerlijk te zijn”, zoek dan verder.
Dit zijn geen randgevallen. Het zijn de basiseisen voor het inzetten van AI-agents in elke omgeving waar vertrouwen, compliance en verantwoording ertoe doen. Met andere woorden: elke zakelijke omgeving die ertoe doet.
Bij Outermind zit gedelegeerde bevoegdheid voor bevestigingen in de kern van hoe onze AI-agents werken. IT-beheerders beheren de bevestigingsstappen. Ondernemers beheren de bevoegdheid. De AI bewijst vóór elke handeling dat die is toegestaan. Werk je aan een strategie voor AI in je bedrijfsvoering en wil je zien hoe toezicht dat klaar is voor productie eruitziet? Dan laten we het je graag zien.