Keurt niemand de actie van een AI-agent op tijd goed, dan mag die actie niet doorgaan. Het verzoek verloopt, het logboek legt dat vast, en wie morgen alsnog op de oude goedkeuring klikt, verstuurt niets. Verandert de actie terwijl ze wacht, dan is er een nieuw verzoek nodig.
Een goedkeuringspoort is het controlepunt waar een agent moet wachten op toestemming van een benoemde persoon voordat hij iets verstuurt, betaalt, verwijdert of publiceert. De payload is de exacte inhoud van de actie: ontvangers, tekst, bedrag en doel. Het time-outbeleid bepaalt wat er gebeurt als de beoordelaar niet reageert.
Een platformlimiet is geen goedkeuringsbeleid
Een time-out is een besluit, geen standaardinstelling. Laat je het aan het platform over, dan heb je ook besloten; het staat alleen nergens zwart op wit.
Microsoft Power Automate beperkt een flow-run tot 30 dagen, gerekend vanaf de start van de run en inclusief openstaande stappen zoals goedkeuringen. Na 30 dagen krijgen openstaande stappen een time-out (Microsoft Learn). Vraag je pas na 25 dagen om goedkeuring, dan laat die limiet hooguit vijf dagen over.
De OpenAI Agents SDK (Python) pauzeert een run zodra een tool goedkeuring nodig heeft, en laat je de gepauzeerde toestand opslaan en later hervatten (handleiding human-in-the-loop). Volgens de handleiding moet de server voorkomen dat gelijktijdige of herhaalde inzendingen dezelfde momentopname twee keer hervatten. De handleiding raadt ook aan een versiemarkering op te slaan als goedkeuringen een tijd kunnen blijven liggen. Een deadline voor openstaande goedkeuringen vond ik in de handleiding niet.
Geen van beide bepaalt hoe lang deze specifieke actie open mag blijven voor goedkeuring, of wat een laat antwoord nog mag doen. Dat is jouw beleid, en dat hoort op papier te staan.
Vier statussen, en verlopen is niet afgekeurd
Geef elk verzoek één van vier statussen. Dit is een voorgesteld technisch ontwerp, geen leveranciers-API en geen formele standaard.
| Status | Wat het betekent | Wat de agent mag |
|---|---|---|
| Open | Wacht op een besluit, vóór de deadline | Wachten. De actie niet uitvoeren. |
| Goedgekeurd | Een benoemde persoon zei op tijd ja tegen precies deze versie | Alleen de goedgekeurde versie uitvoeren, zolang de goedkeuring geldig is. |
| Afgekeurd | De persoon zei nee | De reden vastleggen en stoppen. Een herziene actie is een nieuw verzoek. |
| Verlopen | De deadline is verstreken zonder besluit | Stoppen. Een nieuw verzoek starten als het werk nog nodig is. |
Afgekeurd betekent dat iemand de actie heeft beoordeeld en geweigerd. Verlopen betekent dat niemand erover heeft geoordeeld. Allebei blokkeren ze de uitvoering, maar de vervolgstap verschilt: een afgekeurde actie moet je herzien, een verlopen verzoek wijst op de deadline, de routering of de werklast van de beoordelaar. Gooit de geschiedenis die twee op één hoop, dan raak je dat signaal kwijt. Een late klik heropent geen van beide.
Leg ook vast hoe lang een goedkeuring geldig blijft voordat de actie wordt uitgevoerd. Een tijdige ja mag de actie niet onbeperkt toestaan. Houd de uitvoeringsgeschiedenis gescheiden van de goedkeuringsstatus: ‘goedgekeurd’ betekent niet ‘verstuurd’. Leg elke poging en de uitkomst ervan vast, herhaalpogingen inbegrepen.
Waarom keur je de exacte actie goed en niet een samenvatting?
Een goedkeuring hoort de actie, het doel, de versie van de payload, de reikwijdte, de beoordelaar en de deadline te benoemen. ‘Verlengingsherinnering aan Acme’ is een samenvatting. De definitieve onderwerpregel, tekst en ontvangerslijst zijn wat de persoon moet goedkeuren. Verandert daar ook maar iets aan, dan mag de oude knop ‘Goedkeuren’ de herziene actie niet toestaan.
De diefstal bij Bybit laat zien wat een gewijzigde payload kan kosten, al ging het niet om AI of een time-out. In februari 2025 startte de cryptobeurs een transactie via de webinterface van Safe{Wallet}. Het onderzoek van Sygnia beschrijft hoe de aanvallers die transactie manipuleerden en de payload wijzigden (Sygnia). De FBI schreef de diefstal van ongeveer 1,5 miljard dollar aan virtuele activa toe aan Noord-Korea (FBI).
Voor een goedkeuringspoort haal je er één les uit: de goedkeuring hoort bij de payload die wordt uitgevoerd, niet bij wat het beoordelingsscherm toonde. Bewaar de goedgekeurde payload, of een vingerafdruk ervan. Controleer bij uitvoering of de goedkeuring nog geldig is en of de payload overeenkomt. Maak die controle onderdeel van de uitvoeringsstap zelf, zodat er tussendoor niets kan veranderen.
Uitgewerkt voorbeeld: de mededeling die na de deadline veranderde
Dit voorbeeld is verzonnen. Een agent bereidt een mededeling aan leveranciers voor over een geplande onderbreking van de dienstverlening. De operationeel verantwoordelijke moet de ontvangerslijst en de definitieve tekst goedkeuren voordat er iets de deur uitgaat.
- 15.00 uur. Verzoek A bevat versie 1 van de mededeling en verloopt om 16.00 uur Nederlandse tijd. De verantwoordelijke vertrekt zonder ernaar te kijken.
- 16.00 uur. Niemand heeft gereageerd. Verzoek A krijgt de status ‘verlopen’. Er gaat niets de deur uit.
- 16.10 uur. Een collega voegt een ontvanger toe en verschuift het tijdvak van de onderbreking. Dat is versie 2, dus die wordt een nieuw open verzoek B, met een eigen deadline en de wijzigingen gemarkeerd. B erft de goedkeuringslink van A niet.
- De volgende ochtend. De verantwoordelijke opent de melding van gisteren en klikt bij verzoek A op ‘Goedkeuren’. De poort meldt dat A verlopen is, verstuurt niets en verwijst naar verzoek B, waar het nieuwe tijdstip en de extra ontvanger zichtbaar zijn.
Een test moet twee dingen aantonen: de status is veranderd, en er is niets geprobeerd. Een scherm met ‘al afgehandeld’ zegt weinig als de server erachter stilletjes de oude goedkeuring heeft geaccepteerd. Bekijk de verzoekgeschiedenis en de uitvoeringslogs bij hetzelfde verzoek-ID.
Wat doe je met nieuwe pogingen, herstarts en plaatsvervangers?
Nieuwe pogingen. Krijgt een verzending een time-out, dan weet het systeem misschien niet of die is aangekomen. Die onzekerheid is geen toestemming om nog eens te versturen. Gebruik een idempotentiesleutel als het ontvangende systeem die ondersteunt, zodat het een nieuwe poging van dezelfde actie herkent. De documentatie van Stripe zegt bijvoorbeeld dat je met idempotentiesleutels een verzoek veilig opnieuw kunt proberen zonder dezelfde handeling twee keer uit te voeren, en dat een herhaalde sleutel met andere parameters een foutmelding geeft (Stripe). De sleutel gaat over dubbelingen, niet over toestemming: een gewijzigde actie heeft nog steeds een nieuw verzoek nodig.
Herstarts. Sla de deadline en de status op bij het verzoek zelf, niet in het geheugen van een draaiend proces. Na een herstart moet het systeem nog weten dat een verzoek verlopen is.
Plaatsvervangers. Leg vooraf vast wie de plaatsvervanger is en wat die mag goedkeuren. Een doorgestuurde melding maakt niemand goedkeurder, en door omleiden komt een verlopen verzoek niet weer tot leven.
Vijf tests voor je goedkeuringspoort
Gebruik een testomgeving. Vervang de echte actie door een onschuldige logregel, maar laat de controles op goedkeuring en uitvoering staan. Controleer eerst of een geldige goedkeuring die regel oplevert; anders zegt een leeg logbestand weinig.
| Test | Wat je doet | Geslaagd als |
|---|---|---|
| 1. Stilte | Laat een verzoek onbeantwoord tot na de deadline | De status is ‘verlopen’. Er is geen poging tot uitvoeren. |
| 2. Late klik | Klik op ‘Goedkeuren’ bij het verlopen verzoek | Het blijft verlopen. Er volgt geen uitvoeringspoging. Een eventueel actueel verzoek vraagt om een nieuwe beoordeling. |
| 3. Gewijzigde payload | Wijzig de ontvangers terwijl het verzoek openstaat, gebruik dan de oude goedkeuring | De oude goedkeuring wordt geweigerd. Een nieuw verzoek toont wat er is veranderd. |
| 4. Dubbele levering | Keur één keer goed en stuur daarna het startsein twee keer | De actie wordt precies één keer uitgevoerd. |
| 5. Herstart | Herstart de worker met een verlopen verzoek in de opslag | Het verzoek is na de herstart nog steeds verlopen. |
Een poort die voor een van deze tests zakt, is een herinneringssysteem: het helpt iemand iets op te merken, maar beslist niet of de actie door mag. Herstel elke fout voordat je op de poort vertrouwt. Een geslaagde test laat zien hoe de poort zich in die test gedroeg, niet dat hij elke fout aankan.
Hoe past dit bij mens in de lus?
Wat betekent mens in de lus? definieert de benoemde persoon die het werk kan afkeuren. HITL in AI-workflows zet die persoon op de onomkeerbare stap en geeft elke schrijf-tool een kaart met een regel voor de vervaltermijn. Mens op de lus gaat over de zwakkere rol van een monitor die de volgende run kan stoppen, maar deze run niet kan afkeuren. Wat een agent nooit mag doen gaat over de override-doctrine: de uitgeschreven lijst van besluiten die een agent nooit mag nemen. Deze pagina beantwoordt één smallere vraag: wat er gebeurt als de benoemde persoon niet op tijd reageert.
Probeer dit vandaag (20 minuten)
Gebruik deze sessie voor test 1 en 2: stilte en de late klik. Je hebt een testomgeving nodig waarin je de deadline kunt inkorten en de uitvoeringslogs kunt lezen.
- Minuut 0–5: isoleer de poort. Vervang de actie door een onschuldige logregel. Noteer de gedocumenteerde wachttijdlimiet van het platform, als die er is, en stel voor de test een goedkeuringsdeadline van één minuut in.
- Minuut 5–8: controleer of een gewone goedkeuring werkt. Keur een nieuw verzoek goed vóór de deadline. Controleer dat er precies één logregel verschijnt, herkenbaar aan het verzoek-ID.
- Minuut 8–12: laat een verzoek liggen. Maak een tweede verzoek aan en bewaar de goedkeuringslink. Bekijk na de deadline de opgeslagen status en de uitvoeringslogs. Verwacht: verlopen, zonder poging tot uitvoeren.
- Minuut 12–16: gebruik de oude link. Klik op ‘Goedkeuren’ bij het verlopen verzoek. Controleer opnieuw: het moet verlopen blijven, zonder uitvoeringspoging.
- Minuut 16–20: leg het resultaat vast. Bewaar het verzoek-ID, de deadline, de statusgeschiedenis en het bewijs uit de uitvoering. Toets ze aan één regel: ‘Bij de deadline verloopt het verzoek en wordt er niets uitgevoerd. Een late klik doet niets.’
Kost de opzet de hele sessie, noteer de test dan als niet uitgevoerd. Kunnen de logs het resultaat niet aantonen, noteer het dan als niet geverifieerd. Herstel elke fout, draai de controle opnieuw en werk daarna test 3 tot en met 5 af.
Citeer deze pagina:Zonder tijdige goedkeuring mag je AI-agent niets uitvoeren.Len P. van der Hof. https://lenvanderhof.com/nl/blog/menselijke-goedkeuring-timeout-test/ ·