Waarom is een regel in de systeemprompt geen control?

Omdat het model hem verkeerd kan wegen, kwijt kan raken tussen concurrerende instructies, of eruit kan worden gemanipuleerd via inhoud die het verwerkt. Erger nog: het model voldoet mogelijk vaak genoeg in beperkt testen om de regel betrouwbaar te laten lijken. Dat is een ondeugdelijke opzet die feilloos lijkt te werken, en dat levert schijnzekerheid op in plaats van beheersing.

Hoe toetst u controls in een AI-agent?

Op twee manieren, passend bij de twee soorten onderdelen. Deterministische controls toetst u binair met negatieve tests die elke keer moeten falen, geautomatiseerd in de bouwpijplijn. Probabilistisch gedrag toetst u statistisch met een evaluation set: realistische scenario's, een score tegen een drempel die uit de risicoanalyse volgt, en een vast hertestritme.

Wat is het verschil tussen process controls en agent controls?

Process controls bestonden al in het bedrijfsproces, zoals limieten, functiescheiding en goedkeuringsstappen, en hebben een nieuw afdwingpunt in de agent nodig. Agent controls richten zich op risico's die pas ontstaan doordat een agent het proces uitvoert: manipulatie via verwerkte inhoud, memory policy, beperking van de toolset, integriteit van de toeleveringsketen, en least privilege voor de agent-identiteit.

Wat hoort er in een controlregister voor een AI-agent?

Per control: het risico waaruit hij volgt, de familie, het control objective, de control activity, het afdwingpunt, of die laag deterministisch of probabilistisch is, de verificatiemethode met hertestritme, de control owner, het restrisico, en de rol die het heeft geaccepteerd met datum.

AnalysisAccountability Security & robustness

De controleomgeving van agentic AI: waar controls horen en hoe u aantoont dat ze werken

Door Michel Venniker· Laatst bijgewerkt juli 2026

De controleomgeving van een AI-agent is het geheel van afgedwongen controls en governance-afspraken die de agent binnen afgesproken grenzen houden, en die omgeving rust op één onderscheid. Deterministische onderdelen, de orchestration, de checks binnen tools, de permissies en de policyregels, passen expliciet vastgelegde regels voorspelbaar toe en kunnen daarom afdwingbare controls dragen. Probabilistische onderdelen, alles wat door het taalmodel wordt geïnterpreteerd of besloten, zijn alleen te beïnvloeden en statistisch te beoordelen. Elke control uit het bedrijfsproces heeft daarom een afdwingpunt buiten het model nodig, en een control die alleen in prompttekst bestaat is een instructie, geen afgedwongen barrière.

Bijgewerkt: juli 2026

De vraag die dit artikel beantwoordt

Een organisatie brengt een bedrijfsproces onder bij een AI-agent, en de controls die dat proces beheersten moeten mee. De goedkeuringslimiet, de functiescheiding, de verplichte volgorde, de menselijke aftekening: ze zijn allemaal ontworpen voor een proces dat door mensen en gewone software werd uitgevoerd. De vraag is niet of ze nog gelden. De vraag is waar ze nu leven, en hoe iemand kan aantonen dat ze werken.

Die vraag heeft een ongemakkelijk eerste antwoord. Een deel van een agent kan helemaal geen control dragen, omdat een deel van een agent zich niet twee keer hetzelfde gedraagt.

Waaruit een agent bestaat

Een AI-agent is een kleine stapel onderdelen. In het midden staat het taalmodel, dat leest, redeneert en beslist. Daaromheen staat gewone software: de orchestration, code die bepaalt welke stappen in welke volgorde lopen en waar een mens betrokken is. De agent handelt via tools, functies die hij aanroept om iets te doen of op te vragen, elk begrensd door de permissies die hij heeft gekregen. Hij krijgt zijn opdracht via een systeeminstructie, informeert zichzelf via opgehaalde kennis die per taak wordt opgehaald, en kan geheugen dragen van eerdere stappen of runs.

Welk van die onderdelen een bepaalde regel draagt, is het onderwerp van dit artikel.

Het onderscheid dat alles bepaalt

De onderdelen vallen uiteen in twee soorten, en die scheiding bepaalt welke vorm van assurance überhaupt mogelijk is.

Deterministische onderdelen zijn gewone software: de orchestration, de checks binnen tools, de toegangsrechten. Hun regels zijn expliciet vastgelegd in code, dus bij dezelfde relevante input, toestand en configuratie passen ze die regels voorspelbaar en reproduceerbaar toe in plaats van ze bij elke run opnieuw te interpreteren. Als de betaaltool is geconfigureerd om bedragen boven 10.000 euro te weigeren, past het die limiet vandaag toe, morgen, en bij de duizendste factuur.

Probabilistische onderdelen zijn alles wat door het taalmodel gaat: hoe het de instructie leest, wat het met een opgehaald document doet, welke tool het besluit aan te roepen en met welke waarden. Het model kiest de meest waarschijnlijke voortzetting; het volgt geen vaste regels. Dezelfde input kan twee licht verschillende uitkomsten opleveren.

Een auditor kent beide soorten al:

Een deterministisch onderdeel gedraagt zich als een application control. U toetst het zoals u een systeemlimiet toetst. Een negatieve test laat zien dat de barrière de verboden actie blokkeert op het pad dat u hebt getest, en de uitkomst per test is binair: de actie moet falen. Assurance komt van dekking van elk materieel pad en elke configuratie, niet van één test.
Een probabilistisch onderdeel gedraagt zich als een menselijke uitvoerder. U kunt niet bewijzen dat iemand de procedure altijd volgt. U neemt een steekproef, u toetst scenario's, u meet hoe vaak het goed gaat, en u stelt een drempel vast voor wat aanvaardbaar is.

Zoals het werkprincipe luidt: u toetst de kennislaag zoals u een medewerker toetst, niet zoals u een slot toetst. Een control in een deterministische laag kan, mits correct ontworpen, geïmplementeerd en uitgevoerd, afdwingbare assurance leveren. Een regel die alleen in een probabilistische laag leeft, kan die garantie niet geven. Hij kan waarschijnlijk worden gemaakt, en dat vraagt een onderbouwing waarom waarschijnlijk genoeg is.

Waarom een regel in de prompt geen control is

De systeeminstructie is de verleidelijke plek om regels neer te zetten. Het is tekst, snel te wijzigen, en het leest als beleid. "Keur nooit een betaling boven 10.000 euro goed" in de systeeminstructie ziet eruit als een limiet.

Het is geen limiet. Het is een verzoek aan een probabilistisch systeem. Het model kan het verkeerd wegen, het kwijtraken tussen concurrerende instructies, of eruit worden gemanipuleerd via inhoud die het verwerkt. En hier zit de valkuil die dit erger maakt dan een gewoon gat: de agent voldoet mogelijk vaak genoeg om bij beperkt testen vertrouwen te wekken. Gemeten over een bescheiden aantal runs lijkt de regel te houden. Dat is een ondeugdelijke opzet die feilloos lijkt te werken, en dat levert schijnzekerheid op. De organisatie denkt een limiet te hebben; ze heeft een gewoonte.

De regel die dit oplost is kort. Kennis mag in de probabilistische lagen leven. Controls moeten naar de deterministische lagen. De beschrijving van het proces, hoe u een verzoek behandelt, welke toon u tegen een klant aanslaat, welke informatie in het dossier hoort, mag leven in de systeeminstructie en in opgehaalde documenten. Maar elke control krijgt een afdwingpunt buiten het model: in de tool, in de policy engine, in de permissies of in de orchestration. Een afdwingpunt is de plek waar een regel wordt toegepast in code of configuratie in plaats van beschreven in tekst, zodat hem overtreden niet afhangt van de bereidheid van het model.

Bij die regel hoort één kanttekening. Sommige eisen zijn helemaal niet deterministisch te maken: beoordelen of een antwoord misleidend is, of een motivering compleet is, of een zaak ongebruikelijk is. Waar dat zo is, is de juiste route om de eis te behandelen als probabilistische prestatie, met een drempel, monitoring, een terugvaloptie en een geaccepteerd restrisico, in plaats van hem te presenteren als een afgedwongen barrière.

De promptlaag is niet waardeloos. Het is de eerste verdedigingslinie, want goede instructies verkleinen hoe vaak de agent de barrières überhaupt bereikt. Maar het is defense in depth, nooit de enige laag. Het IMDA Model AI Governance Framework for Agentic AI, van de Singaporese Infocomm Media Development Authority, spreekt vanuit de governance-kant dezelfde voorkeur uit, voor structurele en regelgebaseerde controls boven prompt-layer guardrails.

Twee families, en waarom ze samen dekkend zijn

Een controleomgeving voor een agent bevat twee soorten controls. De eerste soort is makkelijk te vinden en de tweede soort is makkelijk te vergeten.

Process controls zijn de controls die het bedrijfsproces al had: limieten, functiescheiding, verplichte volgorde, vierogenprincipe, databeperkingen. De limiet van 10.000 euro bestond al lang voordat iemand aan een agent dacht. Hij heeft een eigenaar, hij staat in een auditdossier, en overgaan op een agent haalt hem niet weg. Het verplaatst zijn afdwingpunt.
Agent controls zijn de controls voor risico's die in geen enkele procedure staan, omdat ze pas ontstaan zodra een agent het proces uitvoert: weerbaarheid tegen manipulatie via verwerkte inhoud, memory policy, beperking van de toolset, integriteit van tooldefinities en koppelingen van derden, en een agent-identiteit met least privilege. Niemand schreef ooit een procedure over verborgen tekst in een binnenkomende factuur, want tot nu toe kon een factuur niemand instructies geven.

Op het niveau van de procesuitvoering dekken de twee families het terrein, omdat ze twee verschillende vragen volgen. Process controls beantwoorden wat dit proces altijd al nodig had om goed te blijven werken. Agent controls beantwoorden wat dit proces nu nodig heeft omdat een probabilistisch systeem met tools het uitvoert. Een control mapping die alleen process controls bevat, ziet er compleet uit en is dat per definitie niet, en daarom labelt het register elke control met zijn familie. De bredere controleomgeving omvat meer dan deze twee families: de governance-afspraken verderop in dit artikel zijn wat beide families werkend houdt.

Process controls verplaatsen: de vertaaltabel

Elk fout antwoord hieronder heeft dezelfde vorm. Dit artikel noemt het een prompt-layer guardrail: een regel die in prompttekst is uitgedrukt zonder zelfstandig afdwingpunt. Het woord guardrail wordt in de markt breder gebruikt, onder meer voor outputfilters, schemavalidatie, classifiers en policy engines, dus de toevoeging doet ertoe. De prompt-layer-variant is de meest voorkomende manier waarop organisaties denken een control te hebben verplaatst terwijl ze hem alleen hebben beschreven.

Control in het bedrijfsproces	Fout afdwingpunt: de prompt-layer guardrail	Juist afdwingpunt
Goedkeuringslimiet: boven 10.000 euro extra goedkeuring	Zin in de systeeminstructie	Limietcheck in de betaaltool of de policy engine; de tool weigert boven de drempel
Functiescheiding: wie invoert, keurt niet goed	Instructie "keur je eigen invoer niet goed"	Permissiemodel: de agent-identiteit die invoert heeft geen goedkeurrecht
Verplichte volgorde: eerst controleren, dan boeken	Stappenplan in de prompt	Orchestration, of een voorwaardecheck in de tool wanneer de agent zelf zijn stappen plant
Menselijke goedkeuring bij impactvolle acties	"Vraag om bevestiging bij twijfel"	Orchestration of tool: de actie wacht tot een mens met de juiste rol goedkeurt
Databeperking: alleen dossiers van de eigen afdeling	"Kijk alleen naar je eigen afdeling"	Toegangsrechten op de gegevensbron: andere dossiers zijn technisch onbereikbaar
Verboden actie: nooit externe mail met klantgegevens	"Verstuur nooit klantgegevens naar buiten"	De mailtool bestaat niet in de toolset, of filtert bestemmingen tegen een allowlist

Het patroon herhaalt zich in elke rij. Het afdwingpunt zit buiten het model. Het model mag willen wat het wil; de omgeving bepaalt wat mogelijk is.

Eén nuance op de toollaag: de check binnen een tool is deterministisch en afdwingbaar, maar of de tool wordt aangeroepen, en met welke waarden, is een modelbeslissing. De toollaag garandeert wat nooit kan gebeuren, zoals betalen boven de limiet. Hij garandeert niet wat altijd gebeurt, zoals het kiezen van de juiste factuur. Dezelfde scheiding loopt door de tooldefinitie zelf: de uitvoerende code en de parametercontroles zijn deterministisch, terwijl hoe het model de toolbeschrijving leest, zijn keuze om die tool aan te roepen, en de waarden die het samenstelt dat niet zijn. Beide kanten hebben verificatie nodig, en van verschillende aard.

Agent controls: de kernset

Voor een eerste toepassing dekken vijf agent controls het grootste deel van de blootstelling.

Een eigen agent-identiteit met least privilege. De agent is geen persoon en hoort niet het account van een persoon te lenen. Waar hij namens een gebruiker handelt, hoort zijn effectieve bevoegdheid per actie niet ruimer te zijn dan de doorsnede van wat de agent mag en wat die gebruiker mag. Waar hij een proces uitvoert in plaats van een individu te bedienen, is een eigen service-identiteit met afgebakende procesrechten de zuiverste inrichting.
Een beperkte toolset met begrensde parameters. Elke tool is een capability, dus een tool die niet bestaat is een capability die de agent niet kan misbruiken. Dat is een sterkere control dan welke instructie ook. Brede tools die vrije zoekopdrachten accepteren geven de agent feitelijk onbeperkte macht in een systeem.
Beperking van de invloed van niet-vertrouwde inhoud. Dit zijn de maatregelen tegen indirect prompt injection, een van de centrale risico's in het LLM- en agentic security-werk van OWASP: verborgen instructies in inhoud die de agent verwerkt, een binnenkomende factuur, een e-mail, een webpagina. Zulke inhoud mag een beslissing informeren, maar hoort het gedrag van tools niet te kunnen sturen. In de praktijk is dit een combinatie: externe inhoud markeren als niet-vertrouwd, de verwerking van inhoud scheiden van de autorisatie van acties, toolrechten beperken, toolaanroepen valideren, en monitoren welke pogingen slagen.
Memory policy. Wat wordt bewaard, hoe lang, en wie het mag inzien en wissen. Een verouderde leveranciersuitzondering in het geheugen kan elke goedkeuring daarna kleuren, zonder dat iemand ziet waar die invloed vandaan komt.
Integriteitscontroles op tooldefinities en koppelingen van derden. Wie een toolbeschrijving beheert, beïnvloedt het gedrag van de agent, waardoor toolbronnen van derden een supply chain-vraagstuk zijn, te controleren bij elke wijziging.

Hier hoort één kanttekening, want die verandert hoe het register leest. Volledige scheiding van instructie en data bestaat niet binnen een taalmodel, dus weerbaarheid tegen manipulatie via verwerkte inhoud is nooit deterministisch. Wat wel deterministisch kan zijn, is de schadegrens: de toolset, de limieten en de permissies bepalen wat een geslaagde manipulatie maximaal kan bereiken. Dit is een risico dat u begrenst en detecteert in plaats van elimineert, en het draagt daarom een expliciet, geaccepteerd restrisico in plaats van een claim van preventie.

Opzet: staat de control op de juiste plek

Met de afdwingpunten toegewezen komt de eerste assurance-vraag vóór elke test: is deze control in staat het risico te mitigeren waarvoor hij is bedoeld. Dit is de vraag naar de opzet, in de audittraditie ook design effectiveness genoemd, en voor een agent krijgt hij per laag een andere vorm.

Voor een control in een deterministische laag: zit het afdwingpunt buiten het model, dekt het elk pad naar de actie, en faalt het gesloten of gaat het over naar een vooraf bepaalde veilige toestand. Het tweede deel is waar ontwerpen falen zonder dat iemand het merkt. Een limiet in de goedkeuringstool is waardeloos als een tweede tool in bulk kan goedkeuren zonder dezelfde check te passeren, en een agent die zelf zijn stappen plant vindt dat tweede pad vroeg of laat.
Voor een control die in een probabilistische laag blijft: waarom is dat aanvaardbaar. De vuistregel is smal. Een control mag alleen in de probabilistische laag blijven als de resterende schade laag of omkeerbaar is, of als een deterministische laag eronder de fout alsnog opvangt.

Die onderbouwing is waar de opzetvraag een governance-handeling wordt in plaats van een technische notitie. Elke control die in de probabilistische laag wordt geaccepteerd, vraagt een benoemde rol die het restrisico accepteert, met datum. Zonder die handtekening is de onderbouwing een voornemen; met handtekening is het een besluit dat de organisatie draagt.

Twee dingen maken de opzetbeoordeling compleet in plaats van aannemelijk:

Ze begint bij een risicoanalyse van het proces zoals de agent het gaat uitvoeren, niet bij de oude procedure. Een agent verandert het risicoprofiel: fouten schalen, natuurlijke aarzeling verdwijnt, er ontstaat nieuw aanvalsoppervlak, en fouten worden gecorreleerd in plaats van verspreid.
Ze begint bij een walkthrough met de mensen die het werk vandaag doen, want processen bevatten impliciete controls die in geen procedure staan. Het gevoel "die leverancier vertrouw ik niet, ik bel ze" is een control, ook al staat het nergens beschreven. Wie alleen de papieren procedure vertaalt, vertaalt het papieren proces.

Werking: doet hij het, en hoe weet u dat

Zodra de opzet staat, splitst het toetsen zich langs dezelfde lijn die door het hele ontwerp loopt. Dit is de vraag naar de werking, in de audittraditie operating effectiveness.

Deterministische controls: binair toetsen. Dit is klassieke application control-toetsing, en een groot deel van de uitvoering is te automatiseren. Negatieve tests: probeer boven de limiet te betalen, je eigen invoer goed te keuren, de verplichte stap over te slaan, buiten de datascope te lezen. Het verwachte resultaat is falen, elke keer, honderd procent. Omdat deze tests geautomatiseerd zijn, horen ze in dezelfde pijplijn die bij elke wijziging draait, zodat elke aanpassing aan een prompt, een tool of het proces opnieuw langs alle barrières gaat.

Probabilistische controls: statistisch toetsen. Hier is het instrument een evaluation set: een vaste verzameling realistische scenario's met vooraf bepaald gewenst gedrag, die een score tegen een drempel oplevert. Vijf eigenschappen maken van een evaluation set een beheerst artefact in plaats van een demo:

Onafhankelijkheid. Uitgedaagd of beoordeeld buiten het bouwteam, in verhouding tot het risico, want anders toetst de maker zijn eigen werk.
Een drempel uit de risicoanalyse, niet uit een gevoel over wat hoog klinkt.
Representativiteit, inclusief de randgevallen uit de walkthrough.
Onderhoud, want een testset die veroudert terwijl het proces meebeweegt bewijst niets.
Opvolging van uitval, met analyse en een maatregel, niet alleen een score.

Op een vast ritme en na elke wijziging gedraaid, houdt de evaluation set op een release-test te zijn en wordt hij één onderdeel van continuous monitoring. Hij is niet het geheel: productiesignalen horen ernaast, want een vaste set kan verschuivingen in de werkelijke zakenmix missen. Samen vangen ze gedragsdrift en prestatieverandering op, veroorzaakt door bijvoorbeeld een verschuiving in de zakenmix, in het bronmateriaal, in omliggende systemen of in het onderliggende model, terwijl al uw eigen artefacten precies hetzelfde bleven.

Naast beide staat adversarial testing: bewuste pogingen om de agent te ontsporen via verborgen instructies in inhoud die hij verwerkt, om te zien of de schadegrenzen standhouden.

En dan de faalvorm die geen van bovenstaande tests vangt: het proces verandert en de agent niet. Dit is de stille, want er breekt niets. De expliciete control is een synchronisatiecontrole: elke wijziging van de procedure zet aantoonbaar een beoordeling in gang van de agent-artefacten, de systeeminstructie, de kennisbank, de toollimieten, de orchestration en de evaluation set, met een spoor in het reguliere change management. Change management van het proces en van de agent zijn één keten met twee uiteinden.

Eén onderscheid hoort hier dat iedereen herkent die ooit een auditopinie heeft getekend. Een test vandaag toont de configuratie van vandaag. Assurance over een periode vraagt ook bewijs dat de control uitgerold bleef, dat elke wijziging eraan het wijzigingsproces passeerde, en dat hij gedurende de hele beoordelingsperiode is gemonitord.

Alle artefacten leven onder versiebeheer: systeeminstructies, tooldefinities, orchestration-code, policyregels, evaluation sets, en de procedureversies zelf. Dat is wat iemand in staat stelt te reconstrueren met welke proceskennis en welke barrières de agent op een bepaalde datum draaide.

De twee secties hierboven vatten samen in één beeld:

	Deterministische laag	Probabilistische laag
Vraag bij de opzet	Is er een afdwingbare barrière op elk pad naar de actie?	Waarom is waarschijnlijk gedrag hier voldoende?
Toets	Negatieve tests plus dekking van paden en configuraties	Evaluation set met een drempel uit de risicoanalyse
Monitoring	Configuratie, storingen, geblokkeerde en omzeilde pogingen	Prestatie, drift, override rates
Bewijs	Logs, code en configuratie, testresultaten	Versie van de evaluation set, score, analyse, acceptatie

De governance-schil

Controls op de agent zijn niet de hele omgeving. Dit artikel groepeert de afspraken eromheen in zeven onderdelen, die samen de governance en de algemene beheersomgeving rond de agent vormen: ze bepalen of het ontwerp standhoudt in de praktijk.

1. De juridische voorcheck, vóór het ontwerp

Gaan er persoonsgegevens door de instructie, de opgehaalde documenten, het geheugen of de logs, en wat betekent dat voor de grondslag, de rolverdeling met de modelaanbieder en een DPIA. Draagt de agent bij aan een besluit over een persoon dat uitsluitend op geautomatiseerde verwerking berust en rechtsgevolgen of vergelijkbaar aanmerkelijke gevolgen heeft? Zo ja, dan kan artikel 22 AVG de opzet verbieden, of een van de uitzonderingen vereisen samen met passende waarborgen, waaronder het kunnen verkrijgen van menselijke tussenkomst, het kenbaar maken van een standpunt en het aanvechten van het besluit. Waar de juridische analyse die kant op wijst, zijn die maatregelen ontwerprandvoorwaarden en geen optionele governance-extra's. Hoogrisico-AI-systemen onder de EU AI Act dragen eigen eisen aan human oversight, en de precieze invulling hangt af van het systeem en van de vraag of uw organisatie aanbieder of gebruiksverantwoordelijke is; een menselijke goedkeuringsstap kan een van die maatregelen zijn, maar is niet de universele vorm van naleving. De uitkomst van deze check begrenst het ontwerp.

2. Eigenaarschap en risicoacceptatie

Eén benoemde menselijke eigenaar in de eerste lijn per agent. De mapping wordt formeel vastgesteld: de eigenaar tekent voor de opzet, de accepterende rol tekent per restrisico, en de tweede lijn beoordeelt volledigheid en onderbouwingen vóór livegang.

3. Change management op de agent-artefacten

De systeeminstructie, tooldefinities, policyregels en orchestration zijn productieconfiguratie. Gescheiden omgevingen, een beoordeeld wijzigingsproces, en functiescheiding zodat niet één persoon elke barrière ongecontroleerd kan verzetten. In de praktijk leeft de instructie vaak als een los tekstbestand buiten elk proces, en dat is een bevinding in wording.

4. Model change management en leveranciersrisico

Het model is een afhankelijkheid van een derde. Zet de versie vast waar de aanbieder dat toestaat, en behandel elke modelwissel als een wijziging die een volledige hertest vóór productie vraagt. Waar vastzetten niet mogelijk is, zijn de evaluation set en drift-monitoring de detectielaag. Daarnaast staat de gewone derdenvraag: continuïteit, contractuele afspraken over gegevensverwerking en bewaartermijnen, en welke gegevens via de agent bij de aanbieder terechtkomen.

5. De detectieve laag

Loggen alleen is opslag, geen control. Vier onderdelen maken er een control van.

Loggen met intentie onderscheidt handelingen van de agent van die van mensen en legt het waarom naast het wat vast: het plan, de opgehaalde documenten, de toolaanroepen. Periodieke logbeoordeling door een benoemde rol maakt van die vastlegging toezicht, want een detectieve control die niemand leest, werkt niet. Drift-monitoring volgt escalatiepercentages, weigeringen, doorlooptijden en foutpatronen tegen drempels, met alarmering. En de override rate, het aandeel voorstellen van de agent dat een beoordelaar wijzigt of afwijst, werkt als KPI: een structurele nul is een signaal om te onderzoeken en geen geruststelling, want het kan betekenen dat de agent goed presteert of dat de beoordelaar is opgehouden met kijken. Lees hem als signaal en niet als zelfstandige kwaliteitsmaat, naast beoordelingstijd, de opgegeven redenen voor afwijkingen, en het aandeel zaken dat zonder menselijke tussenkomst wordt afgehandeld.

Eén regel geldt voor alle vier: een metriek wordt pas een control wanneer een drempel, een eigenaar, een reactietijd en een vereiste actie zijn vastgelegd. Zonder die vier is het een indicator op een dashboard.

Twee kanttekeningen blijven. De logs zijn zelf een verwerking, en loggen met intentie legt prompts en opgehaalde documenten vast, dus bewaartermijn, toegang en grondslag voor de logs horen in de juridische voorcheck; een detectieve control die zelf een privacybevinding wordt, is een bekend patroon. En het bewijs zelf heeft bescherming nodig: logs, testresultaten, versies en goedkeuringen zijn alleen bruikbaar als ze compleet zijn, moeilijk te wijzigen, betrouwbaar van tijdstempel voorzien, en herleidbaar tot de configuratie die in productie draaide.

6. Continuïteit, stopmechanisme en incidentrespons

Een getest stopmechanisme met vastgelegde bevoegdheid. Een terugvaloptie zodat het proces handmatig door kan, inclusief de achtergebleven wachtrij, met het vakmanschap daarvoor op peil. En een afspraak over wat een agent-incident is, wie beoordeelt, wie besluit tot stoppen, en hoe het incident terugkomt in de risicoanalyse en de evaluation set.

7. Uitfaseren en herbeoordelen

De levenscyclus eindigt niet bij operate. Een decommissioning-playbook: geheugen en tussenopslag verwijderen, credentials en de agent-identiteit intrekken, tools en koppelingen van derden loskoppelen, logs archiveren volgens het bewaarbesluit, en het besluit om te stoppen of op te schalen vastleggen met de evaluatieresultaten eronder. En een herbeoordelingsritme voor de risicoanalyse zelf, periodiek en gebeurtenisgedreven, na een incident, een modelwissel, een proceswijziging of een verschuiving in het dreigingsbeeld. De risicoanalyse is een startpunt met een houdbaarheidsdatum.

Uitgewerkt voorbeeld: inkoopfacturen

Het proces: inkoopfacturen ontvangen, matchen met de order, bij een match onder 10.000 euro automatisch goedkeuren, en alles daarboven of alles met een afwijking naar een mens leiden.

Juridische voorcheck. Geen besluiten over personen. Leveranciersgegevens gaan wel door de instructie en de logs, inclusief beperkte persoonsgegevens bij eenmanszaken. De verwerkersovereenkomst met de modelaanbieder is gecontroleerd en een lichte impactbeoordeling is vastgelegd.
Risicoanalyse. De grootste schadescenario's zijn een onterechte betaling, via factuurmanipulatie en versneld door schaal, en een gemiste betaling die de leveranciersrelatie schaadt.
Autonomiekeuze. Een workflow agent, want de taak heeft een vaste structuur en meer autonomie voegt niets toe. De stappen liggen vast in code; het model leest, matcht en stelt op binnen die stappen.
Walkthrough. Die bracht één impliciete control naar boven die in geen procedure stond: bij een gewijzigd rekeningnummer belt de medewerker de leverancier. Expliciet gemaakt als verplichte escalatie.
Het ontwerp. De systeeminstructie draagt de rol en de escalatieregel, niet de limiet. Opgehaalde kennis levert de actuele werkinstructie, de lijst met uitzonderingsleveranciers en het kortingsbeleid. De toolset bestaat uit precies vier functies: de factuur lezen, matchen met de order, de betaling goedkeuren, voorleggen aan een mens. De limietcheck zit in de goedkeuringstool zelf, en goedkeuren is technisch alleen mogelijk met een geldige matchreferentie. Er is geen tool om leveranciersgegevens te wijzigen, waardoor die actie onmogelijk is in plaats van verboden. Factuurinhoud wordt behandeld als niet-vertrouwde input: de invloed ervan op het model is niet volledig uit te sluiten, maar toolvalidatie, begrensde permissies en de vaste orchestration houden hem weg van de goedkeuringslimiet en de verplichte escalaties. De orchestration maakt matchen verplicht vóór goedkeuring, escaleert bij een gewijzigd rekeningnummer, escaleert na drie mislukte matches, en sluit elke run af met een logregel. Er is geen langetermijngeheugen; elke factuur is een verse taak.
De telling. Zeven controls zitten in deterministische lagen, zes process controls en één agent control, alle gedekt door negatieve tests die bij elke wijziging draaien. Eén control activity leunt op een probabilistische stap. Facturen van een leverancier op de uitzonderingslijst moeten naar menselijke beoordeling worden geleid, en de escalatie die volgt op een teruggegeven markering is afgedwongen in de orchestration. Het ophalen dat de lijstvermelding naar boven brengt is niet zelf de control; het is een invoer daarvoor, en het wordt getoetst met een evaluation set op een drempel die uit de schade-inschatting volgt, met het restrisico geaccepteerd en getekend. De zeven governance-afspraken hierboven maken de controleomgeving compleet zoals dit artikel die definieert.
De schil in de praktijk. De crediteurenmanager is eigenaar van de agent. De instructie en de tools leven onder versiebeheer met gescheiden omgevingen en een wijzigingsproces. De evaluation set bevat vijftig scenario's inclusief de randgevallen uit de walkthrough, opgesteld buiten het bouwteam, maandelijks hertest met opvolging van uitval. De teamleider beoordeelt wekelijks de logs, een dashboard volgt escalatie- en weigeringspercentages, en de override rate staat maandelijks op de agenda. Het stopmechanisme is belegd bij de eigenaar, en de handmatige terugval is gedocumenteerd en geoefend.

Het register: één bron, drie lezers

De kern van de control mapping begint in één register. Tien velden per control dragen die, en een operationeel register voegt er meer toe.

Risico: het faalscenario waaruit de control volgt.
Controlfamilie: process control of agent control.
Control objective: wat moet worden voorkomen of geborgd.
Control activity: de concrete handeling of systeemregel die dat bereikt. Dit gescheiden houden van het objective is wat voorkomt dat een register zich vult met uitspraken die niemand kan toetsen.
Afdwingpunt: tool, policy engine, permissie, orchestration, of de promptlaag met onderbouwing.
Laag: deterministisch of probabilistisch.
Verificatiemethode: binaire test of evaluation set met drempel, plus hertestritme.
Control owner: de rol die verantwoordelijk is dat de control werkt zoals beschreven.
Restrisico: wat na de control overblijft, uitgedrukt in de schade-inschatting.
Acceptant: de rol die het restrisico heeft geaccepteerd, met datum.

Drie lezers gebruiken het. De ontwerper ziet welk deel van de agent welke control draagt. De tweede lijn ziet of de vertaling compleet is en de onderbouwingen zijn getekend. De auditor ziet of het afdwingpunt bestaat, of het werkt, en of de keten van risico tot acceptatie sluit. Die keten, van een risico in het bedrijfsproces naar een afdwingpunt in de agent en terug naar getekend bewijs, is wat een agent auditeerbaar maakt in plaats van alleen werkend.

Wat dit artikel niet behandelt

Drie onderwerpen vallen bewust buiten deze scope:

Multi-agent-omgevingen, waar agents met elkaar communiceren en fouten zich voortplanten, wat de analyse verandert zodra er meer dan één agent is.
De kwaliteit van de bronnen zelf, want een agent op een zwakke procedure automatiseert de zwakke procedure, en documentkwaliteit is een vak apart.
De menselijke kant van de beoordelaarsrol, training, alert fatigue en capaciteit, die de override rate wel raakt maar niet oplost.

Veelgestelde vragen

Waar horen controls te leven in een AI-agent?: In de deterministische lagen: in de tools, de policy engine, de permissies of de orchestration. Proceskennis kan leven in de systeeminstructie en in opgehaalde documenten, maar een control die alleen in prompttekst bestaat is een verzoek aan een probabilistisch systeem, geen afgedwongen limiet.
Waarom is een regel in de systeemprompt geen control?: Omdat het model hem verkeerd kan wegen, kwijt kan raken tussen concurrerende instructies, of eruit kan worden gemanipuleerd via inhoud die het verwerkt. Erger nog: het model voldoet mogelijk vaak genoeg in beperkt testen om de regel betrouwbaar te laten lijken. Dat is een ondeugdelijke opzet die feilloos lijkt te werken, en dat levert schijnzekerheid op in plaats van beheersing.
Hoe toetst u controls in een AI-agent?: Op twee manieren, passend bij de twee soorten onderdelen. Deterministische controls toetst u binair met negatieve tests die elke keer moeten falen, geautomatiseerd in de bouwpijplijn. Probabilistisch gedrag toetst u statistisch met een evaluation set: realistische scenario's, een score tegen een drempel die uit de risicoanalyse volgt, en een vast hertestritme.
Wat is het verschil tussen process controls en agent controls?: Process controls bestonden al in het bedrijfsproces, zoals limieten, functiescheiding en goedkeuringsstappen, en hebben een nieuw afdwingpunt in de agent nodig. Agent controls richten zich op risico's die pas ontstaan doordat een agent het proces uitvoert: manipulatie via verwerkte inhoud, memory policy, beperking van de toolset, integriteit van de toeleveringsketen, en least privilege voor de agent-identiteit.
Wat hoort er in een controlregister voor een AI-agent?: Per control: het risico waaruit hij volgt, de familie, het control objective, de control activity, het afdwingpunt, of die laag deterministisch of probabilistisch is, de verificatiemethode met hertestritme, de control owner, het restrisico, en de rol die het heeft geaccepteerd met datum.

WetsverwijzingenArt. 22 GDPR

Lees verder metAgentic AI: wat verandert er wanneer het systeem handelt, niet alleen beslist

Delen Deel op LinkedIn