Risicoanalyse voor agentic AI: van architectuurkeuzes naar control objectives

Bijgewerkt: juli 2026

De stap tussen architectuur en controls

De architectuur van een AI-agentAI-agentEen systeem dat zijn omgeving waarneemt, beslist en handelingen verricht richting een doel, tools aanroept, plannen uitvoert. Autonomie van handelen vereist allowlists, goedkeuringspoorten, sandboxing, logging en een kill switch. Zie agentic AI, kill switch.Open full entry → bepaalt waar hij kennis bewaart, beslissingen neemt en bevoegdheid uitoefent. Zeven keuzes dragen die architectuur: de zes bouwblokken waarlangs proceskennis de agent bereikt, te weten het model, de systeeminstructie, opgehaalde kennis, de tooldefinities, de orchestrationorchestrationDe vaste programmacode rond een AI-model die bepaalt welke stappen in welke volgorde lopen, wat verplicht is, en waar een mens betrokken is. Omdat het gewone software is, gedraagt het zich voorspelbaar en kan het afdwingbare controls dragen, en daarom hoort processtructuur daar en niet in prompttekst. Zie afdwingpunt, guardrail.Open full entry → en het geheugen, plus de autonomie die de agent krijgt. Die keuzes zijn op zichzelf geen risicorisicoIn de termen van de EU AI Act de combinatie van de waarschijnlijkheid dat een schade optreedt en de ernst ervan als dat gebeurt. De schakel tussen een principe (via de schade die het zou schenden) en een control (de maatregel die het vermindert). Het benoemen van de schade en het inschatten van het risico is op grond van Art. 9 vereist voordat een maatregel wordt gekozen. Zie schade, control, restrisico.Open full entry →'s. Een tool dat betalingen kan goedkeuren is een capability, geen fout. Ze worden risico's zodra ze de mogelijkheid van schadeschadeDe concrete schade die een AI-systeem kan aanrichten en die een principe van verantwoorde AI beoogt te voorkomen: in de termen van de EU AI Act schade aan iemands gezondheid, veiligheid of grondrechten. Schade is de brug tussen een abstract principe en een bestuurbaar risico; governance wordt operationeel op het moment dat een organisatie de specifieke schades benoemt die ze wil voorkomen. Voor eerlijkheid is een schade dat een groep stelselmatig slechtere uitkomsten krijgt vanwege een kenmerk dat niet had mogen meetellen. Zie principe, risico.Open full entry → scheppen, en dat is een apart oordeel.

Dit artikel maakt dat oordeel expliciet. Het neemt de vastgelegde architectuurkeuzes van een agent en vertaalt die naar risicoscenario's en control objectivescontrol objectiveEen uitspraak over de uitkomst die een control moet bereiken, bijvoorbeeld "ongeautoriseerde betalingen mogen technisch niet uitvoerbaar zijn". Het benoemt wat waar moet zijn in plaats van wat er gebouwd moet worden, waardoor meer dan één control activity eraan kan voldoen. Het objective gescheiden houden van de activity is wat een controlregister toetsbaar houdt. Zie control activity, afdwingpunt.Open full entry →, en dat is precies wat de controleomgeving als invoer nodig heeft.

De methode verandert niet; de invoer wel

AI risk management heeft al een vorm: herken het risico, beoordeel hoe waarschijnlijk en hoe ernstig het is voor uw specifieke systeem, en beheers het met maatregelen die u kunt toetsen. Dat patroon, en de keten erachter van principeprincipeEen van de zeven waarden van verantwoorde AI waaraan een bestuurd systeem zou moeten voldoen (eerlijkheid, veiligheid en betrouwbaarheid, privacy, beveiliging en robuustheid, transparantie en uitlegbaarheid, verantwoording, menselijk toezicht). Een principe is abstract: het benoemt een uitkomst, geen knop die je kunt omzetten. Het wordt bestuurbaar door de schade te benoemen die het zou schenden, het risico van die schade in te schatten, en controls tegen dat risico te plaatsen. Zo geborgd, wordt een principe een pijler. Zie pijler, schade, risico.Open full entry → via schade en risico naar controlcontrolDe concrete, toetsbare maatregel die een specifiek risico vermindert en daarmee het achterliggende principe beschermt. Ook wel risicobeheersmaatregel, risicorespons of risicobehandeling genoemd. Altijd herleidbaar tot het risico dat het adresseert: onder EU AI Act Art. 9 moet elke control terug te voeren zijn op een specifiek risico, en controls die los van hun risico's worden vastgelegd vormen een erkende compliance-fout. Het werkt in een van drie typen: preventief, detectief of correctief. Zie risico, control-typen, bewijs.Open full entry → en bewijsbewijsHet concrete bewijs dat een control is ontworpen, geïmplementeerd en werkt: een testrapport, een audit trail, een impactassessment, een monitoringlog. Elke schakel in de governance-keten levert een artefact op, en samen zijn ze wat een organisatie overhandigt aan haar eigen bestuur, een toezichthouder, een klant of een betrokkene om te tonen, niet te zeggen, dat een systeem bestuurd is. De afwezigheid ervan is zelf het falen: een risicoregister zonder testresultaten, of een maatregel die wordt geclaimd zonder validatie, is een governance-gat, geen papierwerk-gat. De sluitende schakel van de governance-keten. Zie control, governance.Open full entry →, staat in het artikel over AI risk management en hoeft hier niet te worden herhaald. Waarschijnlijkheid, ernst, risicobereidheidrisicobereidheidHet niveau van risico dat de leiding van een organisatie bereid is te aanvaarden in het nastreven van haar doelen, vastgesteld op het niveau van governance design. De maatstaf waartegen het restrisico aanvaardbaar wordt geoordeeld of niet. Geërfd uit de bredere governance van de organisatie en toegepast op AI. Een begrip uit enterprise risk management (COSO ERM) voordat het een AI-begrip is. Zie restrisico, governance design.Open full entry → en de verplichtingen onder artikel 9 van de EU AI ActEU AI ActVerordening (EU) 2024/1689, in het Nederlands de AI-verordening, de Europese wet over artificiële intelligentie. Ze hanteert een risicogebaseerde aanpak: verboden praktijken, eisen voor hoogrisico-AI-systemen, transparantieverplichtingen voor specifieke toepassingen en een apart regime voor AI-modellen voor algemene doeleinden (general-purpose AI). Verplichtingen zijn verdeeld tussen aanbieders en gebruiksverantwoordelijken. Zie hoogrisico-AI-systeem, general-purpose AI, conformiteitsbeoordeling.Open full entry → staan daar eveneens.

Agentic AIagentic AISystemen waarin een model handelingen verricht, tools aanroept, plannen in meerdere stappen uitvoert, wat zowel de capaciteit als elke faalvorm versterkt; bestuurd met action-allowlists, goedkeuringen en volledige logging. Zie AI-agent, agentic governance.Open full entry → verandert de invoer voor die methode op drie manieren.

• Het proces wordt anders uitgevoerd. Een deel van het werk loopt nu door een probabilistisch systeem, waardoor "de procedure schrijft dit voor" niet langer voorspelt wat er gebeurt.
• De agent heeft bevoegdheid. Hij kan handelen en niet alleen adviseren, en de tools die hij heeft bepalen wat hij kan bereiken.
• De faalvormen zijn nieuw. Sommige staan in geen enkele procedure, omdat ze pas ontstaan zodra een agent het proces uitvoert.

Het gevolg is praktisch. Een risicoanalyse voor een proces dat door een agent wordt uitgevoerd, kan niet de oude analyse met een alinea erbij zijn. Ze begint bij de architectuurkeuzes, want die keuzes bepalen hoe dit proces nu kan falen.

Begin bij het proces, niet bij het model

Bak de analyse eerst af met vier vragen, voordat u de architectuur aanraakt.

• Welk proces voert de agent uit, en welke uitkomst moet hij bereiken? Een agent die een antwoord opstelt draagt andere belangen dan een agent die een factuur betaalt.
• Wie en wat kan geraakt worden? Mensen en hun rechten, geld, gegevens, continuïteit van dienstverlening, de reputatie van de organisatie.
• Welke beslissingen of acties zijn materieel? Niet elke stap verdient evenveel aandacht; de stappen die waarde verplaatsen, een persoon raken of moeilijk terug te draaien zijn wel.
• Wat is het volume? Dezelfde fout bij tien zaken per week en bij tienduizend per week is niet hetzelfde risico.

Deze antwoorden bepalen het gewicht van alles wat volgt. Ze bepalen ook hoeveel analyse proportioneel is: een interne assistent met lage impact vraagt niet de behandeling die een betaalagent vraagt, en aan beide evenveel besteden is een fout op zichzelf.

De architectuurkeuzes als invoer

Elke architectuurkeuze is een plek waar dit proces nu kan falen.

Architectuurkeuze	De risicovraag die eruit volgt
Model en versie	Welke aannames doet het ontwerp over het gedrag van het model, wat kan er buiten onze invloed veranderen, en bevat het model organisatiespecifieke kennis door fine-tuningfine-tuningEen bestaand model verder trainen op je eigen data om zijn gedrag aan te passen, wat jou verantwoordelijk maakt voor de wijziging, mogelijk tot op aanbiederniveau. Zie aanbieder, foundation model.Open full entry →?
Systeeminstructie	Welke procesregels bestaan alleen als gedragsinstructie?
Opgehaalde kennis	Welke bronnen kunnen beslissingen beïnvloeden, en hoe actueel zijn die?
Tooldefinities	Welke acties kan de agent technisch uitvoeren, en wat weigert elke tool?
Orchestration	Welke processtappen zijn in code afgedwongen, en waar is een mens betrokken?
Geheugen	Welke eerdere informatie kan latere beslissingen kleuren?
Autonomie	Welke stappen en volgordes bepaalt het model zelf?

De tabel is een startpunt, niet de analyse. De scherpste risico's komen zelden uit één keuze alleen.

De versterkers die agentic risico anders maken

Dezelfde fout kan in de ene situatie klein zijn en in de andere ernstig. Acht factoren bepalen hoe ernstig een scenario wordt. Het zijn geen nieuwe risicocategorieën: ze veranderen het gewicht van de risico's die u al hebt geïdentificeerd, en een agent verandert er meerdere tegelijk.

• Autonomie. Hoe meer het model bepaalt, hoe meer uitvoeringspaden er bestaan, en hoe lastiger het wordt om ze allemaal te toetsen.
• Schaal en snelheid. Eén fout is niet één fout. Het is dezelfde fout, herhaald totdat iets hem stopt.
• Omkeerbaarheid. Een concept kan worden weggegooid, een betaling niet. Onomkeerbare acties verdienen zwaardere beheersing, ongeacht hoe onwaarschijnlijk de fout lijkt.
• Detecteerbaarheid. Hoe lang zou dit verkeerd lopen voordat iemand het merkt? Trage detectie maakt van een kleine fout een grote.
• Bevoegdheden. Wat de agent kan bereiken, bepaalt het plafond van wat een fout, inclusief een geslaagde manipulatie, maximaal kan aanrichten.
• Externe blootstelling. Komt er inhoud van buiten de organisatie in de context van de agent? Daar komt manipulatie binnen.
• Impact op personen. Beslissingen die mensen raken dragen een juridisch gewicht dat operationele fouten niet hebben.
• Correlatie. Menselijke fouten zijn verspreid en heffen elkaar vaak op. De fouten van een agent wijzen allemaal dezelfde kant op, dus stapelen ze.

Gebruik deze factoren om scenario's te wegen, niet als tweede scoringsschema. De algemene beoordeling van waarschijnlijkheid en ernst blijft zoals ze is. Deze factoren verklaren waarom een bekend risico ernstiger wordt zodra een agent het werk uitvoert.

Van keuzes naar scenario's

Een bruikbaar scenario heeft drie delen: een oorzaak, een gebeurtenis en een impact. Zonder de oorzaak valt het niet te beheersen, en zonder de impact valt het niet te wegen.

De scenario's die er het meest toe doen, komen uit combinaties van architectuurkeuzes. Zes voorbeelden, met de versterkers die ze zwaar maken.

• Opgehaalde kennis en orchestration. Een verouderde uitzonderingslijst wordt opgehaald, waardoor de agent een leverancier met beperkingen als gewoon behandelt, een factuur wordt goedgekeurd zonder de vereiste beoordeling, en er wordt betaald aan een leverancier die gecontroleerd had moeten worden. Versterkers: detecteerbaarheid, schaal.
• Autonomie en toolset. Een planning agent vindt een tweede route naar dezelfde actie, een route die de limietcheck niet dekt, waardoor een bedrag boven de drempel wordt goedgekeurd zonder de vereiste extra goedkeuring. Versterkers: autonomie, omkeerbaarheid.
• Externe inhoud en bevoegdheden. Een verborgen instructie in een binnenkomend document stuurt de agent om een tool aan te roepen met waarden die de afzender koos, en gegevens verlaten de organisatie via een legitiem kanaal. Versterkers: externe blootstelling, bevoegdheden.
• Geheugen en tijd. Een verouderde uitzondering blijft in het geheugen staan en kleurt stilletjes elke goedkeuring daarna, wat een systematische fout oplevert die niemand herleidt tot de oorsprong. Versterkers: detecteerbaarheid, correlatie.
• Modelwijziging en ongewijzigde artefactenartefactHet concrete record dat bewijst dat een control is uitgevoerd: een testrapport, een impactassessment, een monitoringlog, een release-sign-off. Een artefact is de tastbare vorm die bewijs aanneemt, het ding waar een auditor naar grijpt om te bevestigen dat een control niet alleen is ontworpen maar ook echt heeft gewerkt. Elke fase van de AI-levenscyclus levert haar eigen anker-artefact op. Onderscheiden van bewijs als geheel: bewijs is het bewijsmateriaal, een artefact is er één stuk van. Zie bewijs, levenscyclus.Open full entry →. De aanbiederaanbiederDe actor die een AI-systeem ontwikkelt (of laat ontwikkelen) en het onder eigen naam op de markt brengt of in gebruik neemt, met fabrikantachtige plichten: ontwerpcontrols, documentatie, conformiteit. Zie gebruiksverantwoordelijke, AI-verplichtingen.Open full entry → werkt het model bij, het gedrag verschuift, escalaties vallen weg, en zaken die naar een mens hadden moeten gaan worden automatisch afgehandeld terwijl al uw eigen artefacten hetzelfde bleven. Versterkers: detecteerbaarheid, schaal.

Niet elk belangrijk scenario begint in de techniek. Automatisering verandert ook hoe mensen zich gedragen.

Menselijke goedkeuring en automation biasautomation biasDe menselijke neiging om geautomatiseerde uitkomsten te veel te vertrouwen, een aanbeveling van een systeem aanvaarden zonder het geval echt te wegen, wat het menselijk toezicht uitholt. Zie menselijk toezicht.Open full entry →. De beoordelaar keurt goed zonder de zaak te onderzoeken, omdat de agent meestal gelijk heeft en de wachtrij lang is, waardoor de goedkeuringsstap in het ontwerp bestaat en in de praktijk niet. Versterkers: schaal, impact op personen.

Twee bronnen houden deze lijst compleet. De architectuurkeuzes, die u vertellen wat technisch mogelijk is, en een walkthrough met de mensen die het proces vandaag uitvoeren, die de impliciete controls naar boven haalt die in geen procedure staan. Het gevoel "die leverancier vertrouw ik niet, ik bel ze" is een control, en die verdwijnt geruisloos wanneer het proces wordt geautomatiseerd door iemand die nooit wist dat hij bestond.

Van scenario naar control objective

Een control objective benoemt de uitkomst die moet gelden. Het is niet de maatregel zelf, en het zegt bewust niets over het mechanisme, omdat het kiezen van het mechanisme later komt en te vroeg kiezen de opties versmalt.

Drie voorbeelden, ontleend aan de scenario's hierboven:

• Ongeautoriseerde betalingen mogen technisch niet uitvoerbaar zijn, ongeacht welke route de agent daarheen neemt.
• Beslissingen op basis van verouderde proceskennis moeten vóór uitvoering worden gedetecteerd, of naar een mens worden geleid.
• Een geslaagde manipulatie van verwerkte inhoud mag geen waarde of gegevens buiten de afgesproken grenzen kunnen brengen.

Elk van deze objectives is in beginsel toetsbaar, elk zegt wat waar moet zijn in plaats van wat er gebouwd moet worden, en elk kan op meerdere manieren worden bereikt. Dat maakt ze bruikbaar: ze laten het ontwerp van de control aan de volgende stap in plaats van het voor te schrijven.

De behandeling kiezen

Niet elk risico vraagt een control. De vier opties zijn de bekende, en twee ervan verdienen in deze context een aantekening.

• Vermijden. Geef de agent de capability helemaal niet. In agentontwerp is dit de sterkste en minst gebruikte optie: een tool die niet bestaat, kan niet worden misbruikt.
• Verminderen. Verlaag de autonomie, versmal de toolset, of voeg controls toe. Least agencyleast agencyHet principe uit het agentic security-werk van OWASP dat een agent de kleinste set capabilities en de minste autonomie krijgt die de taak vraagt. Toegepast op architectuurniveau is het een risicobesluit en geen technische voorkeur: minder autonomie laat meer van het proces afdwingbaar in code. Zie OWASP, agentic AI, afdwingpunt.Open full entry → hoort hier: beperken wat de agent mag beslissen is risicobehandeling en niet slechts een architectuurvoorkeur, en hoort ook zo te worden vastgelegd.
• Overdragen. Contractuele afspraken met een aanbieder verschuiven een deel van de blootstelling, maar ze verplaatsen de verantwoordelijkheid voor het proces niet.
• Accepteren. Een besluit, geen default. Het vraagt een benoemde acceptant met het mandaat om te accepteren, een onderbouwing en een herbeoordelingsdatum.

Wat deze stap oplevert

Het resultaat is een korte, gewogen set scenario's, elk met een control objective en een behandelbesluit. Dat is de invoer voor de volgende vraag, die een andere is: waar elk objective wordt afgedwongen, hoe u toetst dat het standhoudt, en welk bewijs laat zien dat het over een periode standhield. Die vraag is het onderwerp van de controleomgeving van agentic AI.