Je hebt een agent die tickets routeert, een die facturen matcht, misschien een derde die content hergebruikt. Elke agent werkt. De vraag die je nog niet beantwoord hebt: als er over drie maanden iets misgaat, kun je dan aanwijzen welke beslissing, door welke agent, op basis van welke gegevens? En had een mens ernaar moeten kijken?
Kun je dat niet, dan heb je geen agent-probleem. Je hebt een verantwoordingsprobleem dat toevallig pas zichtbaar wordt als er een agent bij betrokken is.
Het probleem: autonomie zonder spoor
Een los script dat één taak doet, kun je nog navertellen door de code te lezen. Een agent die zelf beslist welk pad hij neemt, welke gegevens hij ophaalt en wanneer hij escaleert, is dat spoor sneller kwijt. Tenzij je hem expliciet laat vastleggen wat hij deed en waarom. Zonder logboek bestaat het besluit alleen op het moment dat het genomen wordt.
Dat wordt duur op precies het moment dat het pijn doet. Een klant klaagt over een foutieve creditering. Een toezichthouder vraagt naar de verwerking van klantgegevens. Een medewerker vraagt waarom zijn werk is overschreven. In alle drie de gevallen is de vraag hetzelfde: wat gebeurde er, wie besliste, en waarom greep niemand in. Zonder logboek is het antwoord een gok, en een gok is geen verantwoording.
Reken het zelf uit. Tel het aantal agentbeslissingen dat je per week zonder menselijke blik door laat gaan. Vermenigvuldig dat met het aantal weken dat je die agent al draait. Dat getal, illustratief pak ik 40 beslissingen per week maal 12 weken is 480, is niet je risico. Het is het aantal beslissingen waarvoor je vandaag geen reconstructie hebt als iemand ernaar vraagt. Vul je eigen aantallen in; het gaat om het besef dat dit getal groeit terwijl je niets doet.
Vier vragen om te bepalen of dit bij jou speelt
Kun je van je meest gebruikte agent de laatste tien beslissingen reconstrueren: welke gegevens hij zag, wat hij besloot, en of een mens keek?
Weet je, zonder te bellen met je leverancier, in welk land de gegevens van die agent worden verwerkt en hoe lang ze bewaard blijven?
Ligt er een verwerkersovereenkomst met de modelleverancier die specifiek jouw agentgebruik dekt, of draai je nog op de standaardvoorwaarden van een consumentenaccount?
Als een medewerker vandaag zou vragen of de agent zijn werk bijhoudt om hem te beoordelen, wat is je eerlijke antwoord, en heb je dat ooit hardop tegen het team gezegd?
Hoe je governance opbouwt: rollen, logboek, ingreep
Governance voor agents bestaat uit drie lagen die apart moeten staan, ook als één persoon ze in de praktijk allemaal doet.
De eerste laag is het rechtenmodel: wie mag welke agent welke actie laten uitvoeren, op welke databron. Leg dat vast per agent, niet per persoon, want agents wisselen sneller van taak dan medewerkers van functie. Een routeeragent mag lezen uit het ticketsysteem en schrijven naar het CRM. Hij mag nooit een creditering boeken. Die grens staat niet in een instructie aan het model, die staat in de rechten van het systeemaccount waarmee de agent draait. Een prompt is een verzoek, geen beveiliging.
De tweede laag is het logboek. Per beslissing leg je vast: het tijdstip, welke agent, welke gegevens hij gebruikte, wat hij besloot, zijn zekerheidsscore, en of een mens keek voor het doorging. Dat laatste veld is het scharnier van je hele governance: zonder het bewijs dat iemand keek, kun je nooit aantonen dat je escalatieregel werkte in plaats van alleen bestond. Bouw dit logboek voor je de agent op productiedata loslaat, niet erna. Achteraf loggen reconstrueert niets.
De derde laag is het escalatiepad: wanneer grijpt een mens in, en wie is die mens. Twee triggers volstaan om te beginnen. Zekerheid onder een vaste drempel gaat altijd naar een mens. En een vaste lijst van onomkeerbare acties, betalingen, opzeggingen, verwijderingen, gaat altijd naar een mens, ongeacht de zekerheid. Ken elke trigger een met naam genoemde rol toe, niet “het team”. Zonder eigenaar wordt een escalatie een melding die niemand oppakt.
Bouw daaromheen een vast ritme: een wekelijkse steekproef van tien gelogde beslissingen, gelezen door de eigenaar van het proces, niet door wie de agent bouwde. Die scheiding voorkomt dat de bouwer zijn eigen werk goedkeurt.
Wat de AVG hier concreet van je vraagt
Zodra een agent persoonsgegevens verwerkt, ligt de verantwoordelijkheid bij jou, niet bij je leverancier. De AVG kent drie rollen en die vervagen niet omdat er een model tussen zit. Jouw bedrijf is de verwerkingsverantwoordelijke: jij bepaalt doel en middelen van de verwerking. De modelleverancier is de verwerker: hij verwerkt in jouw opdracht en mag niets voor eigen doel gebruiken. Zet die leverancier op zijn beurt gegevens door naar een onderliggende infrastructuurpartij, dan is dat een subverwerker, en die moet in de overeengekomen keten staan, niet er stilzwijgend bij komen.
Voor een Nederlands bedrijf van 10 tot 100 mensen betekent dat, voor elke agent die persoonsgegevens raakt, één concreet document. Een verwerkersovereenkomst met de modelleverancier: welke gegevens, voor welk doel, hoe lang bewaard, wie erbij kan. Een zakelijk abonnement, geen consumentenaccount, want consumentenvoorwaarden zijn zelden op verwerkersniveau geschreven. Weten in welke regio de verwerking plaatsvindt en dat kunnen aantonen, niet aannemen. Een retentieregel per gegevenssoort, met een vervaldatum die technisch wordt afgedwongen, niet met een belofte in een document. En het logboek uit de vorige sectie is hier niet optioneel: het is je enige manier om aan een toezichthouder of een klant te laten zien wat er gebeurde met wiens gegevens.
Waar het gat expliciet blijft: er is geen gepubliceerde norm voor hoeveel bedrijven dit al op orde hebben. Benoem dat gat gerust in je eigen risicobeoordeling, vul het niet met een geleend cijfer.
Waarom logboek nooit medewerkersmonitoring wordt
Elk logboek dat een agent bijhoudt, registreert ook wat een medewerker met de output van die agent doet: of hij het concept overnam, corrigeerde of negeerde. Dat is onvermijdelijk en het is ook precies het punt waar governance kan doorslaan naar iets wat je nooit wilt bouwen.
Onze harde regel: die gegevens zijn eigendom van het team, bedoeld om de agent te verbeteren en de werklast te verlagen. Ze zijn nooit input voor een individuele beoordeling, een functioneringsgesprek of een prestatieranking. Wil je die gegevens ooit voor een ander doel gebruiken dan het bijsturen van de agent, dan is dat een nieuw doel. Dat doel bespreek je vooraf met de ondernemingsraad, die daarin veto heeft. Niet achteraf melden. Vooraf beslissen.
Zeg dat hardop tegen je team voordat je een agent met logboek live zet, niet nadat iemand het zelf ontdekt. Een team dat denkt gevolgd te worden, corrigeert minder eerlijk, en dan verlies je precies het signaal waarop de agent moet leren.
De eerlijke grens
Governance van deze omvang is overkill als je één agent hebt die geen persoonsgegevens raakt en geen onomkeerbare actie kan nemen. Bouw dan eerst het logboek, en stel het rechtenmodel en het escalatiepad uit tot je een tweede agent toevoegt of tot de eerste agent klantgegevens gaat aanraken. Governance die voor de behoefte uit loopt, wordt een proces dat niemand onderhoudt, en een ongebruikt proces is even riskant als geen proces.
Het is ook geen vervanging voor een geordend brondocument. Een agent die zonder logboek draait op een proces dat nergens is vastgelegd, heeft twee gaten tegelijk, en governance dicht er maar één. Begin bij RENEW als je antwoordset nog in hoofden zit; daar begint elk agentproces, ook dit.
Verder lezen en de eerste stap
Wil je eerst zien waar autonomieniveaus en de PRAL-lus vandaan komen die dit stuk aanhaalt, lees dan de pillar over agentic werken. Draait je eerste agent op klantcontact, dan is support-triage de workflow waar deze governance het eerst hard nodig is, want daar zit de zwaarste persoonsgegevensblootstelling. Een logboek zonder geheugen legt alleen het verleden vast en leert niets. Agentic geheugen is de laag die bepaalt of je agent na drie maanden scherper beslist of nog steeds dezelfde fout logt. Ik kijk liever een uur mee met de laatste tien beslissingen van je eigen agent dan dat ik je een governance-sjabloon stuur. Ik plan graag een gesprek in waarin we samen je logboek en je escalatiepad opzetten.