Consistent over sectoren heen geldt één ding: de meeste AI-initiatieven bereiken een interessante demo en stagneren daarna. Deloitte, MIT Sloan en andere instellingen rapporteren dat 75–95 % van de AI-projecten de geplande bedrijfswaarde niet realiseert. Het cijfer verschilt per definitie van mislukking, maar de richting is ondubbelzinnig.
Erger nog: deze pilots mislukken niet op de technologie. Ze mislukken op beslissingen die werden genomen vóórdat er ook maar één regel code werd geschreven. Hieronder de meest voorkomende oorzaken — en wat je anders kunt doen.
Valkuil één: een pilot zonder productieplan
Het patroon dat we het vaakst zien, ziet er als volgt uit: een team kiest een use-case, bouwt in zes weken een demonstratie, het management is enthousiast, het project krijgt "groen licht" voor de volgende fase — en dan blijkt dat niemand heeft nagedacht over wat die volgende fase eigenlijk inhoudt.
Een pilot is geen productie. Een pilot draait in een geïsoleerde omgeving, met handmatig geselecteerde data, zonder belasting, zonder beveiligingsvereisten, zonder integratie in bestaande systemen. Een pilot is het bewijs dat een idee fysiek mogelijk is. Geen bewijs dat het schaalbaar, onderhoudbaar en veilig is.
Een productiesysteem heeft nodig:
- Integratie met live databronnen (CRM, ERP, sensoren, documentopslagplaatsen)
- Authenticatie, audit log, role-based access
- Monitoring en alerting wanneer het model afwijkend gedrag vertoont
- Een rollback-plan als er iets misgaat
- Een plan voor modelupdates wanneer de domeindata veranderen
Geen van deze punten komt voort uit een pilot. Als een productieplan geen onderdeel is van de pilot-opdracht, is de pilot een hobby, geen investering.
Wat je anders kunt doen: Schrijf vóór de start van de pilot één pagina: "Wat wordt de productie-architectuur? Wie is de eigenaar? Wat is het plan voor data-ontsluiting? Wat is het succescriterium aan het einde van fase 2?" Als niemand op deze vragen een antwoord heeft, stel de pilot dan uit — dat bespaart tijd en geld.
Valkuil twee: geen data, geen eval
De tweede meest voorkomende reden voor mislukking: een team bouwt een systeem zonder vooraf te definiëren hoe ze weten of het werkt.
Een RAG-pipeline geeft een antwoord terug. Is het correct? Relevant? Consistent over vijf vergelijkbare vragen? Zonder een eval-set — een verzameling echte vragen met verwachte antwoorden — kan niemand dit beantwoorden. En dat is een probleem, want zonder eval-set:
- Kun je versies van het systeem niet vergelijken (is V2 beter dan V1?)
- Kun je regressie na een model- of datawijziging niet detecteren
- Kun je aan stakeholders niet onderbouwen dat het systeem werkt
- Kun je niet identificeren waar het systeem precies faalt
Een eval-set hoeft niet groot te zijn — 50–200 representatieve gevallen met een gemarkeerd correct antwoord is een goede start. Belangrijk is dat die er is vóór de uitrol, niet erna.
Een parallel probleem zijn de data zelf. De Cisco AI Readiness Index geeft aan dat slechts ongeveer een derde van de bedrijven haar data-gereedheid als voldoende beoordeelt. In de praktijk ziet dat er zo uit: documenten in uiteenlopende formaten, slecht benoemd, zonder metadata, verspreid over vier verschillende locaties. Een RAG-systeem op zulke data geeft resultaten terug — alleen geen goede. En het team merkt het niet, want de eval-set bestaat niet.
Wat je anders kunt doen: Breng vóór de pilot de databronnen in kaart en beantwoord drie vragen: waar zitten de data, in welke staat verkeren ze en wie is de eigenaar. Stel tegelijkertijd een eval-set samen op basis van echte gevallen. Deze twee activiteiten onthullen 80 % van de blockers nog voordat je begint te bouwen.
Valkuil drie: geen duidelijke eigenaar
AI-pilots in een corporate omgeving lijden eraan dat ze van iedereen en van niemand zijn. De IT-afdeling heeft de architectuur ontworpen. Het businessteam heeft de use-case gedefinieerd. Management heeft goedkeuring gegeven. Maar wie is er verantwoordelijk voor het resultaat?
Onderzoek toont consistent aan dat projecten met een sterke en eenduidige executive sponsor een dramatisch hogere slagingskans hebben. Zonder een duidelijke eigenaar gebeurt het volgende:
- Elk team heeft andere prioriteiten en de pilot schuift naar het einde van de wachtrij
- Niemand wil beslissingen nemen over afwegingen (snelheid vs. nauwkeurigheid, kosten vs. dekking)
- Als het systeem slechter presteert, weet niemand wie het probleem moet oplossen
- Wanneer het moment van productie-uitrol aanbreekt, wacht iedereen op wie de eerste stap zet
Wat je anders kunt doen: Wijs één projecteigenaar aan met het mandaat om beslissingen te nemen, niet alleen te coördineren. Die persoon moet businesscontext hebben (niet alleen technisch), toegang tot stakeholders en de capaciteit om minstens 20–30 % van zijn tijd aan het project te besteden. Zonder dat is de pilot een hobby voor vrijwilligers.
Valkuil vier: integratie wordt onderschat
In de pilotfase draait het systeem doorgaans op een voorbereide datasample, met handmatige export, in een Jupyter-notebook of Streamlit-prototype. In productie moet het:
- Data lezen uit live systemen in realtime of met een gedefinieerde frequentie
- Outputs wegschrijven naar systemen waarop andere mensen of processen wachten
- Authenticatie en rechten respecteren vanuit bestaande identity-systemen
- Uitval, vertragingen en inconsistente invoerformaten kunnen opvangen
Elk van deze punten is een apart project. Integratie is doorgaans 40–60 % van de totale kosten van een productiesysteem — en de meeste pilots houden er helemaal geen rekening mee.
We zien ook het andere uiterste: een team heeft drie maanden besteed aan integratie, het model is technisch verbonden met live data, maar niemand heeft gecontroleerd of de data in productie dezelfde kwaliteit en structuur hebben als de data uit de pilot. Antwoord: die hebben ze niet.
Wat je anders kunt doen: Neem een geschatte integratieprijs op in de businesscase van de pilot. Onzekerheid is acceptabel — schrijf een bandbreedte op. "Integratie met SAP en SharePoint: geschatte bandbreedte 40–120 ingenieurdagen." Als dat cijfer het management verrast, is het beter dat nu te weten dan na zes maanden werk.
Valkuil vijf: onrealistische verwachtingen
Een AI-demo is altijd beter dan productie. Een demo bevat zorgvuldig geselecteerde voorbeelden waar het model het beste presteert. Productie krijgt alles — inclusief randgevallen, slecht geformatteerde invoer en vragen buiten het getrainde domein.
Als een stakeholder een demo heeft gezien en gelooft dat het productiesysteem vergelijkbaar zal functioneren — of zelfs beter, als het "meer data" heeft — ontstaat er een probleem. Op het moment dat het productiesysteem een slecht antwoord geeft (en dat zal het doen), is de reactie een mismatch tussen wat er werd beloofd en wat het systeem werkelijk aankan.
Een verwant probleem is de verwachting van directe ROI. Onderzoek toont aan dat de meeste CEO's er realistisch van uitgaan dat een positief rendement langer dan zes maanden duurt. Bij complexere use-cases is een realistische horizon 12–24 maanden. Wanneer een project onder druk komt te staan om "zichtbare resultaten voor het einde van het kwartaal" te leveren, eindigt het óf met onrealistische metriekclaims, óf met vroegtijdige beëindiging.
Wat je anders kunt doen: Stel vóór de pilot expliciet verwachtingen in: "De demo toont het potentieel. Het productiesysteem heeft een foutmarge van X %. De eerste meetbare waarde zien we in maand Y. Volledig rendement op de investering verwachten we in de horizon Z." Als het management het met deze cijfers niet eens is, is het beter dat nu te weten.
Valkuil zes: de "demo werkt"-val
Dit is het meest onderschatte probleem en het verdient een eigen hoofdstuk.
De demo werkt. Het model beantwoordt vragen. Retrieval geeft relevante documenten terug. Het prototype is uitgerold op testservers. Het team viert feest. En dan... vertraagt het project. Niet omdat er iets misgaat — maar omdat niemand weet wat er hierna moet komen.
Oorzaken:
- Er is geen meetbare doelgrens: de pilot had niet gedefinieerd wat een "geslaagde pilot" betekent. Hij eindigde als een wetenschappelijk experiment zonder conclusies.
- Productiegereedheid is niet binair: de overgang van prototype naar productie is geen deployment — het zijn maanden werk aan beveiliging, stabiliteit, monitoring, documentatie en training.
- Procesverandering is moeilijker dan technologieverandering: een nieuw AI-hulpmiddel vereist dat mensen hun manier van werken aanpassen. Change management wordt doorgaans onderschat of ontbreekt volledig.
- Een succesvol project genereert nieuwe complexiteit: als de pilot werkt, wil de business meer (meer use-cases, meer gebruikers, meer talen). Zonder schaalbare architectuur is dat geen expansie — het is technische schuld.
Wat je anders kunt doen: Definieer de exitcriteria van de pilot van tevoren. "De pilot is geslaagd als: (1) de eval-set een nauwkeurigheid van ≥ X % bereikt, (2) de latentie onder Y seconden ligt, (3) het team de productie-architectuur heeft geïdentificeerd en de kosten ervan heeft geschat." Zonder exitcriteria eindigt een pilot nooit — hij wordt eindeloos "nog iets verbeterd".
Wat teams die het wél halen, gemeenschappelijk hebben
Van projecten waarbij de overgang van pilot naar productie soepel verliep, zijn een paar gemeenschappelijke patronen te onderscheiden:
- Ze begonnen met een kleine, goed afgebakende use-case. Niet "AI voor het hele klantencentrum" — maar "AI beantwoordt de eerste laag van vragen over de status van een bestelling". Heldere scope, meetbaar resultaat.
- Businessmetrieken waren gedefinieerd vóór de start. Niet "we verbeteren de efficiëntie" — maar "we verlagen de eerste responstijd van 4 uur naar 45 minuten voor categorie X vragen".
- Het datateam was er van het begin bij, niet pas in de integratiefase. Ze vermeden de situatie waarin modelingenieurs zes weken wachten op datatoegang.
- De pilot had een productie-architectuur op papier vóór de eerste commit. Die hoefde niet definitief te zijn — maar ze bestond.
- Change management was vanaf dag één onderdeel van het project. Wie gaat het systeem gebruiken? Wat verandert er in hun dagelijkse routine? Wie traint hen? Wie is het escalatiepunt bij problemen?
Projecten waarbij dit allemaal op orde was, realiseren meetbare waarde — in de meeste gevallen binnen zes maanden na de productiestart. Projecten waarbij dit ontbrak, blijven draaien in een kringloop van pilots.
Wanneer een pilot zinvol is — en wanneer niet
Een pilot is een legitiem instrument om onzekerheid te reduceren. Als je niet weet of RAG over jouw documenten voldoende nauwkeurigheid haalt, is een pilot het juiste antwoord. Als je niet weet of een model jouw specifieke terminologie aankan, verifiëert een pilot dat sneller en goedkoper dan een volledige uitrol.
Een pilot is niet zinvol als:
- De use-case voldoende onderzocht is (industriële documentatie, klantenservice, interne Q&A) — in dat geval zijn er genoeg referentie-implementaties en stelt de pilot de beslissing alleen maar uit
- Het team niet de capaciteit heeft om het project naar productie te brengen — de pilot eindigt in een la
- Het management niet accepteert dat productie aanzienlijk meer kost dan een pilot — dat kun je beter nu zeggen
Aan de andere kant zijn pilots aan het begin van AI in een bedrijf een natuurlijk onderdeel van het leerproces — op voorwaarde dat elke pilot een duidelijk gedefinieerd doel heeft en de leerpunten systematisch worden overgedragen naar de volgende iteratie.
Hoe je meet of een pilot de investering waard is
Beantwoord vóór de start van de pilot zes vragen:
- 1.Wat meet precies het succes? (een concrete metriek, niet "verbetering")
- 2.Wie is de eigenaar en heeft het mandaat om te beslissen?
- 3.Wat zijn de geschatte kosten van de productiefase? (minimaal een bandbreedte)
- 4.Welke data zijn beschikbaar en in welke staat verkeren ze?
- 5.Hoe wordt het systeem geïntegreerd in bestaande tools en processen?
- 6.Wat gebeurt er als de pilot goed uitpakt — wie beslist wanneer over productie?
Als je op een van deze vragen geen antwoord hebt, begin dan niet aan de pilot — investeer die tijd in voorbereiding. Paradoxaal genoeg: projecten met een goede voorbereiding duren korter, niet langer.
Voor een dieper inzicht in hoe je de werkelijke bedrijfswaarde van AI-initiatieven meet, bekijk dan ROI van AI-projecten — inclusief een raamwerk voor voortdurende tracking en rapportage aan stakeholders.
Veelgestelde vragen
Wat is de gemiddelde doorlooptijd van pilot naar productie?
In de praktijk varieert die van drie maanden bij eenvoudige use-cases (interne Q&A over documenten) tot 12–18 maanden bij systemen met diepe integratie in ERP, regelgevende vereisten of de noodzaak van fine-tuning. De kritische factor is niet technische complexiteit, maar de gereedheid van de organisatie — op datagebied, procesgebied en menselijk vlak.
Wat kost een productie-AI-systeem vergeleken met een pilot?
Een pilot kost doorgaans 5–20 % van de totale projectkosten. De rest gaat naar integratie, beveiliging, monitoring, change management en onderhoud. Teams die deze verhouding onderschatten, belanden in een situatie waarbij de businesscase van de pilot er goed uitziet, maar de productie-businesscase door niemand wordt goedgekeurd omdat de cijfers anders zijn.
Wat als de pilot goed uitpakte maar stakeholders niet willen investeren in productie?
Dit is een signaal dat de businesscase niet voldoende vooraf is gecommuniceerd. De pilot had niet duidelijk gedefinieerd wat er na succes zou gebeuren. Oplossing: terugkeren naar concrete metrieken, de verbinding tonen tussen pilotresultaat en bedrijfswaarde en een productieplan presenteren met een kostenbandbreedtte. Als er ook dan geen draagvlak is, is de use-case waarschijnlijk geen hoge genoeg prioriteit — en dat is waardevolle informatie.
Hoe kies je de juiste use-case voor de eerste pilot?
De ideale eerste use-case voldoet aan vier criteria: (1) goed afgebakend — duidelijke in- en outputs, (2) er is een beschikbare databasis, (3) meetbaar — je kunt zeggen of het werkt of niet, (4) er is een interne voorvechter — iemand die het oprecht wil en het resultaat daadwerkelijk zal gebruiken. Een uitgebreider raamwerk voor use-case-selectie vind je in het artikel Hoe begin je met AI in een bedrijf.
Is een foutmarge in een AI-systeem acceptabel in productie?
Dat hangt af van de use-case. Voor interne Q&A of een assistent bij documentvoorbereiding is een foutmarge van 5–10 % doorgaans acceptabel, als het systeem tegelijkertijd tijd bespaart. Voor een systeem waarbij fouten financiële of veiligheidsconsequenties hebben, moet je een human-in-the-loop gate inbouwen en de doelmarge voor de uitrol bespreken. Er is geen universele norm — maar er is wel een verplichting om die te definiëren vóór productie.
*Als u staat voor de beslissing of uw AI-pilot de moeite waard is om naar productie te brengen, of als u een partner zoekt voor de beoordeling van architecturele gereedheid en een realistisch businessplan, voert MP Industrial Solutions deze beoordelingen uit als onderdeel van een eerste consultatie — vrijblijvend, met concrete conclusies.*