De meeste AI governance-programma’s weten niet wie namens wie handelt.
Dat klinkt scherp, en dat is het ook. Maar het is geen aanval op de mensen die aan AI governance werken — het is een observatie over waar het werk vaak begint en waar het zou moeten beginnen. Frameworks, beleid, ethische principes, risk classification, AI impact assessments. Veel daarvan is uitstekend werk. Wat onder die laag ontbreekt, is wat governance pas afdwingbaar maakt: weten welke identiteit, met welke scope, namens welke gebruiker, met welke autorisatie iets in jouw omgeving aan het doen is.
Governance zonder identity-laag is niet afdwingbaar.
Waarom AI governance nu vaak policy-first is
De grote frameworks die op dit moment de richting bepalen — het NIST AI Risk Management Framework, ISO/IEC 42001 voor AI management systems, de EU AI Act voor risk-classified systemen — beginnen allemaal aan de bovenkant. Ze definiëren governance functies, accountability mechanismen, risico-categorieën, transparantievereisten, menselijk toezicht. Dat is goed, en het is precies wat een nieuw vakgebied nodig heeft om zichzelf serieus te nemen.
Maar de manier waarop organisaties hier vervolgens mee aan de slag gaan, is meestal beleidsmatig. AI principes worden vastgelegd. Een AI ethics board wordt ingericht. Een impact assessment-template wordt geschreven. Risk owners worden benoemd voor specifieke use cases. Daar gaat veel zorgvuldig werk in zitten.
Wat in al die documenten zelden expliciet staat — en wat in de praktijk dus zelden gebeurt — is de vertaling naar wat de identity- en authorization-laag eronder moet doen. Niemand vraagt zich in dat stadium af: welke identiteit gebruikt deze AI als hij straks aan het werk is? Onder wiens autoriteit handelt hij? Wie keurt zijn rechten goed, wie reviewt ze, wie haalt ze weg als hij niet meer nodig is?
Die vragen komen pas later, als de eerste AI-implementatie productie nadert. En tegen die tijd is het te laat om ze structureel goed te beleggen.
Het vergeten onderdeel: identiteiten en bevoegdheden
In klassieke IT geldt een simpele regel: alles wat handelt heeft een identiteit, alles wat een identiteit heeft is iemand z’n verantwoordelijkheid, en wat die identiteit mag is een review-bare beslissing. Dat is geen revolutionair idee — het is gewoon hoe IAM (Identity and Access Management) en IGA (Identity Governance and Administration) al jaren werken, in elk geval voor mensen.
Voor AI-systemen geldt dat principe niet ineens anders. Een AI agent die data leest, een API aanroept, een actie uitvoert — hij doet dat onder een identiteit, met bepaalde rechten, namens iemand. Het probleem is dat veel AI-implementaties dat principe niet expliciet maken. De agent draait onder een service account van een ontwikkelaar. Of onder de geleende identiteit van een gebruiker. Of onder een account dat niemand meer kan terughalen wie het ooit heeft aangemaakt.
Veel organisaties behandelen service accounts en agent-identiteiten nog steeds alsof het tijdelijke technische details zijn. In werkelijkheid zijn het operationele actoren met privileges die vaak breder zijn dan die van medewerkers — en die in geen enkele recertificatie-cyclus zitten. Een AI agent in productie heeft niet zelden meer kritische toegang dan de stagiair die er drie weken eerder uit dezelfde data is geweerd. Dat is geen tooling-tekort. Dat is een conceptueel gat.
In veel organisaties draaien inmiddels AI-functionaliteiten onder bestaande integratie-accounts die ooit voor een heel ander doel zijn aangemaakt. Niemand heeft die accounts ooit beoordeeld op wat een AI-laag erbovenop er feitelijk mee zou doen. Dat is niet onveilig per ongeluk — dat is onveilig per ontwerp.
Een agent zonder owner is geen technisch detail. Het is een accountability-gat.
Het bredere patroon is geen AI-probleem in de strikte zin. Het is een non-human identity probleem dat al jaren bestaat en door AI acuut wordt. Daar heb ik recent meer over geschreven in Non-Human-Identities en AI en ook in Wie is eigenaar van een AI-agent binnen de organisatie?.
AI agents handelen namens mensen — of niet?
Een wezenlijk onderscheid dat in veel AI governance documenten ontbreekt: handelt deze AI namens de gebruiker, namens de organisatie, of zelfstandig?
Het verschil is allesbehalve cosmetisch. Een agent die acties uitvoert onder de geleende identiteit van een gebruiker (delegated authority) is volgens de meeste IAM-modellen nog steeds die gebruiker — de actie wordt aan hem toegerekend, en hij is accountable. Een agent met een eigen identiteit is een aparte actor, met eigen rechten, eigen audit trail, eigen lifecycle. Een agent die wisselt tussen identiteiten — soms namens de gebruiker, soms onder een service account — maakt het hele attributievraagstuk effectief onmogelijk.
Veel AI-implementaties zitten in die laatste categorie zonder dat iemand het zo benoemd heeft. De agent doet wat hij doet, en wie er achteraf moet uitleggen wat er is gebeurd loopt aan tegen logs die niet meer netjes terug te leiden zijn naar een aanwijsbare actor.
Een AI-agent die tickets afhandelt onder een generiek service account lijkt operationeel efficiënt — tot een incidentonderzoek moet reconstrueren wie feitelijk verantwoordelijk was voor een foutieve actie. Dan blijkt het service account te zijn aangemaakt door een ontwikkelaar die er drie reorganisaties geleden niet meer werkt, en gebruikt door een agent die door een ander team in productie is gezet.
Dat is het kerngat waar AI governance en IAM elkaar zouden moeten ontmoeten, en het is precies waar het meestal mis gaat.
Logging is niet hetzelfde als accountability
“We hebben audit logs” is een antwoord dat in governance-gesprekken vaak wordt gegeven. Het bedoelt: we kunnen reconstrueren wat er is gebeurd. In de praktijk betekent het vaak iets veel beperkers: we hebben een hoop data die ergens in een SIEM landt, en als we weten wat we zoeken kunnen we het waarschijnlijk vinden.
Echte accountability vraagt meer. Wie was de actor (mens of agent)? Onder wiens autoriteit werd er gehandeld? Welke scope had die autorisatie? Welke specifieke beslissingen heeft de actor genomen en op basis waarvan? Welke downstream effecten heeft dat gehad? Op die vragen geeft een rauwe log file zelden antwoord — daarvoor heb je een identity-laag nodig die de keten van actor naar actie naar data naar uitkomst expliciet vasthoudt.
Logs zonder identity-context lossen weinig op zodra er echt iets misgaat.
De governance-gap tussen AI en IAM
In de meeste organisaties zitten AI governance en identity governance in andere teams die elkaar onvoldoende vinden.
Het AI governance team bestaat vaak uit risk officers, compliance professionals, ethici, juristen. Ze praten over bias, transparantie, menselijk toezicht, dataminimisatie. Hun frameworks komen uit ISO 42001, het NIST RMF, de EU AI Act.
Het IAM team bestaat uit identity engineers, IGA-specialisten, security architects. Ze praten over rollen, rechten, recertificatie, segregation of duties. Hun frameworks komen uit ISO 27001, NIS2, sectorale standaarden.
Beide hebben gelijk in hun domein. Maar tussen die twee zit een vacuüm — en daar zit precies het werk dat AI agents nodig hebben. Een AI policy zonder vertaling naar identity controls is niet afdwingbaar. Een IAM programma zonder besef van wat AI agents semantisch doen mist een hele klasse niet-menselijke actors. Een access review die alleen menselijke gebruikers ziet, gaat per definitie voorbij aan de grootste blootstellingscategorie in de omgeving — een patroon dat ik specifieker uitwerk zal werken in de toekomst.
Die twee disciplines moeten elkaar vinden, en dat gebeurt niet vanzelf.
Wat organisaties operationeel missen
Een paar concrete dingen die in de praktijk bijna nooit goed staan.
Eigenaarschap per agent. Niet een team, niet een afdeling — een named mens die accountable is voor wat de agent doet, voor zijn rechten, voor zijn lifecycle.
Rolprofielen voor non-human entities. Hetzelfde principe als rollen voor mensen: een vastgelegd profiel met scope, rechten en doel, dat reviewed en geattesteerd kan worden.
Recertificatie die ook NHI’s omvat. Periodieke (of risk-gebaseerde) reviews die niet alleen kijken naar wat mensen hebben, maar ook naar wat agents hebben — en die zinvolle context aanbieden om die beslissing te maken.
Baseline en drift detectie. Vastleggen wat een agent bij commissioning hoort te doen, en signaleren wanneer dat patroon zich wijzigt. Dat bewaakt of agents zichzelf herschrijven (onbedoeld of bedoeld).
Audit trail die de keten reconstrueert. Niet alleen “deze identity heeft deze actie uitgevoerd”, maar de hele cascade: welke gebruikersvraag, welke agent-beslissing, welke tool, welke data, welke uitkomst.
Praktische aanbevelingen
Geen revolutionaire blauwdruk. Wel een paar vertrekpunten die voor de meeste organisaties direct werkbaar zijn.
Begin niet met een AI policy als je nog geen identity inventaris hebt voor non-human entities. Dat is bouwen aan het dak voor er fundamenten zijn. Een eenvoudige inventarisatie van welke service accounts, API tokens, agents en workloads in je omgeving actief zijn, met daarbij wie ze beheert, geeft je een uitgangspunt dat alle latere governance steviger maakt.
Map elke AI agent expliciet op een menselijke eigenaar. Niet bij ingebruikname als nice-to-have, maar als harde voorwaarde. Geen eigenaar, geen agent in productie.
Trek bestaande IAM-processen door naar non-human identities. Recertificatie cycli, role mining, segregation of duties controles — die werken in principe ook voor NHI’s, ze worden alleen vaak niet uitgevoerd. Begin daar.
Bouw aan audit trails die actor → action → data → outcome verbinden. Dat is niet triviaal, en het is geen out-of-the-box functie van de meeste IAM-platforms vandaag. Maar zonder is forensisch onderzoek en compliance rapportage zeer beperkt.
En zorg dat AI governance en IAM in dezelfde gesprekken zitten. Een AI ethics board zonder identity expert is een eenzijdig gesprek. Een IAM programma dat AI agents niet erkent als nieuwe klasse identiteiten loopt achter de feiten aan.
Slot
AI governance zonder identity governance is een ethisch framework zonder ankerpunt. De principes zijn er, de afdwingingsmechanismen niet. Op de korte termijn is dat te overzien — er gebeurt nog niet zoveel autonoom waar het écht ongemakkelijk wordt. Op de iets langere termijn is het een fundamenteel governance probleem dat zich niet alleen door beleid laat oplossen.
De governance-vraag die ertoe doet is niet of we de principes goed hebben opgeschreven. Het is of we kunnen aantonen wie, namens wie, met welke autorisatie, welke actie heeft uitgevoerd op welke data — en of we daar consequenties aan kunnen verbinden. Dat is wat identity governance levert. En zonder die laag blijft AI governance een ander woord voor goede intenties.
Veel organisaties ontdekken pas tijdens een audit, AI-uitrol of security-incident hoe ver hun AI governance is vooruit gelopen op de identity-laag eronder. Juist daar ontstaan governance-gaten die niet met beleid of tooling alleen oplosbaar zijn — ze vragen om verbinding tussen AI governance, identity governance en de operationele werkelijkheid van non-human identities. Het puur toepassen van checkboxen zodat het voldoet aan de EU AI Act is wel compliant, maar niet de enige oplossing.
Wil je sparren over hoe dit in jouw context speelt? Bereik me via het contactblok op de homepage.
Veelgestelde vragen
Wat is het verschil tussen AI governance en identity governance?
AI governance gaat over de principes, risico’s en kaders rondom AI-systemen: bias, transparantie, menselijk toezicht, risk classification. Identity governance gaat over wie of wat in een omgeving handelt, met welke rechten, namens wie, en hoe dat over tijd wordt beheerd en herzien. De twee disciplines overlappen op het punt waar AI-systemen feitelijke acties uitvoeren — en daar valt vaak een gat.
Waarom is logging niet genoeg voor AI accountability?
Logging levert data, geen accountability. Voor accountability moet je kunnen aantonen wie de actor was, onder wiens autoriteit, met welke scope, op welke gronden. Rauwe logs zonder identity context laten zien dát er iets is gebeurd, maar zelden volledig wie ervoor verantwoordelijk was — zeker niet in een AI-keten waar tools weer tools aanroepen.
Welke frameworks raken zowel AI governance als identity governance?
ISO/IEC 42001 (AI management systems, 2023) en het NIST AI Risk Management Framework adresseren AI governance op programmaniveau. ISO/IEC 27001:2022 en de EU NIS2-richtlijn adresseren identity en access controls. De EU AI Act vereist voor high-risk systemen menselijk toezicht en logging — controls die effectief alleen werken als de identity-laag eronder kloppend is.
Wat is delegated authority in een AI context?
Delegated authority betekent dat een AI-systeem acties uitvoert namens een gebruiker, op basis van diens identiteit en rechten. In de praktijk wisselen agents vaak tussen identiteiten — soms namens de gebruiker, soms onder een service account. Dat maakt attributie en accountability complex, en is een van de redenen waarom expliciete identity-keuzes per AI-implementatie zo belangrijk zijn.
Waar zou een organisatie vandaag minimaal aan moeten beginnen?
Drie dingen. Een inventaris van non-human identities die in je omgeving actief zijn. Voor elke AI agent een menselijke eigenaar. En een gesprek tussen het AI governance team en het IAM team over wat hun gezamenlijke control-framework zou moeten zijn. Geen van die drie kost veel; geen van die drie wordt structureel gedaan.
