AI-agent governance: de vijf afspraken die je maakt voordat je agents de productie in stuurt

In februari 2024 verloor Air Canada een rechtszaak van zijn eigen chatbot. Een rouwende passagier vroeg de bot naar de kortingsregeling voor nabestaanden; de bot verzon een regeling die niet bestond en beloofde geld terug met terugwerkende kracht. Toen Air Canada weigerde, voerde het een opmerkelijk verweer: de chatbot was "een aparte juridische entiteit die verantwoordelijk is voor zijn eigen daden". De tribunaalrechter noemde dat argument "remarkable" en hield Air Canada gewoon aansprakelijk voor wat zijn eigen chatbot had beloofd. Het bedrijf moest betalen.

Onthoud dat dit nog maar een chatbot was die alleen praatte. Hij boekte niets, betaalde niets, tekende niets. Toch zat het bedrijf vast aan zijn woorden. Trek die redenering nu door naar een echte AI-agent: een systeem dat in jouw naam bestellingen plaatst, offertes verstuurt, betalingen vrijgeeft of een klant een toezegging doet. Mijn stelling is dat het grootste risico van een agent in productie niet is dat hij "iets doms doet" en je dat ziet. Het is dat hij iets volkomen geloofwaardigs doet dat je contractueel bindt, en dat je daar pas achter komt als de schade al is aangericht. Dat risico dek je niet af met een dashboard dat je achteraf bouwt. Je dekt het af met vijf afspraken die vastliggen vóórdat de agent live gaat.

Een agent is geen tool, het is een gevolmachtigde

AI-agents worden vaak besproken alsof het gereedschap is: een slimmere versie van een macro of een zoekfunctie. Dat frame is precies de fout. Een tool wacht op jouw instructie en doet één afgebakend ding. Een agent krijgt een doel, kiest zelf zijn stappen en handelt zelfstandig namens jou. Dat is geen gereedschap, dat is een gevolmachtigde, zoals een medewerker met tekenbevoegdheid of een externe partij met een volmacht.

En zo behandel je het in de rest van je bedrijf ook. Je geeft een nieuwe medewerker niet op dag één een onbeperkte bankpas en de bevoegdheid om elk contract te tekenen. Je bepaalt wat hij zelfstandig mag, vanaf welk bedrag hij moet overleggen, en wie meekijkt. Bij een AI-agent wordt die stap massaal overgeslagen, omdat het "software" heet. Maar juridisch verandert dat niets: zodra een agent in jouw naam handelt, ben jij als gebruiksverantwoordelijke aansprakelijk voor de gevolgen, niet de leverancier van het model. De volmacht die je een agent geeft is even echt als die van een mens, alleen schrijf je hem zelden op.

"Het gaat iets doms doen" is de verkeerde angst

Vraag een ondernemer waar hij bang voor is bij een AI-agent, en het antwoord gaat bijna altijd over een zichtbare blunder: de agent hallucineert, zegt iets geks, maakt een fout die iedereen meteen ziet. Dat soort fouten is vervelend, maar het is niet je grootste probleem, want je ziet ze en je corrigeert ze.

Het echte risico is het tegenovergestelde: de actie die er volkomen correct uitziet en daarom ongezien doorrolt. Een keurig opgemaakte offerte met een verkeerde marge. Een terugbetaling die netjes wordt goedgekeurd maar nooit had gemogen. Een bestelling bij de juiste leverancier, alleen tien keer te veel. De bot van Air Canada klonk volstrekt geloofwaardig, en juist daarom geloofde de klant hem, en juist daarom betaalde het bedrijf. Een agent die overtuigend de verkeerde dingen doet, is gevaarlijker dan een agent die zichtbaar faalt.

Hier hoor ik meteen het tegenargument: de modellen worden toch snel beter, dus dit lost zichzelf op? Het tegendeel is waar. Een beter model maakt de bindende acties juist plausibeler en moeilijker te betrappen. Betere taal, strakkere redeneringen en minder zichtbare fouten betekenen dat de paar acties die wél misgaan er nóg geloofwaardiger uitzien. Capaciteit lost een bevoegdheidsprobleem niet op. Sterker nog: hoe bekwamer de agent, hoe meer je hem laat doen, en hoe groter de volmacht die je weggeeft.

De vijf afspraken die vóór go-live vastliggen

Governance voor agents is geen compliance-map die je na de lancering invult. Het is een set ontwerpkeuzes die je vóór go-live maakt en vastlegt: wat de agent zelfstandig mag, wanneer hij stopt, en hoe je ingrijpt. Agent-governance is met andere woorden het expliciet afbakenen van de volmacht die je een autonoom systeem geeft. Vijf afspraken dragen die afbakening:

• Mandaat: wat mag de agent zelfstandig? Bepaal vooraf, en op papier, welke acties binnen de bevoegdheid vallen en welke niet. Het uitgangspunt is "alles verboden tenzij expliciet toegestaan", niet andersom. Een agent die mag lezen en voorstellen is een andere risicocategorie dan een agent die mag versturen, betalen of toezeggen. Dit is dezelfde grens als de vraag waar je de agent in je ERP laat lezen en waar je hem laat schrijven: de scheidslijn tussen voorstellen en uitvoeren is de belangrijkste die je trekt.
• Escalatie: vanaf welke drempel stopt hij en vraagt hij? Een mandaat zonder bovengrens is geen mandaat. Leg vast bij welk bedrag, welk risico of welke onzekerheid de agent niet doorzet maar een mens om akkoord vraagt. Dat is de mens in de lus die de AI Act voor hoog-risicotoepassingen sowieso eist, maar je wilt hem niet omdat het moet; je wilt hem omdat hij het verschil is tussen een fout van honderd euro en een van honderdduizend.
• Logging: is elke actie achteraf te bewijzen? Elke beslissing die de agent neemt moet herleidbaar en toewijsbaar zijn: wat deed hij, op welke input, op welk moment. Dit is niet alleen hygiëne, het is je verdediging. De AI Act verplicht je de logs van een hoog-risicosysteem minimaal zes maanden te bewaren, en zonder dat bewijs kun je later niet aantonen dat je toezicht hield. Een agent zonder sluitend logboek is een aansprakelijkheid die je niet kunt weerleggen.
• Kill-switch: kun je de volmacht in één keer intrekken? Je moet de agent onmiddellijk en volledig kunnen stilzetten, zonder eerst een leverancier te bellen of een deployment te herschrijven. En je moet die knop getest hebben, want een noodrem die je nooit hebt geprobeerd is een aanname, geen voorziening.
• Eigenaarschap: wie tekent voor wat de agent doet? Er moet een mens met naam verantwoordelijk zijn voor de output van de agent, net als voor het werk van een teamlid. Verantwoordelijkheid die over "het systeem" wordt uitgesmeerd, is verantwoordelijkheid die niemand draagt, en precies dan ontstaan de beslissingen die niemand nam maar iedereen moet uitleggen.

Het hoe van die laatste drie, de concrete logging, budgetplafonds en kill-switches, staat in een praktische gids voor het instellen van logging, budgetten en kill-switches. De afspraken zelf, en de wil om ze te maken, horen hier thuis: ze gaan niet over techniek maar over hoeveel macht je weggeeft.

Maar vertraagt dit niet juist waar je een agent voor wilde?

Het eerlijke tegenargument tegen al deze afspraken: als ik de agent bij elke stap laat stoppen, escaleren en loggen, regel ik de snelheid weg waarvoor ik hem inzette. Dan kan ik het net zo goed zelf doen.

Dat klopt alleen als je governance verwart met remmen. Een afgebakend mandaat is geen rem op autonomie, het is de voorwaarde om autonomie te durven uitbreiden. Je begint smal: de agent mag voorstellen, een mens keurt goed, alles wordt gelogd. Werkt dat een paar honderd keer zonder incident, dan verschuif je de drempel omhoog en geef je hem meer ruimte, met bewijs in de hand. Zonder die afbakening doe je het omgekeerde: je geeft op dag één de volledige volmacht en hoopt dat het goed gaat. Dat is niet sneller, dat is alleen onbetaald risico dat nog niet is opgeëist.

De cijfers wijzen dezelfde kant op. Gartner verwacht dat ruim 40 procent van de agentic-AI-projecten voor eind 2027 sneuvelt, onder meer door gebrekkige risicobeheersing, naast oplopende kosten en onduidelijke waarde. De projecten die overleven zijn niet de projecten met het slimste model. Het zijn de projecten waar van tevoren is nagedacht over wat de agent mag en wanneer hij stopt.

Slot: governance is een ontwerpkeuze, geen formulier

De wet loopt hier verrassend genoeg voor op de onderbuik. De AI Act eist niet dat je achteraf rapporteert, maar dat je het menselijk toezicht vooraf in het systeem ontwerpt: de mens moet de agent kunnen begrijpen, kunnen overrulen en kunnen stoppen, en die mogelijkheid moet zijn ingebouwd voordat het systeem draait. Dat is geen bureaucratie, het is dezelfde logica als de vijf afspraken: bevoegdheid die je niet vooraf afbakent, baken je nooit meer af.

De vraag voor wie nu agents in productie zet is dus niet "wat als hij een fout maakt". Die fout komt, net als bij elke medewerker. De vraag is of je van tevoren hebt opgeschreven wat hij in jouw naam mocht beslissen. Doe je dat niet, dan delegeer je geen werk, dan geef je de controle weg, en kom je daar pas achter op het moment dat iemand anders de rekening bij jou neerlegt.