Human-in-the-loop: een mens in de lus houden bij een AI-agent

Een autonome AI-agent die continu draait, zijn eigen route kiest en handelt zonder dat hij bij elke stap wordt aangesproken, roept een logische vraag op: op welk moment neemt een mens de controle weer over? Human-in-the-loop is het antwoord op die vraag. Het is geen rem op autonomie, het is een bewust gekozen doorgangspunt, geplaatst daar waar de actie voldoende gevolgen heeft om een validatie te rechtvaardigen.

Definitie in detail

Human-in-the-loop (HITL), letterlijk mens in de lus, is een ontwerpprincipe waarbij een persoon de bevoegdheid behoudt om een door een AI-systeem gegenereerde beslissing of actie te valideren, corrigeren of blokkeren, op een precies punt in het proces, voordat ze een werkelijk effect heeft. Het AI-risicobeheerkader van het NIST (AI Risk Management Framework, AI RMF 1.0) behandelt menselijk toezicht en de verdeling van verantwoordelijkheden tussen mens en AI als governance-elementen die expliciet moeten worden gedocumenteerd, en dat is een gedeelde referentie geworden voor regelgevers en auditors die de AI-governance van een organisatie beoordelen.

Human-in-the-loop moet worden onderscheiden van permanent toezicht. HITL betekent niet dat een mens voortdurend elke stap van een agent bekijkt, wat de autonomie van elk nut zou ontdoen. De omslag speelt zich vooral af wanneer een agent overgaat van een loutere suggestie naar een werkelijke actie: een bericht versturen, een database wijzigen, een workflow activeren. Het gaat om een gericht controlepunt, geplaatst vóór de acties die als het meest gevoelig of het minst omkeerbaar worden beschouwd: een bericht naar een onbekende sturen, een publieke publicatie, een financiële transactie. De rest van het werk van de agent kan in volledige autonomie blijven doorlopen.

Het is een mechanisme naast andere mogelijke vangrails, geen universele vereiste. Afhankelijk van het risiconiveau van een actie kan een organisatie ervoor kiezen om geen enkel punt van menselijke validatie in te stellen, er systematisch een te plaatsen, of de keuze aan de gebruiker over te laten.

Hoe het werkt

In de praktijk wordt een punt van menselijke validatie op een precies moment in een geautomatiseerde flow ingevoegd. De AI (of de agent) bereidt een actie voor, maar die wordt in een wachtrij geplaatst in plaats van meteen uitgevoerd. Een persoon ontvangt een melding, bekijkt de voorgestelde inhoud, en kiest ervoor om ze goed te keuren, te wijzigen, of af te wijzen. Pas na deze validatie heeft de actie een werkelijk effect, bijvoorbeeld het daadwerkelijk versturen van een bericht.

Drie elementen onderscheiden een goed punt van menselijke validatie van een louter bureaucratische rem: de timing (de validatie komt op het juiste moment, niet te vroeg en niet te laat om nuttig te zijn), de context die aan de valideerder wordt gegeven (hij moet genoeg hebben om te kunnen oordelen, niet enkel een knop om te klikken zonder informatie), en de reikwijdte (alleen echt gevoelige acties passeren dit filter, niet het volledige werk van de agent, anders wordt hij onbruikbaar).

Concreet voorbeeld met Atako

Bij Atako heeft het best gedocumenteerde mechanisme voor menselijke validatie betrekking op het versturen van koude e-mails, wat cold send wordt genoemd, een bericht naar iemand met wie de agent nog geen lopend gesprek heeft. Voor dit kanaal bestaan drie modi: de modus approval, standaard ingeschakeld, plaatst elke verzending in een wachtrij voor menselijke validatie voordat ze daadwerkelijk vertrekt; de modus auto verstuurt onmiddellijk zonder herlezing, met een waarschuwing in de interface om deze keuze te signaleren; de modus disabled verhindert dat de agent een koude e-mail verstuurt, hij kan dan alleen nog antwoorden in al lopende gespreksdraden. Antwoorden in een bestaand gesprek passeren nooit een validatie, alleen het eerste contact is betrokken.

Een tweede gedocumenteerd voorbeeld betreft de use case release-communicator, een agent die aankondigingen van nieuwe functies opstelt en op meerdere kanalen publiceert. Voor grote releases wordt de validatie van de inhoud vóór publicatie daar beschreven als optioneel aan mensenkant, een keuze die aan het team wordt overgelaten in plaats van een door het platform opgelegde verplichting.

Buiten deze twee gedocumenteerde mechanismen bestaat er geen generieke poort voor menselijke validatie die automatisch op elke actie van een Atako-agent zou worden toegepast. Het principe blijft: validatiepunten richten op de plaatsen waar de actie gevolgen heeft, in plaats van systematisch te blokkeren.

Veelgemaakte fouten

Een klassieke fout is human-in-the-loop verwarren met permanent toezicht. HITL vraagt niet dat een mens elke stap van een agent bewaakt, wat neer zou komen op het tenietdoen van het hele nut van automatisering. Het is een precies doorgangspunt, geen continue controle.

Tweede fout: een punt van menselijke validatie op te veel acties tegelijk plaatsen. Een systeem dat voor elke microbeslissing om validatie vraagt, wordt uiteindelijk genegeerd of omzeild, omdat de persoon die geacht wordt te valideren klikt zonder echt te herlezen. Het is beter om validatie voor te behouden aan acties met grote impact of weinig omkeerbaarheid.

Derde fout: denken dat het ontbreken van een expliciete vermelding van een validatiemechanisme in de documentatie betekent dat er geen enkele controle bestaat. Er moet onderscheid worden gemaakt tussen expliciete menselijke validatie (een mens moet klikken opdat de actie vertrekt) en andere vangrails die stroomopwaarts gelden, zoals permissies of quota, zonder dat daar telkens rechtstreekse menselijke tussenkomst voor nodig is.

Ten slotte is het denken dat human-in-the-loop onverenigbaar is met de autonomie van een agent een kaderingsfout. Een goed ontworpen autonome agent combineert beide: ruime autonomie voor het grootste deel van zijn werk, en gerichte validatiepunten voor de beslissingen die dat verdienen.