Technische Samenvatting: SARC – Een Governance-by-Architecture Framework voor Agente AI-systemen

1. Probleemstelling

Agente AI-systemen, die waarnemen, plannen en handelen via tools en sub-agenten, komen sneller in gereguleerde omgevingen dan de governance-infrastructuur is rijp geworden. Er bestaat een kritieke structurele mismatch: regelgevende verplichtingen (bijv. menselijk toezicht, risicobeheer) worden doorgaans geëvalueerd via post-hoc-documentatie of gekoppeld aan prompts en dashboards. Dit creëert een "structurele mismatch" waarbij beperkingen die bedoeld zijn om uitvoering te beperken, vaak pas worden beoordeeld nadat de actie heeft plaatsgevonden.

Huidige benaderingen lijden aan specifieke faalmodi:

• Prompt-beveiliging: Modellen kunnen instructies via tools negeren, herbekijken of omzeilen.
• Output-filtering: Kan geen overtredingen opvangen die tot uiting komen via neveneffecten op de wereld in plaats van zichtbare tekst.
• Post-hoc audit: Documenteert overtredingen maar kan deze niet voorkomen.
• Workflow-regels: Vaak ontoereikend in dynamisch uitbreidende actieruimten, tenzij gekoppeld aan een volledig register en afgedwongen bij dispatch.

Het artikel betoogt dat governancecontroles moeten verschuiven van het zijn gekoppeld aan artefacten (prompts, logs) naar het zijn gekoppeld aan uitvoering binnen de systeemarchitectuur.

2. Methodologie: Het SARC-framework

De auteurs introduceren SARC (State, Action Space, Reward, Constraints), een governance-by-architecture framework. Waar $S$, $A$ en $R$ standaard Reinforcement Learning (RL) primitieven zijn, is $C$ (Constraints) de nieuwe bijdrage. Het behandelt beperkingen als eerste klas specificatieobjecten, gelijk aan staat en beloning, en dwingt deze af op gedeclareerde punten in de agent-runtime.

2.1 De Specificatietuple

Een SARC-specificatie wordt gedefinieerd als $\Sigma = \langle S, A, R, C \rangle$.

• Beperkingen ($C$): Gepartitioneerd in drie klassen:
  • $C_h$ (Hard): Overtredingen zijn onder geen enkel beleid toegestaan.
  • $C_s$ (Soft): Overtredingen zijn toelaatbaar tegen een gedeclareerde marginale kost.
  • $C_e$ (Escalatie): Voorwaarden die overdracht van controle vereisen aan een menselijke operator.
• Beperkingsstructuur: Elke beperking $c \in C$ is een vijftuple $\langle src, class, pred, verif, resp \rangle$, waarbij:
  • $src$: Bron (regelgevend, contractueel, etc.).
  • $class$:$h$, $s$, of $e$.
  • $pred$: Predicaat over staat, actie en tijd.
  • $verif$: Verificatiemechanisme (pre-conditie, runtime-monitor, post-hoc).
  • $resp$: Responsprotocol (blokkeren, loggen, escaleren, afbreken).

2.2 Runtime-afdwingingsarchitectuur

Beperkingen compileren tot vier benoemde afdwingingslocaties binnen de agent-lus:

1. Pre-Action Gate (PAG): Evalueert voor dispatch. Wordt gebruikt voor harde beperkingen en voorspellende escalaties die alleen op basis van staat en actie beslisbaar zijn.
2. Action-Time Monitor (ATM): Evalueert tijdens uitvoering (bijv. het omhullen van tool-aanroepen). Wordt gebruikt voor beperkingen die afhankelijk zijn van gedeeltelijke outputs (kostenaccumulatie, streaming-inhoud).
3. Post-Action Auditor (PAA): Evalueert na voltooiing. Wordt gebruikt voor het vergelijken van de post-actie staat met de pre-actie staat (drift, verificatie van neveneffecten).
4. Escalation Router (ER): Routeert gemarkeerde acties naar menselijke operators met een gebonden wachtrijlatentie ten opzichte van het reversibiliteitsvenster van de actie.

2.3 Multi-Agent Extensie

Voor multi-agent workflows introduceert SARC:

• Beperkingspropagatie: Beperkingen erven af in de aanroepketen. Als een beperking niet beslisbaar is op het niveau van een sub-agent, wordt deze geëvalueerd op het diepste beslisbare niveau ("beslisbaarheidsredding").
• Autoriteitsintersectie: Autoriteit is de intersectie van alle prinsen en agenten in de aanroepketen; deze is monotoon niet-stijgend.
• Attributiebehoudende Trace-bomen: De audittrail is een hiërarchische boom, geen platte sequentie, die de volledige keten van principal-agent-relaties behoudt om attributiedilutie te voorkomen.

2.4 Formele Eigenschappen

• Beperking van Reward Shaping: Het artikel levert een formeel tegenvoorbeeld (Propositie 1) dat aantoont dat eindige reward-penaliteiten over het algemeen geen garantie kunnen bieden voor het voldoen aan harde beperkingen bij lage-kans, hoge-opbrengst overtredingen. Harde beperkingen moeten dus architecturale predicaten zijn, geen reward-termen.
• Specificatie-Trace-correspondentie: Een systeem is "SARC-conform" als het acht invarianten voldoet (bijv. pre-actie toelaatbaarheid, trace-afleiding, volledigheid van afdwinging). Dit zorgt ervoor dat voor elke actie in een trace een auditor mechanisch kan verifiëren welke beperkingen van toepassing waren en welke respons werd genomen, zonder toegang tot het model of prompts.

3. Belangrijkste Bijdragen

1. Beperkingsspecificatiemodel: Een op klassen gebaseerd model ($\langle src, class, pred, verif, resp \rangle$) dat implementatie-onafhankelijk is maar specifieke metadata vereist voor uitvoerbaarheid en auditbaarheid.
2. Agent-lus afdwingingsarchitectuur: Een discipline die beperkingsklassen koppelt aan specifieke afdwingingspunten (PAG, ATM, PAA, ER), waardoor governance wordt omgezet van documentatie naar uitvoeringscontrole.
3. Controleerbare auditbaarheid: Een formele definitie van "auditable by construction" en een prototype checker die runtime-traces verifieert tegen specificaties in $O(|T| \cdot |C|)$ tijd.
4. Multi-Agent Extensie: Mechanismen voor beperkingspropagatie, autoriteitsintersectie en trace-bomen om complexe enterprise-topologieën te hanteren.
5. Regelgevende compilatiepad: Een methode om regelgevende clausules (bijv. Artikel 14 van de EU AI Act) af te beelden naar uitvoerbare predicaten en runtime-controles.

4. Empirische Evaluatie

De auteurs voerden een reproduceerbare synthetische evaluatie uit op een inkooptaak ($H=1.000$ bestellingen, 50 zaden) waarbij SARC werd vergeleken met vier baselines: Post-hoc Audit, Output Filtering, Workflow Rules en alleen Policy-as-Code (PaC).

Resultaten:

• Harde Overtredingen: SARC voerde nul overtredingen van harde beperkingen uit onder exacte predicaten, wat overeenkomt met de Policy-as-Code-baseline maar beter presteert dan Output Filtering en Post-hoc Audit.
• Zachte Beperkingen: SARC verlaagde soft-window overschrijdingen met 89,5% ten opzichte van de alleen Policy-as-Code-baseline. Dit werd toegeschreven aan de expliciete plaatsing van een throttling-respons bij de Post-Action Auditor (PAA) in plaats van te vertrouwen op intrinsieke prestaties.
• Residuele Overtredingen: Bij imperfecte afdwinging (predicaatruis of afdwingingsfalen) schaalden residuele overtredingen met de afdwingingsstack-fout ($\epsilon_{pred} + \epsilon_{exec}$) in plaats van met de omgevingsovertredingskans.
• Latentie Trade-off: SARC leidde tot een per-stap latentie van ~21ms (vs. 0ms voor post-hoc), wat de expliciete kosten van runtime-governance aantoont.

5. Betekenis en Claims

Het artikel positioneert SARC niet als een veiligheidsgarantie of een juridische compliance-certificering, maar als een architecturale substraat dat verplichtingen uitvoerbaar, inspecteerbaar en auditabel maakt tijdens runtime.

• Verschuiving van Artefact naar Uitvoering: De primaire bijdrage is de verschuiving van het koppelen van beperkingen aan artefacten (prompts, logs) naar het koppelen ervan aan uitvoeringspaden.
• Auditable by Construction: SARC maakt "auditable by construction" mogelijk, waarbij de audittrail wordt gegenereerd door de naleving van het systeem aan zijn specificatie, in plaats van reconstructie uit logs achteraf.
• Regime B: Het framework is ontworpen voor "Regime B" implementaties (gereguleerd, onomkeerbaar of omgevingen met asymmetrisch verlies) waarbij het weglaten van het beperkingscomponent $C$ een specificatie onvolledig maakt.
• Economische Duidelijkheid: Door het afdwingen van expliciete declaratie van operationele punten en reversibiliteitsvensters, maakt SARC de trade-offs tussen false positives, false negatives en operatorcapaciteit zichtbaar als kapitaalallocatiebeslissingen.

De auteurs concluderen dat SARC systemen op zichzelf niet veilig maakt; het biedt eerder de structurele discipline die nodig is om veiligheid en compliance te engineeren, door optimalisatie ($R$), capaciteit ($A$) en toelaatbaarheid ($C$) te scheiden om te voorkomen dat systemen falen als onwaarneembare anomalieën.