Een paar maanden geleden sprak een directeur ons. Zijn bedrijf had een jaar besteed aan een AI-customer-service systeem. Budget: €180.000. Resultaat: een chatbot die in 30% van de gevallen het verkeerde antwoord gaf, en in 20% een antwoord dat klopte maar dat de klant nooit gevraagd had.
De pijnlijke vraag: "Hadden we dit niet eerder kunnen weten?"
Het korte antwoord: ja. Voor €8.000 en 3 weken werk. Maar dat had iemand moeten doen.
Waarom AI-projecten misgaan
AI gedraagt zich anders dan reguliere software. Bij gewone software weet je vooraf wat het systeem zal doen — je hebt het immers zelf geprogrammeerd. Bij AI moet je het systeem trainen of prompten en daarna zien wat eruit komt. Het gedrag emergeert.
Dat betekent dat de gebruikelijke aanpak ("schrijf een PRD, splits in epics, sprint na sprint, ship") fundamenteel niet werkt. Je weet pas of de AI z'n werk goed kan doen nadat je het hebt gebouwd en getest. En dan is het bouwwerk al achter de rug.
De oplossing: scheid validatie van productie. Eerst bewijzen dat het werkt, daarna pas opschalen.
Het 4-stappenmodel voor validatie
Hier is de aanpak die de meeste verspilling voorkomt. Doel: binnen 4 weken weten of jouw AI-idee technisch en zakelijk werkt. Totale investering: €5k–€15k. Vergelijk dat met de €180k uit het verhaal hierboven.
Stap 1: Definieer harde succescriteria (week 0, voor je begint)
Voordat één regel code geschreven wordt, beantwoord deze vraag: "Wat moet het systeem kunnen, en hoe meten we of het dat kan?"
Goede succescriteria zijn:
- Concreet. Niet "het moet goed werken", maar "het moet 95% van de inkomende facturen correct categoriseren".
- Meetbaar. Met een objectieve test, niet met een onderbuikgevoel.
- Vooraf vastgesteld. Niet pas bedacht na de oplevering, want dan past iedereen het criterium aan tot hij past bij wat er geleverd is.
Slechte succescriteria:
- "De AI moet net zo goed zijn als een mens." → Welke mens? Junior of senior? Met of zonder context?
- "Het moet er professioneel uitzien." → Te subjectief.
- "Het moet schalen naar een miljoen gebruikers." → Niet relevant voor een POC.
Vuistregel: als je succescriterium niet in een spreadsheet getest kan worden, is het geen succescriterium. Herformuleer.
Stap 2: Bouw het kleinst haalbare bewijs (week 1–3)
Geen UI. Geen integraties. Geen mooie verpakking. Alleen het minimum dat de vraag beantwoordt: kan de AI doen wat we willen, met onze data, op een acceptabel niveau?
Wat hoort er wel bij:
- Echte data uit jouw bedrijf (geen synthetische voorbeelden — die zijn altijd te schoon).
- De AI-pijplijn die je in productie zou gebruiken (zelfde model, zelfde prompting-aanpak, zelfde context).
- Een testharnas waarmee je de output kunt evalueren tegen je succescriteria.
Wat hoort er niet bij:
- Mooie UI — een commandline volstaat.
- Integratie met productiesystemen — CSV in/CSV uit is genoeg.
- Foutafhandeling, monitoring, schaling — allemaal voor later.
Dit is het hart van een POC. Doel is om binnen 2–3 weken een werkende implementatie te hebben die je kunt testen.
Stap 3: Test met échte data, échte randgevallen (week 3–4)
Hier sneuvelen de meeste AI-ideeen. De AI werkt prachtig op de 10 voorbeelden die je tijdens ontwikkeling hebt gebruikt. Maar in productie zit 30% van je data in formaten die je nooit hebt overwogen.
Een goede test bevat:
- Een representatieve dataset. Liefst 100–500 echte voorbeelden die de variatie in je productie-data weergeven.
- Edge cases die je verwacht. Wat als een factuur in het Spaans is? Wat als er handgeschreven aantekeningen op staan?
- Edge cases die je niet verwacht. Vraag mensen die het werk doen: "wat zijn de meest absurde voorbeelden die je ooit hebt gezien?" Test daarmee.
- Adversariale tests. Wat gebeurt er als iemand probeert het systeem te misleiden?
Meet de output met je succescriteria uit stap 1. Niet met je gevoel.
Stap 4: Beslis op basis van data (einde week 4)
Nu komt de waarheid. Je hebt drie mogelijke uitkomsten:
A) De POC haalt de succescriteria. Goed, maar niet klaar.
Voordat je doorgaat naar productie, beantwoord deze vragen:
- Wat zijn de operationele kosten per transactie? (LLM-kosten kunnen exploderen op schaal.)
- Wat is de latency, en hoe wil je gebruikers daarvan op de hoogte stellen?
- Welke compliance-implicaties zijn er als data via externe modellen gaat?
- Wie is verantwoordelijk als de AI een fout maakt? (Een AI-fout is altijd een mens-z'n-fout in juridische zin.)
B) De POC haalt de criteria niet, maar komt dichtbij.
Drie opties: criteria aanpassen (alleen als zakelijk verantwoord), pivot naar een andere aanpak (ander model, andere scope), of stoppen. De vraag is altijd: welke investering zou nodig zijn om wel de criteria te halen, en is dat verantwoord?
C) De POC faalt duidelijk.
Goede uitkomst. €10.000 uitgegeven om te ontdekken dat een €200.000-traject niet zou hebben gewerkt. Stop het project en gebruik de geleerde lessen om een ander idee te valideren.
Belangrijk: faillissement van een POC is niet hetzelfde als een mislukt project. Een POC die laat zien dat het idee niet werkt, is geslaagd — hij heeft je een dure fout bespaard.
De 5 meest gemaakte fouten in validatie
1. Synthetische data gebruiken
Je AI presteert briljant op de testdata die je samen hebt gemaakt. In productie crasht hij omdat echte data nooit zo schoon is. Test altijd met een representatieve sample uit je productie-omgeving.
2. Succescriteria pas achteraf bedenken
Als je criteria pas formuleert na de oplevering, zul je ze altijd zo aanpassen dat ze passen bij wat je hebt gebouwd. Dat is geen validatie, dat is rationalisatie.
3. Te ambitieus scopen
Een POC die "alle facturen, in alle talen, geïntegreerd met SAP" probeert te doen, is geen POC meer — dat is een minder-getest MVP. Snijd genadeloos: één type, één taal, geen integratie.
4. Te perfectionistisch op de UI
Een POC heeft geen mooie UI nodig. Tijd besteden aan animations en design tokens is tijd niet besteed aan het bewijzen of de AI werkt.
5. Niet meten, alleen kijken
"Het lijkt redelijk goed te werken" is geen validatie. Bouw een testharnas die objectief kan zeggen: "op deze 200 voorbeelden klopte 187 keer het antwoord".
Wat als je geen tijd of intern team hebt?
De meeste bedrijven hebben geen interne AI-engineers met POC-ervaring. Dan zijn er drie opties:
- Iemand intern leren. Tijdrovend (3–6 maanden voordat ze productief zijn) en je weet niet of je daarna nog werk voor ze hebt.
- Een groot consultancybureau inhuren. Krijgt je in 3 maanden een POC voor €75.000+, met heel veel slides eromheen.
- Een gespecialiseerde POC-aanbieder. Vaste prijs vanaf €5.000, oplevering in 2–4 weken, en je krijgt het werk plus een eerlijke beoordeling.
Voor 90% van de Nederlandse MKB- en mid-market AI-vraagstukken is optie 3 de juiste. Lage instapkosten, snelle feedbackcyclus, en geen verborgen agenda om je in een vervolgtraject te trekken (dat is het verdienmodel van optie 2).
Conclusie: validatie als verzekering
Een POC van €5.000–€15.000 is geen kostenpost. Het is een verzekeringspremie tegen een €100.000+ AI-project dat niet werkt. Het rendement is enorm: of je krijgt groen licht om met vertrouwen door te bouwen, of je bespaart een fortuin door op tijd te stoppen.
De meeste bedrijven slaan deze stap over omdat ze denken: "we doen het wel goed, we hebben het idee al uitgedacht". Negen van de tien keer ontdekken ze pas na zes maanden dat de aannames niet kloppen. Validatie is goedkoop. Niet-valideren is duur.
Krijg in 4 weken zekerheid — voor minder dan een half-week consultancy.
Wij doen alle vier de stappen voor je: harde succescriteria opstellen, het kleinst haalbare bewijs bouwen, testen met je echte data en een eerlijke beoordeling met roadmap. Vaste prijs vanaf €5.000.