AI-adoptie bij IT-teams loopt zelden vast op de techniek. Een engineer die al tien jaar via zijn eigen scriptmap werkt, draait niet om omdat iemand een agent heeft gebouwd die hetzelfde in een derde van de tijd doet. Hij blijft zijn scriptmap openen, en hij heeft daar een gevoel bij dat hij sneller is. Dat gevoel is hardnekkiger dan welke demo, training of interne aankondiging dan ook. En precies daar wringt het in de meeste organisaties die nu in AI investeren.
We zien het bij onze eigen engineers, en we horen het terug bij klanten in zakelijke dienstverlening, cultuur en hospitality die hun eigen interne IT- of facilitaire teams proberen mee te krijgen. De tooling staat. De agent in Teams werkt. De handleiding voor de monteur op locatie kan in seconden worden opgehaald in plaats van in een PDF op een gedeelde schijf. En toch opent diezelfde monteur zijn map met bookmarks, omdat dat altijd plek A was.
Het frustrerende voor de leiding: de business case klopt op papier. Twee opdrachten per dag in plaats van één, minder fouten in de uitvoering, kortere doorlooptijd op tickets. Maar de cijfers blijven hangen op het oude niveau. Niet omdat de techniek faalt, maar omdat de gewoonte sterker is dan de tool. Wie dat onderschat, koopt licenties die voor de helft ongebruikt blijven en bouwt agents die alleen door de bouwer zelf worden geraadpleegd.
En dan komt het moment waarop iemand in het MT vraagt: wat heeft die investering ons nu eigenlijk opgeleverd? Dat gesprek wordt ongemakkelijk, omdat de eerlijke antwoorden (“we zien wel activiteit, maar geen verschuiving in throughput”) niet matchen met de cijfers die in de oorspronkelijke business case stonden. Vervolgens ontstaat de reflex om óf de tool af te schrijven als hype, óf om er nóg een laag bovenop te bouwen. Beide reacties missen de kern: het probleem zit niet in de tool, en ook niet in een gebrek aan kennis bij het team. Het zit in het feit dat niemand in de dagelijkse aansturing systematisch terugkomt op de vraag welke ingang er is gebruikt.
Wat werkt bij AI-adoptie bij IT-teams: gewoonte breken, niet techniek pushen
Wat in de praktijk werkt is niet nog een extra training of een interne nieuwsbrief over de nieuwe agent. Het is een verschuiving in waar je als leiding op stuurt. Niet op of de tool beschikbaar is, maar op of plek B daadwerkelijk wordt gebruikt voor het soort vragen waarvoor plek A altijd de default was.
Concreet betekent dat: meten hoe vaak een monteur of engineer naar de oude bron gaat versus de nieuwe, en daar herhaald op terugkomen. Niet één keer in een kickoff, maar in elke werkverdeling, elk weekoverleg, elke retrospective. De engineer die zegt “als ik het zelf doe ben ik sneller” heeft op die ene taak misschien gelijk. Over honderd taken niet. Dat verschil zichtbaar maken is geen techniekprobleem, dat is een sturingsprobleem.
Waarom monteurs en engineers vasthouden aan plek A
De reflex om naar de bekende plek te gaan is geen luiheid en geen onwil. Het is een rationele keuze op individueel niveau. Een monteur die op locatie staat met een klant die meekijkt, gaat geen experiment doen met een agent waarvan hij niet zeker weet of het antwoord klopt. Hij opent de handleiding die hij kent, scrolt naar het hoofdstuk dat hij kent, en lost het op zoals hij het altijd oplost. Op die ene opdracht is dat verdedigbaar. Het probleem ontstaat pas als je het over een kwartaal optelt en ziet dat dezelfde monteur structureel één opdracht per dag doet in plaats van twee.
Bij engineers speelt iets vergelijkbaars, maar met een extra laag. Hun identiteit hangt vaak samen met het vakmanschap van zelf de oplossing kennen. Een agent die het antwoord aanreikt voelt, bewust of onbewust, als een aantasting van die identiteit. Dat is geen argument om de tool weg te halen, maar het is wel iets dat je benoemt in plaats van wegredeneert. Pas als de engineer ervaart dat de agent hem helpt om sneller bij de niet-triviale problemen te komen, in plaats van zijn werk over te nemen, draait de houding.
Drie faalpunten die we steeds terugzien
Bij interne IT-teams en bij field-teams in hospitality zien we drie patronen die adoptie blokkeren. Eén: de nieuwe tool zit niet op de plek waar het werk al gebeurt. Een agent in een apart portaal wordt minder gebruikt dan dezelfde agent in het Teams-kanaal waar de monteur al de hele dag in zit. Twee: er is geen feedback-loop. De engineer die de agent één keer probeert en een matig antwoord krijgt, gaat niet terug. Drie: de leiding meet output maar niet gedrag. Zolang je alleen kijkt of de opdracht is afgerond, zie je niet of het via plek A of plek B is gegaan, en kun je het gesprek niet voeren.
Wat een werkend sturingsritme er in de praktijk uitziet
In de teams waar we adoptie wel zien doorzetten, ziet het ritme er ongeveer zo uit. In de wekelijkse werkverdeling wordt benoemd welke types vragen via de agent horen te lopen, niet als verplichting maar als verwachting. In de retrospective wordt één concreet voorbeeld besproken waarin iemand toch via plek A is gegaan, zonder oordeel, met de vraag wat er nodig was geweest om plek B te kiezen. Maandelijks ligt er een simpel overzicht op tafel met het aantal queries op de agent versus het aantal openingen van de oude bronnen, uitgesplitst per persoon of per team. Niet om af te rekenen, wel om het gesprek scherp te houden.
Wat daarbij helpt is dat de leiding zelf de nieuwe ingang gebruikt waar dat kan, en dat ook laat zien. Een teamlead die in een overleg hardop zegt “ik heb dit even via de agent gecheckt” doet meer voor adoptie dan drie trainingen. En omgekeerd: een teamlead die in datzelfde overleg een PDF op zijn scherm heeft staan die ook in de agent zit, geeft impliciet toestemming om bij het oude te blijven.
De oplossing is dus niet ingewikkeld, maar wel onaangenaam. Je moet als leiding bereid zijn om herhaald terug te komen op gedrag dat op individueel niveau verdedigbaar lijkt. Adoptie is geen communicatieprobleem, het is een sturingsritme. Wie dat ritme niet inricht, eindigt met een dure tool en een team dat doet wat het altijd deed. Wie het wel doet, ziet binnen één tot twee kwartalen dat de oude bookmarks langzaam worden vervangen door de nieuwe ingang, en dat de capaciteitswinst die op papier stond, ook in de cijfers gaat verschijnen.
AI-tools bouwen is het makkelijke deel geworden. Een agent op een handleiding zetten is een middag werk. Het lastige deel zit in de maanden daarna, waarin je als organisatie de gewoonte van plek A moet vervangen door de gewoonte van plek B. Wij richten Microsoft Cloud-omgevingen zo in dat de nieuwe ingang op de plek staat waar het werk al gebeurt, en we kijken mee met de leiding hoe je het sturingsritme inricht waarin adoptie daadwerkelijk doorzet. Een kort gesprek is genoeg om te bepalen of jouw situatie hier op lijkt.