De 4 lagen van betrouwbare AI-agents: een praktisch framework

Vorige week analyseerde ik twee papers over AI-agent capabilities. De conclusie: agents kunnen meer dan we denken, maar minder dan marketing beweert. De vraag die organisaties nu stellen is: hoe bouw je agents die je kunt vertrouwen?

De EU AI Act, BIO2, en NIS2 verplichten allemaal een vorm van "betrouwbaarheid." Maar geen van deze frameworks vertaalt dat naar concrete architectuur. Dit artikel doet dat wel — in 4 lagen, met concrete controles, en directe mappings naar compliance vereisten.

Laag 1: Orchestratie — Wie mag welke agent starten?

De orchestratielaag bepaalt wie een agent kan instantiëren, welke permissies die agent krijgt, en hoe lang die agent mag draaien. Dit is de meest onderschatte laag — en de meest kritieke voor compliance.

De risico's:

• Shadow AI: medewerkers starten agents zonder goedkeuring
• Excessive agency: een agent krijgt meer rechten dan nodig
• Orphaned agents: agents blijven draaien zonder monitoring
• Privilege escalation: een agent start een andere agent met hogere rechten

De controles (EU AI Act mapping):

| Control | AI Act Artikel | Implementatie | |---------|---------------|---------------| | Agent inventory | Art. 12 (record keeping) | Elke agent geregistreerd met eigenaar, doel, tools | | Start authorization | Art. 14 (human oversight) | OIDC + RBAC, geen anonieme agent spawning | | Runtime limits | Art. 15 (accuracy) | Max sessieduur, max tool calls, max tokens | | Nested agent blocking | Art. 10 (transparancy) | Agents mogen geen andere agents spawnen zonder approval | | Kill switch | Art. 14 (human oversight) | Operator kan elke agent sessie realtime beëindigen |

Praktisch voorbeeld: Een gemeente wil een agent inzetten voor uitkeringsbeoordeling. De orchestratielaag vereist:

• Medewerker logt in met SSO (eHerkenning of interne IdP)
• Medewerker start agent via gecontroleerd portaal (geen vrije CLI)
• Agent krijgt alleen toegang tot specifieke dataset (geen HR, geen andere uitkeringen)
• Sessie max 30 minuten, max 10 documenten, max 100.000 tokens
• Alle beslissingen worden gelogd met medewerker ID en timestamp
• Medewerker kan sessie anytime killen

Laag 2: Model — Welk model gebruik je, en hoe monitor je het?

Het model is het brein van de agent. Maar niet alle modellen zijn gelijk — en niet alle modellen zijn geschikt voor alle toepassingen.

De risico's:

• Hallucinatie: het model genereert onware informatie
• Concept drift: het model presteert slechter op nieuwe data
• Bias: het model reproduceert bestaande vooroordelen
• Jailbreak: het model wordt overgehaald tot ongewenst gedrag

De controles:

| Control | AI Act Artikel | Implementatie | |---------|---------------|---------------| | Model versioning | Art. 12 (record keeping) | Elk model geregistreerd met versie, training data, capabilities | | Performance monitoring | Art. 15 (accuracy) | Continu monitoring van accuracy, latency, error rates | | Bias auditing | Art. 10 (transparancy) | Periodieke bias scans op representatieve testsets | | Red teaming | Art. 15 (cybersecurity) | Gestructureerde red team exercises om jailbreaks te vinden | | Explainability | Art. 14 (human oversight) | Elke beslissing kan worden uitgelegd (chain-of-thought logging) |

Praktisch voorbeeld: Een belastingdienst gebruikt een LLM voor vragenbeantwoording. De modellaag vereist:

• Gekozen model: geverifieerd, geaudit, met bekende limitations
• Hallucinatie detectie: elke output wordt gecontroleerd tegen bronnen
• Concept drift monitoring: maandelijkse accuracy test op nieuwe vragen
• Red teaming: kwartaalscan op jailbreak prompts en data exfiltratie
• Explainability: elke antwoord bevat een "waarom" sectie met bronvermelding

Laag 3: Tool — Welke tools heeft de agent, en hoe controleer je die?

Agents gebruiken tools — APIs, databases, bestanden, berekeningen. Elke tool is een potentiële aanvalsroute.

De risico's:

• Unauthorized tool use: agent gebruikt een tool die niet geautoriseerd is
• Tool parameter injection: kwaadaardige parameters aan tool calls
• Data leakage via tools: agent exfiltreert data via een web API tool
• Tool cascading: een tool roept een andere tool aan, buiten controle

De controles:

| Control | AI Act Artikel | Implementatie | |---------|---------------|---------------| | Tool allowlist | Art. 10 (transparancy) | Alleen geregistreerde, geverifieerde tools beschikbaar | | Parameter validation | Art. 15 (cybersecurity) | Alle tool parameters gevalideerd tegen schema | | Tool call logging | Art. 12 (record keeping) | Elke tool call gelogd met parameters, output, timestamp | | Data loss prevention | Art. 14 (human oversight) | Tool outputs gescand op PII, secrets, gevoelige data | | Tool isolation | Art. 15 (accuracy) | Tools draaien in sandbox, geen directe database toegang |

Praktisch voorbeeld: Een rechtbank gebruikt een agent voor juridische research. De toollaag vereist:

• Alleen toegang tot publieke jurisprudentie databases (geen interne systemen)
• Web search alleen naar allowlisted domeinen (rechtspraak.nl, eur-lex.europa.eu)
• File read/write alleen in geïsoleerde project directory
• Database queries alleen via geparametriseerde stored procedures
• Alle tool outputs gescand op case numbers, namen, en andere PII

Laag 4: Data — Welke data passeert de agent, en waar log je dat?

Data is de brandstof van agents. Maar data is ook het grootste risico — zeker in de publieke sector.

De risico's:

• Training data leakage: prompts bevatten gevoelige data die in het model terecht komt
• Inference data exposure: outputs bevatten meer data dan de gebruiker mag zien
• Audit trail gaps: je kunt niet reconstrueren welke data de agent heeft gezien
• Data retention overschrijding: data wordt langer bewaard dan wettelijk toegestaan

De controles:

| Control | AI Act Artikel | Implementatie | |---------|---------------|---------------| | Data classification | Art. 10 (transparancy) | Alle input data geclassificeerd voor verwerking | | Prompt PII scanning | Art. 14 (human oversight) | Alle prompts gescand op PII, secrets, gevoelige data | | Output filtering | Art. 15 (accuracy) | Alle outputs gescand op ongeautoriseerde data | | Audit logging | Art. 12 (record keeping) | Alle data interactions gelogd, 7 jaar retentie | | Data retention | AVG Art. 5 | Automatische verwijdering na wettelijke retentietermijn | | Right to explanation | AI Act Art. 14 | Gebruiker kan uitleg vragen over elke beslissing |

Praktisch voorbeeld: Een zorginstelling gebruikt een agent voor patient dossier analyse. De datalaag vereist:

• Input: alleen gepseudonimiseerde data, nooit BSN of volledige namen
• Output: alleen geaggregeerde statistieken, nooit individuele patient data
• Logging: elke data interactie gelogd met pseudoniem, timestamp, medewerker ID
• Retentie: logs 7 jaar (wettelijk verplicht), daarna automatisch verwijderd
• Explainability: elke analyse kan worden gereconstrueerd tot bron data

Het framework samengevat

De 4 lagen vormen een defense in depth voor AI-agents:

┌─────────────────────────────────────┐
│  L1: Orchestratie                   │  Wie mag starten? Human oversight.
│  L2: Model                          │  Welk model? Monitoring + red teaming.
│  L3: Tool                           │  Welke tools? Allowlist + sandbox.
│  L4: Data                           │  Welke data? Classificatie + audit.
└─────────────────────────────────────┘

Geen enkele laag is voldoende. Samen vormen ze een verdedigbaar perimeter voor agentic AI in gereguleerde omgevingen.

Implementatie: start klein

Je hoeft niet alle 4 lagen tegelijk te implementeren. Start met:

1. Week 1: Inventariseer alle agents in je organisatie (Laag 1)
2. Week 2: Kies één model en documenteer zijn capabilities en limitations (Laag 2)
3. Week 3: Maak een tool allowlist voor je eerste agent (Laag 3)
4. Week 4: Implementeer prompt logging en PII scanning (Laag 4)

Na deze 4 weken heb je een minimum viable governance voor agentic AI. Dat is meer dan 90% van de organisaties nu hebben.

De compliance connectie

Dit framework is niet theoretisch. Het is direct gemapt naar:

• EU AI Artikel 12 (record keeping) → L1, L3, L4 logging
• EU AI Artikel 14 (human oversight) → L1 orchestratie, L4 explainability
• EU AI Artikel 15 (accuracy + cybersecurity) → L2 monitoring, L3 sandboxing
• AVG Artikel 5 (data minimization) → L4 classification, retention
• BIO2 (toegangsbeheer, detectie, respons) → L1 authorization, L3 logging

Voor organisaties die een DPIA moeten doen voor high-risk AI: dit framework vormt de technische implementatie sectie.

---

DjimIT helpt organisaties met AI governance, EU AI Act compliance, en agentic security. Wil je dit framework toepassen in jouw organisatie? Neem contact op.