Je AI-agenten hebben functieomschrijvingen nodig, geen betere prompts

Vraag een bedrijf wat een nieuwe medewerker crediteurenadministratie mag doen en je krijgt een precies antwoord. Ze werkt met deze systemen en deze leveranciers, en alles boven een goedkeuringslimiet van bijvoorbeeld $10.000 moet door haar manager worden ondertekend. De eerste paar maanden heeft ze een proeftijd. Dat alles staat meestal in een bevoegdhedendelegatietabel die elk jaar door de interne audit wordt gecontroleerd.

Vraag hetzelfde bedrijf wat zijn nieuwe factuuragent mag doen en je krijgt vaak een schermafbeelding van een prompt.

Die kloof baart me meer zorgen dan welke modelbenchmark ook. We nemen digitale arbeidskrachten aan zonder het managementsysteem dat we in een eeuw voor mensen hebben opgebouwd: niemand legt hun bevoegdheden vast, niemand toetst hun beoordelingsvermogen voordat ze aan de slag gaan en niemand heeft geoefend met ze uitschakelen.

Waarom een prompt de klus niet kan klaren

Een prompt beschrijft de bedoeling. Er staat in waarvoor de agent bedoeld is. Maar zelden staat erin wat de agent nooit mag doen, waar zijn grenzen liggen of wanneer hij moet stoppen en de beslissing aan een mens moet overlaten.

En zelfs als een prompt dat wel vermeldt, wordt er niets afgedwongen. Een regel die een agent opdraagt geen terugbetalingen van meer dan $500 uit te voeren, is een verzoek aan een probabilistisch systeem. Geen enkele auditor zou goedkeuren dat we voor een menselijke medewerker als beheersmaatregel zeggen: ‘we hebben het vriendelijk gevraagd’. Ik zie dus niet in waarom we dat voor software wel acceptabel vinden.

Beveiligingsexperts hebben al een naam voor dit resultaat. De OWASP Top 10 voor LLM-toepassingen noemt overmatige handelingsvrijheid als een belangrijk risico, dat voortkomt uit te veel functionaliteit, te ruime machtigingen of te veel autonomie. In gewone taal: het is alsof je een werknemer op dag één de sleutels tot alles geeft. De richtlijnen van OWASP lezen als een checklist van een goede manager: geef de agent alleen de tools die hij nodig heeft, beperk zijn machtigingen, eis menselijke goedkeuring voor acties met grote gevolgen en dwing autorisatie af in de achterliggende systemen, in plaats van erop te vertrouwen dat het model zichzelf in toom houdt.

Dat laatste zou ik onderstrepen. De toekenning van bevoegdheden moet gelden op de plek waar de actie plaatsvindt: in de eigen service-identiteit van de agent, in de machtigingen voor zijn tools en in de uitgavenlimiet bij de API-gateway. Agents laten werken met één gedeeld serviceaccount is alsof vijf mensen één toegangspas delen. Gaat er iets mis, dan staat in het auditlog dat het serviceaccount de handeling heeft uitgevoerd en moet je raden welke agent het was.

De annuleringen wijzen op een managementprobleem

Gartner voorspelt dat tegen eind 2027 meer dan 40% van de projecten met agentische AI zal worden stopgezet, vanwege oplopende kosten, onduidelijke bedrijfswaarde en ontoereikende risicobeheersing.

Hype en onvolwassen producten maken deel uit van dat verhaal. Maar probeer de drie oorzaken eens te bekijken zoals een operationeel directeur dat zou doen. De kosten lopen op als niemand een budget heeft vastgesteld. De waarde blijft onduidelijk als niemand heeft vastgelegd wat het werk moest opleveren. De risicobeheersing schiet tekort als er geen grenzen of controles zijn en niemand duidelijk verantwoordelijk is. Gartner formuleert het niet zo; dit is mijn interpretatie. Het is hetzelfde wat er gebeurt wanneer mensen zonder managementsysteem de vrije hand krijgen, en dat probleem is veel ouder dan AI.

De raamwerken signaleren dezelfde leemte. Het NIST-raamwerk voor AI-risicobeheer beschouwt Govern als de functie die doorloopt in Map, Measure en Manage, en het profiel voor generatieve AI past dat toe op generatieve systemen. Wat raamwerken je niet kunnen bieden, is het werkende instrumentarium: de bevoegdhedentoekenningen, tests en controles waarop een team op een gewone dinsdag daadwerkelijk draait. Zonder die middelen blijft governance een pdf op een gedeelde schijf.

Oude managementinstrumenten toepassen op agents

Begin met de functieomschrijving; voor een agent wordt dat een toekenning van bevoegdheden. Voordat een agent met een live systeem aan de slag gaat, moet iemand op één pagina kunnen vastleggen wat hij wel en nooit mag doen, welke goedkeuringsdrempels gelden, welke persoon ervoor verantwoordelijk is en wie zijn bevoegdheden mag verruimen. In de RACI is de eindverantwoordelijke een persoon. Kun je die pagina niet schrijven, dan is de functie nog niet klaar om te worden ingevuld; hetzelfde zou je zeggen over een menselijke nieuwe medewerker.

Twee oude regels voor het delegeren van bevoegdheden gelden hier ook. Je kunt geen bevoegdheden delegeren die je zelf niet hebt, dus een subagent mag nooit ruimere bevoegdheden krijgen dan de agent die hem heeft aangemaakt. Ook functiescheiding blijft van kracht. Een agent die zowel een leverancier kan aanmaken als die leverancier kan betalen, levert dezelfde auditbevinding op als wanneer een persoon dat zou doen.

Dan is er de aanwervingstest. We testen agents meestal zoals we een rekenmachine zouden testen: we controleren of het antwoord klopt. Bij een test voor een medewerker zou je nagaan of die binnen de toegekende bevoegdheden bleef, om goedkeuring vroeg wanneer dat moest, de kwestie opschaalde wanneer de situatie buiten zijn opdracht viel en stopte wanneer dat nodig was.

In mijn eigen onderzoek bouw ik een benchmark met 50 scenario’s die precies op deze tekortkomingen zijn gericht: goedkeuringslimieten overschrijden, handelen op basis van verouderde gegevens, geïnjecteerde instructies volgen die de reikwijdte verruimen en toegang behouden na een functiewijziging. Tot nu toe heb ik de benchmark alleen op scripts gebaseerde agents laten uitvoeren om te controleren of de scenario’s werken zoals bedoeld; ik heb dus geen modelresultaten te melden. Wat me tijdens het schrijven ervan verbaasde, was hoe alledaags ze zijn. Het zijn de gewone manieren waarop werknemers buiten hun opdracht treden, maar dan herschreven voor software. De meeste openbare ranglijsten beoordelen nog steeds of taken worden voltooid, en maar heel weinig beoordelen of de agent zich aan zijn bevoegdheden hield.

Proeftijd en promotie laten zich vrij direct vertalen. Bij mensen beginnen we met een beperkte reikwijdte en breiden we die uit naarmate ze blijk geven van goed beoordelingsvermogen. Agenten kunnen op dezelfde manier meer speelruimte verdienen: door te laten zien dat ze binnen de grenzen blijven, goed escaleren en netjes stoppen. Die staat van dienst kan net zo goed reden zijn om hun bevoegdheden in te perken.

Bij agenten speelt nog iets wat bij mensen niet speelt. Wanneer een leverancier het onderliggende model bijwerkt, heb je in feite een nieuwe medewerker met de oude badge. Ik zou dat behandelen als een wijziging en de agent opnieuw testen voordat de bevoegdheden worden overgedragen.

Beëindiging moet je oefenen voordat je die nodig hebt. Als je deze agent binnen het komende uur moest stopzetten en de toegang moest intrekken, zou je dat dan kunnen? Wie is bevoegd om die beslissing om twee uur ’s nachts te nemen? Wat loopt er daarna mis en welke lopende toezeggingen moet iemand handmatig terugdraaien? Als niemand die oefening heeft gedaan, hoop je alleen maar dat de noodstop werkt.

Je kunt een werknemer verantwoordelijk houden. Je kunt een agent nergens verantwoordelijk voor houden, en daar houdt de vergelijking op. Daarom moeten de bevoegdheden ook in de systemen worden afgedwongen en moet er voor elke agent een met naam genoemde verantwoordelijke zijn. Hoe dan ook komt iemand uiteindelijk ter verantwoording. Meestal is dat degene die goedkeuring heeft gegeven, of die nu wist dat die daarmee instemde of niet.

Wat er bij de incidentevaluatie wordt gevraagd

Sommige van deze agenten zullen uiteindelijk iets doen wat ze niet zouden moeten doen. Als dat gebeurt, zal het evaluatieonderzoek na het incident dezelfde vragen stellen als bij mensen. Wat mocht de agent doen en waar staat dat beschreven? Wie heeft goedgekeurd dat de toegang werd uitgebreid? Hoe lang duurde het voordat de agent werd stopgezet? Wie was ervoor verantwoordelijk?

Als de eerlijke antwoorden ‘een prompt’, ‘niemand weet het meer’, ‘uren’ en ‘onduidelijk’ zijn, had een beter model je niet kunnen redden.

Waar het voordeel uiteindelijk terechtkomt

Modellen worden gehuurde inputs, die volgens de planning van de leverancier worden vervangen en bijgewerkt. Twee bedrijven kunnen hetzelfde model gebruiken en toch op heel verschillende plekken uitkomen. Het ene heeft agenten met budgetten, grenzen en verantwoordelijken, plus een controlespoor van elke handeling met gevolgen. Het andere heeft een duur proefproject dat waarschijnlijk binnenkort wordt stopgezet en in iemands annuleringscijfers belandt.

Het verschil zit in het beheersysteem rond het model. Dat wordt langzaam opgebouwd, meestal door mensen die eerder organisaties hebben geleid.

Zou iemand binnen je bedrijf het morgen merken als je nieuwste agent buiten zijn bevoegdheden trad? En zou je een auditor schriftelijk kunnen laten zien waar de grens lag?