> Bron: https://neuralex.nl/blog/wanneer-moet-een-mens-goedkeuren
> Niet elke actie van een AI-agent hoort hetzelfde vrijheidsniveau te krijgen. Een praktisch afwegingskader langs omkeerbaarheid, impact, schaal en betrouwbaarheid van de input — met een concrete beslisboom voor wanneer een mens eerst moet goedkeuren.

[Terug naar kennisbank](/blog)

Agents ·27 september 2026 ·7 min lezen

# Wanneer moet een mens goedkeuren? Een beslisboom voor autonomie

Niet elke actie van een AI-agent hoort hetzelfde vrijheidsniveau te krijgen. Een praktisch afwegingskader langs omkeerbaarheid, impact, schaal en betrouwbaarheid van de input — met een concrete beslisboom voor wanneer een mens eerst moet goedkeuren.

Een AI-agent mag een actie autonoom uitvoeren als de gevolgen beperkt en omkeerbaar zijn, de impact op mensen, geld en juridische verplichtingen laag is, en de input waarop de agent beslist voldoende betrouwbaar is. Zodra één van die voorwaarden wegvalt, hoort menselijke goedkeuring onderdeel van de workflow te worden.

De praktische vraag is dus niet: vertrouwen we de agent? De vraag is: wat gebeurt er als deze specifieke actie fout gaat? Een agent die zelfstandig een intern document labelt, vormt een ander risico dan dezelfde agent die een contract verstuurt, een leverancier betaalt of honderd klanten mailt. Autonomie moet daarom per actie worden bepaald, niet per agent.

## Begin bij de actie, niet bij de intelligentie van de agent

Het is verleidelijk om autonomie te koppelen aan hoe goed een model presteert. Een geavanceerd model zou dan meer mogen dan een kleiner of goedkoper model. Dat is een verkeerde basis voor toegangsbeleid.

Ook een zeer betrouwbaar model kan verkeerde input krijgen, een instructie verkeerd interpreteren of via [prompt-injectie](/blog/prompt-injectie-uitgelegd) worden beïnvloed. Andersom kan een relatief eenvoudige agent prima volledig autonoom werken wanneer hij alleen acties uitvoert met beperkte gevolgen.

Definieer daarom per tool of handeling welke autonomie is toegestaan. Bijvoorbeeld:

-   een conceptdocument aanmaken: autonoom;
-   een intern ticket categoriseren: autonoom;
-   een agenda-afspraak voorstellen: autonoom;
-   een bestaande afspraak verwijderen: mogelijk goedkeuring nodig;
-   een factuur betalen: menselijke goedkeuring;
-   een contract namens het bedrijf versturen: menselijke goedkeuring.

Autonomie is daarmee een eigenschap van de combinatie agent + actie + context, niet van het model alleen.

## Vraag 1: is de actie eenvoudig terug te draaien?

Omkeerbaarheid is meestal de beste eerste scheidslijn.

Kan een fout zonder grote gevolgen worden hersteld, dan kan een agent relatief veel vrijheid krijgen. Denk aan het toevoegen van metadata, het opstellen van een conceptantwoord of het verplaatsen van een intern bestand naar een verkeerde map.

Moeilijk of niet omkeerbare acties vragen meer controle. Voorbeelden zijn:

-   een betaling uitvoeren;
-   gegevens definitief verwijderen;
-   een juridische verklaring versturen;
-   een account blokkeren;
-   vertrouwelijke informatie extern delen;
-   een bestelling definitief plaatsen.

Daarbij is niet alleen technische omkeerbaarheid relevant. Een verzonden e-mail kun je technisch misschien opvolgen met een correctie, maar een fout bericht naar een klant of toezichthouder kan reputatie- of juridische gevolgen hebben die niet werkelijk terug te draaien zijn.

Een bruikbare vuistregel: hoe moeilijker het is om de toestand van vóór de actie te herstellen, hoe sterker de reden voor menselijke goedkeuring.

## Vraag 2: hoe groot is de impact als de actie fout gaat?

Niet iedere fout heeft dezelfde consequenties. Een agent die één intern document verkeerd classificeert, heeft een ander risicoprofiel dan een agent die automatisch prijzen wijzigt of klantaccounts afsluit. Beoordeel minimaal drie soorten impact.

**Financiële impact.** Kan de actie direct geld kosten, een betalingsverplichting creëren of inkomsten beïnvloeden? Een agent kan bijvoorbeeld prima een factuur voorbereiden, maar het daadwerkelijk initiëren van een betaling kan een goedkeuringsstap vereisen.

**Juridische of contractuele impact.** Kan de actie een verplichting aangaan, rechten wijzigen of formele communicatie veroorzaken? Denk aan het accepteren van voorwaarden, versturen van een contract, indienen van een verklaring of wijzigen van een personeelsdossier.

**Operationele impact.** Kan een fout processen stilleggen, gegevens beschadigen of toegang voor medewerkers of klanten blokkeren? Een verkeerde serverconfiguratie of massale accountwijziging kan meer schade veroorzaken dan een verkeerd geformuleerd conceptbericht.

Hoe hoger de mogelijke impact, hoe minder logisch volledig autonome uitvoering wordt.

## Vraag 3: hoeveel mensen of systemen worden geraakt?

Schaal verandert een kleine fout snel in een groot probleem.

Een agent die één e-mailconcept opstelt, heeft een beperkte blast radius. Een agent die hetzelfde bericht automatisch naar de volledige klantenlijst verstuurt, niet. Hetzelfde geldt voor technische acties: één record aanpassen kan laag risico zijn, een wijziging uitvoeren over de volledige database vraagt een ander veiligheidsniveau.

*Vraag daarom: als deze beslissing verkeerd is, hoeveel mensen, records, accounts of systemen worden dan geraakt?*

Een praktisch patroon is om autonomie af te bouwen naarmate de schaal toeneemt:

-   individuele, interne actie: vaak autonoom mogelijk;
-   kleine groep of beperkt systeemonderdeel: autonoom met controles;
-   grote groep, productieomgeving of externe communicatie: goedkeuring of extra verificatie;
-   organisatiebrede of moeilijk herstelbare wijziging: vrijwel altijd menselijke controle.

Dit voorkomt dat een lokaal foutje door automatisering direct wordt vermenigvuldigd.

## Vraag 4: hoe betrouwbaar is de input waarop de agent handelt?

Een agent kan alleen zo betrouwbaar beslissen als de informatie waarop hij zijn beslissing baseert. Een actie op basis van gestructureerde gegevens uit een gecontroleerd intern systeem is doorgaans voorspelbaarder dan een actie op basis van een binnengekomen e-mail, webpagina of willekeurig document.

Dat verschil is belangrijk omdat externe en ongestructureerde input zowel onvolledig als kwaadaardig kan zijn. Een e-mail kan een misleidende instructie bevatten, een document kan verouderd zijn, een webpagina kan tekst bevatten die probeert de agent andere opdrachten te laten uitvoeren.

Maak daarom onderscheid tussen:

-   gecontroleerde interne data;
-   data uit bekende systemen met validatie;
-   menselijke vrije tekst;
-   externe documenten en e-mails;
-   publiek internet;
-   input waarvan de herkomst niet goed kan worden vastgesteld.

Hoe minder betrouwbaar de bron, hoe minder verstandig het is om daar direct een onomkeerbare actie aan te koppelen.

## De praktische beslisboom

Voor iedere actie van een agent kun je dezelfde reeks vragen doorlopen:

1.  **Is de actie volledig en eenvoudig omkeerbaar?** Ja: ga verder. Nee: menselijke goedkeuring, tenzij de impact aantoonbaar verwaarloosbaar is.
2.  **Kan een fout financiële, juridische, privacy- of veiligheidsgevolgen hebben?** Nee: ga verder. Ja: voeg goedkeuring of een sterke beleidscontrole toe.
3.  **Kan één fout veel mensen, accounts, gegevens of systemen raken?** Nee: ga verder. Ja: beperk de schaal of voeg menselijke goedkeuring toe.
4.  **Komt de beslisinformatie uit een betrouwbare en gecontroleerde bron?** Ja: autonome uitvoering kan passend zijn. Nee: eerst valideren, escaleren of laten goedkeuren.
5.  **Kan de agent vooraf controleren of de uitkomst binnen expliciete grenzen valt?** Ja: autonomie kan worden toegestaan binnen die grenzen. Nee: laat een mens de beslissing beoordelen.

De uitkomst hoeft niet alleen "autonoom" of "mens beslist" te zijn. Er bestaat een nuttige tussenlaag: autonomie binnen grenzen. Een agent mag bijvoorbeeld zelfstandig inkoopvoorstellen voorbereiden, maar niet bestellen. Of zelfstandig afspraken plannen zolang hij geen bestaande afspraak verwijdert. Of klantmails verzenden vanuit vooraf goedgekeurde templates, maar nieuwe vrije tekst eerst als concept aanbieden.

## Gebruik goedkeuring als veiligheidsmechanisme, niet als standaardoplossing

Alles door een mens laten goedkeuren klinkt veilig, maar haalt uiteindelijk veel waarde uit een agentensysteem. Wanneer medewerkers tientallen laag-risicoacties moeten bevestigen, ontstaat bovendien het risico dat goedkeuring een routineklik wordt.

Human-in-the-loop werkt daarom vooral wanneer de mens wordt ingezet op beslissingen waar daadwerkelijk oordeel nodig is. Automatiseer acties met lage impact en duidelijke grenzen. Escaleer uitzonderingen, twijfelgevallen en risicovolle acties.

Een agent die elke handeling moet laten bevestigen is weinig meer dan een geavanceerde assistent. Een agent die alles zelfstandig mag doen is daarentegen moeilijk beheersbaar. De bruikbare positie ligt meestal tussen die twee uitersten.

## Combineer autonomie met least privilege en observability

Een goedkeuringsmodel staat niet op zichzelf. Ook autonome acties moeten beperkt blijven tot wat de agent daadwerkelijk nodig heeft. Een agent die alleen afspraken moet plannen, heeft geen reden om klantrecords te verwijderen. Zo pas je [least privilege toe op AI-agents](/blog/agent-toegang-tot-bestanden).

Daarnaast moet achteraf zichtbaar zijn wat de agent heeft gedaan: welke input hij gebruikte, welke tool hij aanriep, welke actie werd uitgevoerd en of daarbij goedkeuring is gegeven — precies waar [agent-observability](/blog/agent-observability) voor bedoeld is.

Least privilege beperkt wat fout kan gaan. Observability maakt zichtbaar wat er is gebeurd. Menselijke goedkeuring voorkomt dat bepaalde risicovolle acties überhaupt zonder controle plaatsvinden. Samen vormen ze een veel sterker veiligheidsmodel dan één van deze maatregelen afzonderlijk — de kern van [AI-agents met de juiste vangrails voor het mkb](/blog/ai-agents-voor-het-mkb).

## Conclusie

Een AI-agent moet menselijke goedkeuring vragen wanneer een actie moeilijk terug te draaien is, aanzienlijke financiële, juridische of operationele gevolgen kan hebben, veel mensen of systemen raakt, of gebaseerd is op onvoldoende betrouwbare input. Acties met lage impact, beperkte schaal, duidelijke grenzen en betrouwbare gegevens kunnen juist prima autonoom worden uitgevoerd. De beste architectuur geeft een agent daarom niet simpelweg "wel" of "geen" autonomie, maar bepaalt per actie hoeveel vrijheid verantwoord is.

Agents met de juiste vangrails

## Weet jij welke acties jouw AI-agent zelfstandig mag uitvoeren?

Wij ontwerpen de rechten, goedkeuringsstappen en logging zodat een agent alleen doet wat verantwoord is — niet meer. Benieuwd wat dat voor jouw situatie betekent?

[Stel je vraag](/contact) [Lees AI-agents voor het mkb](/blog/ai-agents-voor-het-mkb)

---
Volledige (opgemaakte) versie: https://neuralex.nl/blog/wanneer-moet-een-mens-goedkeuren