human-in-the-loop is de verkeerde benadering voor AI

Human-in-the-loop klinkt alsof wij gewoon een hulpmiddel voor AI zijn. Ik zie iemand aan het eind van een proces zitten die output van een model leest. De meeste AI-producten verkopen dat verhaal: automatisering draait, daarna valideert een mens. Codingmodellen geven je een diff, LLM's herschrijven copy vanuit een prompt. De interface is meestal afgestemd op snelheid, waardoor de mens eerder een stempelmachine wordt dan een kritische beoordelaar. Dat wringt juist als fouten duur zijn of als je moet begrijpen wat je hebt opgeleverd, dus eigenlijk bijna altijd, en ik zie veel mensen die workflow vertrouwen omdat het zo'n handige manier is om het eerste deel van een project zo snel mogelijk af te ronden.

Verschillende startpunten

Laat ik uitleggen wat die twee richtingen nou eigenlijk betekenen. Human-in-the-loop (HITL) is het label voor valideren of corrigeren nadat automatisering heeft gedraaid, zoals AI-gegenereerde code checken voor een merge. AI-in-the-loop (AITL) is eigenlijk iets dat we al kenden, alleen noemden we het vroeger gewoon een suggestie: het model stelt voor, de mens beslist.

Dit roept voor mij veel vragen op, zijn de modellen van nu wel goed genoeg om de leiding te nemen? Is de HITL-aanpak wel de juiste en kunnen we verwachten dat mensen kritisch genoeg blijven als AI het voortouw neemt? Willen mensen überhaupt output van een systeem valideren, of zoeken ze iets uitdagenders in hun werk? Veel werk vraagt dat iemand het resultaat echt begrijpt, zodat de volgende persoon niet blijft hangen met wijzigingen die niet te doorgronden zijn.

In de praktijk

Tijdens mijn project voor Triodos Bank testte ik beide benaderingen om het gedragsverschil te begrijpen. Triodos werkt met gevoelige financiële en klantdata, dus het is extreem belangrijk dat alle data 100% klopt. In de test moesten gebruikers data valideren met zowel de HITL- als AITL-benadering.

Gebruikers hadden echt het gevoel dat HITL sneller was, wat logisch is, je hoeft vooral output te bevestigen in plaats van zelf iets in te dienen. Maar de kritische validatie bleef beperkt, mensen scanden meer dan dat ze echt reviewden. Voor mij laat dat precies het probleem zien: als iets te handig voelt, valideren gebruikers minder zorgvuldig. Dat lijkt op het moment productief, maar doet pijn op de lange termijn, bijvoorbeeld in rapportages, of bij code, waar verkeerde patronen kunnen eindigen in een codebase die niet meer te onderhouden is.

De AITL-aanpak liet totaal ander gedrag zien, gebruikers kwamen eerst zelf met een oplossing en gebruikten AI daarna als validator. Ze duwden vaker terug op modelsuggesties en zorgden ervoor dat wat uiteindelijk werd ingevoerd ook echt klopte. Ze leunden dus veel minder op AI-modellen, en in dit project is dat belangrijker dan snelheid. Deelnemers rapporteerden minder tijdswinst, maar ze zeiden wel dat ze de uitkomsten meer vertrouwden en merkbaar meer controle hadden.

Niet altijd slecht

Ik geloof niet dat er geen scenario's zijn waarin human-in-the-loop prima kan werken, sterker nog, Brian Lovin van Notion legt uit dat hij AI gebruikt om snel nieuwe ideeën te prototypen en te testen in een echte productomgeving. Dat vind ik een goed voorbeeld van waar tools zoals code agents prima werken, niet voor een definitieve uitkomst, maar om gedrag van gebruikers te begrijpen in een echte context, niet op een Figma-canvas.

Dat heb ik binnen dit Triodos-project ook gedaan. Door de complexiteit van de productcase zou een Figma-prototype geen realistische omgeving zijn. Daarom gebruikte ik Onlook AI om snel een prototype te bouwen. Tegenwoordig kun je bijvoorbeeld ook Figma MCP combineren met Claude Code, Cursor of een andere tool die je fijn vindt, die workflow is de afgelopen twee jaar een stuk makkelijker en nauwkeuriger geworden richting design. Maar het blijft belangrijk om te beseffen dat AI-first output op de lange termijn problemen kan veroorzaken als je die direct als eindresultaat shipt.