Human-in-the-loop (HITL) is een ontwerppatroon waarbij een systeem op een bepaald punt niet verder kan zonder expliciete menselijke invoer. De persoon beoordeelt, keurt goed, corrigeert of wijst af, en het systeem gaat verder op basis van die reactie.
Waar de term vandaan komt
De term is afkomstig uit besturingssystemen en machine learning, waar een mens nodig was om data te labelen of modeloutput te valideren. In moderne software-engineering is hij breder overgenomen om elk werkproces te beschrijven waarbij automatisering bewust wordt onderbroken voor menselijke beoordeling.
Waarom systemen zo worden gebouwd
Volledige automatisering is niet altijd geschikt. De redenen om een menselijke stap in te voegen vallen doorgaans in een paar categorieën:
- Risico: de gevolgen van een verkeerde actie zijn groot genoeg om een pauze te rechtvaardigen. Een betaling boven een drempelbedrag, een uitrol naar productie, het verwijderen van records.
- Onzekerheid: het systeem heeft weinig vertrouwen in zijn output en signaleert dit in plaats van te raden.
- Regelgeving: sommige domeinen vereisen een menselijke beslissing op grond van wet- of regelgeving. Kredietbeslissingen, medische aanbevelingen, bepaalde gegevensverwerkingsactiviteiten.
- Randgevallen: de invoer valt buiten het bereik waarvoor het systeem betrouwbaar is ontworpen.
Het patroon accepteert een lagere doorvoer in ruil voor minder fouten bij consequentievolle beslissingen.
HITL in AI-ondersteunde systemen
Nu meer productiesoftware modelgegenereerde output verwerkt, of het nu suggesties, samenvattingen, classificaties of acties zijn, is HITL een standaard architectuurbeslissing geworden in plaats van een randgeval.
Een AI coding agent kan een pull request voorstellen, maar een mens beoordeelt en merged het. Een RAG-pipeline kan een antwoord teruggeven, maar een supportmedewerker leest het voordat het wordt verstuurd. Een agentische workflow kan een reeks stappen uitvoeren, maar vereist bevestiging voordat bijwerkingen zoals het versturen van e-mails of het aanpassen van een database plaatsvinden.
De ontwerpvraag is waar in de flow je mensen plaatst en welke informatie je ze meegeeft op dat moment. Of je ze erbij betrekt, is geen vraag meer.
Wanneer een HITL-stap wel of niet werkt
Een menselijk controlepunt werkt alleen als de persoon die het beoordeelt ook daadwerkelijk kan beoordelen wat er voor hem ligt. Dat klinkt vanzelfsprekend, maar in de praktijk mislukt het wanneer:
- De output te lang of te complex is om in de beschikbare tijd te lezen.
- De beoordelaar de domeinkennis mist om fouten te herkennen.
- Goedkeuring een formaliteit is geworden en mensen doorklikken zonder te lezen.
- Het systeem geeft geen toelichting op hoe het tot zijn output is gekomen, waardoor de beoordelaar niets heeft om op te steunen.
Wanneer HITL een stempelformaliteit wordt, geeft het de schijn van toezicht zonder de inhoud. Dat is een serieus engineering- en organisatorisch probleem, niet alleen een UX-kwestie.
Implementatiepatronen
Veelgebruikte aanpakken zijn:
- Goedkeuringswachtrijen: het systeem schrijft een voorgestelde actie naar een wachtrij; een mens verwerkt de items in de wachtrij voordat ze worden uitgevoerd.
- Betrouwbaarheidsdrempels: het systeem verwerkt uitvoer met hoge betrouwbaarheid automatisch en markeert uitvoer met lage betrouwbaarheid voor beoordeling.
- Escalatiepaden: het systeem probeert zelfstandig een oplossing te vinden en escaleert alleen naar een mens als het niet verder kan.
- Audittrails met terugdraaifunctie: het systeem handelt direct maar legt alles vast en biedt de mogelijkheid om binnen een bepaalde periode terug te draaien. Dit is HITL achteraf in plaats van vooraf.
Het juiste patroon hangt af van de latentietolerantie, het risiconiveau en het volume aan beslissingen dat het systeem verwerkt.
De relatie met codereview
Codereview is zelf een HITL-mechanisme dat wordt toegepast op softwarewijzigingen. Nu AI-gegenereerde code een steeds groter deel uitmaakt van wat er wordt gemerged, wordt de reviewstap belangrijker, niet minder. De reviewer is de mens in de loop voor de uitvoer van de coding agent. Wat dit van engineers vraagt is enigszins veranderd; zie wat er is veranderd aan codereview voor meer details.
Waar we op testen
HITL-ontwerp weerspiegelt het oordeelsvermogen van een engineer over waar automatisering moet stoppen en wat een reviewer daadwerkelijk moet kunnen zien. Onze beoordeling kijkt hier direct naar. In Sessie 1 laten prioritering en technisch begrip zien of iemand een probleem kan structureren voordat hij het aanpakt. In Sessie 2 laten AI output verification en judgement by risk zien of ze gepast vertragen wanneer een agent iets consequents produceert, in plaats van het goed te keuren omdat het werkt. Zie hoe we beoordelen.
Korte antwoorden
Is human-in-the-loop hetzelfde als supervised learning?
Niet precies. Supervised learning gebruikt door mensen gelabelde data om modellen te trainen. HITL in engineering verwijst naar runtime-workflows waarbij een persoon moet handelen voordat een systeem verdergaat. De concepten overlappen in active learning-pipelines, maar zijn verder van elkaar te onderscheiden.
Maakt een menselijke stap een systeem veiliger?
Alleen als de reviewer de beslissing zinvol kan beoordelen. Een controlepunt waarbij mensen routinematig goedkeuren zonder te lezen biedt weinig bescherming. De kwaliteit van de menselijke stap is net zo belangrijk als de aanwezigheid ervan.
Wanneer moet een systeem een HITL-stap verwijderen die het eerder had?
Wanneer er bewijs is, doorgaans uit auditlogs of foutpercentages, dat de menselijke stap latentie toevoegt zonder fouten op te sporen. Dat bewijs moet komen uit meting, niet uit aanname.
