Dat model wordt nu verstoord. Niet door één technologie, maar door een verschuiving in wat er aan de andere kant van het scherm gebeurt: tools die zelfstandig andere tools gebruiken.
En dat verandert meer dan we toegeven.
Het oude model
In het kort: gebruiker bedient tool, tool levert resultaat. De gebruiker klikt iets, vult iets in, opent een bestand. Bij een fout zijn er twee mogelijke schuldigen — de gebruiker of de tool. Allebei traceerbaar.
In dat model is IT vooral dienstverlener. Governance ging over wie welke tool mocht, op welk apparaat, met welke data. IAM ging over gebruikers en hun rechten. Behapbaar.
Het nieuwe model
Nu zit er een actor tussen.
De gebruiker vraagt iets. Een agent kiest welke tools nodig zijn, in welke volgorde, met welke data, en met welke rechten. Die rechten heeft hij óf van de gebruiker geleend, óf zelf gekregen, óf via een service account dat hij nu blijkt te mogen gebruiken.
Gaat er dan iets mis, dan zijn er ineens een hele rits mogelijke schuldigen. En de keten valt niet altijd compleet te reconstrueren — soms ontbreken er stukken in de logs, soms is niet meer te achterhalen welke beslissing waar is genomen.
Dat klinkt theoretisch. Het is in een toenemend aantal workflows gewoon de huidige werkelijkheid.
Wat dat in de praktijk verandert
Een paar dingen krijgen ineens ander gewicht. Approvals bijvoorbeeld. Vroeger was dat: gebruiker vraagt rechten, manager keurt goed, klaar. Nu zet de gebruiker een agent op, claimt die agent rechten namens de gebruiker, en voert hij acties uit waar de gebruiker niet altijd nog bij stilstaat. Wie keurt dan eigenlijk wat goed?
Hetzelfde geldt voor delegatie. Mensen delegeren al jaren impliciet aan tools. Maar een tool die zelf weer doorgeeft aan andere tools is delegatie van delegatie. Daar hebben we niet eens echt taal voor, laat staan een proces.
Observability is een ander pijnpunt. Loggen wat een gebruiker doet, dat lukt. Loggen wat een agent doet inclusief tussenstappen — wisselend. Loggen wat een keten van agents over meerdere systemen heen doet en daar één leesbaar overzicht van maken — daar staan we echt nog vroeg in.
Dan identity chaining: welke identiteit wordt waar gebruikt? Loopt het token van de gebruiker door tot in de derde tool, of stapt er ergens een service account in dat alles ineens als zichzelf uitvoert? Dat is een vraag die security architecten over een paar jaar dagelijks zullen stellen.
En misschien wel het minst besproken stuk — cognitive load. Niet voor IT. Voor de gebruiker. Als jouw agent dingen voor je doet, hoeveel weet jij dan nog van wat er gebeurt? En als je straks formeel verantwoordelijk bent voor de output van een agent die je niet helemaal begrijpt, voelt dat comfortabel?
Het lijkt me niet.
Een korte case
Bij een organisatie waar ik recent meekeek, draaide een applicatie dagelijks rapportages uit drie bronnen. De maker werkte er al niet meer. Die was met pensioen. Wel mooi dat die tool nog zijn naam had gekregen (en ik dacht dat het iets officieels was, maar kon via Google het product niet vinden). Het ding deed zijn werk gewoon. Niemand wist exact welke rechten het had. Niemand wist precies welke beslisregels erin zaten. En toch werd er management op gestuurd.
Niet rampzalig. Wel een voorbode van waar dit zonder ingrijpen heen gaat.
Dat eigenaarschapsvraagstuk heb ik in een ander artikel verder uitgewerkt. Hier wil ik vooral het bredere model laten zien.
De oude IT-vocabulaire schiet tekort
Het lastige is: we proberen dit te managen met de woorden die we al hadden. “Een nieuwe applicatie.” “Een service account.” “Een changeproces.” “Een policy.”
Maar een actor is iets anders dan een applicatie. Een actor handelt. En actor-modellen vragen om ander vocabulaire — uit andere disciplines. Identity governance heeft er een deel van. Operating model thinking heeft er een deel van. Risicomanagement, regulatory frameworks, en deels ook gewoon: gezond boeren verstand.
Wat er nodig is, zijn mensen die over die disciplines heen kunnen lezen en de vertaling maken. Niet alleen security-experts. Niet alleen AI-experts. Mensen die het snijvlak begrijpen. Uiteindelijk is pragmatiek ook wel belangrijk.
Waarom dit een strategisch vraagstuk is, niet alleen een IT-vraagstuk
Een toolset upgrade je. Een actor-model bouw je opnieuw, vanaf het organisatiemodel.
Dat klinkt zwaar. Het hoeft het ook niet meteen volledig te zijn. Maar de vragen die in een actor-model spelen — wie mag wat namens wie, hoe houden we zicht, wie is accountable, wat doen we bij offboarding — zijn niet alleen IT-vragen. Het zijn organisatievragen die toevallig in IT-systemen geland zijn.
Wie de digitale werkplek alleen vanuit IT optuigt voor agents, maakt iets dat technisch werkt en organisatorisch klem komt te zitten.
Wie hem optuigt vanuit governance, IAM én operating model tegelijk, bouwt iets dat houdbaar is.
Slot
De digitale werkplek wordt geen toolset 2.0. Het wordt iets anders. Een omgeving waarin mensen samenwerken met actoren die zelf ook weer samenwerken, met rechten, context, geheugen en een eigen mate van autonomie. En met alle governance-, identity- en accountability-vragen die daarbij horen.
Wie de werkplek nog inricht alsof het een toolset blijft, mist die verschuiving. En dat is geen kwestie van te vroeg of te laat — het gaat sowieso komen, of we het nu bewust adresseren of niet.
Werk je aan je digitale werkplek en zit je middenin deze verschuiving? Of speelt het hier ergens op de achtergrond en weet je nog niet helemaal hoe je het beet moet pakken? Even sparren mag altijd — via het contactblok op de homepage. Ik help vaak met de vertaling tussen IT, governance en business, en een eerste gesprek hoeft nergens toe te leiden.
Veelgestelde vragen over de digitale werkplek en het actor-model
Wat is een actor-model in de context van de digitale werkplek?
Een digitale werkplek waarin niet alleen mensen actoren zijn, maar ook AI-agents en geautomatiseerde processen die zelfstandig keuzes maken, andere tools aanroepen en namens de gebruiker handelen. Tegenover het oude toolset-model waarin de gebruiker direct elke tool bedient.
Wat verandert er voor IAM in een actor-model?
IAM krijgt er een hele categorie identiteiten bij — non-human identities die zelfstandig handelen. Approvals, delegation, recertificatie en offboarding moeten worden uitgebreid naar deze actoren, met expliciete eigenaarschapsstructuren en identity chaining tussen tools.
Wat is identity chaining?
Het doorgeven van een identiteit (of het wisselen van identiteit) door een keten van systemen heen. Bij een agent die namens een gebruiker meerdere tools aanroept is de vraag: wordt de identiteit van de gebruiker doorgegeven, of stapt er onderweg een service account in dat alles ineens als zichzelf uitvoert?
Hoe behoud je menselijke controle in een actor-model?
Door bewuste keuzes over welke beslissingen door agents mogen worden genomen, welke approvals een mens vereisen, en hoe gedrag van agents zichtbaar en auditbaar blijft. Menselijke controle is geen automatisch gevolg meer van dat de mens elke klik zet — het moet expliciet ontworpen worden.
