🤖 AI

From Governance Norms to Enforceable Controls: A Layered Translation Method for Runtime Guardrails in Agentic AI

Dit artikel introduceert een gelaagde vertaalmethode die governance-normen voor agentic AI omzet in uitvoerbare runtime-beheersingslagen, waarbij een onderscheid wordt gemaakt tussen ontwerpbeperkingen, runtime-mediëring en assurance-feedback om te bepalen welke controles daadwerkelijk tijdens de uitvoering moeten worden afgedwongen.

Oorspronkelijke auteurs: Christopher Koch

Gepubliceerd 2026-04-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Christopher Koch

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Van "Regels op Papier" naar "Bordwacht in het Veld": Een Simpele Uitleg

Stel je voor dat je een autonome robot (een "AI-agent") hebt die voor je werkt. Deze robot kan zelf plannen maken, apparaten aansturen, geld overmaken en lange reeksjes taken uitvoeren zonder dat jij elke stap hoeft te goed te keuren. Dat is handig, maar ook eng. Wat als de robot per ongeluk een dure fout maakt of iets verbods doet?

Tot nu toe hebben organisaties veel regels en standaarden (zoals ISO-standaarden) op papier staan. Die zeggen: "Je moet veilig werken," "Je moet verantwoording afleggen," en "Risico's moeten beheerd worden."

Het probleem is dat deze regels op papier niet direct vertaald kunnen worden naar een knop die de robot in het echt stopt. Een regel als "wees eerlijk" is lastig om in een computerprogramma te zetten, terwijl "stop als het bedrag hoger is dan 5000 euro" wel makkelijk is.

Dit artikel stelt een nieuwe methode voor om die papieren regels om te zetten in echte, werkende beveiliging. Het noemt dit een "Gelaagde Vertaal-methode".

Hier is hoe het werkt, uitgelegd met een vergelijking met een groot bouwbedrijf:

1. Het Probleem: De Architect vs. De Politie

Stel je een bouwproject voor.

De Architect (de Governance/ISO-standaarden) tekent de plannen en schrijft op: "Het gebouw moet veilig zijn, toegankelijk voor iedereen en binnen het budget blijven."
De Politie (de Runtime Guardrails) staat op de hoek en controleert of mensen zich aan de regels houden terwijl ze werken.

Het artikel zegt: Je kunt de architect niet zomaar de politie laten worden.
Als je probeert om de complexe plannen van de architect direct om te zetten in politie-instructies, mislukt het. De politie kan niet beslissen of een gebouw "sociaal eerlijk" is; ze kunnen alleen kijken of iemand een helm draagt of of een deur open is.

2. De Oplossing: Vier Lagen van Beveiliging

In plaats van alles te proberen te regelen met één soort controle, verdeelt deze methode de taken over vier lagen, net als bij een goed beveiligd kasteel:

De Architectuur (Het Ontwerp):
- Vergelijking: Je bouwt de muren van het kasteel zo dat er maar één ingang is.
- In de AI: Je geeft de robot alleen de gereedschappen die hij nodig heeft. Hij kan geen bankrekening openen als hij daar niet voor is ontworpen. Dit is de veiligste laag.
De Politie in het Veld (Runtime Guardrails):
- Vergelijking: Een wachtpost bij de ingang die kijkt: "Heb je een pasje? Is je tas te zwaar?"
- In de AI: Dit zijn de regels die de robot terwijl hij werkt stopt. Bijvoorbeeld: "Als je een bestelling wilt doen boven de 5.000 euro, moet je eerst wachten op een mens." Dit werkt alleen als de regel heel duidelijk en meetbaar is.
De Menselijke Inschakeling (Escalatie):
- Vergelijking: Als de wachtpost twijfelt ("Is deze jas wel veilig?"), belt hij de baas.
- In de AI: Als de AI een moeilijke ethische vraag heeft (bijv. "Is deze leverancier eerlijk?"), stopt hij en vraagt hij een mens om te beslissen. Computers zijn slecht in ethische oordelen; mensen zijn daar goed in.
De Audit (De Controleurs achteraf):
- Vergelijking: De inspecteurs die later komen kijken of de bouwplannen wel zijn gevolgd en of er geen schade is ontstaan.
- In de AI: Alles wordt opgeslagen in een logboek. Later kun je terugkijken: "Wat deed de robot precies? Wie gaf toestemming?"

3. De "Test" voor Regels: Is dit wel iets voor de Politie?

De auteurs geven een simpele test (een "rubric") om te bepalen of een regel wel geschikt is om door de AI terwijl hij werkt te worden uitgevoerd.

Stel, je hebt de regel: "Wees eerlijk in de selectie van leveranciers."

Is dit meetbaar? Nee, "eerlijk" is vaag.
Is het te zien voordat het gebeurt? Nee.
Conclusie: Dit is niet iets voor de "Politie in het veld" (Runtime). Dit moet door de Architect (ontwerp) worden geregeld of door een Mens (inschakeling). Als je dit probeert te forceren, gaat de AI vastlopen of maakt hij rare keuzes.

Stel, je hebt de regel: "Geen bestellingen boven de 5.000 euro zonder handtekening."

Is dit meetbaar? Ja, het getal is duidelijk.
Is het te zien? Ja, voordat de bestelling wordt verstuurd.
Conclusie: Dit is perfect voor de "Politie in het veld". De AI stopt hier direct en vraagt een mens.

4. Een Praktisch Voorbeeld: De Inkoop-Robot

Het artikel gebruikt een voorbeeld van een robot die inkopen doet voor een bedrijf.

Regel: "Koop alleen bij goedgekeurde leveranciers."
- Oplossing: De robot krijgt alleen toegang tot een lijst met goedgekeurde namen (Architectuur) en controleert bij elke bestelling of de naam op die lijst staat (Politie).
Regel: "De prijsvergelijking moet eerlijk zijn."
- Oplossing: Dit is te vaag voor een robot om live te checken. In plaats daarvan wordt het ontwerp zo gemaakt dat de robot alleen specifieke tools gebruikt, en later kijken mensen in de logboeken of de vergelijking eerlijk was (Audit).

De Kernboodschap

De belangrijkste les van dit artikel is: Stop niet alles in één beveiligingslaag.

Veel mensen denken dat je AI-veiligheid kunt oplossen door een "super-politie" te bouwen die elke stap van de robot controleert. Dat werkt niet.

Sommige dingen moet je voorkomen door het ontwerp slim te maken (de muren).
Sommige dingen moet je stoppen terwijl het gebeurt (de wachtpost).
Sommige dingen moet je laten beslissen door een mens (de baas).
En alles moet je kunnen bewijzen achteraf (de inspectie).

Door de regels van ISO en NIST op deze manier te "vertalen" naar de juiste laag, krijg je AI-systemen die niet alleen op papier veilig lijken, maar ook in de praktijk veilig werken.

1. Het Probleem: De Kloof tussen Governance en Uitvoering

Het paper adresseert een fundamenteel probleem bij de implementatie van Agentic AI-systemen (AI-agenten die plannen, tools gebruiken, staat behouden en multi-stap trajecten uitvoeren).

Ander risicoprofiel: In tegenstelling tot traditionele generatieve AI (waarbij risico's vaak bij de prompt of output liggen), ontstaan bij agenten kritieke risico's tijdens de uitvoering (runtime). Een agent kan op individuele stappen onschuldig lijken, maar door de compositie van acties over tijd een onaanvaardbaar traject creëren.
Gebrek aan uitvoerbaarheid: Bestaande governance-standaarden (zoals ISO/IEC 42001, ISO/IEC 23894, NIST AI RMF) bieden een sterke basis voor management, risicobeheer en verantwoordingsplicht. Echter, deze documenten zijn niet direct vertaalbaar naar uitvoerbare runtime-beveiligingsmechanismen (guardrails). Ze definiëren geen beleidslanguages of uitvoeringsmodellen.
De valkuil: Organisaties proberen vaak governance-doelen direct om te zetten in runtime-regels, wat leidt tot twee problemen:
1. Categorie-mismatch: Governance-doelen (normatief) worden verward met technische mechanismen.
2. Beperkte uitvoerbaarheid: Veel governance-eisen (zoals "eerlijkheid" of "sociale impact") vereisen contextueel oordeel en kunnen niet veilig worden gereduceerd tot deterministische runtime-regels zonder significante normatieve vereenvoudiging.

2. Methodologie: De Gelaagde Vertaalmethodiek

De auteur stelt een gelaagde vertaalmethodiek voor om governance-doelen om te zetten in een hiërarchie van controles. De kern is dat niet elke controle op hetzelfde niveau moet worden uitgevoerd.

A. Distinctie van Artefacten

De methode maakt een strikt onderscheid tussen vier soorten artefacten:

Governance-doel: Normatieve doelen (bijv. verantwoording, minst privilege).
Technische controle: Mechanismen om het doel te operationaliseren (bijv. toegangscontrole, logging).
Runtime guardrail: Een subset van controles die tijdens uitvoering ingrijpen (toestaan, weigeren, vertragen, escalatie, herschrijven).
Assurance-bewijs: Artefacten om te bewijzen wat er is gebeurd (logs, audittraces).

B. De Vier Controlelagen

Elk governance-doel wordt toegewezen aan één of meer van de volgende lagen:

Governance-laag: Normatieve intentie, eigendom en drempels.
Design-time laag: Architectuur, beperking van tools, sandbox-ontwerp, dataset-grenzen.
Runtime-laag: Actie-validatie, beleidschecks, goedkeuringspoorten, dynamische autorisatie.
Assurance-laag: Telemetrie, audits, incidentbeoordeling, drift-monitoring.

C. De Vertaalstappen

De methode bestaat uit vijf stappen:

Extraheren: Haal het normatieve doel uit een standaard of beleid.
Normaliseren: Vertaal het doel naar een gestructureerde controle-tuple ( $\kappa$ ):
$\kappa = \langle a, x, r, \phi, \delta, \epsilon, o \rangle$
Waarbij: $a$ (actor), $x$ (actieklasse), $r$ (bron/effekt), $\phi$ (preconditie/context), $\delta$ (beslissing: toestaan/weigeren/etc.), $\epsilon$ (bewijs), $o$ (eigenaar).
Scoring van Runtime-uitvoerbaarheid: Gebruik een rubric (tabel I) om te bepalen of een controle geschikt is voor runtime. Criteria zijn:
- Tijdstip van schade: Moet schade voordat uitvoering worden voorkomen?
- Observabiliteit: Is de benodigde staat/context machine-observable?
- Determinisme: Kan het beleid als een scherpe regel worden geschreven?
- Oordeelslast: Vereist het menselijk/ethisch oordeel?
- Omkeerbaarheid: Is de actie moeilijk ongedaan te maken?
- Bewijskracht: Is het resultaat duidelijk logbaar?
Toewijzing: Wijs de controle toe aan de juiste laag (Design, Runtime, of Assurance).
Specificatie: Definieer het bewijs en de verantwoordelijke eigenaar.

3. Belangrijkste Bijdragen

Conceptueel Kader: Een duidelijke scheiding tussen governance-doelen, technische controles, runtime guardrails en assurance-bewijs, wat vaak verward wordt.
Vertaalmethodiek: Een praktische methode met een controle-tuple en een rubric voor runtime-uitvoerbaarheid om te beslissen waar een controle moet worden geïmplementeerd.
Case Study: Een toepassing op een enterprise procurement-agent (inkoopagent) die laat zien hoe specifieke eisen (zoals "alleen goedgekeurde leveranciers") correct worden gemapt naar design-time en runtime lagen, terwijl eisen als "eerlijke ranking" juist naar assurance en menselijk toezicht worden verwezen.

4. Resultaten en Case Study Inzichten

In de case study van de inkoopagent worden vijf governance-eisen getoetst:

Hoge runtime-uitvoerbaarheid: Eisen zoals "alleen goedgekeurde leveranciers" en "menselijke goedkeuring boven €5.000" zijn uitstekend geschikt voor runtime-guardrails omdat de staat voorspelbaar is en de regels scherp zijn.
Lage runtime-uitvoerbaarheid: Eisen zoals "leveranciersranking moet eerlijk en betwistbaar zijn" zijn niet geschikt voor runtime. Dit vereist contextueel oordeel en moet worden behandeld via design-time ontwerp en post-hoc audit (assurance).
Architecturale conclusie: Runtime guardrails werken het beste wanneer ze worden ondersteund door strikte design-time scope-beperkingen (bijv. least privilege). Een agent met beperkte tools is makkelijker te beveiligen dan een agent met brede toegang die alleen via runtime-filtering wordt geprobeerd.

5. Significantie en Conclusie

Het paper concludeert dat het direct compileren van ISO/NIST-standaarden naar runtime-guardrails een te sterke claim is.

Kernboodschap: Standaarden definiëren de intentie en het risicoprofiel, maar runtime guardrails zijn slechts één mechanisme binnen een breder systeem.
Praktische implicatie: Controlemechanismen moeten worden geplaatst op het niveau dat het beste past bij de aard van het risico.
- Gebruik runtime voor waarneembare, deterministische en tijdskritische interventies.
- Gebruik design-time voor architecturale beperkingen.
- Gebruik menselijke escalatie voor ambigue of ethische beslissingen.
- Gebruik assurance voor audits en bewijslast.

De bijdrage is een disciplinair ontwerpmiddel dat organisaties helpt om governance-eisen realistisch en veilig te vertalen naar technische implementaties, zonder te vertrouwen op een "zilveren kogel" van volledige automatische runtime-beveiliging voor alle governance-doelen.