Proof of concept, prototype, pilot of MVP: welke heeft jouw AI-project nodig?

Deze vier zijn geen synoniemen en ze beantwoorden vier verschillende vragen. Een proof of concept vraagt of iets mogelijk is. Een prototype vraagt hoe het eruit moet zien. Een pilot vraagt of het werkt in jouw eigen bedrijfsvoering. Een MVP vraagt of de kleinste bruikbare versie de moeite waard is om te houden. De verkeerde kiezen is waarom teams wegwerpcode gaan doorontwikkelen, en waarom pilots stilletjes een jaar doorlopen.

Die verwarring is niet academisch. In ons eigen voorstellenarchief piekten aanvragen met deze woorden in het eerste kwartaal van 2026 en lopen ze sindsdien terug naarmate klanten naar implementatie opschuiven, maar in briefings worden de termen nog altijd door elkaar gebruikt. Een verzoek om “even een PoC” dat eigenlijk echte gebruikers en een wegschrijfactie naar productie nodig heeft, is een verzoek om een pilot, en dat als proof of concept prijzen zet iedereen op voor teleurstelling.

Het vroeg goed doen telt, want het alternatief is goed gedocumenteerd. Gartner verwacht dat ruim veertig procent van de agentic AI-projecten voor eind 2027 wordt stopgezet, met oplopende kosten en onduidelijke businesswaarde als redenen. Allebei beschrijven ze een eerste stap waarvan het doel nooit is afgesproken.

Hoe verhouden de vier zich tot elkaar?

Vergelijking	Proof of concept	Prototype	Pilot	MVP
Vraag die hij beantwoordt	Is dit technisch mogelijk?	Hoe moet dit eruitzien?	Werkt dit in onze bedrijfsvoering?	Is de kleinste bruikbare versie het waard?
Wie gebruikt hem	Het bouwteam	Betrokkenen, in een demo	Echte gebruikers, beperkte groep	Echte gebruikers, live
Data	Voorbeeld, vaak historisch	Illustratief of dummy	Echt, op beperkte scope	Echt, in productie
Doorlooptijd	1 tot 4 weken	1 tot 3 weken	6 tot 12 weken	8 tot 16 weken
Indicatie kosten	6.000 tot 24.000 euro	Laag, vaak 20 tot 40 uur	Bouw plus begeleidingsinzet	Vergelijkbaar met een eerste release
Wat er met de code gebeurt	Weggegooid	Weggegooid	Meestal herbouwd	Uitgebreid
Wat hij niet bewijst	Dat iemand hem gaat gebruiken	Dat hij te bouwen is	Dat hij schaalt of beheerbaar is	Dat de volle scope haalbaar is

De onderste rij is de rij die je twee keer moet lezen, want elk van deze stappen wordt net zozeer bepaald door wat hij bewust weglaat als door wat hij aantoont.

Wanneer is een proof of concept de juiste keuze?

Wanneer er een echte technische vraag ligt en een aannemelijk antwoord nee is. Die voorwaarde is strenger dan hij klinkt. Gelooft iedereen al dat het gaat werken, dan levert een proof of concept alleen een demonstratie op en stelt hij de echte bouw een maand uit.

Goede kandidaten hebben een herkenbare vorm: een ongebruikelijk dataformaat, een koppeling die niemand eerder heeft geprobeerd, een vereiste nauwkeurigheid die misschien niet haalbaar is, of een taak waarbij haalbaarheid echt getest moet worden in plaats van aangenomen. Gestructureerde gegevens uit technische tekeningen halen is een echte proof of concept-vraag, want elke organisatie tekent anders en er is geen gedeelde conventie om op te leunen. Een factuurnummer uit een PDF halen is dat niet, want die vraag is beslecht.

Baken af op een tot vier weken en één vraag. In ons werk is een smalle technische extractievraag in ongeveer veertig uur te beantwoorden, met een gestructureerd uitvoerbestand en een helder ja of nee als resultaat. Een bredere usecase zit aan de bovenkant van die bandbreedte. Loopt een voorgestelde proof of concept langer dan vier weken, dan is hij geen proof of concept meer maar een onbeheerde bouw.

Het onderzoek van RAND naar waarom AI-projecten mislukken, op basis van gesprekken met vijfenzestig vakmensen, zet een verkeerd begrepen probleemstelling bovenaan de lijst met oorzaken. De verkeerde eerste stap kiezen is die faalvorm in zijn vroegste en goedkoopste gedaante.

Ga ervan uit dat de code weggegooid wordt, en zeg dat hardop bij aanvang. Een proof of concept is geoptimaliseerd om snel een vraag te beantwoorden, en dat betekent kortere bochten in foutafhandeling, beveiliging en structuur die op dat moment volstrekt juist zijn en in productie volstrekt verkeerd. Achteraf besluiten hem weg te gooien kost meer dan het vooraf besluiten, want tegen die tijd is iemand eraan gehecht geraakt.

Wanneer wil je juist een prototype?

Wanneer de onzekerheid over de beleving gaat en niet over de techniek. Wat moet het scherm tonen, in welke volgorde, en wat doet iemand met de uitkomst? Die vragen beantwoordt iets klikbaars op dummydata sneller dan welk specificatiedocument ook.

Een prototype is vaak de goedkoopste van de vier stappen en de meest ondergewaardeerde. Bij een rapportageproject bouwden we een prototypedashboard op een aangeleverde data-export, valideerden de cijfers tegen het bestaande rapport van de klant, en gebruikten het om vast te stellen hoe de signalering moest werken. Dat prototype daarna beschikbaar maken als echte webapplicatie met single sign-on was vervolgens een apart, klein blok werk van twintig uur, en het bleef daarna expliciet een prototype. Dat onderscheid helder houden is wat voorkomt dat een prototype voor een product wordt aangezien.

De faalvorm hier is dat prototypes goed demonstreren. Een prototype dat een directie overtuigt, wordt makkelijk aangezien voor iets dat bijna af is, terwijl het gat tussen dat prototype en een werkend systeem doorgaans groter is dan het gat dat al is overbrugd.

Wanneer draai je een pilot?

Wanneer haalbaarheid vaststaat en de open vraag is of het ding contact met jouw bedrijfsvoering overleeft. Dat betekent echte data, echte gebruikers en een beperkte scope, draaiend naast het bestaande proces in plaats van in de plaats daarvan.

Twee ontwerpkeuzes bepalen of een pilot nuttig is. De eerste is de duur: lang genoeg om de uitzonderingen te zien, wat bij de meeste bedrijfsprocessen zes tot twaalf weken betekent. Een pilot van twee weken ziet alleen de gewone gevallen, en dat zijn precies de gevallen waar je je nooit zorgen over maakte. De tweede is de stopvoorwaarde, afgesproken voordat de pilot begint. Zonder die voorwaarde wordt een pilot een permanent parallel proces, en twee processen draaien is duurder dan afmaken of stoppen.

Een pilot hoort te draaien met een mens in de lus binnen de afdeling die het proces uiteindelijk gaat bezitten, en niet als demonstratie voor het management. Dat verschil telt, want de mensen die het werk doen merken dingen op die een demonstratie nooit blootlegt, zoals uitkomsten die technisch kloppen maar op het verkeerde moment in hun dag binnenkomen.

Reken erop dat je daarna herbouwt. Pilotcode draagt compromissen die zijn gemaakt om snel iets voor gebruikers te krijgen, en het doel van de pilot is wat je leert en niet wat je overhoudt.

Wanneer is een MVP de juiste eerste stap?

Wanneer haalbaarheid niet ter discussie staat en de echte vraag is of een smalle versie genoeg oplevert om de volledige te rechtvaardigen. Anders dan de andere drie is een MVP gebouwd om uitgebreid te worden en gaat hij echt live, wat betekent dat hij vanaf dag één productie-eisen draagt: uitzonderingsafhandeling, monitoring, toegangsbeheer en een eigenaar.

De discipline zit in het kiezen van de plak. Bij een traject rond contractverwerking dat we dit jaar afbakenden, was de aanpak om te beginnen met de meest gestructureerde en eenvoudige contracttypen, dat succesvol op te leveren, en pas daarna door te groeien naar de volledige oplossing met alle contracttypen en talen. Die volgorde is het hele punt. Een MVP die de makkelijkste twintig procent van de gevallen dekt en betrouwbaar werkt, leert je meer en kost minder dan een volledige bouw die alles dekt en onbetrouwbaar is.

De veelgemaakte fout is iets een MVP noemen terwijl het als proof of concept is afgebakend. Zodra echte gebruikers op de uitkomst leunen, zijn productie-eigenschappen nodig ongeacht hoe je het noemt, en die overslaan vanwege het etiket is precies hoe wegwerpcode een bedrijfsproces gaat dragen.

Hoe kies je tussen de vier?

Beantwoord één vraag eerlijk: wat zou je doen stoppen?

Is het antwoord “als het onmogelijk blijkt”, dan wil je een proof of concept. Is het “als mensen het verwarrend vinden”, dan wil je een prototype. Is het “als het op ons echte werk niet standhoudt”, dan wil je een pilot. Is het “als de waarde er niet is, ook als het werkt”, dan wil je een MVP.

Is het antwoord “niets zou ons doen stoppen”, dan is geen van deze vier de juiste stap. Dan ligt er een beslissing die al genomen is, en de eerlijke vervolgstap is de bouwplannen in plaats van hem als experiment te verkleden. Dat is geen verwijt. Het is aanzienlijk goedkoper dan vier weken besteden aan het bewijzen van iets aan een publiek dat toch niet van gedachten ging veranderen.

Conclusie

Een proof of concept, prototype, pilot en MVP hebben elk een ander doel. De juiste keuze hangt af van wat je wilt onderzoeken, welke onzekerheden je wilt wegnemen en wat je uiteindelijk wilt bereiken. Door vooraf duidelijke doelen en succescriteria vast te stellen, voorkom je onnodige ontwikkelkosten en vergroot je de kans op een succesvolle AI-implementatie.

Bij DataNorth AI begeleiden we organisaties van het eerste idee tot een werkende AI-oplossing. Met onze AI Strategie helpen we je de juiste kansen en vervolgstappen te bepalen. Via een gerichte AI Proof of Concept toetsen we de technische haalbaarheid voordat je grotere investeringen doet. Met onze AI Ontwikkeling en Implementatie vertalen we gevalideerde ideeën naar betrouwbare AI-oplossingen die aansluiten op jouw bedrijfsprocessen.

Twijfel je of jouw AI-project een PoC, prototype, pilot of MVP nodig heeft? Neem contact op met DataNorth AI en ontdek welke aanpak het beste past bij jouw organisatie.

Want het doel is niet alleen bewijzen dat AI werkt, maar AI ontwikkelen die daadwerkelijk bedrijfswaarde oplevert.

Veelgestelde vragen