Wat 35+ AI-implementaties mij leerden.

Deel 1. Voor je tekent.

De duurste fouten worden gemaakt voordat er één regel code staat. In de intake, in de scope, in de platformkeuze, in wat niemand hardop zegt over wat "klaar" betekent, en in de meting die niemand heeft gedaan.

Les 1Het probleem zit zelden waar de klant zegt dat het zit.

Eerste gesprekken beginnen met een oplossing. "Wij willen een chatbot." Of: "Wij willen onze documenten doorzoekbaar maken met AI." Zelden met het probleem zelf.

De eerste stap in elk traject: die oplossing terugschroeven naar de vraag. Welk probleem lost dit op, voor wie, hoeveel tijd scheelt het, en is dit het grootste probleem dat er is?

Bij een exameninstituut vroegen ze om automatisering van hun kennisbank. Na doorvragen zat de grootste pijn in de kandidaatregistratie in een extern portaal. Eén uur handwerk per tien kandidaten, foutgevoelig. Dát pakten we eerst aan. De kennisbank kwam later. En de certificaatgeneratie, die dertig minuten per stuk kostte, duurt nu seconden.

Bij een IT-dienstverlener met 1.500 medewerkers was de vraag "meer AI in sales". De nulmeting zei iets anders: van de vijftien salesmensen gebruikten er drie de AI-functies die al in hun CRM zaten. Het probleem was geen gebrek aan tooling. Het was dat niemand de tooling in zijn dag kreeg. Dat is een ander project dan "bouw nog een tool".

De vraag waar je tijd in moet steken is niet "kunnen we het bouwen", maar "is dit het probleem dat we moeten oplossen".

Les 2Wie prijst op aannames, betaalt in uren.

De tweede fase bij datzelfde exameninstituut ging over de kennisbank. Het voorstel was gebaseerd op 152 documenten in veertien vakgebieden. De werkelijkheid: ongeveer duizend documenten in twintig vakgebieden. Ruim zes keer zoveel, ontdekt toen de scope al op papier stond. Eén onderdeel, een drukklare PDF, bleek al door een ander systeem geleverd te worden. Dubbel geprijsd.

Bij een houtverwerker was het patroon hetzelfde, met hardere cijfers. Een AutoCAD-onderdeel was begroot op 50 uur en kostte er 600. Een module waarvan we hadden besloten "die doen we niet" werd alsnog gebouwd: 160 uur. De hele fase liep van 1.140 geplande uren naar 1.421 gewerkte uren, 25 procent over. Het eindresultaat was goed, dertig uur per week bespaard. Maar de weg ernaartoe had niemand zo getekend.

Nu doe ik één ding anders: eerst een audit van het materiaal, dan pas een prijs. Hoeveel documenten zijn het echt. Hoeveel uitzonderingen zitten er in het proces. Wie raakt het aan. Een dag kijken voorkomt een kwartaal uitloop.

Les 3Het platform bepaalt het plafond. Ook het platform van de klant zelf.

Een kickstart bij een grote energieleverancier op Copilot Studio. Halverwege bleek: het platform blokkeert externe toolintegraties, biedt alleen GPT zonder reasoning, en gedraagt zich inconsistent tussen de Teams- en de Copilot-interface.

Dat zijn fundamentele beperkingen die je niet omzeilt met een betere prompt. De klant zei het zelf het scherpst, over de uiteindelijke agent: "Als ik Copilot open in SharePoint weet die meer context en kan hij beter antwoord geven." Terecht. De grenzen van het platform waren vooraf onvoldoende op tafel gelegd. Dat was onze fout, niet die van de klant, en we hebben het zo benoemd. De deliverable werd in overleg herijkt naar twee kleinere MVP's.

Het plafond zit lang niet altijd in het AI-platform. Vaker zit het in wat de klant al heeft. Bij een softwarebedrijf zagen we bij de intake dat de teamlimiet van hun AI-abonnement de bouwdag kon blokkeren: de gebruiker zat al op een kwart van zijn weekquotum, dus een extra seat moest vooraf geregeld worden. Bij een opleidingsbureau vroeg de klant op dag twee om centraal hergebruik van media over cursussen heen. We bouwden het ontwerp om, en vijf dagen later bevestigde de leverancier van het leerplatform dat één gedeelde bibliotheek over contentbibliotheken heen niet kan. Die vraag had vóór het ombouwen gesteld moeten worden. Bij een theatergezelschap bepaalde een Europese soevereiniteitseis de hele stack voordat er één functie was besproken. En bij de energieleverancier werd een koppeling die technisch in een middag kon, tegengehouden door de ondernemingsraad van het moederbedrijf, dat kritisch is op AI.

Sindsdien: platform-assessment vóór de kickoff, niet erna. Het AI-platform, de systemen van de klant, de licenties, en het bestuur. Soms is het antwoord: kies een ander platform. Soms: bouw deze use case ergens anders. Je ziet het plafond alleen als je ernaar vraagt.

Les 4Verwachtingen zijn asymmetrisch. Leg vast wat "klaar" is én hoe je het meet.

Klanten horen "PoC" en denken "werkend product". Ze horen "vier weken" en denken "alles klaar".

Dat is geen onwil. Het is het gevolg van marketing die AI presenteert als een eenvoudige oplossing, en van consultants (inclusief ik, soms) die de onderkant van de verwachtingslat niet expliciet genoeg neerzetten. Een klant in de houtverwerking vatte het zo samen, toen een oplevering technisch klopte maar in zijn ogen niet af was: "Als ik een pen koop, wil ik ermee schrijven. Niet alleen het inktpatroon krijgen."

Aanpak sindsdien: stel in week één een definitie van done op. Niet vaag ("een werkende chatbot") maar concreet: welke vragen beantwoordt het, met welk foutpercentage, in welk systeem, beoordeeld door wie? Dat document is nu een vast onderdeel van de projectstart, met een formeel acceptatiemoment.

En één regel die ik pas later leerde: leg ook de meetmethode vast, niet alleen het target. Bij een webshop stonden twee KPI's op papier, logo-herkenning en e-mailmatching, allebei met een ondergrens. Logo-herkenning haalden we: 93,8 procent. E-mailmatching niet: onze logs zeiden 73,2 procent, de klant mat 53, afgesproken was 80. Twee problemen in één. Een gemiste KPI, en twintig punten verschil tussen twee metingen van hetzelfde ding, omdat niemand had vastgelegd hoe er gemeten werd. Factuur betwist, app op pauze. De targets stonden op papier. De manier van meten niet.

Dat gesprek is ongemakkelijk. Het is ook het nuttigste gesprek dat je vroeg in een project kunt hebben.

Les 5Zonder nulmeting is elk resultaat een mening.

De meeste AI-projecten eindigen met een gevoel. "Het scheelt echt tijd." "Mensen zijn enthousiast." Dat is geen resultaat, dat is een stemming. Een resultaat is een delta: zo was het, zo is het nu, dit is het verschil.

Daarom zit de nulmeting in het ritme, niet in de goede bedoelingen. In week twee meet ik hoe het proces nu loopt: minuten per taak, fouten per batch, aantal mensen dat de bestaande tooling echt gebruikt. In week drie meet ik de delta. Zonder delta is het een mening. Met delta is het bewijs, en bewijs is wat je nodig hebt als iemand in maand vier vraagt waarom dit geld kostte.

De nulmeting verandert ook de scope. Bij die IT-dienstverlener uit les 1 was "drie van de vijftien" niet een cijfer in een rapport. Het was het project. Zonder die meting hadden we een tool gebouwd voor twaalf mensen die de vorige ook al niet gebruikten.

Les 6Uurtje-factuurtje beloont uitloop.

Kijk nog eens naar de houtverwerker uit les 2. Die 281 uur extra waren niet het gevolg van slecht werk. Ze waren het gevolg van een contract zonder strakke fasering, zonder tussentijdse evaluatiemomenten en zonder financiële rem. Elke sub-flow at zich vast in extra uren, en niemand had een reden om te stoppen.

Daarom werk ik nu met een vaste prijs en een vaste scope. Niet omdat uren oneerlijk zijn, maar omdat de prikkel verkeerd staat. Wie per uur factureert, verdient aan scope creep. Wie een vaste prijs afspreekt, verdient aan scherp afbakenen. Dat laatste is wat je als klant wilt.

Er is nog een reden, en die is nieuw. Een analyse die vroeger twee dagen kostte, duurt met AI nu twee uur. Code die drie dagen vroeg, staat in een dag. Geef je dat voordeel door in een uurtarief, dan verdient de klant aan jouw snelheid en heb jij er niets aan. Dan houd je als bureau op met sneller worden. Een vaste prijs op een vast resultaat beloont het bureau dat sneller wordt, en de klant die weet wat hij krijgt.

De spiegel hoort erbij: lever niet vóór de handtekening. Bij een bouwgroothandel draaiden de eerste sessies al voordat het contract rond was, omdat de relatie goed voelde. Het kwam goed. Het had ook niet goed kunnen komen. De commerciële klok en de operationele klok lopen zelden synchroon; laat de eerste leidend zijn.

Deel 2. Tijdens het bouwen.

Een goede start is geen garantie. De volgende vier lessen gaan over wat er tussen kickoff en oplevering misgaat, en hoe je dat vroeg ziet.

Les 7Kleine scope, groot vertrouwen. En een checkpoint op dag vijf.

De projecten die het beste uitpakten waren niet de grootst geambitieerde. Ze waren de meest afgebakende. Eén probleem, één team, vier weken. Dan meten. Dan beslissen of je verder gaat.

Klanten die willen beginnen met "een compleet AI-platform voor de hele organisatie" rem ik af. Niet omdat het niet kan, maar omdat het zelden een goed startpunt is. Eén werkende tool die twintig mensen dagelijks gebruiken zegt meer dan een roadmap van honderd pagina's. Bij een tegelhandel was de scope één rekensom: materiaalhoeveelheden uit een werktekening halen. Dat was binnen weken bruikbaar. Bij de houtverwerker was de scope "de planning en de kennisbank en de tekeningen", en je hebt gelezen hoe dat uren kostte.

De eerlijke les achter die kleine scope: onze eigen vierweekse kickstart was lange tijd te ambitieus voor de prijs. Training, analyse én een automatisering live in vier weken werkt alleen bij simpele cases. Bij complexere projecten ontdekten we pas in week twee of drie dat het lastiger lag, en dan begint de scope creep. Daarom zit het beslismoment nu op dag vijf, met drie uitkomsten. Simpel: doorgaan en bouwen in week drie en vier. Gemiddeld: de klant kiest, een simpelere automatisering nu of een groter traject. Complex: meerdere dingen tegelijk, dan stoppen we met de kickstart-vorm en gaan we meteen naar een langer traject. Eén beslismoment, vroeg, met de klant aan tafel. Dat is goedkoper dan een verrassing in week drie.

Les 8Intern groen is geen bewijs. Klantdata is de waarheid, en de test hoort van de klant te zijn.

De tool voor die tegelhandel werkte op onze eigen testset. Groen, alles. Toen we hem tegen een echt werkboek van een klant van de klant zetten, kwam de waarheid: stuks 0,0 procent afwijking, wand 8,1 procent, kim 6,8 procent. Niet slecht. Maar ook niet wat de interne test suggereerde, en de kalibratie die het verschil maakte kon pas beginnen toen we echte klantdata hadden.

Bij het exameninstituut zat de waarheid in één cel. De import naar het examensysteem faalde op een hele batch zodra één veld in één rij fout stond. De data van de klant was de bottleneck, niet het model. Dat geldt vaker wel dan niet.

Les: bouw tegen je eigen testset, maar vier pas als het tegen de echte data van de klant overeind blijft. Rapporteer de afwijking eerlijk, inclusief de lelijke getallen. Een klant die 8,1 procent te horen krijgt vertrouwt je meer dan een klant die "het werkt" hoort en later zelf de afwijking ontdekt.

En ga één stap verder: geef de klant de test. De evaluatieset waarmee ik bouw maak ik open, zodat hij op de machine van de klant draait. Jouw machine, mijn test, jouw oordeel. Een claim die je niet kunt narekenen is geen claim maar marketing. Dat geldt voor "95 procent nauwkeurig" net zo goed als voor "35+ implementaties".

Les 9De security-blokkade is vaak een schijnblokkade.

Bij een groothandel lag een koppeling met het voorraadsysteem maanden stil op een security-clearance. Toen we uitzochten welke data we écht nodig hadden, bleek het grootste deel al ergens anders bereikbaar. De koppeling was niet nodig. De blokkade ook niet.

Het omgekeerde komt ook voor: legal en IT die maanden doen over een AI-beleid, terwijl medewerkers intussen privé-ChatGPT gebruiken voor werkdocumenten. Zonder kaders haken niet je slechtste mensen af, maar je nauwkeurigste: de mensen die wachten op toestemming.

Twee lessen in één. Vraag bij elke blokkade eerst: welke data hebben we minimaal nodig, en staat die al ergens waar we wel mogen komen? En zorg dat er kaders zijn vóór de tool, niet erna. Een beleid van één pagina op dag één verslaat een juridisch sluitend document in maand zes.

Les 10De champion is de sleutel. En de bus-factor.

In elk succesvol project zat een champion: iemand intern die het echt wilde begrijpen. Niet de IT-manager, niet de directeur. Een medewerker die zag wat AI voor zijn eigen werk betekende en anderen daarin meenam.

Projecten zonder duidelijke champion lopen vast, ook als de tool goed is. De tool wordt niet gebruikt, de feedback blijft weg, en na drie maanden weet niemand meer wat er ook alweer gebouwd was.

Maar één champion is ook een risico. Bij een bedrijf waar een e-mailbot-pilot veertig minuten per dag bespaarde, kende maar één persoon de techniek. Toen het vervolg ter sprake kwam, werd het geparkeerd tot na de zomer. Niet omdat het niet werkte. Omdat de kennis bij één iemand zat.

Het tegenvoorbeeld is een verzekeraar. We trainden er 300 mensen. Na zes weken waren er tien die het zelf gingen trekken. Na drie maanden was de salesverwerking zestig keer sneller. Na zes maanden hadden ze ons niet meer nodig. Dat laatste is het doel. Een bureau dat je na een half jaar nog elke week nodig hebt, heeft geen champions gebouwd maar afhankelijkheid.

Identificeer de champion in week één. Geef diegene toegang, tijd, input. En zorg in week vier dat het er twee zijn.

Deel 3. Na de livegang.

Live is niet klaar. De vier lessen die het verschil maken tussen een tool die gebruikt wordt en een tool die in maand drie stilstaat.

Les 11Adoptie begint niet na de launch.

De meest gemaakte fout: adoptie als aparte stap plannen na de implementatie. "We bouwen de tool, dan doen we een training, dan gaan mensen het gebruiken."

Dat werkt niet. Adoptie begint bij de probleemanalyse. De mensen die de tool straks gebruiken moeten betrokken zijn bij het definiëren van het probleem. Niet als checkbox, maar omdat hun input de tool beter maakt en hun betrokkenheid de adoptie vergroot.

Bij een logistiek concern vroeg een manager of zijn team de training kon betalen via het bedrijf, direct, niet declareren. Dat klinkt als een administratieve vraag. Het was een adoptiesignaal. Hij wilde zijn team achter dit zetten. Die bereidheid is goud waard, en begint niet op de dag van de lancering.

Les 12De stille meerderheid bepaalt adoptie, niet de believers.

In elke organisatie zie je drie groepen. De versnellers, die op dag één al aan het experimenteren zijn. De afwachters, vijftien tot twintig procent, sceptisch of gewoon te druk, die pas bewegen als ze bewijs zien. En daartussen de middengroep: zestig tot zeventig procent van de mensen, die het prima vinden maar niet uit zichzelf beginnen.

De fout die ik het vaakst zag: alle aandacht naar de versnellers. Zij zijn enthousiast, zij geven feedback, zij komen naar de sessies. Maar zij nemen de middengroep niet vanzelf mee. Een tool die twintig enthousiastelingen gebruiken en tweehonderd anderen niet, is geen adoptie. Het is een hobbyclub.

Wat wel werkt: de middengroep krijgt bewijs uit hun eigen werk, niet uit een demo. Eén collega naast je die laat zien dat het haar dinsdag een uur scheelt, doet meer dan een training van een dag. Daarom stuurt de verzekeraar uit les 10 met tien interne champions en niet met tien externe consultants. Peer-to-peer verslaat top-down, elke keer.

Les 13Eén fout weegt zwaarder dan 99 goede antwoorden.

AI-agents draaien inmiddels 95 tot 99 procent van de tijd zonder fouten. Toch onthouden mensen die ene fout. Krijgen ze daar geen uitleg bij, dan groeit het wantrouwen, en een tool die gewantrouwd wordt, wordt omzeild.

De oplossing is geen hoger percentage. Het is zichtbaarheid. Laat de tool zeggen wat hij niet weet. Laat hem zijn bron tonen. Bouw checkpoints in waar de agent laat zien wat hij deed en waarom, vóórdat hij verdergaat. Geef een mens de knop om te corrigeren en laat zien dat de correctie iets doet. Een klant in de houtverwerking zei het over een tool die we voor hem bouwden: "Maakt niet uit hoelang het duurt, als het maar klopt." Dat is de lat. Niet snelheid. Kloppen, en uitleggen wanneer het niet klopt.

Les 14Wat je achterlaat is geen systeem maar een agent met een eigenaar.

De twee voorbeelden uit les 10 laten hetzelfde zien: eigenaarschap bepaalt wat er na je vertrek gebeurt. De verzekeraar draait op tien interne champions; bij de e-mailbot die veertig minuten per dag bespaarde, kende maar één persoon de techniek. Dan Shipper van Every, dat zijn eigen adviespraktijk door een agent in Slack laat draaien, zegt het scherp: "every agent needs a human". Gartner verwacht dat ruim 40 procent van de agent-projecten voor eind 2027 wordt gestopt door oplopende kosten, onduidelijke bedrijfswaarde of gebrekkige risicobeheersing.

Daarom is mijn overdracht sinds augustus 2026 een vaste lijst van vijf. Eén naam die eigenaar is. De evaluatieset uit les 8, draaiend op de machine van de klant en niet op de mijne. Een runbook van één pagina: wat doet het, wat mag het niet, waar kijk je als het stilvalt. Een afspraak over wie ingrijpt bij een fout, met de knop uit les 13. En een pad voor de volgende modelversie, want het model dat vandaag werkt kan binnen een half jaar zijn vervangen, en dan hoort er een hertest te draaien.

Eerlijk: die lijst is jonger dan de meeste projecten in dit memo. De eerste opdracht waar alle vijf punten bij de klant zijn afgevinkt moet nog worden afgerond. Daarom staat hij hier als les en niet als bewijs. Vraag ernaar bij elk bureau, ook bij mij: wat laat je achter, en wie is dan de eigenaar?

De rode draad.

35+ implementaties zijn geen bewijs dat ik alles goed doe. Ze zijn bewijs dat ik genoeg fout heb gedaan om te weten wat werkt.

De rode draad in de succesvolle projecten is steeds dezelfde: meten vóór je bouwt, en eerlijk zijn over wat je meet. Een probleem dat je eerst hebt gecontroleerd. Een scope die je op echte cijfers hebt geprijsd. Een platform waarvan je de grenzen kent, ook die van de klant. Een definitie van done met meetmethode. Een nulmeting in week twee. Een vaste prijs. Een beslismoment op dag vijf. Validatie op klantdata, met een test die de klant zelf kan draaien. Een champion plus reserve. Adoptie die begint op dag één en mikt op de middengroep, niet op de fans. En een tool die uitlegt wat hij doet.

Dat klinkt simpel. De meeste bedrijven slaan toch minstens één van deze stappen over. Meestal omdat het bureau er niet om vraagt.

Tien vragen voor je tekent.

Stel ze aan elk bureau. Ook aan mij.

1. Welk probleem lossen we op, voor wie, en hoeveel tijd of geld scheelt het per week? Als het antwoord "een chatbot" is, is het geen antwoord.
2. Heeft het bureau het materiaal gezien voordat het een prijs noemde? Hoeveel documenten, hoeveel uitzonderingen, hoeveel systemen?
3. Wat kan het gekozen platform niet, en wat kunnen onze eigen systemen en licenties niet? Vraag om drie concrete grenzen. "Geen" is een rode vlag. En wie van ondernemingsraad, security of legal moet nog ja zeggen?
4. Wat is de definitie van done, op papier, met foutpercentage, meetmethode en beoordelaar?
5. Wat is de nulmeting, wanneer wordt die gedaan, en wie meet de delta in week drie?
6. Is de prijs vast of per uur? Wie betaalt de uitloop?
7. Wanneer is het eerste moment waarop we kunnen stoppen zonder gezichtsverlies? Als dat pas na vier weken is, is het te laat.
8. Op welke data wordt getest: die van het bureau of die van ons? En kunnen we de test zelf draaien?
9. Wie is intern de eigenaar, en wie is de tweede?
10. Wat gebeurt er in week één met de mensen die de tool straks gebruiken, en wat is het plan voor de zestig procent die niet uit zichzelf begint? Als het antwoord "training na oplevering" is, lees les 11 en 12 nog een keer.

Welke sla jij over?