Mens-in-de-lus inbouwen in je AI-workflow: per actie bepalen wanneer je doorlaat en wanneer een mens beslist

Een chatbot praat, een AI-agent handelt. Hij verstuurt een offerte, plaatst een bestelling, keurt een terugbetaling goed of schrijft naar je CRM. Zodra een agent in jouw naam handelt, is de vraag niet meer of je hem vertrouwt, maar waar je een mens tussen het voorstel en de uitvoering zet. Dat punt heet de goedkeuringspoort, en waar je hem plaatst bepaalt of je agent een betrouwbare collega wordt of een risico dat je niet kunt overzien.

Deze gids gaat over dat ontwerp: niet over wat de agent achteraf heeft gedaan, maar over welke acties je vooraf laat doorrollen en welke je stillegt tot een mens kijkt. Dat is iets anders dan monitoring. Hoe je elke agent-actie achteraf herleidbaar maakt met logging, tokenbudgetten en een kill-switch is de observability-kant: zien wat er gebeurde. Hier ontwerp je de besturing zelf, het moment waarop een handeling wel of niet mag plaatsvinden. De twee horen bij elkaar, maar dit is de helft die je voor go-live moet vastleggen.

De gids is voor de ondernemer of het team dat een of meer agents van experiment naar productie tilt, van een MKB-bedrijf tot een afdeling binnen een grotere organisatie. Het is geen theorie over autonomie, maar een concreet stappenplan: scoren, kiezen, bouwen, testen.

Waarom een poort een ontwerpkeuze is, geen rem

Het aantrekkelijke aan agents is juist dat ze zelfstandig handelen. Een poort overal neerzetten haalt dat voordeel weg; nergens een poort zetten maakt elke fout een handeling in de echte wereld. De kunst is dus niet maximaal afremmen, maar precies daar een mens plaatsen waar de impact het rechtvaardigt. Een agent is juridisch geen gereedschap maar een gevolmachtigde, en welke afspraken je over zijn mandaat en escalatiedrempel vastlegt voordat hij live gaat bepaalt hoe ver je hem mag laten gaan. Een afgebakend mandaat is geen keurslijf, het is wat je toelaat de agent op meer en belangrijker werk los te durven laten.

Er is ook een juridische ondergrens. De EU AI Act schrijft voor hoog-risico AI-systemen voor dat ze zo ontworpen moeten zijn dat een mens er effectief toezicht op kan houden, kan ingrijpen en de uitvoer kan negeren, en dat dat toezicht in verhouding staat tot hoeveel autonomie het systeem heeft. Die verplichting geldt vanaf 2 augustus 2026. Valt jouw agent niet onder hoog-risico, dan is dit geen wet maar nog steeds de blauwdruk: hoe groter de impact van een actie, hoe explicieter je de menselijke controle inbouwt. Dat principe, menselijke controle als bewuste rem op autonome AI-agenten, is precies de richting die de grote platforms inslaan, en het is geen toeval dat een organisatie die agents structureel in haar softwareontwikkeling inzet over ongeveer 1.100 engineeringteams dat in een gecontroleerde hub doet en niet vrij in het wild.

Wat je nodig hebt

Voordat je iets bouwt, zorg dat je dit op orde hebt. Veel hoef je niet te kopen; de bouwstenen zitten vaak al in je automatiseringstool.

• Een lijst van acties, niet van agents. Niet "de offerte-agent", maar elke afzonderlijke handeling die hij kan uitvoeren: mail versturen, factuur aanmaken, bestelling plaatsen, record overschrijven, betaling vrijgeven. De poort hoort bij de actie, niet bij de agent.
• Een simpele manier om risico te scoren. Drie vragen per actie (impact, omkeerbaarheid, hoe scherp afgebakend) zijn genoeg. Geen risicomatrix van een adviesbureau.
• Een workflow-tool die kan pauzeren en hervatten. n8n, Make of een agent-platform als Amazon Bedrock AgentCore. De kern is dat de flow kan stoppen, wachten op een mens, en daarna verdergaan.
• Een kanaal waar de goedkeurder echt zit. Een verzoek in een ongelezen inbox is geen poort. Slack, e-mail of Teams, daar waar mensen toch al kijken.
• Een eigenaar per poort. Een mens met naam die de uitkomst goedkeurt en draagt. Techniek zonder eigenaar is geen toezicht.

De stappen

Je ontwerpt mens-in-de-lus door elke agent-actie een risicoscore te geven, daar het juiste poort-niveau aan te koppelen (van volledig autonoom tot een mens die het uitvoert), de goedkeuringsflow te bouwen in je automatiseringstool, en hem te testen met een reeks edge-cases voordat de agent live gaat. Het resultaat: lage-risicowerk rolt zonder wrijving door, en precies de handelingen die ertoe doen, stoppen bij een mens. Doorloop de stappen in volgorde.

Stap 1: Inventariseer de acties die de agent kan uitvoeren

Maak een platte lijst van elke tool en handeling die de agent tot zijn beschikking heeft. Splits ze fijn: "klant mailen" en "interne notitie schrijven" zijn niet hetzelfde risico, ook al gaat het allebei om tekst. Deze lijst is de basis; een poort die je op "de agent" zet in plaats van op een actie is per definitie te grof, want dan stop je ook het onschuldige werk of je laat het gevaarlijke door.

Stap 2: Geef elke actie een risicoscore

Scoor elke actie op drie assen. Je hoeft geen getallen te verzinnen; laag, midden, hoog is genoeg.

• Impact: wat kost een fout? Een verkeerde interne tag is niets; een verkeerde factuur of een mail naar de verkeerde klant is reputatie en geld.
• Omkeerbaarheid: kun je het terugdraaien? Een concept is volledig omkeerbaar, een verzonden mail half, een uitgevoerde betaling niet.
• Afbakening: is de taak scherp gedefinieerd of open? "Zet status op verzonden" is dichtgetimmerd; "stel een passende korting voor" is open en dus risicovoller.

De hoogste van de drie bepaalt de toon. Een onomkeerbare actie is hoog, ook als de impact meestal klein lijkt. Wil je dit gestructureerd aanpakken over je hele processenlijst, dan helpt hetzelfde idee als bij de keuze welke processen je als eerste automatiseert met een scorekaart en beslisboom: scoren maakt de keuze navolgbaar in plaats van een onderbuikgevoel.

Stap 3: Koppel een poort-niveau aan de score

Vertaal de score naar een van vier niveaus. Dit is de autonomieladder: hoe hoger het risico, hoe meer mens.

Het doel is een korte tabel waarin elke actie precies één niveau heeft. Twijfel je tussen twee niveaus, kies het strengere; je kunt een poort later versoepelen als hij in de praktijk niets tegenhoudt, maar een te losse poort merk je pas als het misgaat.

Stap 4: Bouw de goedkeuringspoort in je tool

Nu wordt het concreet. De drie meestgebruikte routes:

In n8n. Voor een directe goedkeuring gebruik je op een app-node de operatie Send and Wait for Response. Bij Gmail, Slack of Teams stelt de agent de actie voor, de node pauzeert de flow en stuurt de goedkeurder een bericht. Je kiest bij Type of Approval tussen alleen een Approve-knop of Approve en Disapprove, zodat een mens met één klik goed- of afkeurt. Heb je meer nodig dan een knop, dan zet je de Wait-node ervoor: die hervat de flow op een ingediend formulier of een webhook-aanroep via de gegenereerde resume-URL, en met Limit Wait Time loopt hij na een deadline automatisch door. Het formulier laat de goedkeurder bovendien de parameters zien voordat hij beslist.

In Make. Make heeft geen kant-en-klare goedkeuringsstap, maar bouwt het op met een router: die scheidt het routinepad van het uitzonderingspad dat menselijke review nodig heeft. Het uitzonderingspad stuurt een Slack-bericht met goedkeur-knoppen of een e-mail met een deeplink, en de beslissing komt via een webhook of formulier terug; je legt hem vast in een data store voor de herkomst.

In Amazon Bedrock AgentCore. Werk je op AWS, dan kun je per tool instellen of een actie eerst om menselijke bevestiging vraagt, of dat de controle helemaal teruggaat naar jouw applicatie. Bevestiging is een ja/nee voor uitvoering; "controle teruggeven" laat de mens de parameters nog aanpassen voordat de actie de echte wereld in gaat. Dat dekt precies de twee bovenste treden van je ladder.

Welke tool je ook kiest, de poort doet hetzelfde: de flow pauzeert, een mens beslist op een kanaal waar hij echt kijkt, en pas daarna gebeurt de actie.

Stap 5: Ontwerp de fallback voor afkeuring en timeout

Een poort is pas af als je weet wat er gebeurt als niemand reageert. Zonder fallback hangt je flow voor altijd, of erger: hij voert na de wachttijd alsnog uit. Leg drie paden vast. Bij goedkeuring: uitvoeren en loggen. Bij afkeuring: stoppen en de reden vastleggen, zodat je later ziet waarom. Bij timeout (gebruik Limit Wait Time in n8n of een sleep-grens in Make): nooit stilzwijgend uitvoeren, maar escaleren naar een tweede persoon of veilig niets doen. De vuistregel: de veilige uitkomst bij geen reactie is niet-handelen, behalve bij acties waar niets-doen zelf schade geeft.

Stap 6: Test met een scenario-roulette voor de edge-cases

Voor go-live laat je de poort niet op de gelukkige weg los, maar op de rafelranden. Draai bewust een reeks testgevallen door de flow: de actie die net over de risicogrens valt, dubbelzinnige input waar de agent een gok doet, een goedkeuringsverzoek dat de timeout raakt, een expliciete afkeuring, en een dubbele uitvoering (wat als de agent twee keer hetzelfde voorstelt?). Voor elk geval controleer je: stopte de poort waar hij moest, en deed de fallback wat je bedoelde? Wat hier doorglipt, glipt straks in productie door. Pas de scores en niveaus uit stap 2 en 3 aan op wat je in deze test leert; een poort-ontwerp is nooit in één keer goed.

Valkuilen

• De poort op de agent zetten in plaats van op de actie. Dan is het alles of niets: je remt onschuldig werk af of laat de gevaarlijke handeling door. Scoor en poort per actie.
• Goedkeuringsmoeheid. Te veel poorten en mensen klikken blind "approve". Een poort die altijd wordt goedgekeurd, beschermt niets; haal hem weg of verhoog de drempel. Reserveer de mens voor de acties die het echt verdienen.
• Goedkeuren zonder context. Een knop zonder te tonen wát er wordt goedgekeurd, is schijntoezicht. Zet de actie en de parameters in het goedkeuringsbericht, zodat de beslissing inhoudelijk is.
• Geen timeout of fallback. Een flow die eeuwig hangt of na de wachttijd alsnog uitvoert, is gevaarlijker dan geen poort. Ontwerp het geen-reactie-pad expliciet.
• Een poort die alleen ja/nee vraagt waar aanpassen nodig is. Soms is de actie bijna goed; dan wil je de parameters kunnen wijzigen, niet alleen afkeuren. Kies daar de controle-terug-vorm, niet een kale bevestiging.
• Eigenaarloze poorten. Een verzoek dat in een ongelezen kanaal belandt, is geen toezicht. Wijs per poort een mens aan en stuur naar een kanaal dat hij echt leest.

Kant-en-klaar vs. maatwerk

De drie routes verschillen vooral in hoeveel maatwerk de poort aankan en hoeveel je zelf beheert.

Voor de meeste organisaties is de no-code route het verstandige begin: de meeste poorten zijn een Approve-of-Disapprove-knop op het juiste kanaal, en die bouw je in n8n of Make in een middag. Zit je al diep in een agent-platform, gebruik dan zijn ingebouwde bevestiging, dan zit het toezicht het dichtst op de agent. Maatwerk loont pas als je acties, rollen en escalatieregels zo specifiek zijn dat de standaard knoppen je in een keurslijf duwen, en dan nog bouw je het bovenop dezelfde logica: scoren, een niveau kiezen, pauzeren, een mens laten beslissen, en een fallback voor als niemand reageert.

Wat je ook kiest, de volgorde blijft gelijk. Een mens-in-de-lus is geen vangnet dat je er achteraf onder hangt, maar een ontwerpkeuze die je vóór de eerste productie-actie maakt: per actie weet je of hij vrij mag rollen, of hij eerst langs een mens moet, en wat er gebeurt als die mens zwijgt. De agents die straks het meeste werk uit handen nemen, zijn niet de meest autonome, maar die waarvan je precies weet waar jij de teugels houdt.