Waarom AI-pilots stranden, en zelden door het model
Ik heb inmiddels genoeg AI-pilots van dichtbij gezien om het patroon te herkennen. Ze stranden bijna nooit op het model. Ze stranden op drie vragen die niemand vooraf beantwoordt.
Een pilot verloopt meestal zo. Iemand bouwt in twee weken iets indrukwekkends. De demo werkt, de zaal is enthousiast, er komt budget. Drie maanden later draait het nog steeds niet in productie, en niemand kan precies zeggen waarom niet.
Het antwoord is bijna altijd hetzelfde, en het heeft niets met AI te maken.
Vraag 1: wat gebeurt er als hij het fout heeft
Elk systeem dat beslissingen neemt heeft er ooit een fout. Dat is geen tekortkoming, dat is een eigenschap. De vraag is niet of het gebeurt maar wat er dan volgt, en dat is een organisatorische vraag, geen technische.
In de systemen die ik bouw classificeer ik elke actie in drie niveaus. Groen: doe het gewoon, de kost van een fout is verwaarloosbaar en omkeerbaar. Geel: bereid het voor en leg het voor aan een mens. Rood: raak er niet aan, signaleer alleen.
Die indeling maak je vóór je begint te bouwen, samen met de mensen die verantwoordelijk zijn voor het proces. Ze duurt een uur en ze bepaalt de hele architectuur. Een pilot die dit overslaat kan technisch perfect zijn en toch nooit uitrollen, omdat op het moment van uitrol niemand durft te tekenen voor wat het ding autonoom mag doen.
Vraag 2: wie is eigenaar van het proces eronder
Een agent automatiseert een proces. Als dat proces geen eigenaar heeft, automatiseer je chaos, alleen sneller.
Je kan geen proces automatiseren dat niemand bezit. Je kan het hoogstens versnellen tot het opvalt.
Dit is de meest voorkomende stille doodsoorzaak. Het project wordt getrokken door een innovatiemanager of een CTO, het proces zit bij operations, en operations was niet in de kamer toen de scope werd bepaald. Bij de uitrol blijkt dan dat de agent aannames maakt die niet kloppen met hoe het werk werkelijk gebeurt, en dat er niemand is met zowel het mandaat als de kennis om dat recht te trekken.
De remedie is banaal: de eigenaar van het proces is opdrachtgever van de bouw. Niet betrokken, niet geraadpleegd. Opdrachtgever.
Vraag 3: wie onderhoudt het over zes maanden
Agents verouderen sneller dan gewone software. Je CRM krijgt een veld erbij, een API verandert, een leverancier past zijn model aan, het proces zelf schuift op. Een agent die niemand onderhoudt degradeert stil, en het vervelende is dat hij blijft antwoorden terwijl hij verslechtert.
Dat betekent dat de vraag "wie past dit aan" beantwoord moet zijn voor de eerste regel code. Als het antwoord "de externe partij" is, heb je geen automatisering gekocht maar een abonnement op afhankelijkheid. Ik vind dat een slecht resultaat, ook al is het commercieel aantrekkelijk voor mij.
Wat een pilot wél zou moeten bewijzen
De meeste pilots bewijzen dat de technologie werkt. Dat wisten we al. Wat ze zouden moeten bewijzen is iets anders:
- Dat het proces goed genoeg begrepen is om er regels op te zetten
- Dat er iemand is die durft te tekenen voor de groene acties
- Dat de foutgevallen hanteerbaar zijn in aantal en in ernst
- Dat er iemand intern is die het over zes maanden nog snapt
Als die vier kloppen is de bouw het makkelijke deel. Als er één niet klopt, is geen enkel model goed genoeg om dat te compenseren.
Een praktische volgorde
Als ik ergens binnenkom voor een automatiseringsvraag, is dit de volgorde die ik aanhoud. Eerst kijken wat er werkelijk gebeurt, inclusief de uitzonderingen die niemand documenteert. Dan met de proceseigenaar de drie niveaus vastleggen. Dan pas bouwen, tegen de echte data, in een omgeving waar fouten niets kapotmaken. Dan uitrollen met logging, escalatie en een drempel waarboven een mens beslist. En dan overdragen, met documentatie, aan iemand met een naam.
Dat is trager dan een demo in twee weken. Het is ook het verschil tussen iets dat draait en iets dat indruk maakte.