Een van onze klanten — een productiebedrijf met een middelgroot ERP — rolde een AI-agent uit voor orderverwerking. De eerste drie weken liep hij uitstekend: hij groepeerde aanvragen, controleerde beschikbaarheid en genereerde voorstellen. Toen kwam een geval dat niet in de trainingsdata zat — een klant met een afwijkende betalingsconditie. De agent schatte de situatie in als standaard en bevestigde de order. Zonder goedkeuring. Zonder escalatie. Met onjuiste voorwaarden.
Het was niet bij de agent opgekomen om te stoppen en te vragen. Hij had er geen regels voor.
Dit is geen argument tégen AI-agents. Het is een argument vóór doordacht human-in-the-loop (HITL)-ontwerp — een set regels die bepaalt wanneer een agent zelfstandig handelt en wanneer hij op een mens wacht. Dit artikel is een praktisch beslisraamwerk: waar de grens te trekken, hoe u een approval flow technisch implementeert en hoe u de autonomie van een agent stapsgewijs en veilig uitbreidt.
Waarom HITL geen "veiligheidspleister" is
De meest voorkomende fout bij het ontwerpen van agents: HITL wordt achteraf toegevoegd als filter. De uitvoer van de agent — een beslissing, een actie, een document — passeert een goedkeuringsvenster, en als een mens op "OK" klikt, gaat het verder.
Deze aanpak lost alleen het symptoom op. U ziet niet wat de agent daarvóór deed. U weet niet of de beslissing logisch voortvloeide uit de juiste stappen, of dat de agent via een verkeerde route tot het juiste resultaat kwam. En als er iets misgaat, is de audit trail leeg.
Correct HITL is een architectuurpatroon, geen toevoeging. U definieert het vóór de uitrol, niet na het eerste incident. Het omvat:
- Classificatie van acties naar mate van risico en onomkeerbaarheid
- Expliciete interrupt-punten in de agentgraph — niet alleen bij de uitvoer, maar direct in de beslissingsstroom
- Audit trail van elke stap: wat de agent zag, wat hij besliste, wie het goedkeurde
De EU AI Act vereist in artikel 14 menselijk toezicht voor hoog-risico AI-systemen vanaf 2 augustus 2026. Als uw systeem in deze categorie valt — geautomatiseerde besluitvorming in arbeidsrechtelijke zaken, kredietscore, beheer van kritieke infrastructuur — is HITL geen aanbeveling. Het is een wettelijke verplichting.
Acties die altijd goedkeuring vereisen
Niet elke actie van een agent is even risicovol. Het sleutelcriterium is onomkeerbaarheid: kunt u de actie terugdraaien? Zo niet, dan is goedkeuring verplicht.
Het tweede criterium is reikwijdte van impact: wie wordt geraakt door de actie, hoeveel geld of data staat er op het spel, hoe groot is de regulatoire blootstelling?
Acties waarbij we altijd aanraden te stoppen en goedkeuring te vragen:
- Financiële transacties — betaling versturen, factuur uitschrijven, prijslijst wijzigen, bestelling bij leverancier boven een gedefinieerd limiet
- Onomkeerbare databewerkingen — records verwijderen, backup vóór overschrijven, export naar een extern systeem
- Externe communicatie namens het bedrijf — e-mail aan een klant, reactie op een klacht, juridisch document
- Wijzigingen in systemen van derden — schrijven naar ERP, CRM, SCADA; configuratiewijzigingen in de productieomgeving
- Escalatiebeslissingen met juridische blootstelling — reclamatie afwijzen, contract beëindigen, verplichting accepteren
In de praktijk zien we dat bedrijven deze categorieën aanvankelijk onderschatten. Zolang de agent alleen in een interne sandbox werkt, ziet alles er veilig uit. De problemen komen op het moment dat de agent toegang krijgt tot productietools.
Human-on-the-loop vs. human-in-the-loop
Een belangrijk onderscheid dat het hele ontwerp beïnvloedt:
Human-in-the-loop (HITL) — de agent stopt en *wacht* op goedkeuring vóór hij een actie uitvoert. De stroom is geblokkeerd. De reactietijd hangt af van de beschikbaarheid van de operator. Geschikt voor onomkeerbare of hoog-risico acties.
Human-on-the-loop (HOTL) — de agent handelt autonoom, maar logt elke stap en de operator kan asynchroon ingrijpen. De stroom is niet geblokkeerd. Geschikt voor acties die gemakkelijk omkeerbaar zijn of weinig impact hebben.
De meeste productiesystemen hebben beide modi nodig. Een eenvoudige beslisboom:
- 1.Is de actie onomkeerbaar? → HITL verplicht
- 2.Is de financiële impact boven het limiet (bijv. 1.000 EUR)? → HITL verplicht
- 3.Is er regulatoire blootstelling (AVG, contract, aansprakelijkheid)? → HITL verplicht
- 4.Is de actie routinematig en omkeerbaar? → HOTL volstaat
Dit is geen eenmalige beslissing. De limieten veranderen naarmate de agent een trackrecord en vertrouwen opbouwt.
Technische implementatie: LangGraph interrupt()
De schoonste technische implementatie van HITL voor stateful agents is via LangGraph en het interrupt()-mechanisme. Het principe is eenvoudig: in de agentgraph definieert u knooppunten waarop de stroom pauzeert en wacht op externe input — goedkeuring, correctie of afwijzing.
Het basispatroon:
- De agent verwerkt de input en beslist welke actie hij wil uitvoeren
- Vóór uitvoering bereikt hij het interrupt-knooppunt: slaat de huidige staat op (checkpointing), genereert een beschrijving van de voorgestelde actie voor de operator en wacht
- De operator ontvangt een melding (e-mail, Slack, geïntegreerd UI-paneel)
- Bij goedkeuring wordt de stroom hervat vanaf het exacte checkpoint — de agent onthoudt de volledige context, niet alleen het laatste bericht
- Bij afwijzing of aanpassing ontvangt de agent feedback en kan hij herplannen
De kernfunctie van LangGraph-checkpointing: de agentstaat wordt geserialiseerd naar een persistent opslagmedium. De goedkeuring kan een uur of een dag later komen — de agent "ontwaakt" met de volledige context. Dit is een fundamenteel verschil met de naïeve aanpak, waarbij u de interrupt zelf zou moeten implementeren via een database en Redis.
Voor een betrouwbare audit trail legt elk interrupt-knooppunt vast: agent-ID, tijdstip, voorgestelde actie, tool-argumenten, en later ook de beslissing van de operator en de motivatie.
Hoe agentarchitecturen er in de praktijk uitzien beschrijven we in het artikel AI-agentarchitecturen: ReAct, Plan-and-Execute — wanneer welke kiezen.
Ontwerp van de approval flow
Een goede approval flow heeft drie eigenschappen: contextrijkheid (de operator ziet *waarom* de agent deze actie voorstelt, niet alleen *welke*), snelle reactietijd (hoe langer de agent wacht, hoe meer geblokkeerde taken zich ophopen) en escalatie (als de operator niet reageert binnen een gedefinieerde tijd, escaleert de taak of wordt hij veilig beëindigd).
Aanbevolen structuur van de melding aan de operator:
- Context: Waarop de beslissing is gebaseerd — het oorspronkelijke verzoek, relevante data, stappen vóór de actie
- Voorgestelde actie: Wat de agent precies wil doen, inclusief argumenten (bijv. "500 stuks SKU-4421 bestellen bij leverancier X voor prijs Y")
- Reden: Waarom de agent tot deze beslissing is gekomen
- Alternatieven: Als de agent meerdere opties overwoog, toon ze (helpt de operator bij correctie)
- Acties: Goedkeuren / Afwijzen / Aanpassen met opmerking / Escaleren
Dit is niet alleen een UX-detail. Een operator die alleen "Bevestig actie?" ziet, keurt doorgaans reflexmatig goed. Een operator die de volledige context ziet, neemt een geïnformeerde beslissing — en bouwt tegelijkertijd intuïtie op over waar de agent fouten maakt.
Over beveiliging en guardrails bij agents gaan we uitgebreider in op het artikel Guardrails voor AI-agents.
Vertrouwen vs. snelheid: de centrale afweging
HITL heeft een prijs. Elk interrupt-punt voegt latency toe — wachten op menselijke reactie kan minuten of uren duren. Als een agent tien stappen heeft en elk stap wacht op goedkeuring, is het systeem geen agent meer. Het is een formulierworkflow met een AI-façade.
Vertrouwen in een agent is daarom een schaalbare variabele, geen binaire beslissing.
Een praktisch raamwerk voor het stapsgewijs uitbreiden van autonomie:
Fase 1 — Schaduwmodus (shadow mode): De agent stelt acties voor, maar een mens voert ze altijd uit. Er worden data verzameld: hoe vaak had de agent het juist, waar maakte hij fouten, wat was de context van de fouten. Duur: 2–4 weken of 100–200 acties.
Fase 2 — Selectieve autonomie: Op basis van de data uit fase 1 definieert u categorieën acties waarbij de agent > 95% nauwkeurigheid had, en laat u die over naar HOTL. U blijft monitoren. Hoog-risico categorieën blijven HITL.
Fase 3 — Beperkte autonomie met limieten: Autonomie in laagrisicocategorieën met expliciete limieten (bijv. bestellingen tot 500 EUR zonder goedkeuring). Elk limiet heeft een motivatie en een revisiédatum.
Fase 4 — Adaptieve autonomie: Het systeem bewaakt de prestaties in real-time. Als het foutenpercentage boven de drempel stijgt, schakelt het automatisch terug naar een restrictiever regime. Als het laag blijft, kan het limiet worden uitgebreid.
Dit is geen eenmalig project. Het is een continu proces van het kalibreren van vertrouwen — vergelijkbaar met het inwerken van een nieuwe medewerker.
De vraag over kosten en return on investment vanuit het perspectief van agents behandelen we in Kosten van een AI-agent in productie.
Wat HITL niet oplost: grenzen van de aanpak
HITL is noodzakelijk, maar niet voldoende. Enkele zaken die een approval flow op zichzelf niet oplost:
Prompt injection — een aanvaller plaatst instructies in de input van de agent (bijvoorbeeld in een verwerkt document), die de agent uitvoert zonder dat dit zichtbaar is in het goedkeuringsvenster. De operator ziet een "normale" actie, terwijl er een gemanipuleerde stroom achter zit. OWASP LLM Top 10 plaatst prompt injection op de eerste plaats in productie.
Te brede toolset — als een agent toegang heeft tot een te brede set tools, beschermt HITL alleen bij acties die expliciet zijn gemarkeerd. Acties buiten het expliciet bewaakte bereik kunnen buiten het zicht vallen. Oplossing: principe van minimale rechten voor elke tool.
Goedkeuringssnelheid als bottleneck — als één operator tientallen verzoeken per dag goedkeurt, daalt de kwaliteit van zijn beslissingen. Routinematige verzoeken worden reflexmatig goedgekeurd, echte anomalieën glippen door. HITL moet worden aangevuld met triage: niet elke goedkeuring is even belangrijk.
Agentdrift — de prestaties van een agent veranderen in de loop van de tijd als de data of de promptingcontext wijzigt. Een actie die zes maanden geleden veilig autonoom was, kan vandaag risicovol zijn. Revisiédata voor limieten zijn daarom een verplichting, geen aanbeveling.
Observability van de agent — het bewaken van traces, foutenpercentage en latencies in real-time — is een voorwaarde voor een functionele HITL. Zonder dit weet u niet wanneer drift optreedt. Over tools voor het bewaken van agents schrijven we in Observability van AI-agents.
Praktische aanbevelingen voor uitrol
Op basis van ervaring uit tientallen projecten:
- 1.Begin met volledige HITL voor alle acties. Niet uit voorzichtigheid, maar om data te verzamelen. Zonder geschiedenis kunt u geen geïnformeerde beslissingen nemen over waar autonomie uit te breiden.
- 2.Categoriseer acties expliciet. Laat de lijst van categorieën met gedefinieerd risico en limiet goedkeuren door de proceseigenaar — niet alleen door het IT-team.
- 3.Log alles, niet alleen incidenten. Routinematige goedkeuringen zijn even belangrijk voor trendanalyse als afwijzingen.
- 4.Stel automatische escalatie in. Als de operator niet reageert binnen X minuten, escaleert de taak naar een vervanger of wordt hij veilig beëindigd met een melding. Een wachtende agent mag nooit een productieproces blokkeren.
- 5.Test slechte inputs. Simuleer inputs waarbij de agent mogelijk een problematische actie zou willen uitvoeren. Controleer of de interrupt correct werkt.
- 6.Revisiécyclus elke 3 maanden. Bekijk de goedkeuringsstatistieken. Waar het foutenpercentage laag is en de geschiedenis goed — overweeg autonomie uit te breiden. Waar verrassingen opduiken — aanscherpen.
Veelgestelde vragen
Hebben we HITL ook nodig voor een interne chatbot die alleen vragen beantwoordt?
Als de agent alleen leest en antwoordt — geen tools met schrijftoegang, geen externe acties — is HITL niet noodzakelijk. HOTL volstaat: u bewaakt de uitvoer, stelt content guardrails in en heeft de mogelijkheid om in te grijpen. HITL is relevant daar waar een agent *handelt*, niet alleen *antwoordt*.
Hoe voorkomt u dat operators zonder nadenken goedkeuren?
Twee beproefde technieken: ten eerste, toon de volledige context (waarom de agent de actie voorstelt), niet alleen de actie zelf. Ten tweede, vereis bij kritieke categorieën een korte motivatie van de operator — minstens één zin. Een verplichte motivatie vermindert reflexmatige goedkeuringen drastisch.
Kan HITL een agent te traag maken voor productiegebruik?
Ja, als het slecht is ontworpen. De sleutel is selectiviteit: HITL alleen voor echt hoog-risico acties, al het andere op HOTL. In de praktijk vormt de categorie werkelijk kritieke acties 5–15% van het totale volume bij een typische bedrijfsagent — de rest kan autonoom draaien met monitoring.
Wat als een agent goedkeuring nodig heeft midden in een lange taak — verliest hij dan de context?
Precies daarom is LangGraph-checkpointing belangrijk. De agent serialiseert de staat bij elk interrupt-punt. Als de goedkeuring na een uur of zelfs een dag komt, hervat de agent de stroom vanaf het exacte punt zonder contextverlies. Zonder checkpointing zou u de hele taak opnieuw moeten starten.
Wat is de relatie tussen HITL en de EU AI Act?
Artikel 14 van de EU AI Act vereist menselijk toezicht voor hoog-risico AI-systemen. Vanaf 2 augustus 2026 geldt deze verplichting voor systemen op gebieden als arbeid, onderwijs, kritieke infrastructuur, beheer van toegang tot essentiële diensten en andere. Als uw agent in een van deze categorieën valt, is HITL geen keuze — het is een wettelijke verplichting die u ook via een audit moet kunnen aantonen.
*Een HITL-flow ontwerpen en configureren voor een concrete agent is geen project van weken — het is een architectuurkeuze die de hele levenscyclus van het systeem beïnvloedt. Bij MP Industrial Solutions helpen we bedrijven precies in kaart te brengen waar de grens ligt tussen autonomie en toezicht, een approval flow in te stellen die past bij hun regulatoire omgeving en stapsgewijs vertrouwen op te bouwen in de prestaties van de agent. Als u een uitrol overweegt of een bestaande agent heeft zonder doordacht HITL-ontwerp — neem contact op voor een consultatie.*