--- title: "AI implementatie: stappenplan van pilot naar productie" description: "Waarom de meeste AI-pilots nooit productie bereiken, en het concrete stappenplan om dat wel te doen. Met echte productiecijfers uit twee klantprojecten." canonical: "https://www.whatsnext-ai.com/nl/blog/ai-implementation" published: "2026-08-04T00:00:00.000Z" updated: "2026-08-04T14:32:00.580Z" --- # AI implementatie: stappenplan van pilot naar productie Waarom de meeste AI-pilots nooit productie bereiken, en het concrete stappenplan om dat wel te doen. Met echte productiecijfers uit twee klantprojecten. ![A hand placing wooden blocks into a rising staircase, building it up stage by stage](https://fgzcpjbyiakhjifaciaj.supabase.co/storage/v1/object/public/media/imagine-buddy-btmtgget5s4-unsplash.jpg) AI-implementatie is het proces waarmee je een AI-pilot omzet in een systeem dat elke dag draait: met eigenaarschap, monitoring en een team dat het gebruikt, niet alleen een werkend prototype in een demo-omgeving. De meeste bedrijven zitten inmiddels niet vast op het idee. Ze zitten vast op de stap daarna. Er draait een veelbelovende pilot, de directie was onder de indruk, en dan gebeurt er maanden niets. Dit is het stappenplan om die pilot wel naar productie te krijgen, en waarom die laatste stap bijna nooit over het model gaat. ### Wat is AI-implementatie? AI-implementatie is het hele traject van een idee naar een AI-systeem dat structureel meedraait in je bedrijfsvoering. Het verschil tussen "een pilot draaien" en "iets in productie hebben" is groter dan het lijkt. Een pilot bewijst dat iets kan. Iemand laat zien dat een model facturen kan uitlezen of e-mails kan beantwoorden, meestal in een geïsoleerde omgeving, handmatig aangezwengeld, zonder koppeling met je echte systemen. Dat is waardevol als bewijs, maar het is geen implementatie. Productie betekent dat het systeem elke dag draait zonder dat iemand het handmatig start. Het is gekoppeld aan je CRM, je boekhouding of je klantenservice. Het houdt bij wat het doet, geeft een seintje als er iets misgaat, en er is een duidelijke eigenaar die verantwoordelijk is. Dat is het verschil tussen een indrukwekkende demo en iets waar je bedrijf op kan bouwen. ### Waarom komen de meeste AI-pilots nooit in productie? Uit [MIT NANDA-onderzoek uit 2025 (The GenAI Divide: State of AI in Business)](https://nanda.media.mit.edu) blijkt dat zo'n 95% van de generatieve-AI-pilots geen meetbaar bedrijfsresultaat oplevert. De oorzaak is zelden het model; het is bijna altijd dat de pilot de productiefase nooit haalt. Het probleem zit in wat er ná de pilot komt. Een demo lijkt voor 90% klaar terwijl hij feitelijk voor 20% af is. De ontbrekende 80% is het onspannende engineeringwerk dat niemand had begroot: authenticatie, een database, toegangsrechten, foutafhandeling, monitoring en een deployment-pijplijn. Dat werk is niet spannend om te demonstreren, maar zonder dat werk is er geen productie. De tweede reden is organisatorisch. Zonder een duidelijke eigenaar buiten de IT-afdeling loopt een AI-traject bijna altijd vast. De pilot was van "het AI-team", maar niemand van de afdeling die het dagelijks moet gebruiken voelt zich verantwoordelijk. We gaan hier bewust niet dieper op de faalanalyse in, dat is een onderwerp op zich. De rest van dit artikel gaat over de route die het wel werkt. ### Het stappenplan: van pilot naar productie Onderstaand stappenplan is de route die wij bij klantprojecten aanhouden. De kern is dat je het productiewerk niet naar het einde schuift, maar het vanaf de pilot al meeneemt. #### Fase 0: probleem en eigenaar vastleggen Begin niet bij de technologie, begin bij het probleem en de eigenaar. Welk concreet, meetbaar probleem los je op, en wie in het bedrijf wordt beter van de oplossing? Die persoon is de eigenaar, niet de IT-afdeling. Leg in deze fase ook vast hoe succes eruitziet in cijfers. Niet "de klantenservice verbeteren", maar "de gemiddelde afhandeltijd van een offerteaanvraag halveren". Zonder die KPI weet je later niet of de productieversie het waard is om te blijven draaien. Aan die KPI hangt de business case. Een AI-implementatie moet zichzelf terugverdienen, en dat reken je vooraf uit: hoeveel uur of hoeveel fouten kost het proces nu, en wat levert het op als een systeem het overneemt. Wil je een eerste inschatting van die waarde, dan helpt onze [automatiserings-ROI-calculator](https://www.whatsnext-ai.com/tools/automation-roi) je op weg. Zonder een heldere business case bouw je een technisch huzarenstukje dat niemand mist als het wegvalt. Dit is ook het moment om eerlijk naar je data te kijken. Een AI-systeem is zo goed als de data waar het op draait, en dit is de stap die het vaakst wordt overgeslagen. Staat de informatie die het systeem nodig heeft ergens toegankelijk, of zit die verspreid over mailboxen, spreadsheets en de hoofden van een paar mensen? Als het antwoord "verspreid" is, dan is data op orde krijgen onderdeel van de implementatie, niet iets dat je achteraf oplost. #### Fase 1: pilot met heldere kaders Nu pas komt de pilot, ook wel proof of concept of PoC genoemd, en die heeft een strakke afbakening nodig. Een goede pilot lost één probleem op, met een duidelijke evaluatieset en vooraf afgesproken guardrails: wat mag het systeem wel en niet doen, en waar grijpt een mens in. Praktisch betekent afbakenen: kies één proces, één afdeling en een vast tijdvak, bijvoorbeeld vier weken. Niet "AI voor de klantenservice", maar "de eerste 200 offerteaanvragen van type X, alleen classificeren, nog geen antwoord versturen". Hoe smaller de scope, hoe eerder je iets echt weet in plaats van iets vermoedt. Definieer vooraf niet alleen hoe succes eruitziet, maar ook wat falen is. Welke foutmarge is acceptabel, en bij welke uitkomst zeg je "dit is niet goed genoeg"? Even belangrijk: breng in kaart waar de pilot bekend zwak is, de randgevallen die het model nog niet aankan. Die bekende zwakke plekken zijn geen schande, ze bepalen juist de grens van wat je live zet: alles daarbinnen automatiseer je, alles daarbuiten gaat voorlopig naar een mens. Zo wordt de scope van je productieversie een bewuste keuze in plaats van een verrassing achteraf. Sluit de pilot af met een expliciete go/no-go op basis van de KPI uit Fase 0. Dit voorkomt de meest voorkomende val: een pilot die "best goed werkt" en daarom eindeloos blijft hangen zonder ooit een beslissing te forceren. #### Fase 2: de productielaag bouwen Dit is de fase die het verschil maakt en die in de meeste trajecten ontbreekt. Hier bouw je de 80% die de demo niet liet zien: koppelingen met je echte systemen, authenticatie en toegangsrechten, foutafhandeling, en een mens-in-de-lus voor de gevallen waar het model twijfelt. Een concreet voorbeeld van dat laatste: in plaats van het model blind te vertrouwen, laat je het per resultaat een betrouwbaarheidsscore teruggeven. Bij lage zekerheid gaat het naar een mens. Zo bouw je een systeem dat je durft te vertrouwen, in plaats van een zwarte doos. In deze fase leg je ook het eigenaarschap technisch vast. Het systeem draait bij voorkeur in jouw eigen omgeving, op jouw cloud-account, met code die je bezit. Dat klinkt als een detail, maar het is het verschil tussen een asset en een afhankelijkheid: kun je van leverancier wisselen, de code laten aanpassen of het systeem overnemen zonder dat alles stilvalt? Als het antwoord nee is, heb je geen productiesysteem gebouwd maar een abonnement afgesloten. #### Fase 3: productie-uitrol Zet het systeem niet in één keer voor iedereen live. Rol het gefaseerd uit. Eerst schaduw-draaiend naast het bestaande proces, zodat je de uitkomsten kunt vergelijken zonder risico. Daarna naar een kleine, afgebakende groep gebruikers, en pas als dat stabiel is naar de rest. Technisch leunen we hierbij op blue-green deployments: er draaien twee identieke productieomgevingen naast elkaar, en je zet het verkeer pas over naar de nieuwe versie als die zich bewezen heeft, met de oude omgeving als directe terugvaloptie als er iets misgaat. In combinatie met het uitrollen naar deelverzamelingen van gebruikers betekent dit dat een fout nooit je hele gebruikersgroep in één klap raakt, en dat terugdraaien een kwestie van seconden is, niet van een noodoperatie. Bij deze fase horen ook de saaie maar cruciale afspraken: wie wordt gebeld als het misgaat, hoe snel moet het hersteld zijn, en hoe worden de mensen die ermee werken opgeleid. Een systeem zonder deze afspraken is geen productiesysteem, het is een ongeluk dat op een moment wacht. #### Fase 4: doorlopend verbeteren Productie is geen eindpunt. Modellen en data veranderen, en een systeem dat je vandaag vertrouwt kan over drie maanden zijn afgedwaald. Plan daarom vanaf het begin monitoring, periodieke controle van de kwaliteit, governance en een cadans om het systeem bij te sturen. Dit is ook waar de waarde zich opstapelt. Elke fase bouwt voort op de data die de vorige oplevert, en een systeem dat blijft draaien wordt na verloop van tijd waardevoller en makkelijker verder op te schalen, niet minder. ### Waarom dit een engineering-probleem is, geen tool-probleem Veel adviezen over AI-implementatie beginnen met een aanbeveling: start met kant-en-klare tools zoals Copilot, ChatGPT of Perplexity. Voor individuele productiviteit is dat prima. Voor een systeem dat naar je CRM of ERP schrijft, is het de verkeerde afslag. Het verschil zit in wat er gebeurt als het misgaat. Een gewrapte chatbot die soms een verkeerd antwoord geeft is hinderlijk. Een systeem dat autonoom de verkeerde status in je CRM zet, of een factuur op de verkeerde grootboekrekening boekt, is een probleem dat zich vermenigvuldigt zolang niemand het ziet. Daarom bouwen wij productie-AI in code, niet in low-code platforms zoals n8n of Make. Niet omdat low-code niks kan, maar omdat een productiesysteem foutafhandeling, versiebeheer, testbaarheid en controle nodig heeft die je in een visuele flow-bouwer simpelweg niet krijgt. Als je een pilot in zo'n tool hebt gemaakt en die nu vastloopt, is dat geen falen: het is precies het punt waarop de meeste bedrijven ontdekken dat de productielaag echt engineering vraagt. Concreet betekent code drie dingen die je in een visuele flow niet krijgt. Je kunt het systeem testen: geautomatiseerde tests die afgaan zodra een wijziging iets stukmaakt, voordat het in productie belandt. Je hebt versiebeheer: elke aanpassing is terug te draaien, en je ziet wie wat wanneer veranderde. En je hebt controle over de foutafhandeling: wat gebeurt er precies als een externe koppeling uitvalt of het model een onverwacht antwoord geeft. Dit zijn niet de spannende onderdelen, maar het zijn de onderdelen die bepalen of een systeem overeind blijft wanneer de werkelijkheid afwijkt van de demo. De keuze voor code betekent wel dat de eerste versie iets meer werk kost dan een flow aan elkaar klikken. Dat is de bewuste afweging: langzamer starten, maar een systeem overhouden dat je bezit, kunt aanpassen en kunt vertrouwen. ### Wat het in de praktijk oplevert Twee voorbeelden uit onze eigen projecten laten zien hoe de fasering en de productielaag in de praktijk uitpakken. Voor [CIRFOOD](https://www.whatsnext-ai.com/cases/how-cirfood-scaled-from-4-to-45-tenders-a-year-without-adding-headcount) bouwden we een systeem voor het verwerken van aanbestedingen, dat we in fasen uitrollen. Fase 1 is de Analyst, die documenten uitleest en berekeningen maakt en nu in productie draait. Fase 2 wordt de Schrijf Assistent, die concepten opstelt op basis van eerdere aanbestedingen, en Fase 3 de Strateeg, die win-kansen analyseert. Elke fase bouwt voort op de data van de vorige. De eerste fase ging van discovery tot werkende MVP in ongeveer vijf maanden, en draait nu met twee productietools op CIRFOOD's eigen Google Cloud-omgeving. De verwerkingskosten liggen daardoor ongeveer 400 keer lager per aanbesteding dan bij handmatig werk. En, net zo belangrijk: als What's Next morgen zou verdwijnen, houdt CIRFOOD een werkend bezit, geen dood abonnement. Voor [iClicks](https://www.whatsnext-ai.com/cases/how-iclicks-built-a-scalable-ai-sales-engine) bouwden we een AI-sales-engine die inmiddels 7.500+ gekwalificeerde leads heeft opgeleverd, met een reply-percentage van 28% en 1.000+ automatisch gegenereerde rapporten. Wat dit een goed productievoorbeeld maakt is niet alleen het resultaat, maar wat erna komt: de samenwerking loopt door, met volgende fasen voor diepere data-integraties en een steviger technographics-laag. Productie eindigt niet bij de lancering, daar begint het. ### Wat zijn de fasen van een AI-implementatie? Kort samengevat doorloopt een AI-implementatie vijf fasen: probleem en eigenaar vastleggen (Fase 0), een afgebakende pilot met een go/no-go (Fase 1), de productielaag bouwen met koppelingen en monitoring (Fase 2), een gefaseerde uitrol met duidelijke afspraken (Fase 3), en doorlopend verbeteren (Fase 4). De pilot is één fase van de vijf, niet het eindpunt. ### Voor wie is dit relevant, en wat is de volgende stap? Dit stappenplan is bedoeld voor de beslisser die al een pilot heeft draaien en vastloopt op de stap naar productie: de IT-manager, de operationeel verantwoordelijke of de oprichter die weet dat er meer in zit maar niet de brug naar een echt systeem kan slaan. Heb je nog geen duidelijke strategie of weet je niet welk proces zich het beste leent, begin dan bij het bepalen van de richting via onze [AI-consultancy](https://www.whatsnext-ai.com/ai-consultancy). Staat de strategie al en ben je klaar om te bouwen, kijk dan naar [custom AI-development](https://www.whatsnext-ai.com/custom-ai-development), waar we de eerste werkende versie doorgaans binnen enkele weken opleveren. Wil je sparren over jouw specifieke pilot en de weg naar productie? [Boek een gratis adviesgesprek](https://www.whatsnext-ai.com/contact). Dan kijken we samen waar jouw traject vastloopt en wat de snelste route naar een werkend systeem is. *Verantwoording: het cijfer dat zo'n 95% van de generatieve-AI-pilots geen meetbaar bedrijfsresultaat oplevert komt uit "The GenAI Divide: State of AI in Business 2025" (MIT NANDA, juli 2025). De genoemde klantcijfers voor CIRFOOD en iClicks komen uit onze eigen projecten.*