De eerste 90 dagen AI-adoptie in een mkb-bedrijf: een routekaart

Een mkb-bedrijf dat besloten heeft AI te adopteren staat bijna altijd voor dezelfde verkeerd gestelde vraag: «welke tool koop ik?». Het is de verkeerde vraag, of beter: het is de derde, niet de eerste. Vóór een tool is een traject nodig — en het traject heeft, wanneer het werkt, een herkenbare vorm en een precieze duur. De solidste adoptieplaybooks in omloop — het publieke van GitHub is het best leesbare — delen het allemaal op dezelfde manier in: eerste 30 dagen voor de fundamenten, eerste 90 dagen voor de vaart, dan het doorlopende regime voor de schaal. Dit artikel neemt die structuur en stemt ze af op een Italiaanse kleine onderneming: wat te doen, in welke volgorde, en met welke controles, in de eerste drie maanden.

Het loont te beginnen bij een ongemakkelijk gegeven, want het verklaart waarom de routekaart meer telt dan de tool. De sectoranalyses zijn het eens over twee getallen: de grote meerderheid van de AI-agents haalt de productie nooit, en ongeveer 29% van de projecten wordt binnen 90 dagen gestaakt. Niet door technische beperkingen — de tools werken — maar omdat ze vertrokken zonder te weten waar ze heen gingen, zonder een verantwoordelijke en zonder controles. De 90 dagen zijn geen willekeurige aftelklok: het is precies het venster waarin een slecht opgezette adoptie sterft. Ze goed opzetten is het hele spel.

Week 1–2: weten waar u staat, vóór u wat dan ook koopt

De eerste fout is een tool kopen vóór u het startpunt hebt gemeten. Het eerste dat een serieus traject voortbrengt is geen software, maar een eerlijke foto van waar het bedrijf staat. De maturiteitsmodellen die de markt daarvoor gebruikt — van Gartner tot Deloitte — geven een antwoord in één regel: «u bent op stadium X van 5». Maar de nuttige versie voor een mkb-bedrijf geeft niet één enkel getal: ze splitst de score in twee domeinen — de Fundamenten (data, technologie, competenties) en de Strategie (governance, risico, doelen, cultuur) — om zo te verklaren waarom u vastzit, niet alleen hoezeer. Het is een onderscheid dat de zetten verandert: goede fundamenten maar geen strategie is een omgekeerd probleem ten opzichte van wie de ideeën helder heeft maar de data in wanorde.

Hier is een punt dat in het bijzonder voor Italië geldt. De bekendste readiness-indexen (Cisco bijvoorbeeld) wegen infrastructuur en data zwaar — een weerspiegeling van een wereld van grote ondernemingen. Voor de meeste Italiaanse mkb-bedrijven is de bottleneck niet de infrastructuur: het is de strategie en het proces. Ze weten dat ze iets met AI moeten doen, ze weten niet wat noch waar. Een op het mkb afgestemde beoordeling verschuift het gewicht dus naar strategie, governance en cultuur, en geeft van daaruit aan welke afdeling echt klaar is om als eerste te starten. Het is het werk dat we self-service en gratis hebben gemaakt: onze AI-readiness-beoordeling geeft in twee minuten die foto — op welk stadium u per domein bent en welke afdeling het beste als eerste te openen. Het is het nulpunt van de routekaart; zonder is elke volgende stap een gok.

Week 3–6: één enkele use-case, met een verantwoordelijke

Met de foto in de hand is de verleiding op drie fronten tegelijk te vertrekken. Het is de fout die die 29% stakingen voortbrengt. De regel van de eerste 90 dagen is het tegenovergestelde: één enkele use-case, in de afdeling die de beoordeling als de meest gerede aanwees, tot in productie gebracht. Geen proef in een hoek geparkeerd — een workflow die iemand echt elke dag gebruikt, met een meetbaar vóór en ná. Eén keer winnen, klein en serieus, is meer waard dan vijf gestaakte pilots.

Het tweede ingrediënt is dat wat het verschil maakt tussen een project dat duurt en een dat verdampt zodra het enthousiasme opraakt: een verantwoordelijke. De enterpriseplaybooks noemen het Center of Excellence en kennen het vijf aparte functies toe — wie de prioriteiten beslist, wie het laatste woord heeft, wie de mensen opleidt, wie de standaarden en de herbruikbare modellen bijhoudt, wie naar de waardesignalen kijkt. Een mkb-bedrijf heeft geen vijf teams voor deze zaken, en het heeft ze niet nodig: het heeft één of twee personen nodig die alle vijf die functies dekken. Niet de hiërarchische rang, maar het eigenaarschap: iemand wiens naam naast de use-case staat. Zonder een verantwoordelijke met een naam is de workflow van niemand, en wat van niemand is wordt als eerste verlaten.

Deze eerste use-case is geen geïsoleerd voorval: het is de eerste vermelding van een playbook dat groeit. Elke vermelding brengt een fase mee — pilot, dan schaal, dan regime — zodat men halverwege het traject kan filteren op «wat komt daarna» in plaats van al afgeronde pilots te herlezen. Hoe een playbookvermelding er vanbinnen uitziet — de structuur, de verantwoordelijke, de vastgehaakte controles — hebben we ontleed in de anatomie van een AI Workflow Design.

Vanaf dag 1, niet vanaf dag 90: de minimale controles

De duurste fout van de eerste 90 dagen is de governance tot het einde uitstellen — «laten we het eerst laten werken, dan zetten we de controles». Het is precies andersom: de minimale controles moeten worden gezet op de dag waarop de use-case start, want ze later toevoegen betekent de workflow herontwerpen, niet bijschaven. Er is geen zwaar apparaat nodig — er zijn vier zetten nodig, allemaal verifieerbaar vóór de gang naar productie:

• Classificeer het risico. In welke tier van de AI Act valt de use-case? Het merendeel van de mkb-toepassingen — een interne copilot, contentgeneratie, een eerstelijnsbot — leeft in de tier minimaal of beperkt, waar de last licht is. De zware machinerie gaat pas aan voor de hoog-risicotoepassingen (personeelsselectie, krediet, biometrische data): als uw eerste use-case daar een van is, weet u al dat er meer voorzichtigheid nodig is.
• Verifieer of een DPIA nodig is. Als de workflow geautomatiseerde beslissingen met gevolgen voor mensen neemt, of bijzondere gegevens op grote schaal verwerkt, is de GDPR-effectbeoordeling verschuldigd — en een «standaard»-DPIA volstaat niet, want ze mist de AI-eigen risico's (opaciteit van het model, drift, memorisatie, recht op vergetelheid). Het is een vraag om op dag 1 te stellen, niet om bij een controle te ontdekken.
• Zet een mens in de lus. Geen enkele output die een klant, een kandidaat of het geld raakt zou mogen vertrekken zonder een menselijke tussenkomst. Het is de controle die meer waard is dan alle geschreven policy, en ze moet in de workflow worden ontworpen, niet ernaast gehangen.
• Houd traceerbaarheid bij. Wie heeft wat gedaan, wanneer, met welke input. Voor de hoog-risicogevallen vraagt de AI Act de logs minstens zes maanden te bewaren; voor alle andere is de traceerbaarheid hoe dan ook wat u toelaat een auditor te antwoorden, een fout te reconstrueren en een beslissing te verdedigen.

Het zijn dezelfde vier zetten die onze compliance-overlay aan elke workflow die we ontwerpen vasthaakt — niet als formaliteit achteraf, maar als deel van het ontwerp. De volledige redenering, met de risicotaxonomie en het waarom van elke controle, staat in het artikel over de controles die een use-case verdedigbaar maken.

De eindstreep van 90 dagen: van pilot naar methode

Als de eerste zes weken goed zijn gegaan, hebt u op dag 90 geen «tool erbij»: u hebt een use-case in productie, een verantwoordelijke met een naam, de vastgehaakte controles en — het belangrijkste van al — een methode die herhaald kan worden op de tweede afdeling zonder vanaf nul te herbeginnen. Het loont drie controlepunten langs de weg vast te leggen:

• Dag 30 — fundamenten. De readinessfoto is gemaakt, de startafdeling is gekozen, de verantwoordelijke is aangewezen, de minimale controles zijn gedefinieerd. Nog geen tool per se gekocht: eerst het waarom en het wie, dan het wat.
• Dag 60 — vaart. De eerste use-case leeft en iemand gebruikt hem elke dag. De eerste eerlijke cijfers en het eerste interne «succesverhaal» worden verzameld — dat wat de tweede afdeling overtuigt het te proberen.
• Dag 90 — schaal. De use-case houdt zichzelf overeind, de tweede staat in de wachtrij met dezelfde structuur, en het playbook heeft nu twee vermeldingen in plaats van één. Vanaf hier is de adoptie geen project meer: het is een manier van werken.

Een laatste ding over de cijfers, want het is het punt waar adopties zichzelf voor de gek houden. Het succes meten met «hoeveel er gebruiken» is de eerste trede, niet de laatste: na de gebruiksbreedte komt de diepte (wie het echt gebruikt, en waarvoor) en pas op het eind de impact op de business — de bespaarde tijd, de vermeden fouten, de geraakte omzet. Een pilot die iedereen «geprobeerd» heeft maar niemand in de diepte gebruikt is geen succes: het is een staking die zich nog niet heeft aangekondigd. De 90 dagen dienen om minstens één use-case tot de derde trede te brengen.

Het verschil tussen wie op 90 dagen een methode heeft en wie een ongebruikte tool erbij heeft, zit niet in de technologie — het zit in het feit dat men de dingen in de juiste volgorde heeft gedaan: eerst weten waar u staat, dan één enkele use-case met een verantwoordelijke, de controles vanaf dag 1, en de schaal pas daarna. Het is precies de volgorde waarin wij AI in een bedrijf enten.

De eerste stap is echter altijd dezelfde en u kunt hem nu zetten: weten waar u staat. De gratis beoordeling geeft u in twee minuten de startfoto en de afdeling waarmee u het beste uw 90 dagen opent. Wilt u daarna begrijpen hoe u van begrijpen naar doen gaat, dan praten we erover — vrijblijvend.

Dit artikel is bedoeld ter oriëntatie. De genoemde stakingspercentages en doorlooptijden komen uit marktanalyses en sectorbronnen, niet onafhankelijk geverifieerd, en moeten als richtingaanwijzingen worden gelezen, niet als garanties. De risicotiers, de DPIA-verplichtingen en de bewaartermijnen van de logs hangen af van de use-case en de vigerende regelgeving — de EU AI Act is in ontwikkeling — en moeten altijd op de context van het individuele bedrijf worden geverifieerd vóór te handelen.