Human-in-the-loop workflows: het deel dat iedereen overslaat

AI-workflows worden meestal verkocht met de belofte dat de mens uit de loop gaat. De workflows die in productie blijven draaien hebben bijna altijd juist een menselijke stap: op één plek in het proces, met een duidelijke taak en een scherm dat daarvoor gebouwd is.

Ontbreekt die stap, dan krijg je de problemen uit het vorige artikel. Is hij er wel maar slecht ontworpen, dan krijg je een workflow die draait en tijd bespaart, maar vastloopt op iemand die tientallen cases per dag moet beoordelen in een scherm dat daar nooit voor bedoeld was.

Waar de menselijke stap hoort

Drie vuistregels uit de workflows die ik gebouwd heb:

1. Bij onomkeerbare beslissingen

Alles wat geld, klantcommunicatie, contracten of identiteit raakt, of wat lastig terug te draaien is: een retour, een factuur, een mail naar een klant, een wijziging in een CRM-record die de routing beïnvloedt.

Een mens die er tien seconden naar kijkt is goedkoper dan een AI-fout die je niet kunt terugdraaien, zeker als die fout op honderden records tegelijk wordt gemaakt. Ook bij grote aantallen vangt een review-stap op basis van confidence de uitzonderingen af, zonder dat iemand elke transactie hoeft te bekijken.

2. Bij lage confidence

Het model geeft een confidence score. Doet het dat niet uit zichzelf, dan kun je er één afleiden uit de stabiliteit van de output, de log-waarschijnlijkheid van de gekozen klasse of de consistentie over twee runs. Onder een drempel gaat de case naar een mens, erboven gaat hij door.

Dit is het verschil tussen een workflow waarin een mens alles reviewt (langzaam) en een waarin een mens de 5–15% reviewt waar het model niet zeker over is (beheersbaar). Het maakt het reviewwerk ook zinvoller: geen makkelijke cases afstempelen, maar de twijfelgevallen beoordelen waar een menselijk oordeel iets toevoegt.

3. Bij nieuwe data

Krijgt de workflow input die niet lijkt op wat het model eerder zag (out-of-distribution), laat hem dan pauzeren en om een beoordeling vragen. Een nieuw klantsegment, een nieuwe portaal-bron, een nieuwe productlijn: alles waar de trainingsdata geen vergelijkbaar voorbeeld voor heeft.

Dit is lastiger automatisch te detecteren, maar het loont. Zelfs een simpele embedding-distance check tegen je trainingsset vangt de duidelijke gevallen.

De review-UI

Hier gaat het bij de meeste workflows mis. Het model doet zijn werk en de review-stap bestaat, maar het scherm is een database-adminpaneel met een approve- en een reject-knop, en één case beoordelen kost drie minuten.

Een bruikbare review-UI doet vier dingen:

Laat de redenering van het model zien, niet alleen de output. Als het model een lead als "hot" classificeerde, laat dan zien op basis van welke signalen: de woorden in de aanvraag, de bron, het patroon uit de historie. Beoordelen of een redenering klopt gaat sneller dan zelf opnieuw classificeren.

Maak gedeeltelijk corrigeren mogelijk, niet alleen accepteren of afwijzen. Soms klopt de classificatie wel maar de prioriteit niet, of klopt het geëxtraheerde telefoonnummer maar het landnummer niet. Met gerichte correcties past de reviewer alleen aan wat fout is, zonder de hele taak over te doen.

Log elke override. Met genoeg structuur om er iets mee te kunnen: ook zonder het model te hertrainen kun je er de confidence-drempel mee kalibreren, de prompt mee bijstellen of een eval-set mee vullen.

Groepeer vergelijkbare cases. Twaalf keer achter elkaar "is deze lead hot?" beoordelen gaat sneller dan steeds wisselen tussen ongerelateerde taken. Groepeer op type, bron of soort twijfelgeval.

De bottleneck-vraag

Het bezwaar is altijd dat mensen niet schalen. Klopt, maar dat hoeft ook niet. Als het model 90% met hoge confidence afhandelt en een mens de rest in een goed ontworpen scherm beoordeelt, gaan 100 handmatige cases per dag terug naar 10. Nog verder automatiseren, tot er niemand meer meekijkt, is meestal het punt waar de workflow stukgaat en elke stille fout voor eigen rekening komt.

De verdeling die werkt: het model doet het patroonwerk in bulk, de mens beoordeelt de uitzonderingen.

Wie er moet reviewen

Voor sommige beslissingen is de juiste reviewer niet zomaar iemand van de operatie, maar de oprichter of een senior: prijsuitzonderingen, strategische communicatie, alles waar een fout antwoord veel duurder is dan de tijd van die persoon.

Probeer die beslissingen niet goedkoper te maken door ze lager in de organisatie te beleggen. Zorg met het ontwerp van de workflow dat ze zeldzaam zijn, gebundeld binnenkomen en bij de juiste persoon terechtkomen.

In de praktijk

In de meeste workflow-projecten die ik aanneem moet de menselijke stap alsnog worden ingebouwd of gerepareerd. Wat ik vaak bouw:

• Een review-queue bovenop een bestaande classifier, met batching en gedeeltelijke overrides.
• Confidence-scoring op een bestaande model-output, met een routing-regel erbovenop.
• Een "volledig geautomatiseerde" workflow die maandenlang stilletjes verkeerd classificeerde, vervangen door een 90/10-verdeling tussen model en mens.
• De pijplijn die menselijke overrides omzet in bruikbare data voor eval-sets en drempel-kalibratie.

Het is onopvallend werk, maar het bepaalt of een workflow een jaar blijft draaien of elk kwartaal opnieuw gebouwd moet worden.

In de meeste plannen blijft "human-in-the-loop" vaag. Het wordt pas concreet als je kunt zeggen om welke stap het gaat, wie de reviewer is en hoe diens scherm eruitziet.