Wat een AI-proof of concept van vier weken moet bewijzen voordat u opschaalt

Een proof of concept die in een demo indruk maakt, kan toch het verkeerde zijn om op te schalen. Het model verwerkt de voorbeeldgevallen, de zaal is overtuigd, en een paar maanden later is het project stilletjes gestopt. Gartner meldde in januari 2026 dat eind 2025 minstens de helft van de projecten met generatieve AI na de proof of concept was stopgezet, door slechte datakwaliteit, onvoldoende risicobeheersing, oplopende kosten of onduidelijke bedrijfswaarde.

Geen van die redenen gaat over de vraag of het model de taak aankan. Dat is meestal het makkelijke deel. Een goede proof of concept is erop gericht de moeilijkere vragen te beantwoorden zolang er nog weinig op het spel staat. Twijfelt u nog welk proces u wilt testen, begin dan met vijf vragen die de juiste eerste automatisering kiezen.

Een demo is geen bewijs

Een demo laat zien dat iets mogelijk is. Een bewijs laat zien dat het werkt op uw data, met uw volumes, voor de mensen die ermee gaan werken. Dat verschil doet ertoe, want het model is maar een klein deel van een werkend systeem. In een bekend artikel over machine learning in productie lieten engineers van Google zien dat de modelcode slechts een klein deel van een echt systeem is, en dat de infrastructuur eromheen omvangrijk en complex is.

Een test van vier weken moet dus meer doen dan nagaan of het model het werk aankan. Hij moet de smalste echte versie van het hele traject laten draaien: echte input die binnenkomt, het model dat zijn stap uitvoert, het resultaat dat terechtkomt waar mensen werken, en iemand die het kan corrigeren.

Leg de lat vast vóór week één

Een pilot zonder afgesproken definitie van succes sleept zich vaak voort, omdat elk resultaat voor meerdere uitleg vatbaar is. Spreek drie dingen af voordat er iets wordt gebouwd.

• Een testset met echte gevallen. Verzamel historische voorbeelden met een bekende juiste uitkomst, in de mix die u werkelijk binnenkrijgt, inclusief de lastige. De richtlijnen van Anthropic voor evaluaties raden testsets aan die de echte verdeling van de taak weerspiegelen en randgevallen bevatten.
• Een nulmeting. Meet hoe het werk vandaag gebeurt: tijd per item, foutpercentage, doorlooptijd. De Rules of Machine Learning van Google zetten meten op de eerste plaats en raden aan zoveel mogelijk in het huidige systeem bij te houden voordat u vastlegt wat het nieuwe systeem gaat doen.
• Een drempel per meetpunt. Schrijf op welk resultaat opschalen rechtvaardigt en bij welk resultaat u stopt. Maak elke drempel specifiek en meetbaar: "de juiste categorie bij routineverzoeken, en geen stellige fouten bij terugbetalingen" in plaats van "werkt goed".

Vijf dingen die vier weken moeten bewijzen

Elke rij hieronder hoort bij een reden waarom pilots later mislukken. Gebruik de tabel als agenda voor de eindbespreking.

Over data: bevatten de testgevallen persoonsgegevens, dan geldt de AVG voor de pilot net zo goed als voor productie. Gebruik alleen de gegevens die de test nodig heeft (het beginsel van minimale gegevensverwerking in artikel 5) en stel vóór week één vast hoe u ze mag gebruiken.

Kosten verdienen een eigen controle. Gartner merkt op dat projecten die in een proof of concept haalbaar lijken, in productie een budgetprobleem kunnen worden, omdat kleine kosten per gebruik zich vermenigvuldigen over gebruikers en toepassingen. Meet de kosten per item tijdens de pilot en lees de werkelijke kosten van een AI-systeem voor wat u verder moet begroten.

Een plan van vier weken dat ruimte laat voor het antwoord

Vier weken is genoeg als de scope één proces en één beslissing is. Een opzet die werkt:

1. Week 1: afspreken en verzamelen. Leg de lat vast, stel de testset samen, regel toegang tot de echte data en wijs de mensen aan die het systeem gaan uitproberen.
2. Week 2: het dunne pad bouwen. Verbind input, model en output van begin tot eind, alleen voor het hoofdgeval. Draai aan het eind van de week de volledige testset, ook als de resultaten zwak zijn.
3. Week 3: voorleggen aan gebruikers. Laat het team het naast het normale proces op echt werk gebruiken, zodat er nog niets van afhangt. Leg elke correctie vast en meet de kosten per item.
4. Week 4: verbeteren, opnieuw draaien, beslissen. Pak de meest voorkomende fouttypen aan, draai de testset opnieuw en schrijf een beslisnotitie van één pagina die de cijfers naast de lat legt.

Dezelfde testset draaien in week twee en week vier is precies de bedoeling. Zo wordt voortgang een getal en wordt de eindbespreking geen discussie over indrukken. Het AI Risk Management Framework van NIST stelt dat AI-systemen getest moeten worden vóór ingebruikname en regelmatig tijdens gebruik, en de testset die u nu bouwt, kan de regressietest voor het live systeem worden.

Opschalen, bijsturen of stoppen

Aan het eind van week vier zijn er drie eerlijke uitkomsten.

• Opschalen als elke rij van de tabel onderbouwd is, de lat gehaald is en een benoemde persoon in het bedrijf eigenaar is van het resultaat. De volgende fase is engineeringwerk: integratie, monitoring, toegangsbeheer en ondersteuning.
• Bijsturen als een of twee rijen zwak zijn en de oplossing duidelijk is, bijvoorbeeld een ontbrekende databron. Spreek een korte verlenging af met een vaste einddatum en dezelfde lat. Bijsturen mag geen blijvende toestand worden.
• Stoppen als de kwaliteit ver onder de lat ligt, of als de waarde verdwijnt zodra gebruikskosten en controletijd zijn meegeteld. Een pilot die na vier weken zo eindigt, heeft zijn werk gedaan: hij heeft u een veel groter project bespaard.

In onze projecten komen vooral de pilots soepel in productie waarvan de beslisregels vooraf zijn opgeschreven. Wilt u een realistische lat bepalen? Schat met de ROI-calculator wat het proces vandaag waard is, of bekijk veelvoorkomende workflows per bedrijfsonderdeel voor kandidaten die het testen waard zijn.