In het eerste deel van onze serie stelden we de fundamentele vraag: wanneer moet een mens AI stoppen?
In het tweede deel analyseerden we de autonomie van agenten en probeerden we te beantwoorden hoe ver we AI autonoom mogen laten opereren.
In het derde deel gingen we naar organisatieniveau en spraken we over AI-governance, verantwoordelijkheid, veiligheid, monitoring en controleregels.
Nu is het tijd om al deze elementen te verbinden.
Want je kunt een geweldige AI-strategie hebben. Je kunt goede procedures hebben. Je kunt de beste ingenieurs aannemen. Je kunt het beste model kiezen. Maar uiteindelijk draait alles om één vraag: Hoe bouw je een systeem dat voldoende autonoom is om echt waarde te leveren, maar tegelijk voldoende gecontroleerd is om geen onacceptabel risico te vormen?
Dit is een van de belangrijkste uitdagingen bij het ontwerpen van next-generation AI-systemen. Hier wordt Human-in-the-Loop meer dan een simpele "klik op Akkoord"-functie. Het wordt een onderdeel van de hele systeemarchitectuur.
AI mag niet als een "black box" ontworpen worden
Stel je een klassiek systeem voor:
- De gebruiker stuurt een verzoek.
- Het AI-model analyseert de data.
- Het model genereert een antwoord.
- De gebruiker ontvangt het.
Dat kan voldoende zijn voor een simpele chatbot.
Maar de situatie verandert volledig wanneer AI toegang krijgt tot bedrijfssystemen.
Bijvoorbeeld:
- AI leest een bericht van een klant.
- Het herkent de intentie.
- Het controleert de bestelgeschiedenis.
- Het analyseert de productbeschikbaarheid.
- Het stelt een oplossing voor.
- Het verzendt een antwoord.
- Het start een reclamatieprocedure.
- Het initieert een terugbetaling.
- En vervolgens werkt het CRM bij.
Dat is geen enkelvoudig AI-model meer.
Het is een systeem dat acties uitvoert in de echte wereld.
Daarom moet de architectuur niet alleen het model omvatten, maar de gehele keten: data → model → beslissing → tools → actie → resultaat → monitoring
Als een onderdeel van deze keten slecht is ontworpen, kan het systeem een verkeerde beslissing nemen of — erger nog — deze automatisch uitvoeren.
Autonomie mag geen aan/uit-schakelaar zijn
Een van de grootste fouten in AI-ontwerp is denken: "Of de mens doet alles, of AI doet alles."
In de praktijk hebben we veel meer niveaus nodig.
We kunnen ons een model van autonomie voorstellen:
Niveau 0 - de mens doet alles
AI voert geen acties uit. Het kan alleen als informatiehulpmiddel worden gebruikt.
Voorbeeld: een programmeur vraagt AI hoe een probleem op te lossen.
AI antwoordt.
De programmeur analyseert zelf het antwoord en implementeert de oplossing.
Niveau 1 - AI analyseert
Het systeem verzamelt en verwerkt informatie. De mens neemt de beslissing.
Voorbeeld: AI analyseert documentatie en bereidt een samenvatting voor.
De mens beoordeelt het resultaat zelf.
Niveau 2 - AI adviseert
Het systeem analyseert de situatie en stelt een handeling voor. De mens keurt goed.
Voorbeeld: AI detecteert een verdachte transactie en adviseert extra verificatie.
Niveau 3 - AI bereidt actie voor
AI bereidt niet alleen de beslissing voor, maar maakt alle elementen gereed om deze uit te voeren. De mens keurt goed.
Voorbeeld: een agent bereidt een klantantwoord, een CRM-update en een kortingsvoorstel voor.
Een medewerker keurt alles goed.
Niveau 4 - AI handelt autonoom binnen bepaalde grenzen
Het systeem kan zelfstandig beslissingen nemen en acties uitvoeren, maar alleen binnen vastgestelde regels.
Voorbeeld: de agent kan zelf de leverdatum met één dag verschuiven als de klant die optie heeft geaccepteerd.
Hij kan echter niet de contractvoorwaarden wijzigen.
Niveau 5 - AI handelt volledig autonoom
Het systeem analyseert, besluit en handelt zelfstandig. De mens blijft verantwoordelijk voor toezicht op het gehele systeem.
Zo’n niveau van autonomie moet uiterst terughoudend worden toegepast.
Niet omdat AI nooit zelfstandig zou mogen handelen. Maar omdat hoe groter de autonomie, hoe groter de gevolgen van een mogelijke fout.
Belangrijkste regel: autonomie moet proportioneel zijn aan het risico
Er is geen universele regel: "AI moet altijd menselijke toestemming hebben."
Dat kan de voordelen van automatisering volledig vernietigen.
Stel je een systeem voor dat duizenden routinematige handelingen afhandelt. Als elk handmatig goedkeuring vereist, wordt de mens de bottleneck.
Aan de andere kant: "AI mag alles zelfstandig doen"
is ook een slecht idee.
Daarom moet de beslissing over het niveau van autonomie op risico gebaseerd zijn.
Je kunt onder andere analyseren:
- potentiële schade,
- kosten van een fout,
- omkeerbaarheid van de actie,
- impact op mensen,
- financiële impact,
- juridische impact,
- gevoeligheid van data,
- mogelijkheid om een fout te detecteren,
- tijd nodig om te reageren.
Dat leidt tot een heel praktische regel:
Hoe hoger het risico en hoe moeilijker de consequentie te herstellen, hoe groter de menselijke betrokkenheid in het proces moet zijn.
Omkeerbare versus onomkeerbare acties
Een nuttige criterium is het onderscheid tussen omkeerbare en onomkeerbare acties.
Omkeerbare acties
Bijvoorbeeld:
- wijzigen van taakvolgorde,
- genereren van een conceptdocument,
- opstellen van een antwoordvoorstel,
- opzetten van een campagne-ontwerp.
Als AI een fout maakt, kan een mens deze makkelijk herstellen.
In dergelijke gevallen kun je meer autonomie toestaan.
Moeilijk omkeerbare acties
Bijvoorbeeld:
- uitvoeren van een betaling,
- verwijderen van data,
- ondertekenen van een contract,
- wijzigen van belangrijke systeemparameters,
- versturen van juridisch belangrijke informatie,
- beslissingen die mensenrechten raken.
Hier moet het niveau van controle veel hoger zijn.
Een eenvoudige maar effectieve ontwerpregel:
AI mag meer vrijheid hebben waar fouten makkelijk terug te draaien zijn.
Human-in-the-Loop, Human-on-the-Loop en Human-in-Command
Het is nuttig om drie benaderingen te onderscheiden.
Human-in-the-Loop
Een mens neemt direct deel aan het besluitvormingsproces.
AI adviseert.
De mens keurt goed.
Dit is geschikt voor processen met hoger risico.
Human-on-the-Loop
AI handelt zelfstandig, maar de mens monitort het systeem en kan ingrijpen.
Dit model is geschikt voor repetitieve en goed gedefinieerde processen.
Voorbeeld: het systeem optimaliseert automatisch taakvolgordes.
De mens keurt niet elke wijziging goed.
Hij monitort wel de uitkomsten en kan de controle overnemen.
Human-in-Command
De mens behoudt strategisch toezicht.
Hij controleert niet elke individuele beslissing.
Maar is wel verantwoordelijk voor:
- werkprincipes,
- reikwijdte van autonomie,
- doelen van het systeem,
- beperkingen,
- verantwoordelijkheid,
- mogelijkheden om het systeem te stoppen.
Dit is vooral belangrijk voor grote autonome systemen.
Human Override - de mens moet controle kunnen overnemen
Als een systeem autonoom kan handelen, moet de mens in staat zijn de controle over te nemen.
Dat is precies Human Override.
Het mechanisme kan er verschillend uitzien.
Het kan zijn:
- handmatige goedkeuring,
- onderbreken van het proces,
- annuleren van een actie,
- intrekking van een beslissing,
- overschakelen naar handmatige modus,
- de agent de toegang tot tools ontzeggen.
Belangrijk is dat het geen louter theoretisch mechanisme is.
Als een mens "de controle kan overnemen" maar daar 48 uur voor nodig heeft terwijl de agent binnen enkele seconden handelt, dan is dat problematisch.
Human Override moet: beschikbaar, snel en daadwerkelijk effectief zijn.
Fail-Safe - wat gebeurt er als AI onzeker is?
Een goed ontworpen systeem moet niet veronderstellen dat AI altijd gelijk heeft. Het moet aannemen dat het soms fouten maakt.
Daarom hebben we een Fail-Safe-mechanisme nodig.
Als het systeem:
- niet genoeg data heeft,
- een lage confidence heeft,
- tegenstrijdige informatie detecteert,
- een situatie buiten zijn bereik tegenkomt,
- de actie niet volgens de regels kan uitvoeren,
dan moet het niet geforceerd beslissen.
Het moet zeggen: "Ik weet het niet." — en de zaak aan een mens overdragen.
Dit kan een van de belangrijkste kenmerken van een volwassen AI-systeem zijn: niet het vermogen om op elke vraag te antwoorden, maar het vermogen te herkennen wanneer er geen antwoord gegeven zou moeten worden.
Confidence Score - met voorzichtigheid
In AI-systemen komt het begrip confidence level vaak voor.
Het systeem kan aangeven: "Mijn aanbeveling heeft 95% confidence."
Dat klinkt goed. Maar wees voorzichtig.
Het confidence-niveau van een model betekent niet altijd de kans dat het antwoord correct is. Een model kan erg zeker lijken en toch fout zitten.
Daarom moet de confidence score worden gezien als één signaal, niet als absolute waarheid.
Je kunt het wel gebruiken om het proces te ontwerpen.
Bijvoorbeeld:
- hoge confidence + laag risico = automatisering,
- gemiddelde confidence = aanbeveling voor een mens,
- lage confidence = verplichte escalatie.
Dat maakt een dynamische Human-in-the-Loop mogelijk.
Niet elke beslissing vereist een mens. Maar elke beslissing moet een vast escalatiepad hebben.
Dynamische Human-in-the-Loop
Dit is een interessante richting in AI-ontwerp.
In plaats van een vaste regel: "Elke beslissing wordt door een mens goedgekeurd"
maken we de regel: "De mens verschijnt wanneer het systeem verhoogd risico detecteert."
Bijvoorbeeld:
Een klantenservice-agent kan standaardvragen zelfstandig beantwoorden.
Als de klant naar de verzendstatus vraagt, antwoordt de agent.
Als de klant het adres wil wijzigen, kan de agent de operatie uitvoeren volgens regels.
Als de klant een groot terugbetalingsbedrag eist, draagt het systeem de zaak over aan een mens.
Bij juridische dreiging → escalatie.
Als het systeem de intentie van de klant niet begrijpt → escalatie.
Op deze manier controleert de mens niet alles. De mens controleert wat echt menselijke beoordeling vereist.
Een agent moet alleen de rechten hebben die hij echt nodig heeft
Dit is een van de belangrijkste veiligheidsprincipes. Als een agent een taak moet uitvoeren, moet hij alleen de minimale benodigde rechten krijgen.
Niet: "geef hem toegang tot het hele CRM omdat het misschien handig is."
Maar: "de agent heeft leesrechten op klantgegevens en de mogelijkheid om een ticket aan te maken."
Dit is in cyberbeveiliging bekend als Least Privilege — minimale privileges.
Als een agent gecompromitteerd raakt of een fout maakt, is de schaal van de schade hierdoor beperkt.
Dit is vooral belangrijk in agentgebaseerde architecturen.
Een agent die kan:
- data lezen,
- data schrijven,
- berichten verzenden,
- betalingen uitvoeren,
- systeemconfiguraties wijzigen,
is potentieel erg gevaarlijk.
Daarom moet elke mogelijkheid als een tool met een bepaald risiconiveau worden behandeld.
Tool Calling - een agent mag geen onbeperkte toegang hebben
Moderne AI-agenten gebruiken vaak externe tools.
Het model kan bijvoorbeeld aanroepen:
- API's,
- databases,
- ERP-systemen,
- CRM,
- search-engines,
- betalingssystemen.
Dat is veel macht — maar ook veel risico. Daarom moeten tool-aanroepen gecontroleerd worden.
Het systeem moet weten:
- wie een bepaald tool mag aanroepen,
- welke argumenten toegestaan zijn,
- welke waarden acceptabel zijn,
- of menselijke toestemming vereist is,
- hoe de actie wordt gelogd.
Een agent kan toegang hebben tot de functie: create_invoice
maar mag niet automatisch toegang hebben tot: delete_all_invoices
Dat klinkt logisch.
Maar juist daarom moet je systemen ontwerpen met het slechtst denkbare scenario in gedachten.
Guardrails als veiligheidsarchitectuur
Guardrails moeten op meerdere niveaus werken.
Guardrails voor data
Welke informatie mag de agent lezen?
Guardrails voor acties
Welke operaties mag hij uitvoeren?
Financiële guardrails
Tot welk bedrag mag hij autonoom handelen?
Tijdgebonden guardrails
Wanneer mag hij operaties uitvoeren?
Gebruikers-guardrails
Voor welke klanten mag hij acties uitvoeren?
Risico-guardrails
Welke acties vereisen goedkeuring?
Zo krijgt de agent niet zomaar toegang tot systemen.
Hij krijgt een gecontroleerde set mogelijkheden.
AI-agent als digitale medewerker?
Dat is een populaire metafoor. Een AI-agent kan als een digitale werknemer worden beschouwd. Maar er is één fundamenteel verschil.
Een medewerker heeft:
- ervaring,
- context,
- intuïtie,
- besef van verantwoordelijkheid.
Een agent heeft:
- een model,
- data,
- tools,
- instructies,
- beperkingen.
Daarom mogen we agenten niet ontwerpen volgens het principe: "Zeg hem wat hij moet doen en kijk wat er gebeurt."
Een agent moet duidelijk gedefinieerd hebben:
- doel,
- reikwijdte van activiteiten,
- toegang tot data,
- toegang tot tools,
- niveau van autonomie,
- succescriteria,
- escalatievoorwaarden,
- stopvoorwaarden.
Hoe autonomer het systeem, hoe meer het op een bedrijfsprocesbesturingssysteem gaat lijken — en hoe meer architectuur het nodig heeft.
Architectuur van een veilig AI-systeem
We kunnen ons een systeem voorstellen dat uit meerdere lagen bestaat.
Laag 1 - data
Databronnen van de organisatie.
ERP.
CRM.
CMS.
Databases.
Documenten.
API's.
Laag 2 - AI-modellen
Taalmodellen, voorspellende modellen en andere AI-componenten.
Laag 3 - orkestratie
De logica die bepaalt wat er stap voor stap gebeurt.
Laag 4 - agent
Het systeem analyseert de situatie en plant acties.
Laag 5 - tools
De agent kan bepaalde API's en functies gebruiken.
Laag 6 - guardrails
Het systeem controleert wat de agent mag doen.
Laag 7 - Human-in-the-Loop
In bepaalde gevallen gaat de beslissing naar een mens.
Laag 8 - monitoring
Het systeem monitort het gedrag en de kwaliteit van beslissingen.
Laag 9 - audit trail
Alle relevante acties worden geregistreerd.
Laag 10 - emergency controls
Er is de mogelijkheid om het systeem te stoppen of de controle over te nemen. Dit is niet de enige mogelijke architectuur.
Maar het illustreert een belangrijke regel: een veilig AI-systeem is niet alleen een model.
Het is een heel ecosysteem van controlerende mechanismen.
Hoe implementeer je Human-in-the-Loop in de praktijk?
Begin bij voorkeur met een klein proces.
Niet met: "Laten we het hele bedrijf automatiseren."
Maar: "Kies één proces waarin AI veilig kan helpen."
Vervolgens:
Stap 1 - identificeer de beslissing
Wat moet AI precies doen?
Stap 2 - bepaal het risico
Wat gebeurt er als het systeem faalt?
Stap 3 - bepaal het autonomielevel
Zal AI:
- analyseren,
- aanbevelen,
- een actie voorbereiden,
- of de actie uitvoeren?
Stap 4 - definieer escalatievoorwaarden
Wanneer moet de mens de controle overnemen?
Stap 5 - ontwerp guardrails
Welke handelingen zijn verboden?
Stap 6 - beperk privileges
Welke tools zijn echt nodig?
Stap 7 - ontwerp monitoring
Hoe detecteren we fouten?
Stap 8 - ontwerp Human Override
Hoe stopt een mens het systeem?
Stap 9 - test noodscenario's
Wat gebeurt er als:
- de API uitvalt,
- data fout zijn,
- het model verkeerd antwoordt,
- een gebruiker kwaadaardige instructies geeft,
- de agent een ongewenste actie uitvoert?
Stap 10 - verhoog autonomie pas daarna
Eerst observatie, daarna aanbevelingen, vervolgens beperkte automatisering, en pas uiteindelijk meer autonomie.
Dat is aanzienlijk veiliger dan vanaf dag één volledige autonomie in te voeren.
De meest voorkomende fout: we automatiseren een proces dat we niet begrijpen
Dit probleem beperkt zich niet tot AI. Het geldt voor elke automatisering.
Als een proces slecht is ontworpen, kan automatisering ertoe leiden dat het sneller werkt.
Maar sneller is niet altijd beter.
We kunnen zo een: automatisering van chaos creëren.
AI vergroot dan alleen de schaal van het probleem.
Daarom is het belangrijk om vóór implementatie te vragen: Is het proces dat we willen automatiseren echt goed ontworpen?
Zo niet, ordent eerst het proces. Pas daarna voeg je AI toe.
Belangrijkste ontwerprichtlijn voor AI-systemen
Ontwerp AI niet zodat hij nooit fouten maakt. Dat is onrealistisch.
Ontwerp het zodat: fouten detecteerbaar, begrensbaar en te herstellen zijn.
Dat is het fundamentele verschil. Een volwassen AI-systeem is geen foutloos systeem; het is een foutbestendig systeem.
Checklist voor veilig Human-in-the-Loop
Voor implementatie is het goed om de volgende vragen te beantwoorden:
☐ Weten we welke beslissingen AI neemt?
☐ Kennen we de kosten van een potentiële fout?
☐ Is de beslissing omkeerbaar?
☐ Hebben we het niveau van autonomie bepaald?
☐ Heeft AI alleen de noodzakelijke rechten?
☐ Bestaan er guardrails?
☐ Weet de mens wanneer hij moet ingrijpen?
☐ Kan het systeem de zaak aan een mens overdragen?
☐ Bestaat er Human Override?
☐ Bestaat er een noodstopsysteem?
☐ Worden acties gelogd?
☐ Monitoren we de kwaliteit van acties?
☐ Kunnen we Model Drift detecteren?
☐ Weten we wie verantwoordelijk is voor het systeem?
☐ Hebben we een incidentresponsprocedure?
☐ Hebben we noodscenario's getest?
Als we op de meeste vragen "ja" kunnen antwoorden, zijn we veel dichter bij een volwassen AI-implementatie.
Woordenschat
Human-in-the-Loop
Model waarin een mens direct deelneemt aan het besluitvormingsproces en bepaalde AI-acties goedkeurt.
Human-on-the-Loop
Model waarin AI zelfstandig opereert, terwijl een mens het systeem monitort en kan ingrijpen.
Human-in-Command
Model waarin de mens verantwoordelijk blijft voor doelen, regels, reikwijdte van autonomie en algemeen toezicht op het systeem.
Human Override
Mechanisme waarmee een mens de controle over het AI-systeem kan overnemen of de actie kan annuleren.
Fail-Safe
Veiligheidsmechanisme waarbij het systeem bij onzekerheid of storing naar een veilige toestand schakelt in plaats van risicovolle acties voort te zetten.
Guardrails
Beperkingen die het bereik van acties van AI bepalen.
Least Privilege
Principe van het toekennen van slechts die rechten aan het systeem die nodig zijn voor zijn taak.
Tool Calling
Mechanisme waarmee een AI-model gebruikmaakt van externe tools, API's en systemen.
Kill Switch
Mechanisme voor het snel uitschakelen van het systeem.
Audit Trail
Logboek van acties dat later herstel van de operatiegeschiedenis mogelijk maakt.
Model Drift
Achteruitgang van modelprestaties als gevolg van veranderingen in data of omgeving.
Confidence Score
Indicator die het niveau van vertrouwen van het model in een resultaat aangeeft. Het moet niet automatisch gelijkgesteld worden aan de kans dat het antwoord correct is.
Samenvatting van de hele serie
In vier delen hebben we de reis gemaakt van een eenvoudige vraag: "Moet de mens AI controleren?"
naar een veel complexere vraag: "Hoe ontwerp je een systeem waarin mens en AI veilig kunnen samenwerken?"
Het antwoord is niet: "De mens moet alles goedkeuren."
Het is ook niet: "AI moet volledig autonoom zijn."
De beste oplossing ligt tussen deze extremen.
AI moet zoveel autonomie krijgen als echt nodig is. De mens moet aanwezig zijn waar zijn kennis, verantwoordelijkheid, ervaring en beoordeling de meeste waarde toevoegen.
Het systeem moet weten wanneer het moet handelen, wanneer het moet vragen en wanneer het moet stoppen. En de mens moet altijd weten hoe de controle terug te krijgen.
Dat is de volwassen benadering van Human-in-the-Loop.
Het gaat er niet om dat een mens boven AI staat en elke individuele beslissing goedkeurt. Het gaat om het creëren van een architectuur waarin autonomie gecontroleerd is, verantwoordelijkheid duidelijk is toegewezen, risico gemonitord wordt en de mens daadwerkelijk kan ingrijpen.
Want de toekomst van AI behoort misschien niet uitsluitend toe aan organisaties die de meest autonome systemen bouwen.
Misschien behoort het toe aan diegenen die het beste leren de grens te beheren tussen machinautomatie en menselijke verantwoordelijkheid.
En misschien zal de belangrijkste vraag in het tijdperk van AI-agenten niet zijn: "Hoeveel mogen we AI laten doen?"
Maar: "Hoeveel mogen we AI laten doen, terwijl we volledige controle houden over de gevolgen van haar acties?"
Die vraag zal bij elke belangrijke AI-implementatie terugkomen.
En hoe autonomer systemen worden, hoe belangrijker het is om het antwoord te kennen voordat de agent zijn eerste beslissing neemt.
