Waarom AI-projecten in het MKB stuklopen

Er wordt veel geschreven over wat AI kan. Er wordt weinig geschreven over waarom het bij zoveel bedrijven na een half jaar stilligt. Dat is jammer, want dat is de kant waar je het meest van leert. Hier zijn de patronen die ik het vaakst tegenkom.

1. Te groot beginnen

Het klassieke patroon: er wordt een werkgroep opgericht, er komt een inventarisatie van alle processen, en er volgt een plan met vier fases. Zes maanden later is er nog niks in gebruik en is het enthousiasme op. Een systeem dat na twee weken één taak echt oplost, verandert meer dan een plan dat alles dekt.

2. Het probleem was er niet

Soms wordt er iets gebouwd omdat het kon, niet omdat iemand er last van had. De test is simpel: als het morgen kapot gaat, wie merkt dat dan? Kun je die vraag niet beantwoorden, dan los je geen probleem op en gaat het vanzelf stilvallen.

3. Niemand is eigenaar

Bij een pilot is iedereen betrokken. Zodra het draait is er niemand die verantwoordelijk is voor de vraag of het nog goed werkt. Dan verandert er iets in de gegevens, gaat de uitvoer stilletjes de mist in, en niemand ziet het. Twee maanden later gebruikt niemand het meer en weet niemand precies waarom.

De oplossing is niet ingewikkeld. Wijs iemand aan die het gebruikt en die het mag afkeuren. Dat is geen technische rol, dat is de persoon die het werk kent.

4. Het gaat stil kapot

Software die crasht merk je. AI die geleidelijk slechtere antwoorden geeft merk je niet, want het blijft er goed uitzien. Dat is het gevaarlijkste faalpatroon van allemaal, en de reden waarom je bij dit soort systemen altijd iets moet inbouwen dat luid mag falen: een controle waar het systeem zelf zegt dat het het niet weet, in plaats van een gok met een net antwoord eromheen.

• ▸Zorg dat het systeem mag zeggen dat het iets niet weet, in plaats van iets te verzinnen
• ▸Houd een kleine set voorbeelden bij waarvan je het goede antwoord kent, en toets daar periodiek op
• ▸Laat de uitkomsten ergens landen waar een mens ze langs ziet komen, niet in een map die niemand opent

5. De uitzonderingen zijn niet meegenomen

Elk proces heeft uitzonderingen die niemand noemt, omdat de mensen die het werk doen ze onbewust zelf opvangen. Vraag je hoe iets werkt, dan krijg je de hoofdregel. Bouw je daarop, dan valt het systeem om op het deel van de gevallen dat daar niet in past.

Daarom loop ik bij een nieuw traject altijd een aantal echte gevallen door in plaats van alleen het proces te bespreken. Niet om iemand te betrappen, maar omdat de uitzonderingen precies daar zitten waar de regel niet over gaat. Hoe die werkwijze eruitziet staat op de pagina over mijn werkwijze.

“Een proces dat je alleen kent uit de beschrijving, ken je niet. Je moet de gevallen zien waar de beschrijving niet over gaat.”

Wat wel werkt

Eén taak, twee weken, een meetbaar verschil, en iemand die er eigenaar van is. Werkt het, dan bouw je uit. Werkt het niet, dan heb je twee weken verloren in plaats van een half jaar. Dat is niet spectaculair, maar het is wel de enige aanpak die ik consequent zie werken.