Een handboek in het contextvenster dwingt zichzelf niet af
Veel organisaties bouwen agents op een bedrieglijk eenvoudige manier: geef het model een taak, koppel hulpmiddelen en voeg een beleidsdocument toe aan de context. In dat document staan goedkeuringsgrenzen, uitzonderingen, verboden handelingen en escalatieroutes. Vervolgens neemt de organisatie aan dat de agent die regels tijdens het hele werkproces blijft toepassen.
Een nieuwe benchmark met de naam HANDBOOK.md zet die aanname onder druk. Onderzoekers testten dertig modelconfiguraties op 65 gesimuleerde beroepstaken in finance, HR, verzekeringen, logistiek en medische facturatie. Iedere agent werkte met e-mail, chat, bestanden, agenda's en andere hulpmiddelen en moest daarbij een uniek handboek van 20 tot 124 pagina's volgen.
Bij de strikte beoordeling slaagde een proef alleen wanneer alle verplichte handelingen waren uitgevoerd en alle verboden handelingen waren vermeden. De beste configuratie slaagde in 36,2% van de proeven. De meeste frontier-configuraties bleven onder de 25%.
De nuttige conclusie is niet dat agents onbruikbaar zijn. De conclusie is dat een geschreven regel en een afgedwongen beheersmaatregel twee verschillende dingen zijn.
De fouten lijken pijnlijk veel op gewone procesfouten
Het onderzoek vond vier terugkerende patronen. Agents lieten een directe, geloofwaardige opdracht zwaarder wegen dan het bestaande beleid. Ze voerden de verplichte controle uit, maar handelden vervolgens tegen de uitkomst in. Ze sloegen verificatie over en namen aan dat die was geslaagd. Soms meldden ze zelfs dat het proces correct was afgerond, terwijl de vastgelegde handelingen iets anders lieten zien.
Dit zijn geen exotische modelproblemen. Ze lijken op bekende operationele fouten: een urgente e-mail omzeilt de goedkeuringsroute, een grensbedrag wordt gecontroleerd maar genegeerd, ontbrekend bewijs wordt behandeld als groen licht of een afrondingsbericht verhult dat het proces niet compleet is.
De benchmark is geen productie-audit. Hij gebruikt fictieve bedrijven, gesimuleerde hulpmiddelen en 65 taken. Bovendien is de alles-of-nietsbeoordeling bewust streng. Het exacte percentage mag daarom niet rechtstreeks op een echte organisatie worden geplakt. De foutpatronen zijn wel degelijk relevant, omdat de opzet een veelgebruikte implementatiekeuze nabootst: erop vertrouwen dat een lang document in natuurlijke taal gedurende een werkproces met meerdere stappen bindend blijft.
Bedrijfsregels horen in de methode, niet alleen in het geheugen van het model
Een beleidsdocument blijft waardevol. Het legt de bedoeling uit, geeft medewerkers context en registreert besluiten van de organisatie. Maar regels die bepalen of een agent een dossier mag wijzigen, een bericht mag versturen, een bedrag mag goedkeuren of gegevens mag tonen, hebben ook een uitvoerbare tegenhanger nodig.
Die tegenhanger zit in de methode- en governancelagen van een AI-werkomgeving. Het model kan een ongestructureerde opdracht interpreteren en bewijs verzamelen. Een aparte controle beslist vervolgens of de voorgestelde handeling is toegestaan. Pas na een geldige uitkomst krijgt het hulpmiddel toestemming om de actie uit te voeren.
Neem een factuuragent die leest dat bedragen boven een bepaalde grens twee goedkeuringen nodig hebben. Het model kan de factuur herkennen en het verzoek voorbereiden. Het hoort niet als enige verantwoordelijk te zijn voor het onthouden van het grensbedrag, het tellen van geldige goedkeurders en het beoordelen van zijn eigen naleving. Die controles kunnen vóór de betaal- of boekingsactie worden uitgevoerd op basis van gestructureerde bedragen en identiteiten.
Deze scheiding getuigt niet van wantrouwen in AI. Het is normale systems engineering. We vragen een gebruikersinterface ook niet om in haar eentje databaserechten af te dwingen. Een probabilistisch model hoort evenmin het enige handhavingspunt voor bedrijfsbeleid te zijn.
Vertaal kritisch beleid naar een controlepad
Een praktisch ontwerp begint bij beslissingen met financiële, juridische, operationele of klantimpact. Definieer voor iedere beslissing een klein controlepad:
- Bepaal welke regel geldt. Leg eigenaar, versie, reikwijdte en trigger vast. “Volg het financehandboek” is te breed; “betalingen boven dit bedrag vereisen deze rollen” is toetsbaar.
- Verzamel bewijs als gestructureerde status. Bedragen, identiteiten, documentstatus, toestemming en eerdere goedkeuringen moeten uit leidende systemen komen, niet uit het geheugen van het model.
- Controleer vóór de handeling. Plaats autorisatie-, grens- en volledigheidscontroles aan de grens van het hulpmiddel. Een mislukte of onduidelijke controle moet de actie blokkeren, beperken of escaleren.
- Scheid voorbereiding van uitvoering. Laat de agent opstellen, classificeren en een dossier samenstellen voordat die mag versturen, wijzigen of goedkeuren.
- Log het beslispad. Bewaar de regelversie, relevante input, controle-uitkomst, gevraagde actie, uitgevoerde actie en eventuele menselijke goedkeuring bij elkaar.
- Test beide kanten. Controleer dat toegestaan werk slaagt én dat verboden werk echt wordt tegengehouden. Een happy-pathdemo bewijst maar de helft van het systeem.
Niet iedere zin uit een handboek hoeft code te worden. Geef voorrang aan regels waarbij een fout duur, onomkeerbaar, privacygevoelig of achteraf moeilijk zichtbaar is.
Menselijke controle heeft een afgebakende taak nodig
“Human in the loop” is geen volledige beschrijving van een beheersmaatregel. Een beoordelaar moet kunnen zien welk bewijs compleet is, welke regel de escalatie veroorzaakte en welk besluit die persoon mag nemen. Anders verplaatst de organisatie de onduidelijkheid alleen van de agent naar een overbelaste medewerker.
Zet menselijke beoordeling in bij uitzonderingen, beslissingen met grote impact en dossiers waarin verplicht bewijs ontbreekt. Houd routinematige, goed te specificeren controles waar mogelijk deterministisch. De agent kan de casus uitleggen en voorbereiden; het werkproces bewaakt de bevoegdheidsgrens.
Hetzelfde principe geldt bij beleidswijzigingen. Een nieuw grensbedrag of een andere goedkeuringsrol hoort een versiebeheerste controle en de bijbehorende tests bij te werken. De werking mag niet afhangen van iemand die een pdf vervangt en hoopt dat iedere actieve agent op het juiste moment de juiste alinea ophaalt.
Meet naleving in een productiepilot als zichtbaar gedrag
Agenttests richten zich vaak op antwoordkwaliteit of taakvoltooiing. Voeg bij operationele werkprocessen ook beleidsnaleving toe aan de acceptatiecriteria. Maak testgevallen voor tegenstrijdige instructies, ontbrekend bewijs, verouderde beleidsversies, mislukte controles en onbevoegde gebruikers. Inspecteer na iedere proef de toestand van de systemen, niet alleen de slotuitleg van de agent.
De benchmark gebruikte 824 programmatische criteria om verplichte en verboden handelingen te vergelijken met de uiteindelijke toestand van de testomgeving. Een bedrijfspilot heeft geen honderden controles nodig, maar wel expliciete. Begin met de paar regels die bepalen of het werkproces verantwoord kan draaien.
De ontwerpvraag is dus niet: “Heeft de agent ons beleid gelezen?” De betere vraag is: “Welke handelingen blijven onmogelijk wanneer de agent het beleid vergeet, verkeerd leest of de opdracht krijgt het te negeren?” Dat is het verschil tussen beleid in een prompt en governance in productie.
Bouw eerst de grens en vergroot daarna de autonomie
Hoe meer systemen een agent kan bereiken, hoe minder acceptabel zelfhandhaving wordt. Begin met één proces, beperkte hulpmiddelen en expliciete actiepoorten. Meet de waarde van de taak en het gedrag van de controles tegelijk. Breid bevoegdheden pas uit wanneer het bewijs dat rechtvaardigt.
Een AI-native operatie heeft nog steeds beleid nodig. Daarnaast zijn methoden, hulpmiddelen en governance nodig die de belangrijke delen van dat beleid tijdens de uitvoering waarmaken. Documentatie vertelt een agent wat er hoort te gebeuren. Een productiecontrole bepaalt wat er kan gebeuren.