AI agents en autonome AI onder de EU AI Act in 2026

2026 is het jaar waarin enterprise-AI van assistent naar actor verschuift. AI agents, systemen die zelfstandig redeneren over een doel en stap voor stap acties uitvoeren in digitale of fysieke omgevingen, zijn niet langer een experiment maar onderdeel van de standaard productlijn van OpenAI, Anthropic, Microsoft en Google. Voor Nederlandse organisaties die deze technologie willen inzetten, brengt dat een nieuwe stapeling van naleving-vraagstukken met zich mee. De AI Act heeft geen aparte categorie voor agents, maar verscherpt de toepassing van bestaande artikelen, vooral rond menselijk toezicht, logging en risicoclassificatie.

Dit artikel legt uit wat agents zijn, hoe de AI Act op hen wordt toegepast en welke concrete governance-vragen u nu moet beantwoorden.

Wat zijn AI agents?

Een AI agent is een AI-systeem dat zelfstandig acties uitvoert om een gegeven doel te bereiken. Het verschil met een chatbot of assistent zit in wat het systeem mag doen. Een chatbot beantwoordt vragen. Een assistent draft suggesties. Een agent voert daadwerkelijk uit. Concreet bestaat een agent uit drie componenten:

• Een redeneer-engine, meestal een groot taalmodel, dat plant welke stappen nodig zijn.
• Een tool-set, API-toegang tot externe systemen: browser, e-mail, agenda, betalingen, bestandssysteem, database, CRM, ERP.
• Een loop die stappen plant, uitvoert, observeert en aanpast tot het doel is bereikt of een limiet is gehaald.

Het verschil in praktijk: een conventionele AI-assistent stelt voor om een vergadering in te plannen en wacht op uw goedkeuring. Een agent leest uw inbox, ziet de vergaderverzoeken, controleert beschikbaarheid, stuurt bevestigingen en update uw CRM, allemaal zonder dat u per stap akkoord geeft.

Hot topic in 2026: enterprise rollout van agents

Begin 2026 zijn agents niet meer hypothetisch. Een aantal voorbeelden uit de praktijk:

• OpenAI Operator en zijn opvolgers laten gebruikers via een browser-agent taken delegeren zoals reserveringen, formulieren invullen en simpele aankopen.
• Anthropic Claude Computer Use geeft het taalmodel directe controle over een virtuele desktop, inclusief muis- en toetsenbordacties.
• Microsoft Copilot Studio agents integreren in Teams, Outlook en SharePoint om bedrijfsprocessen autonoom af te handelen.
• AutoGPT- en LangGraph-achtige raamwerken stellen ontwikkelaars in staat eigen multi-step agents te bouwen op basis van GPAI-modellen.
• Salesforce Agentforce en vergelijkbare CRM-agents handelen leads, klantvragen en service-tickets zelfstandig af.

Het gemeenschappelijke kenmerk: de impact-radius is groter dan bij chatbots, omdat acties direct doorwerken in systemen, financien, klanten of fysieke processen.

Status onder AI Act: geen aparte categorie, maar wel verzwaarde toepassing

De AI Act, ontworpen voor en in 2023 vastgesteld, kent geen aparte categorie voor agentic AI. De Commissie heeft in haar uitvoeringsguidance van 2025 wel verduidelijkt dat de bestaande artikelen integraal van toepassing zijn op agents, en dat de risicoclassificatie moet plaatsvinden op basis van de uiteindelijke toepassing en de scope van autonome acties.

Praktisch betekent dit drie dingen:

1. Voor elk agent moet worden geclassificeerd of het systeem onder verboden, hoog-risico, beperkt of minimaal risico valt.
2. Hoog-risico verplichtingen (FRIA, logging, menselijk toezicht, technische documentatie, registratie) gelden onverkort en zwaarder, omdat agents zelfstandig handelen.
3. Transparantieplicht uit artikel 50 geldt bij elke interactie met natuurlijke personen.

Risicoclassificatie van AI agents

De classificatie hangt af van de use case, niet van de techniek. Twee identieke agent-architecturen kunnen in verschillende risicoklassen vallen. Onderstaand de meest voorkomende patronen:

• Hoog-risico (vaak): agents die kredietbeslissingen voorbereiden of nemen, agents die HR-acties uitvoeren (kandidaten afwijzen, contracten beeindigen), agents in zorgcontext, agents die met overheidsdiensten communiceren namens burgers.
• Beperkt-risico: agents die met klanten communiceren via chat of voice (artikel 50), agents die content genereren en publiceren (artikel 50 transparantie over AI-gegenereerde content).
• Minimaal risico: agents voor interne productiviteit zonder externe impact, zoals een agent die uw eigen agenda of bestanden ordent.

Belangrijk: de scope van een agent verandert door tijd. Een agent die start als minimaal risico (interne kalender-organisatie) kan na een feature-update hoog-risico worden (HR-acties op medewerkers uitvoeren). Risicoclassificatie is daarmee een dynamisch proces, geen eenmalige documentstap.

Artikel 14 menselijk toezicht in agentic context

Artikel 14 van de AI Act vereist dat hoog-risico AI-systemen zo zijn ontworpen dat ze door natuurlijke personen effectief kunnen worden gesuperviseerd. In de praktijk van traditionele AI-systemen (suggestie-modellen, classifiers) gaat dit vaak om een mens-in-de-loop voor elk besluit. Voor agents kantelt dat: een agent die honderd acties per uur uitvoert kan niet voor elke stap menselijke goedkeuring krijgen, anders is het geen agent meer.

De AI Act vereist dat de toezichthouder de werking van het systeem kan begrijpen, kan ingrijpen en kan stoppen. Voor agents wordt dat geinterpreteerd als:

• Een dashboard waarin live wordt getoond welke acties de agent neemt, met categorisatie naar impact.
• Een afdwingbaar pauze- of stop-mechanisme dat onmiddellijk de agent-loop afbreekt.
• Pre-approval (mens bevestigt voor uitvoering) voor acties boven een impact-drempel.
• Achteraf-review van logs voor onder de drempel uitgevoerde acties.

De drempel zelf moet onderbouwd zijn. Een agent die financiele transacties uitvoert vraagt een lagere drempel dan een agent die interne notities ordent.

Stop-knop en undo-functionaliteit

Artikel 14 lid 4 noemt expliciet de mogelijkheid om de werking te onderbreken via een stop-functie of vergelijkbaar mechanisme. Voor agents brengt dit twee technische ontwerpkeuzes:

• Hard stop: een interrupt die direct alle openstaande tool-calls afbreekt en de loop beeindigt. Belangrijk dat dit ook werkt midden in een API-call (graceful cancel) en dat lopende transacties teruggedraaid of gemarkeerd worden.
• Undo voor reversibele acties: voor acties die teruggedraaid kunnen worden (een verzonden interne mail nog binnen retract-window, een geplaatste bestelling binnen annulerings-window) moet de agent zelf de undo-paden kennen.

Voor irreversibele acties (geld overgemaakt naar externe partij, openbare publicatie gepubliceerd) is undo niet haalbaar. Daar werkt alleen pre-approval. Dit moet vooraf in het agent-ontwerp zijn vastgelegd, niet aan de inschatting van het taalmodel zelf worden overgelaten.

Logging-uitdagingen voor agents

Artikel 12 verplicht hoog-risico AI-systemen tot automatische logging van events. Voor klassieke AI is dat overzichtelijk: input, model-output, confidence-score. Voor agents is het complex. Elk agent-run kent typisch:

• De originele prompt of taak (system + user message).
• De redeneer-stappen van het model (chain of thought).
• Elke tool-call (welke tool, welke input).
• Elke tool-response (output van externe systemen).
• Intermediate state (geheugen, vector store retrievals).
• De uiteindelijke acties die effect hebben in de echte wereld.
• Eventuele exceptions en herstelpogingen.

De omvang loopt snel op: een eenvoudige agent-run kan honderden tot duizenden log-events genereren. Praktische adviezen:

• Sla redeneerstappen op met een redacted-versie waar gevoelige info uit gefilterd is, maar bewaar de volle versie versleuteld voor audit-doeleinden.
• Hash tool-inputs en outputs zodat reconstructie mogelijk is zonder onnodige opslag van persoonsgegevens.
• Definieer een log-retentieperiode in lijn met artikel 12 (minimaal 6 maanden) en de AVG (zo kort als mogelijk).
• Maak logs doorzoekbaar op agent-ID, gebruiker, doel, tijdstip en categorieen van acties.

Aansprakelijkheid bij multi-agent systems

Een nieuwe complicatie ontstaat als agents elkaar aansturen. Een orchestrator-agent verdeelt een doel onder gespecialiseerde sub-agents (research-agent, schrijf-agent, fact-check-agent). Als de uiteindelijke output schade veroorzaakt, wie is dan verantwoordelijk?

Onder de AI Act blijft de logica gelijk: de deployer is verantwoordelijk voor inzet in zijn proces. Maar er ontstaat een nieuwe complicatie als sub-agents door verschillende vendors worden geleverd of door verschillende interne teams worden gebouwd. Het is aan te raden om:

• Een verantwoordelijke deployer per agent-ID aan te wijzen, ook voor sub-agents.
• De multi-agent compositie zelf als een AI-systeem te beschouwen met een eigen risicoclassificatie.
• Tussen vendors en interne teams de aansprakelijkheid contractueel te regelen.
• Een single point of escalation aan te wijzen die kan ingrijpen bij multi-agent storingen.

Provider versus deployer in agentic context

De AI Act onderscheidt provider (bouwer/aanbieder van het systeem) en deployer (inzetter onder eigen verantwoordelijkheid). Voor agents wordt deze grens vaag:

• Een GPAI-provider (zoals OpenAI of Anthropic) levert het onderliggende foundation model.
• Een agent-framework-leverancier (zoals een SaaS die orchestratie biedt) bouwt daarop.
• Een interne ontwikkelaar combineert framework, model en eigen tools tot een agent.
• Het bedrijf zet de agent in productie.

In de meeste gevallen is uw organisatie deployer en mogelijk provider voor de samengestelde agent als u het systeem onder eigen naam aanbiedt of substantieel wijzigt. Lees onze gids over artikel 26 deployer-verplichtingen voor uitwerking. Voor de GPAI-component zie onze gids over foundation models en GPAI.

Registratie en agent-inventory

Voor goede governance van agentic AI is een centraal agent-register essentieel. Per agent legt u minimaal vast:

• Agent-ID en versie.
• Doel: wat moet de agent bereiken?
• Capabilities: welke acties kan de agent nemen?
• Permissions: tot welke systemen, data en acties heeft de agent toegang?
• Scope: voor welke gebruikers, voor welke processen?
• Onderliggende GPAI-modellen: welk taalmodel, welke versie, welke provider.
• Tool-set: welke API's en integraties.
• Risicoclassificatie en bijbehorende documentatie (FRIA indien hoog-risico).
• Toezichts- en stop-mechanisme: hoe en door wie.
• Log-locatie en retentie.
• Verantwoordelijke deployer binnen de organisatie.

Dit register is de basis voor uw bredere AI-register dat u onder de AI Act bijhoudt.

8-punts checklist agentic AI naleving

Toekomstige Commission-richtlijnen

De Europese Commissie heeft aangekondigd in 2026 en 2027 aanvullende uitvoeringsguidance te publiceren over agentic AI, onder meer over de afbakening van menselijk toezicht in autonome contexten, logging-standaarden voor multi-step agents en aansprakelijkheid in multi-agent configuraties. Het EU AI Office werkt parallel aan een verfijning van de GPAI Code of Practice die specifiek de inzet van foundation models in agent-frameworks adresseert.

Voor organisaties die nu al met agents werken: bouw uw governance modulair. De kerncomponenten (agent-register, risicoclassificatie per use case, menselijk toezicht-mechanisme, logging-pipeline) zijn richting-onafhankelijk. Verfijningen vanuit Brussel zullen vooral betrekking hebben op exacte standaarden en drempels, niet op de basisarchitectuur.