AI Agent Governance: EU-regels ontmoeten Google's Agent ID

Inleiding

Twee aankondigingen uit de eerste week van augustus 2026 wijzen op dezelfde verschuiving, vanuit tegenovergestelde richtingen. Op 2 augustus werden de transparantieregels van de EU AI Act afdwingbaar recht, waardoor iedereen die een chatbot, contentgenerator of emotieherkenningssysteem inzet, dit duidelijk moet vermelden of boetes tot €15 miljoen riskeert. Enkele dagen later bracht Google Cloud zijn Agent Identity-systeem naar algemene beschikbaarheid — een native machtigingenlaag die precies bijhoudt waartoe een AI-agent toegang heeft en alles logt wat hij doet. De ene is een toezichthouder die openbaarmaking afdwingt. De andere is een cloudplatform dat verantwoording als functie verkoopt. Beide komen tot dezelfde conclusie: een AI-agent die niemand kan identificeren, auditen of verantwoordelijk houden, is niet klaar voor productie, of een rechtbank dat nu zegt of niet.

Wat er veranderde op 2 augustus

De transparantieverplichtingen van artikel 50 van de EU AI Act werden op 2 augustus 2026 algemeen toepasbaar en afdwingbaar door nationale autoriteiten in de hele EU. In de praktijk omvat dit vier zaken. Aanbieders moeten ervoor zorgen dat mensen “duidelijk worden geïnformeerd dat ze te maken hebben met een AI-systeem, tenzij dit duidelijk blijkt uit de context” — de chatbot-openbaarmakingsregel. Aanbieders van systemen die synthetische audio, afbeeldingen, video of tekst genereren, moeten die output markeren in een machineleesbaar, detecteerbaar formaat. Iedereen die een systeem inzet dat deepfakes van echte personen, plaatsen of gebeurtenissen produceert, moet dit openbaar maken. En gebruikers van emotieherkennings- of biometrische categoriseringssystemen moeten de mensen die eraan worden blootgesteld informeren en binnen de EU-gegevensbeschermingswetgeving blijven.

Niets hiervan is nieuw in concept — de AI Act werd jaren eerder ondertekend. Wat er op 2 augustus veranderde, is dat deze specifieke verplichtingen ophielden een toekomstige datum op een nalevingsroutekaart te zijn en iets werden dat nationale toezichthouders vandaag daadwerkelijk kunnen handhaven.

Klaar om uw bedrijf te laten groeien?

Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.

Demo aanvragen Inloggen

Wat werd doorgeschoven naar 2027 en 2028

Niet alles in de Wet arriveerde op schema. Via de Digital Omnibus on AI, ondertekend op 8 juli 2026, heeft de EU de vereisten voor hoog-risico systemen uitgesteld. Zelfstandige systemen onder Bijlage III — denk aan wervingsscreening, onderwijs, wetshandhaving, kritieke infrastructuur — hebben nu tot 2 december 2027. AI ingebed in reeds gereguleerde producten onder Bijlage I, zoals medische hulpmiddelen of liften, heeft tot 2 augustus 2028.

Dat uitstel is het waard om precies over te zijn, omdat het gemakkelijk verkeerd wordt gelezen als “de AI Act is vertraagd.” Dat is niet gebeurd. De lijst van verboden praktijken en de verplichtingen voor AI-modellen voor algemeen gebruik blijven onaangetast. Wat is verschoven, zijn specifiek de classificatievereisten voor hoog-risico systemen — de zwaarste nalevingslast, voor de smalste categorie systemen. Als je agent met gebruikers praat of content genereert, val je binnen het deel van de wet dat al actief is.

Waarom transparantieregels ertoe doen

De transparantievereiste klinkt bescheiden naast “hoog-risico systeem,” maar het is de regel waar de meeste AI-agentbouwers daadwerkelijk als eerste tegenaan lopen. Een klantgerichte supportagent, een contentgeneratieworkflow, een spraakassistent — dit zijn allemaal systemen die met mensen praten, wat betekent dat artikel 50 van toepassing is, ongeacht of ze ooit als hoog-risico zouden worden geclassificeerd. Dit goed krijgen is niet ingewikkeld: zeg duidelijk dat de gebruiker met een AI praat, label gegenereerde content en bewaar gegevens die aantonen dat je dit hebt gedaan. Het fout krijgen is waar compliance rapportage ophoudt papierwerk te zijn en begint een juridische blootstelling te worden met een echt getal eraan.

Schrijf u in voor onze nieuwsbrief

Ontvang gratis de nieuwste tips, trends en aanbiedingen.

E-mailadres

Abonneren

Google lanceert Agent Identity

Google Cloud’s antwoord op hetzelfde onderliggende probleem kwam vanuit een compleet andere richting: infrastructuur, niet de wet. Het bedrijf bracht zijn Gemini Enterprise Agent Platform naar algemene beschikbaarheid met een cluster van nieuwe agent-governance primitieven — Agent Memory Bank, Agent Runtime, Agent Gateway, Agent Registry, Agent Evaluation en, het meest opvallend, Agent Identity.

Agent Identity is een native IAM-referentietype gebouwd op open standaarden, specifiek ontworpen voor autonome systemen in plaats van aangepast van menselijke gebruikersaccounts. Het dwingt least-privilege-toegang af door machtigingen direct aan de runtime van de agent te binden, wat een veelvoorkomend aanvalspad afsluit waarbij een gestolen agenttoken elders opnieuw zou kunnen worden afgespeeld. Het produceert niet-verwerpelijke logs van elke actie die een agent onderneemt. En het beheert de referentielevenscyclus automatisch, zodat een gepensioneerde agent geen slapende, vergeten set machtigingen achterlaat die wachten om misbruikt te worden.

Wat Agent Identity daadwerkelijk doet

Het praktische effect is dat “welke agent heeft dit gedaan, en mocht hij dat?” een vraag wordt met een definitief antwoord in plaats van een gok die achteraf uit applicatielogs wordt gereconstrueerd. Dat wordt belangrijker naarmate agents verschuiven van het beantwoorden van vragen naar het ondernemen van acties — dingen boeken, records bewerken, geld verplaatsen, bestanden verwijderen. Een LLM-beveiliging die zich alleen zorgen maakt over promptinjectie in het model zelf, mist dit hele oppervlak: de daadwerkelijke machtigingen van de agent en wat ermee is gedaan.

Dit is ook waar de twee aankondigingen meer met elkaar verbonden zijn dan ze op het eerste gezicht lijken. Artikel 50 vraagt “heb je onthuld dat dit AI was?” Agent Identity beantwoordt een verwante maar andere vraag: “kun je precies bewijzen wat deze specifieke agent deed, met welke machtigingen, op wiens gezag?” Een systeem dat de tweede vraag netjes kan beantwoorden, vindt de eerste veel gemakkelijker.

Twee verschillende paden, dezelfde bestemming

Het is de moeite waard om het patroon direct te benoemen, omdat het zich zal blijven herhalen. Toezichthouders komen uit op openbaarmaking en verantwoording vanuit een juridisch-risicoperspectief. Cloudplatforms komen uit op identiteit en machtigingen vanuit een veiligheids- en betrouwbaarheidsperspectief. AI-agentframeworks behandelden identiteit vroeger als een bijzaak — een API-sleutel in een omgevingsvariabele, gedeeld door elke agent in de vloot. Dat model overleeft geen contact met zowel toezichthoudend onderzoek als een echt beveiligingsincident, wat precies is waarom beide richtingen nu naar dezelfde oplossing wijzen: weet welke agent wat deed, met welke toegang, en wees in staat het te tonen.

Teams die al hebben geëxperimenteerd met praktijkvoorbeelden van AI-agents — klantondersteuningsbots, onderzoeksassistenten, codeeragents — zijn degenen die deze verschuiving het eerst zullen voelen, simpelweg omdat ze meer agents in productie hebben die meer acties genereren om te verantwoorden. Het is hetzelfde patroon dat we zagen toen Claude Cowork en zijn concurrenten agents verschoof van single-session chat naar persistente, meerdaagse taken: meer autonomie komt altijd een stap voor op de tooling om het te besturen.

Vanaf dag één bestuurbare agents bouwen

Het achteraf aanbrengen van audittrails op een agentvloot die nooit is ontworpen om ze te produceren, is een ellendig project — elke actie moet worden gereconstrueerd uit de logs die toevallig bestonden, en de helft van de tijd zijn ze er niet. Het goedkopere pad is bouwen op tooling waar elke stap die een agent neemt vanaf het begin zichtbaar en traceerbaar is, op dezelfde manier waarop datagovernance datalijn beschouwt als een eersteklas zorg in plaats van iets dat je er na een datalek aan vastklikt.

Dit is ook waar het tempo van de onderliggende modellen ertoe doet. Recente releases zoals Microsoft’s Orchard framework en de bredere verschuiving naar gespecialiseerde, auditeerbare agents (in plaats van één enorm algemeen-doel model dat alles doet) maken het praktischer om agents te bouwen waarvan de reikwijdte — en dus de machtigingen — smal en goed gedefinieerd zijn door ontwerp. Een smal afgebakende agent is inherent gemakkelijker te besturen dan een die theoretisch van alles kan doen.

FlowHunt’s aanpak volgt dezelfde logica: als AI-agentplatform is elke automatisering een zichtbare flow, geen black box, dus wanneer een nalevingsvraag binnenkomt — wat deed deze agent, waarom en onder welke autorisatie — ligt het antwoord al klaar in de workflow, niet iets dat je team onder tijdsdruk moet reconstrueren.

Conclusie

De transparantieregels van de EU AI Act en Google’s Agent Identity-systeem hebben niet met elkaar gecoördineerd, en ze lossen ogenschijnlijk verschillende problemen op — de ene is juridische naleving, de andere is cloudinfrastructuur. Maar ze landden in dezelfde week en wezen op dezelfde onderliggende waarheid: nu AI-agents meer autonoom en impactvol werk op zich nemen, is “we weten niet echt wat het deed” geen acceptabel antwoord meer, of de vrager nu een toezichthouder is of je eigen beveiligingsteam. De teams die identiteit, openbaarmaking en auditbaarheid nu als kernvereisten behandelen — niet als functies om later toe te voegen — zijn degenen die zowel naleving als productie-incidenten veel minder pijnlijk zullen vinden wanneer ze zich voordoen.