Wat 35+ AI-implementaties mij leerden.

Deel 1. Voor je tekent.

De duurste fouten ontstaan voordat er één regel code staat: in de intake, de scope en de platformkeuze, in wat niemand hardop zegt over wat "klaar" betekent, en in de meting die niemand deed.

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.

Mijn eerste stap is die oplossing terugbrengen 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 project bleek na doorvragen dat een ander knelpunt meer aandacht verdiende dan de oorspronkelijke bouwvraag. We pasten de volgorde van het werk daarop aan.

Bij een andere opdracht lag het probleem in het gebruik van bestaande software, en meer bouwen zou dat niet oplossen. Eerst moest duidelijk worden waarom mensen de beschikbare functies lieten liggen.

Stel eerst de vraag of dit het probleem is dat je moet oplossen. Of je het kunt bouwen, komt daarna.

Les 2Wie prijst op aannames, betaalt in uren.

Ik heb voorstellen zien uitgaan van minder materiaal en minder uitzonderingen dan er werkelijk waren. Staan prijs en scope eenmaal vast, dan leidt dat tot lastige keuzes. Werk dat buiten de scope leek te vallen, kwam tijdens de uitvoering alsnog terug.

Daarom doe ik eerst een audit van het materiaal en noem ik pas daarna een prijs. Hoeveel documenten zijn het echt, hoeveel uitzonderingen zitten er in het proces, en wie werkt ermee? Uitsluitingen leg ik vast, en wijzigingen bespreken we voordat iemand ze bouwt. Een dag kijken voorkomt een kwartaal uitloop.

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

Tijdens een implementatie bleek het gekozen platform niet alles te ondersteunen wat het ontwerp nodig had. Dat los je niet op met een betere prompt. De beperkingen hadden vooraf op tafel moeten liggen; we pasten het ontwerp en de verwachtingen aan.

De grens zit ook buiten het AI-platform. Bestaande systemen, licenties en interne besluitvorming bepalen net zo goed wat mogelijk is. Sinds dat project doe ik vóór de kickoff samen met de klant een platform-assessment van die vier: het AI-platform, de eigen systemen, de licenties en wie er moet beslissen. Soms is de uitkomst een ander platform, soms een andere plek voor deze use case. Het plafond zie je 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. Marketing wekt verwachtingen die een eerste versie nog niet waarmaakt, en ook ik heb die verwachtingen soms te weinig besproken. Technisch werkend en bruikbaar in het dagelijks werk zijn twee verschillende oordelen.

Daarom stel ik in week één een definitie van done op. "Een werkende chatbot" is te vaag. De definitie zegt welke vragen het beantwoordt, met welk foutpercentage, in welk systeem, en wie dat beoordeelt. Dat document hoort vast bij de projectstart, met een formeel acceptatiemoment.

Leg ook de meetmethode vast. Ik heb meegemaakt dat de bouwer en de klant dezelfde toepassing verschillend beoordeelden. Spreek naast het target af welke gegevens, uitzonderingen en rekenregels bij de meting horen.

Dat gesprek is ongemakkelijk, en het is het nuttigste gesprek dat je vroeg in een project kunt voeren.

Les 5Zonder nulmeting is elk resultaat een mening.

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

Daarom staat de nulmeting vast in de planning. In week twee meet ik hoe het proces nu loopt: minuten per taak, fouten per batch, het aantal mensen dat de bestaande tooling echt gebruikt. In week drie meet ik de delta. Die heb je nodig als iemand in maand vier vraagt waarom dit geld kostte.

Een nulmeting kan de scope veranderen. Wordt bestaande software nauwelijks gebruikt, dan levert begeleiding soms meer op dan een nieuwe toepassing.

Les 6Uurtje-factuurtje beloont uitloop.

Onduidelijke fasering en ontbrekende evaluatiemomenten maken uitloop moeilijk te begrenzen. Ik heb extra werk zien opstapelen wanneer niemand vooraf had afgesproken wanneer je opnieuw beslist.

Daarom werk ik met een vaste prijs en een vaste scope. Het gaat om de prikkel. Wie per uur factureert, verdient aan scope creep. Wie een vaste prijs afspreekt, verdient aan scherp afbakenen, en dat wil je als klant.

De tweede reden is nieuw. Een analyse die vroeger twee dagen kostte, duurt met AI twee uur. Code waar je drie dagen over deed, staat in een dag. Reken je per uur, dan krijgt de klant het voordeel van jouw snelheid en heb jij er niets aan, dus stopt een bureau met sneller worden. Een vaste prijs op een vast resultaat beloont het bureau dat sneller wordt, en de klant weet vooraf wat die krijgt.

Begin niet met leveren voordat de afspraken rond zijn. Een goede relatie vervangt geen duidelijke scope en opdrachtbevestiging.

Deel 2. Tijdens het bouwen.

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 het strakst afgebakend: één probleem, één team, vier weken, daarna meten en beslissen of je doorgaat.

Vraagt iemand om een compleet platform, dan begin ik liever met één afgebakende toepassing. Dan zie je wat werkt en wat ontbreekt voordat je meer onderdelen toevoegt.

Die les geldt ook voor mijn eigen aanbod. De vierweekse kickstart uit mijn vorige rol was lange tijd te ambitieus voor de prijs. Training, analyse én een automatisering live in vier weken lukt alleen bij simpele cases. Bij complexere projecten bleek 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 tussen een simpelere automatisering nu of een groter traject. Complex: er moeten meerdere dingen tegelijk gebeuren, dus vervalt de kickstart-vorm en start meteen een langer traject. Eén vroeg beslismoment met de klant 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.

Een toepassing kan goed werken op de testset van de bouwer en anders uitpakken op gegevens uit het dagelijkse werk. Die verschillen ontdekte ik pas door samen met de klant te testen.

Let ook op de invoer. Een onverwachte waarde of uitzondering kan een verwerking laten mislukken; neem die gevallen op in de beoordeling.

Bouw tegen je eigen testset en beoordeel het resultaat op echte gegevens van de klant. Rapporteer afwijkingen en beperkingen, zodat iedereen hetzelfde beeld heeft van wat werkt.

Ga daarna één stap verder en geef de klant de test. De evaluatieset waarmee ik bouw, maak ik open, zodat die op de machine van de klant draait en de klant zelf oordeelt. Een claim die je niet kunt narekenen, is marketing. Dat geldt voor "95 procent nauwkeurig" net zo goed als voor "35+ implementaties".

Les 9De security-blokkade is vaak een schijnblokkade.

Bij een vastgelopen koppeling bleek een andere route naar de benodigde informatie mogelijk. Onderzoek dus eerst welke informatie je nodig hebt, en kies pas daarna de technische route.

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

Vraag bij elke blokkade eerst welke data je minimaal nodig hebt, en of die al ergens staat waar je wel mag komen. En zorg voor kaders voordat de tool er is. 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: een medewerker, geen IT-manager of directeur, die zag wat AI voor het eigen werk betekende en collega's 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 gebouwd is.

Eén champion is ook een risico. Begrijpt maar één persoon de toepassing, dan wordt verder bouwen en onderhouden kwetsbaar. Een team wordt zelfstandig als meerdere mensen de toepassing begrijpen en anderen kunnen begeleiden, en dat hoort bij de overdracht.

Zoek de champion in week één en geef die persoon toegang, tijd en inspraak. Zorg dat het er in week vier twee zijn.

Deel 3. Na de livegang.

Deze vier lessen gaan over wat na de livegang bepaalt of een tool gebruikt wordt of in maand drie stilstaat.

Les 11Adoptie begint niet na de launch.

De meest gemaakte fout is adoptie plannen als aparte stap 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. Betrek de mensen die de tool straks gebruiken bij het definiëren van het probleem: hun input maakt de tool beter, en wie meedacht over het probleem, gebruikt de oplossing eerder.

Steun van een leidinggevende blijkt uit ruimte om te oefenen, vragen te stellen en mee te beslissen. Die ruimte moet er tijdens het project al zijn.

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

In elke organisatie zie je drie groepen. De versnellers experimenteren op dag één al. De afwachters, vijftien tot twintig procent, zijn sceptisch of te druk en bewegen pas als ze bewijs zien. Daartussen zit 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 gaat naar de versnellers. Zij zijn enthousiast, geven feedback en komen naar de sessies, maar ze nemen de middengroep niet vanzelf mee. Een tool die twintig enthousiastelingen gebruiken en tweehonderd anderen niet, is een hobbyclub.

De middengroep heeft voorbeelden uit het eigen werk nodig. Laat collega's elkaar begeleiden en bespreek waar de toepassing helpt en waar niet.

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.

Laat de toepassing zeggen wat zij niet weet en haar bronnen tonen. Bouw momenten in waarop een mens kan controleren en corrigeren voordat het systeem verdergaat. Dan zie je wat je wel en niet kunt vertrouwen.

Les 14Laat geen agent achter zonder eigenaar.

Eigenaarschap bepaalt wat er na je vertrek gebeurt. Dan Shipper van Every zegt het zo: "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: het model dat vandaag werkt, kan binnen een half jaar vervangen zijn, en dan hoort er een hertest te draaien.

Die lijst is jonger dan de meeste projecten in dit memo. De eerste opdracht waarin de klant alle vijf punten heeft afgevinkt, loopt nog. Daarom staat hij hier als les en niet als bewijs. Vraag elk bureau wat het achterlaat en wie daarna de eigenaar is.

De rode draad.

35+ implementaties bewijzen vooral dat ik genoeg fout heb gedaan om te weten wat werkt.

De succesvolle projecten volgden steeds hetzelfde patroon: eerst meten, dan bouwen, en de meetmethode laten zien. De tien vragen hieronder toetsen elke stap.

De meeste bedrijven slaan minstens één van die stappen over, meestal omdat het bureau er niet naar 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?