n8n Human in the Loop: zo voorkom je dat iedereen in Slack een AI-agent goedkeurt

n8n human in the loop laat een AI-agent sinds versie 2.35 een actie voorleggen aan een mens voordat hij hem uitvoert: Approve of Deny, met de exacte invoer erbij. Dat voelt meteen veiliger. Tot je ontdekt dat n8n's eigen documentatie het met zoveel woorden zegt: een lege goedkeurlijst laat iedereen die het bericht kan zien goedkeuren, ook een stagiair of een externe partij in het kanaal. Hieronder: wat er precies nieuw is, welke twee instellingen het verschil maken, en waar het misgaat met een echte configuratiefout.

Wat is er nieuw: n8n human in the loop is geen verstopte instelling meer

Tot n8n 2.35 (11 augustus 2026) zaten de interessante onderdelen van deze functie achter een experimentele feature flag. De release notes zijn daar expliciet over: "Enhanced human-in-the-loop (HITL) approval options are now enabled for everyone using the Slack and Telegram nodes." De instellingen om te beperken wie mag reageren, wie goedkeurde vast te leggen, en te bepalen wat er na de beslissing gebeurt, staan sindsdien gewoon in het menu in plaats van achter een vlag die je zelf moest omzetten.

Los daarvan bestaat er een tweede, breder inzetbare laag: de "Human review"-tool die je direct aan een AI Agent-node hangt. Je kiest welke tools van de agent een menselijke review nodig hebben (bijvoorbeeld "stuur e-mail" of "maak terugbetaling aan"), en de agent krijgt die goedkeuring via zeven verschillende kanalen: de ingebouwde n8n-chat, Slack, Discord, Telegram, Microsoft Teams, e-mail of WhatsApp Business. Het bericht naar de reviewer gebruikt de $tool-variabele, die de naam van de tool en de exacte parameters toont die de agent wil gebruiken: geen samenvatting, maar de werkelijke invoer.

Hoe werkt een goedkeuringsstap voor een n8n AI-agent in de praktijk?

Je hangt de Human review-stap tussen de AI-agent en de tool die hij wil uitvoeren. Zodra de agent die tool nodig heeft, pauzeert de workflow, gaat er een bericht naar het gekozen kanaal, en wacht n8n op Approve of Deny. Bij Approve voert de tool de actie uit met precies de invoer die de agent voorstelde; bij Deny gebeurt er niets en krijgt de agent terug dat de aanvraag is afgewezen.

Kies je Slack als kanaal, de meest gebruikte optie en ook het kanaal uit onze eerdere vergelijking tussen n8n en Make, dan loop je automatisch tegen de instellingen hieronder aan.

Capture Who Responded en Restrict Who Can Approve: de twee instellingen die het verschil maken

In de Slack-node, onder Message > Send and Wait for Response, met Response Type op Approval, verschijnt een sectie Advanced Interactivity met twee instellingen die op elkaar inhaken:

• Capture Who Responded. Staat dit uit, dan krijg je gewone link-knoppen: ze openen een n8n-bevestigingspagina in de browser, en de rest van de instellingen hieronder bestaat niet eens. Zet je hem aan, dan worden het Slack-interactieknoppen en registreert n8n wie er klikte.
• Restrict Who Can Approve. Deze instelling verschijnt pas zodra Capture Who Responded aan staat. Je kiest hier de mensen die mogen reageren, met namen of met user-ID's via een expressie. De documentatie is hier letterlijk: "If you leave the approver list empty, anyone who can see the message can approve or decline. In a channel, that's every member."

Dat is de omgekeerde aanname van wat de meeste mensen verwachten. Een lege lijst klinkt als "niemand mag het", maar werkt als "iedereen mag het". De lijst bepaalt bovendien wie kan reageren, niet wie het bericht kan zien: zet je 'm goed, maar post je het verzoek toch in een breed kanaal, dan ziet iedereen daar nog steeds het bedrag en de klantgegevens, ook al kunnen ze niet klikken.

Het mechanisme erachter is eenvoudiger dan het klinkt, en niet typisch voor n8n: Slack's signing secret bewijst dat een klik via Slack kwam, niet dat de klikker gemachtigd is. Een onafhankelijke backend-engineer die een vergelijkbaar Slack-goedkeuringssysteem bouwde, voor het verwijderen van cloudinfrastructuur, vat het zo samen: "authentication is not authorization". De ondertekening is app-breed, dus dat bewijs deelt iedereen die het bericht ziet. Restrict Who Can Approve is de aparte autorisatiecheck die n8n daar bovenop zet. Sla die stap over bij iets dat alleen je eigen team raakt en in een paar minuten te herstellen is. Zet hem wel aan zodra een foute klik geld, een klant of een onomkeerbare actie raakt, en reken erop dat je het kanaal de eerste keer nog moet aanpassen voordat de restrictie ook echt dekt wat je bedoelde.

Waar n8n human in the loop misgaat: de lege goedkeurlijst

Een fictief maar herkenbaar voorbeeld: een webshop bouwt een AI-agent die retourverzoeken afhandelt. Onder de 75 euro keurt de agent zelf goed en stuurt een voucher. Boven de 75 euro, of bij een klacht over een beschadigd product, moet eerst een senior klantenservicemedewerker akkoord geven voordat de agent de terugbetaling aanmaakt.

Het team hangt een Human review-stap voor de tool "Maak terugbetaling aan", kiest Slack en post naar #klantenservice. Response Type staat op Approval, de rest op de standaardwaarden: Capture Who Responded staat uit, dus de knoppen zijn gewone link-knoppen. Het kanaal heeft elf leden: twee seniors, zes medewerkers, twee werkstudenten en één externe uitzendkracht.

De node-uitvoer bij een goedkeuring ziet er zo uit:

{
  "approved": true,
  "respondedAt": "2026-10-03T14:12:09.000Z"
}

Geen veld met wie klikte. Bij een terugbetaling van 340 euro kan niemand achteraf nagaan of dat een senior was of de uitzendkracht die toevallig het eerst reageerde: de stap staat er, zonder het probleem op te lossen.

De reparatie: Capture Who Responded aanzetten, waarna Restrict Who Can Approve verschijnt. Daar komen de twee seniors in met hun Slack user-ID's, Unauthorized Reply wordt "Deze goedkeuring is voorbehouden aan de senior klantenservice, vraag het door", en After Decision blijft op Show Outcome and Remove Buttons zodat een latere klik een "geen actie nodig"-melding krijgt in plaats van een nieuwe beslissing.

De node-uitvoer wordt dan:

{
  "approved": true,
  "respondedAt": "2026-10-03T14:12:09.000Z",
  "responder": {
    "id": "U04B2K8QZ1",
    "name": "Marieke de Boer",
    "username": "marieke.deboer",
    "email": "m.deboer@webshop.nl"
  }
}

Eén stap blijft hierna nog open: het kanaal #klantenservice zelf bevat nog de werkstudenten en de uitzendkracht, die het bedrag en de klantnaam dus nog steeds zien, ook al kunnen ze niet meer klikken. Voor een terugbetaling onder de 75 euro is dat geen probleem; voor de zwaardere gevallen verplaatst het team de aanvraag naar een kleiner kanaal met alleen de twee seniors.

Dit is geen zeldzaam ontwerpfoutje. Op het n8n-forum beschrijft een externe ontwikkelaar hetzelfde patroon: "Most n8n AI workflows handle sensitive actions one of two ways: they run fully automated and hope nothing goes wrong, or they send a Slack message asking someone to approve and then proceed regardless." Die post komt van de bouwer van een eigen, betaalde governance-node, dus niet neutraal over de oplossing, maar de probleembeschrijving klopt: een goedkeuringsknop toevoegen is niet hetzelfde als goedkeuring afdwingen.

De tweede valkuil: een agent die niet weet wat "nee" betekent

Een Deny stopt precies die ene tool-aanroep, niet automatisch de rest van de agent. Beschrijft je systeemprompt niet wat er na een afwijzing moet gebeuren, dan improviseert de agent: hij kan de klant alsnog een geruststellend bericht sturen omdat een volgend node altijd hetzelfde "bevestigd"-bericht verstuurt, onafhankelijk van wat de reviewer besliste. Dat gebeurt niet omdat het model liegt, maar omdat niemand die vertakking heeft gebouwd en de agent niets heeft staan over hoe hij een weigering verwoordt.

n8n's eigen documentatie waarschuwt hier zelf voor onder "System prompt configuration required": zet in het systeemprompt welke tools goedkeuring nodig hebben, wat een afwijzing betekent, en hoe de agent moet reageren. Zonder die regel heeft de agent voor dat pad geen instructie, en vult hij het gat met het meest voor de hand liggende antwoord: doorgaan alsof het gelukt is.

Beslisregel: wanneer heb je n8n human in the loop nodig, en hoe streng?

Is dit wettelijk verplicht?

Soms, en het hangt af van wat de agent precies doet. De EU AI Act verplicht in artikel 14 menselijk toezicht, maar alleen voor AI-systemen die onder een hoogrisicocategorie uit Bijlage III vallen: een mens moet dan de uitkomst kunnen "disregard, override or reverse" en het systeem via een stopprocedure kunnen onderbreken. Een agent die retouren afhandelt of interne taken verdeelt, valt doorgaans niet onder die categorieën, dus de wettelijke plicht geldt dan niet. Wat artikel 14 wel laat zien, is precies het ontwerp dat de Approve/Deny-stap hierboven bouwt. Valt je agent wél onder Bijlage III (bijvoorbeeld bij kredietbeoordeling of personeelsselectie), dan is deze stap geen keuze maar een wettelijke eis.

Wat dit verandert voor een Nederlands team dat met n8n werkt

Heb je al een AI-agent in n8n die iets met gevolgen doet, dan kon je tot voor kort niet eenvoudig afdwingen wie die agent mag afremmen: de restrictie stond verstopt achter een experimentele vlag die vrijwel niemand zelf aanzette. Uit onze Agent Sprints zien we dat de meeste bestaande Send and Wait-nodes bij Nederlandse teams nog op die oude standaard staan, zonder vastgelegde identiteit, gebouwd vóór augustus 2026. Dicht zetten is nu twee instellingen aanzetten, geen nieuwe node of externe tool. Concreet: een team dat drie maanden geleden al "human in the loop" bouwde, heeft daarmee niet automatisch de restrictie die het dacht te hebben.

Probeer dit vandaag

Open één bestaande Send and Wait- of Human review-node in een lopende workflow. Kijk of Capture Who Responded aan staat.

Staat hij uit: zet hem aan, vul Restrict Who Can Approve in met de mensen die echt mandaat hebben, en stuur een testaanvraag naar jezelf. Staat er nu een responder-veld met je naam en ID in de uitvoer, dan werkt de restrictie. Ontbreekt dat veld nog, dan staat Capture Who Responded nog uit op die specifieke node: de instelling staat per node, niet globaal.

Wat je realistisch mag verwachten

Uit onze Agent Sprints zien we dit meestal in 20 tot 40 minuten staan voor de eerste node: het grootste deel van die tijd gaat naar het Slack-app registreren en de signing secret, niet naar de twee instellingen zelf, en die staan bij de meeste teams in één poging goed. Wat vaker een tweede ronde kost, is het kanaal: bij zes tot acht van de tien eerste configuraties staat de aanvraag nog in een kanaal dat groter is dan de groep met mandaat. Het systeemprompt aanscherpen voor het afwijzingspad kost een losse sessie: je ziet eerst hoe de agent zich zonder die regel gedraagt, pas dan weet je wat je moet toevoegen.

Wat dit niet oplost: bestaande workflows met een te ruime of ontbrekende restrictie passen zichzelf niet aan. Je moet elke node met een Send and Wait- of Human review-stap handmatig controleren en bijwerken; een update van n8n verandert niets aan configuratie die je zelf al had staan.

Hoe je na zeven dagen weet of het werkt

• Staat er bij elke goedkeuring uit de laatste tien uitvoeringen een responder-veld? Zo niet, staat Capture Who Responded nog uit op die node.
• Vraag de mensen op de Restrict-lijst: kreeg je deze week een verzoek dat je niet had moeten kunnen goedkeuren, of zag je dat iemand anders ook kon klikken? Eén bevestigend antwoord betekent dat de lijst of het kanaal nog niet klopt.
• Hoe vaak stuurde de agent na een afwijzing toch een bevestiging naar de klant? Nul is het doel. Elke treffer wijst naar een ontbrekende regel in het systeemprompt, niet naar een fout van het model.

Doe dit deze week

1. Inventariseer je bestaande goedkeuringsstappen

   Loop elke workflow met een Send and Wait- of Human review-node langs en noteer per node of Capture Who Responded aan staat en wie er op de Restrict-lijst staat, als die al bestaat.

2. Zet de restrictie aan waar geld, klantdata of een onomkeerbare actie in het spel is

   Vul de echte namen in die mandaat hebben, en verplaats gevoelige aanvragen naar een DM of een klein kanaal in plaats van een brede afdelingschat.

3. Schrijf het afwijzingspad in het systeemprompt

   Beschrijf per tool met een Human review-stap wat "afgewezen" betekent: wat de agent tegen de gebruiker zegt, en of hij een alternatief mag voorstellen of moet stoppen.

Het agent-recept dat vandaag werkt: voeg deze regel toe aan het systeemprompt van elke agent met een Human review-tool: "Als een tool-aanroep wordt afgewezen door een menselijke reviewer, stop dan met die actie. Vertel de gebruiker in gewone taal dat je toestemming nodig had en niet kreeg, en vraag wat hij in plaats daarvan wil. Doe nooit opnieuw een poging met net iets andere invoer zonder dat weer voor te leggen."

Wil je dit met je team uitwerken tot een eigen agent met de juiste goedkeuringsgrenzen? Dat bouw je in de Agent Sprint. Wil je eerst het gesprek voeren over wie in jouw organisatie mandaat heeft om wat goed te keuren, dat hoort in een AI-werksessie.

Bronnen

• n8n, Release notes. Zelf geopend via geautomatiseerde paginatekst-extractie (directe toegang tot docs.n8n.io was deze run door de netwerkblokkade geweigerd). Bron voor n8n 2.35 (11 augustus 2026) en de letterlijke release-tekst over de voor iedereen vrijgegeven HITL-instellingen.
• n8n, Approvals (Slack-node). Zelf geopend via dezelfde methode. Bron voor Capture Who Responded, Restrict Who Can Approve, Unauthorized Reply en de letterlijke waarschuwing over een lege goedkeurlijst.
• n8n, Human-in-the-loop for tools. Zelf geopend via dezelfde methode, pagina laatst bijgewerkt 11 dagen voor publicatie. Bron voor de Human review-tool op AI Agent-nodes, de zeven kanalen, de $tool-variabele en de eis om het systeemprompt aan te vullen.
• n8n Community Forum, How to add real human approval to an n8n AI workflow. Zelf geopend. Forumpost van een externe ontwikkelaar (bouwer van een eigen, betaalde governance-node, dus niet neutraal over de oplossing), gebruikt alleen voor de onafhankelijke beschrijving van het probleem dat veel n8n-workflows doorgaan ongeacht de goedkeuring.
• Regulation (EU) 2024/1689 (AI Act), artikel 14, verbatim tekstmirror op GitHub, rechtstreeks gedownload. Zelf geopend. Bron voor de officiële tekst over menselijk toezicht bij hoogrisico-AI-systemen.
• Boaz Leleina, Building a Slack Approval Workflow That Deletes Cloud Infrastructure, dev.to. Zelf geopend, onafhankelijk van n8n: een backend- en cloud-engineer bouwt een vergelijkbaar Slack-goedkeuringssysteem voor een ander doel (infrastructuur verwijderen) en komt op hetzelfde mechanisme uit. Bron voor het onderscheid tussen Slack's signature-verificatie (bewijst dat een klik via Slack kwam) en autorisatie (bewijst niet wie mag klikken).

Veelgestelde vragen

• Wat is human in the loop in n8n?

  Human in the loop (HITL) in n8n betekent dat een AI-agent een actie voorlegt aan een mens voordat hij hem uitvoert. De agent stuurt een goedkeuringsverzoek naar een kanaal zoals Slack, Telegram of e-mail, met de exacte invoer die hij wil gebruiken. Een mens klikt Approve of Deny, en alleen bij Approve voert n8n de actie uit met die invoer.

• Hoe zet je een goedkeuringsstap in een n8n AI-agent?

  Open de Tools Panel van je AI Agent-node, voeg een Human review-stap toe en koppel daar de tool aan die goedkeuring nodig heeft (bijvoorbeeld "stuur e-mail" of "maak terugbetaling aan"). Kies een kanaal zoals Slack, Telegram of de ingebouwde n8n-chat. Gebruik je Slack, zet dan ook Capture Who Responded aan: zonder die instelling verschijnt Restrict Who Can Approve niet, en kan iedereen die het bericht ziet klikken.

• Wie kan een goedkeuringsverzoek in Slack beantwoorden als ik niets instel?

  Standaard iedereen die het bericht kan zien. Een lege goedkeurlijst in de Slack-node betekent niet "niemand mag het", maar "elk kanaallid mag het". Vul je Restrict Who Can Approve in met specifieke gebruikers, dan kunnen alleen die mensen op Approve of Deny klikken; anderen krijgen een privébericht dat ze niet gemachtigd zijn.

• Werkt n8n human in the loop ook via Telegram of Teams?

  Ja. De Human review-tool voor AI Agent-nodes ondersteunt zeven kanalen: de ingebouwde n8n-chat, Slack, Discord, Telegram, Microsoft Teams, e-mail en WhatsApp Business. Je kunt bovendien een ander kanaal gebruiken voor de goedkeuring dan voor het hoofdgesprek, bijvoorbeeld een gebruiker die met de agent chat via de n8n-chat terwijl de goedkeuring naar een specifieke persoon in Slack gaat.

• Is een menselijke goedkeuring voor AI-agents wettelijk verplicht?

  Alleen voor AI-systemen die onder een hoogrisicocategorie uit Bijlage III van de EU AI Act vallen, zoals kredietbeoordeling of personeelsselectie. Artikel 14 eist dan dat een mens de uitkomst kan negeren, overschrijven of terugdraaien, en het systeem kan stoppen. Voor de meeste alledaagse automatiseringen (retouren, interne taken, klantmails) geldt die wettelijke plicht niet, maar het is wel goede praktijk.