Goedkeuringsmoeheid (approval fatigue)

Wat is goedkeuringsmoeheid?

Goedkeuringsmoeheid is wat er gebeurt als een systeem zo vaak om een goedkeuring vraagt dat goedkeuren geen beslissing meer is. Het venster verschijnt, de medewerker klikt op ja, in het logboek staat dat een mens akkoord ging, en niemand heeft iets gelezen. De controle staat op papier en bestaat in de praktijk niet meer.

Het is iets anders dan te veel vertrouwen in de machine. Automation bias gaat over het geloof dat je hecht aan wat een systeem oplevert. Goedkeuringsmoeheid gaat over aantallen: je kan perfect wantrouwig staan tegenover de agent en toch door vraag eenendertig van die ochtend klikken zonder dat je ogen bij de tekst blijven hangen. Je ziet het in een logboek staan. Een controlestap die veertig keer per dag afgaat en elke keer wordt goedgekeurd, een seconde nadat ze verscheen, is geen controle. Het is een toetsaanslag die in de procesbeschrijving toevallig een goedkeuring heet.

Waarom agent-tools zoveel goedkeuringen opleveren

Oudere software vroeg een beslissing op het einde van iets. Je vulde een aankoopaanvraag in, je verstuurde ze, iemand keurde ze goed. Één venster, en wat je goedkeurde was een volledige aanvraag die op zichzelf iets betekende.

Een agent haalt een taak uit elkaar in kleine stappen en voert ze een voor een uit, en op elke stap kan een goedkeuringsvraag staan: dit bestand lezen, dit commando draaien, dit bestand aanpassen, deze API oproepen, dit domein bereiken. Een btw-nummer toevoegen aan het klantenformulier en aan de nachtelijke export wordt dertig of veertig tool-oproepen zodra je het rondkijken, de testruns en de verbeteringen meetelt. De tools zijn bewust op dat detailniveau gebouwd. Claude Code vraagt bij shell-commando's op een ingebouwde leeslijst na, Codex splitst het in een goedkeuringsbeleid en een sandbox-modus die je apart instelt, en VS Code vraagt bij bestandswijzigingen, terminalcommando's en externe URL's. Alle drie gaan ze ervan uit dat de mens aan de andere kant elke vraag leest. Bij drie vragen per taak klopt dat. Bij veertig niet meer.

Wat het onderzoek naar herhaalde waarschuwingen aantoont, en wat niet

Gewenning aan een herhaalde waarschuwing is meetbaar en ze zet snel in. Een team van Brigham Young University legde mensen in een fMRI-scanner en toonde hun beveiligingswaarschuwingen. Hun publicatie uit 2015 meldt een scherpe daling in de visuele verwerkingscentra van de hersenen al na de tweede keer, en de ingreep die het afremde was de waarschuwing er telkens anders laten uitzien. Brian Stanton en Mary Theofanos, verbonden aan het Amerikaanse standaardeninstituut NIST, interviewden computergebruikers en noemden wat ze vonden security fatigue: beu zijn om met beveiliging bezig te moeten zijn, wat zich uit in beslissingen ontwijken en de makkelijkste optie nemen. Hun eerste aanbeveling was het aantal beveiligingsbeslissingen dat mensen moeten nemen te beperken.

Ziekenhuissoftware heeft er de langste ervaring mee. Een overzicht uit 2006 in het Journal of the American Medical Informatics Association bracht zeventien studies samen over geneesmiddelenwaarschuwingen in voorschrijfsystemen en stelde vast dat artsen die in 49 tot 96 procent van de gevallen naast zich neerlegden. Die cijfers bewijzen niet dat artsen blind zaten te klikken. De auteurs schrijven er zelf bij dat het negeren vaak terecht is, omdat veel van die waarschuwingen afgaan op combinaties die voor die ene patiënt geen probleem zijn. Een hoog negeerpercentage zegt je dat je waarschuwingen slecht gericht zijn, niet dat de mens gestopt is met lezen.

Wat niemand heeft, is een cijfer voor agent-vragen. Dat onderzoek is nooit op zulke vensters gedaan, dus wie je een drempel geeft voor wanneer een ontwikkelaar stopt met lezen, verzint die.

De vragen uitzetten, en wat de leveranciers daarover schrijven

De noodrem ligt er altijd, en mensen grijpen ernaar na een week of zo. Elk van die tools heeft een instelling die helemaal stopt met vragen. De naam die de gemeenschap eraan gaf is YOLO-modus, en die is blijven plakken: VS Code levert een /yolo slash-commando dat de globale auto-goedkeuring aanzet.

De formulering die de leveranciers eraan hangen is ongewoon direct. Microsoft schrijft dat globale auto-goedkeuring kritieke beveiligingsbescherming wegneemt en het voor een aanvaller makkelijker maakt om de machine over te nemen, en wijst naar een agent-sandbox of een dev container in de plaats. Anthropic houdt het bij één zin voor de bypass-permissions-modus in Claude Code: gebruik die modus alleen in geïsoleerde omgevingen zoals containers of VM's waar Claude Code geen schade kan aanrichten. OpenAI zet bij de vlag die zowel de sandbox als de goedkeuringen wegneemt dat ze niet aangeraden is. Geen van drie zegt dat je de vragen nooit mag uitzetten. Ze zeggen dat de vragen één van twee grenzen zijn, en dat je de andere nodig hebt als je deze laat vallen. Die andere is isolatie. De positie waar niemand documentatie voor schrijft, is de tussenpositie: vragen staan aan, worden ongelezen weggeklikt, en er is nergens een sandbox. Dat geeft je een beveiligingsmodel met niets erachter en een audit trail die het tegendeel beweert.

Achtendertig vragen voor één taak, en de twee die telden

Een ontwikkelaar bij een bedrijf van dertig man vraagt aan een coding agent om een btw-nummer toe te voegen aan het klantenformulier, het op te slaan en het mee te nemen in de nachtelijke export. In een manuele rechtenmodus loopt dat zo: de testen draaien, de entiteit aanpassen, het formuliertype aanpassen, een migratie genereren, die op de lokale databank draaien, de template aanpassen, de exportservice aanpassen, de test aanpassen, de cache leegmaken, opnieuw testen, drie stukgelopen bestanden herstellen, nog eens testen, klaarzetten, committen. Achtendertig vragen, en de meeste daarvan waren een wijziging of een commando dat die ochtend al vier keer was goedgekeurd. Twee ervan konden echt geld kosten: de migratie, want die verandert een databank, en de commit met de push, want dat is het moment waarop het werk de machine verlaat.

Het herontwerp bestaat uit vier instellingen en kost tien minuten. Zet de veilige, zich herhalende commando's op een allowlijst, want de testrunner, de linter, de cache leegmaken, git status en git diff liepen samen elf keer en het antwoord was altijd ja. Stop met elke bestandswijziging in de werkmap apart af te toetsen, want achttien wijzigingen een voor een goedkeuren zijn achttien kansen om te stoppen met lezen, geen achttien controles. Zet een expliciete ask-regel op de migratie en op de push. En richt de hele run op een lokale kopie van de databank, zodat een foute migratie een verloren namiddag is en geen incident.

Er blijven twee vragen over, en die worden gelezen, omdat het de enige twee van die dag zijn en omdat ze zeggen wat er verandert. Niet dat de agent doctrine:migrations:migrate wil draaien, maar dat dit drie migraties op je lokale databank uitvoert en er één kolom bij komt. Buiten een terminal geldt hetzelfde. Als je boekhoudagent een handtekening wil voor elk van de negen stappen bij het inboeken van één aankoopfactuur, is de oplossing één goedkeuring op de afgewerkte boeking.

Ontwerpkeuzes die het aantal vragen omlaag halen

De maatregelen die werken, veranderen wat er gevraagd wordt of hoe vaak. Geen enkele vraagt aan de mens om zich beter te concentreren.

• Maak de eenheid groter. Één goedkeuring op een stuk werk dat iemand in één zin kan beschrijven: deze factuur ingeboekt, deze pull request, deze reeks prijswijzigingen.

• Zet de veilige en zich herhalende handelingen op een allowlijst. Wat je vijf keer na elkaar hebt goedgekeurd zonder je antwoord te veranderen, hoeft niet meer te vragen. Laat de onderbrekingen over aan de handelingen die er recht op hebben.

• Zeg wat er verandert, niet welke functie er draait. Dit verwijdert 340 rijen uit orders, of dit stuurt 62 klanten een mail, is iets waarover iemand in die twee seconden kan oordelen. Een toolnaam met zijn argumenten geeft hem dat niet.

• Bundel de controle in één diff. Laat het werk afmaken en toon dan de volledige wijziging op één scherm dat de mens één keer leest. Ontwikkelaars houden elkaar voor code al aan die norm.

• Maak de gevaarlijke handelingen onmogelijk in plaats van afgeraden. Een venster voor een destructief commando vraagt aan de mens om voorzichtig te zijn. Een sandbox zonder productiegegevens erin is een muur, en achter een muur hoef je niemand te onderbreken.

Veel kleine goedkeuringen tegenover één goedkeuring op een stuk werk

De twee verschillen op de dimensie die de rest bepaalt: leest de mens echt wat hij goedkeurt? Elk klein venster is één oproep met zijn argumenten en kost een seconde om te overlopen, en die seconde is echt, de eerste drie keer. Tegen de twintigste is het venster de vorm waar je doorheen drukt om weer aan het werk te kunnen, en de stap die je goedkeurt zegt op zich toch niets over de uitkomst. Een wijziging aan een formulierklasse goedkeuren leert je niets over de vraag of de functionaliteit klopt.

Een diff over elf bestanden kost twee minuten, en die maken mensen wel vrij, omdat het één keer gebeurt en omdat ze naar de uitkomst kijken. De val aan die kant is te ver gaan. Een diff van vierhonderd bestanden op het einde van een week wordt even weinig gelezen als die achtendertig vensters, en is erger, want ze ziet er grondig uit. De juiste maat is de grootste die iemand nog in zijn hoofd houdt, en dat is ongeveer wat op twee schermen past.

Wat een ongelezen goedkeuring betekent voor je toezicht

Artikel 14 van de Europese AI Act vraagt dat een hoog-risicosysteem zo ontworpen is dat mensen er doeltreffend toezicht op kunnen houden, en artikel 26 legt de uitvoering bij de gebruiksverantwoordelijke, en dat is het bedrijf dat zo'n systeem koopt. De term menselijk toezicht werkt beide artikelen uit. Geen van beide zegt hoeveel vragen te veel is. Allebei maken ze duidelijk dat het toezicht doeltreffend moet zijn, en een goedkeuring die niemand leest is dat niet. Hier keert je audit trail zich tegen je: een logboek vol goedkeuringen met een tijdstempel één seconde na het verschijnen van de vraag bewijst geen controle die is uitgevoerd, het is een gedateerd bewijs van het tegendeel, gemaakt door je eigen systeem.

Je hoeft geen toezichthouder af te wachten om dit te meten. Kijk één iemand een uur aan het werk en tel de vragen die een gewone taak oplevert. Een handvol betekent dat het ontwerp klopt. Dertig betekent dat het ontwerp fout zit en dat wie erdoor klikt zich gedraagt zoals iedereen zich zou gedragen. Twee cijfers maken het beeld af: hoe vaak iemand nee antwoordt, en hoe lang hij erover doet. Een weigeringspercentage rond nul en een antwoordtijd onder de twee seconden zijn dezelfde vaststelling, twee keer opgeschreven.