Voorkom bij AI-pilots dat je iets overslaat wat je al 20 jaar weet

Van elke 33 AI-pilots die een bedrijf start, halen er vier de productie. Dat cijfer komt uit onderzoek van IDC, uitgevoerd samen met Lenovo en in maart 2025 gepubliceerd door CIO*. IDC noemt zelf drie oorzaken: een onduidelijke opbrengst, data die niet klaar is voor gebruik en te weinig eigen kennis in huis.

In mijn eigen werk gaat het meestal eerder mis, en om een veel simpelere reden. De pilot werkt gewoon. Hij draait alleen nog steeds op de laptop van de collega die hem bouwde, ingelogd met diens eigen account, gevoed door een export die diezelfde collega elke maandagochtend met de hand klaarzet. Twee weken vakantie en het staat stil.

Daar bestaat al twintig jaar een oplossing voor. Welke techniek ontbreekt, is dus niet de interessante vraag. Wat mij bezighoudt, is waarom een organisatie die precies weet hoe je software in de lucht houdt, dat vergeet zodra er AI in het project zit.

Wat er breekt, weet iedereen al

4 dingen gaan in vrijwel elke pilot als eerste stuk:

In die rechterkolom staat niets dat met taalmodellen te maken heeft. Het is de standaarduitrusting van elk systeem dat een organisatie in beheer heeft: de nachtelijke export naar de boekhouding, de koppeling met het orderpakket, het importscript van de loonadministratie. Bij die systemen zou niemand deze dingen overslaan. Bij een AI-pilot gebeurt het bijna altijd. Daar begint voor mij de interessante vraag, en ik zie er 3 verklaringen voor.

1. De eerste werkende versie kost geen weken meer

Tot voor kort was er maar één route naar een werkend prototype: iemand die voor de kost software bouwt, ging er weken mee aan de slag. Die persoon nam vanzelf zijn gewoonten mee. Een eigen plek om het te laten draaien, versiebeheer, het besef dat er ooit iemand gebeld wordt als dit stukgaat. Het prototype was daarmee meteen het bewijs dat er bouwervaring bij betrokken was.

Bij een AI-pilot is dat verband weg. De marketeer die het retourbeleid uit zijn hoofd kent, heeft in een middag een werkende versie die retourverzoeken beoordeelt. Dat is winst, want die kennis zat nooit bij de bouwers. De demo laat nog steeds zien dat het idee klopt. Wat hij niet langer laat zien, is dat er iemand bij zat die weet wat het kost om iets te laten blijven werken. De organisatie leest die demo nog steeds op de oude manier: als het werkt, is het grootste deel van het werk gedaan.

2. Het resultaat ziet er meteen af uit

Bij gewone software die nog niet af is, zie je dat meteen. Knoppen die nergens heen gaan, een inlogscherm dat er nog niet is, een naam die hard in het scherm staat in plaats van uit de database te komen. Iedereen in de zaal snapt dat er nog gebouwd moet worden.

Een pilot met een taalmodel levert vanaf de eerste dag keurige volzinnen. Wat zo’n pilot oplevert, is niet te onderscheiden van wat een afgerond systeem oplevert, want het komt uit het model en het model is af. Alles wat eromheen ontbreekt, blijft onzichtbaar. Er is geen scherm waarop te zien is dat de invoer handwerk is, of dat er niets gebeurt als het model een leeg antwoord teruggeeft omdat een klant een foto meestuurde in plaats van tekst. Een directie beoordeelt wat ze ziet, en wat ze ziet, is klaar.

3. Een pilot is een boekhoudkundige categorie, geen fase

In de praktijk heet een project een pilot omdat het zo betaald wordt: uit een innovatiebudget, of uit wat er op een afdelingsbudget over is. Software krijgt een regel voor beheer, hosting en de uren van degene die gebeld wordt. Een experiment krijgt die regel niet, want een experiment mag mislukken.

Die indeling wordt gemaakt voordat iemand weet of het ding gebruikt gaat worden, en daarna zelden herzien. Dat levert een omkering op: precies op het moment dat de pilot slaagt en collega’s erop gaan leunen, is er nog steeds niemand die ervoor betaald wordt om hem draaiend te houden.

Dat de aandacht in een AI-project op de verkeerde plek zit, valt ook goed te begrijpen. In een gewoon softwareproject is “kan dit eigenlijk wel” een saaie vraag, dus gaat het gesprek al vroeg over beheer, koppelingen en wie het straks draait. Bij AI is diezelfde vraag wel spannend. Kan het model dit echt? Daar gaat alle aandacht heen, en daar blijft die ook hangen nadat de vraag met ja is beantwoord.

Wie is er vanaf dag één verantwoordelijk?

De tabel hierboven ziet eruit als een bouwopdracht. Dat is het niet, het zijn vijf besluiten die in de eerste week van een pilot genomen kunnen worden, in ongeveer een uur, door de mensen die de pilot goedkeuren.

1. Twee namen op papier voordat de demo er is. Een opdrachtgever die beslist of dit blijft, en een beheerder die het draaiend houdt zodra dat besluit ja is. De beheerder mag de bouwer zelf zijn, zolang er uren voor gereserveerd staan. Zonder die tweede naam is er na de demo niemand voor wie dit werk is.
2. Een einddatum voor de pilot. Op een afgesproken dag stopt hij, tenzij iemand hem vóór die dag overneemt, met budget erbij. Zonder einddatum eindigt een pilot nooit, en begint hij ook nooit echt.
3. Het besluit over de overdracht, voordat de uitkomst bekend is. Spreek van tevoren af uit welk budget dit volgend jaar draait als de demo slaagt, en welke afdeling dan eigenaar wordt. Wie die vraag pas stelt nadat de demo geslaagd is, stelt hem in een kamer vol enthousiasme waar niemand nog ruimte op zijn begroting heeft.
4. Een grens voor het persoonlijke account. Draaien op een eigen account mag, zolang niemand anders van de uitkomst afhankelijk is. Zodra een collega die uitkomst gebruikt voor zijn werk, is dat de grens en verhuist het naar een account met eigen rechten en eigen logging. Bij persoonsgegevens is dat ook een AVG-vraag: zonder vastgelegde eigenaar is er niemand die kan uitleggen wie waarvoor verantwoordelijk was.
5. Eén afspraak over de data. Waar komt de invoer vandaan, wie merkt het als die stopt, en wie belt die persoon. Een handmatige export is prima in een pilot. Niet als niemand weet dat hij bestaat.

Wat de pilots die het wel halen anders doen

Geen van deze 5 afspraken gaat over AI, en dat is precies waarom ze worden overgeslagen. Ze horen bij de saaie helft van een project, en die helft krijgt op dit moment geen aandacht omdat de spannende helft alles opeist. De pilots die het wel halen zijn zelden de pilots met het beste model. Het zijn de pilots waar in week één iemand heeft gevraagd wie dit over drie maanden beheert, en waar iemand anders daar toen antwoord op gaf.

Waar je morgen mee kunt beginnen

Die vraag kun je ook stellen over de pilots die nu al lopen, en daar heb je niemands goedkeuring voor nodig. Schrijf op wat er in je organisatie draait onder de noemer pilot, proef of experiment. Vraag het na op de afdelingen zelf, want die lijst staat vrijwel nooit ergens compleet. Wat marketing of finance in een middag in elkaar heeft gezet, kent IT meestal niet.

Zet er per regel 3 dingen achter:

1. Wie beslist of dit blijft
2. Wie houdt het draaiend
3. Op welke dag stopt het als niemand het overneemt

Bij de meeste regels blijven die drie leeg. Dat is geen verwijt aan wie de pilot bouwde, dat is de kaart die je nodig had. Begin bij de regels waar collega’s inmiddels op leunen en waar geen naam achter staat. Daar voer je je eerste gesprek, en dat gaat niet over het model maar over die twee namen en die datum. Zo’n gesprek duurt een uur. Het is precies het uur dat bij de negenentwintig pilots die de productie niet halen nooit is ingepland.

* Onderzoek CIO