Dinsdagavond, 22:14. Je zit met je lead developer in een lege vergaderruimte. Op het whiteboard staat een AI-functie waar klanten al maanden om vragen: automatisch offertes vergelijken, afwijkingen signaleren en risico’s markeren. Iedereen is enthousiast, totdat het gesprek op budget komt. ‘Mooi plan,’ zegt je accountant, ‘maar hoe betalen we de ontwikkeluren?’ Op dat moment komt WBSO in beeld: niet als papieren tijger, maar als hefboom om innovatie wél te bouwen.
Dit artikel is voor Nederlandse mkb-ondernemers en productteams die in 2026 AI-software ontwikkelen, maar twijfelen of het project ‘technisch genoeg’ is voor WBSO. Je krijgt geen juridische ruis, maar een praktisch kader dat je team direct kan toepassen in sprintplanning, documentatie en aanvraagtekst.
Belangrijk om te weten: WBSO beloont technisch speurwerk, niet alleen ‘iets met AI doen’. Als je vooral bestaande tools configureert, zit je vaak in de grijze zone. Als je echt programmeertechnische onzekerheden oplost, ligt de deur wél open.
TL;DR: wanneer is je AI-project WBSO-waardig?
- Je bouwt nieuwe programmatuur voor je eigen organisatie, niet alleen een standaardimplementatie.
- Er is vooraf technische onzekerheid: je weet niet precies of en hoe het gaat werken.
- Je team werkt systematisch: hypotheses, experimenten, codekeuzes en evaluaties zijn vastgelegd.
- Je kunt aantonen welke programmeertechnische knelpunten je oplost.
- Urenadministratie en projectlog zijn op orde vanaf dag één.
Waarom veel AI-projecten worden afgewezen
De grootste afwijzingsreden is niet slechte intentie, maar vaag taalgebruik. Teams schrijven in de aanvraag wat het systeem doet voor de business, terwijl de beoordelaar wil zien welk technisch probleem je oplost. ‘Snellere offertes’ is een bedrijfsdoel. ‘Robuuste normalisatie van ongestructureerde productregels met onvoorspelbare invoer’ is een technisch knelpunt.
Tweede valkuil: te veel leunen op bestaande modellen of libraries zonder eigen technische vernieuwing. Natuurlijk mag je frameworks gebruiken, maar de kern van je project moet bestaan uit nieuwe code, nieuwe architectuurkeuzes of nieuwe oplossingsroutes binnen jouw product.
Derde valkuil: administratie achteraf. Teams denken ‘we reconstrueren het later wel’, maar dan verdwijnen cruciale details. Zonder tijdige documentatie lijkt innovatie achteraf op regulier programmeerwerk.
De vertaalslag: van businessvraag naar technisch knelpunt
Start met één zin van de klant, bijvoorbeeld: ‘Kunnen jullie automatisch contractrisico’s markeren?’ Daarna dwing je jezelf in drie technische vragen: 1) welke inputvariatie maakt dit moeilijk, 2) welke foutkosten zijn onacceptabel, 3) welke bestaande aanpak schiet tekort.
Voorbeeld: je ontvangt contracten als PDF, scan, e-mailtekst en export uit verschillende systemen. Layout wisselt per leverancier, terminologie is inconsistent en clausules hebben context nodig. Technisch knelpunt: betrouwbare segmentatie en classificatie onder hoge documentvariatie met lage false negatives op kritieke risico’s.
Door zo te formuleren, verschuif je van ‘we gebruiken AI’ naar ‘we lossen een programmeertechnisch probleem op’. Dat is precies de taal waarin WBSO sterk wordt.
Een werkbaar 6-blokken aanvraagmodel
Blok 1 is projectdoel in technische termen. Blok 2 benoemt onzekerheden. Blok 3 beschrijft aanpak per ontwikkelfase. Blok 4 maakt expliciet wat nieuw is ten opzichte van bestaande oplossingen. Blok 5 bevat meetcriteria voor slagen of falen. Blok 6 legt vast hoe je uren en voortgang registreert.
Houd elk blok compact. Een sterke aanvraag is concreet, niet literair. Vermijd holle claims als ‘state of the art’ zonder technische context. Laat liever zien welke afweging je moest maken: latency versus nauwkeurigheid, explainability versus performance, kosten versus schaalbaarheid.
Praktijkvoorbeeld: offerte-analyse voor een technisch handelsbedrijf
Een mkb-groothandel wilde binnenkomende offertes automatisch vergelijken met interne inkoopregels. Klinkt simpel, maar leveranciers gebruikten verschillende coderingen, eenheden en staffelstructuren. Het projectteam definieerde drie knelpunten: semantische mapping van productregels, detectie van verborgen toeslagen en betrouwbare confidence scoring.
In plaats van één groot AI-model bouwden ze een hybride pipeline: parserlaag, normalisatielaag, regelsysteem en classificatielaag. Die architectuurkeuze werd expliciet vastgelegd met experimentresultaten. Juist die technische onderbouwing maakte de aanvraag geloofwaardig.
Na toekenning daalden de netto ontwikkelkosten en kon het team een extra iteratie doen op edge cases. Zakelijke impact: snellere beslissingen, minder prijslekken en hogere margecontrole.
Welke bewijsstukken wil je wekelijks verzamelen?
Maak het jezelf makkelijk met een ritme. Elke vrijdag zet je vier items in je projectlog: wat was de technische hypothese, welke code-aanpassing is gedaan, welk testresultaat kwam eruit, en welke onzekerheid blijft open. Dit kost vaak 20 tot 30 minuten en voorkomt uren herstelwerk bij controles.
Bewaar daarnaast issue-threads, benchmarktabellen, architectuurschetsen en release-notes. Niet om indruk te maken, maar om consistent te laten zien dat er echte technische ontwikkeling plaatsvindt.
Gebruik in je urenadministratie heldere labels zoals ‘dataset normalisatie’, ‘foutanalyse pipeline’, ‘inference optimalisatie’. Vermijd containerbegrippen als ‘AI werk’. Specificiteit is je vriend.
30-dagen sprintplan voor je WBSO-voorbereiding
Week 1: scope verkleinen tot één kernprobleem en twee nevenproblemen. Week 2: technische onzekerheden expliciet maken met meetcriteria. Week 3: proof-of-concept met minimaal drie testscenario’s documenteren. Week 4: aanvraagtekst finaliseren en administratieproces borgen.
Belangrijk: zet al in week 1 je loggingstructuur op. Teams die dit uitstellen, verliezen snelheid én overtuigingskracht. Je wil dat elke sprint automatisch bewijs oplevert, zonder extra bureaucratie.
Plan ook een reality-check met je developer en finance-verantwoordelijke samen. Daar botsen vaak aannames: technisch haalbaar betekent niet automatisch financieel verstandig, en andersom.
Hoe je afwijzingsrisico verlaagt zonder consultanttaal
Schrijf actief en concreet. Niet: ‘Er wordt onderzocht of optimalisatie mogelijk is.’ Wel: ‘We testen drie strategieën voor foutreductie bij OCR-ruis en vergelijken precisie per documenttype.’ Dat ene verschil maakt direct duidelijk dat je engineering doet.
Noem cijfers waar mogelijk: testsetgrootte, latencydoel, foutmarges, datavolume. Zelfs eenvoudige metrics verhogen geloofwaardigheid. Bijvoorbeeld: ‘Doel is < 800 ms inferentietijd bij 95e percentiel en maximaal 2% kritieke misclassificaties.’
Wees eerlijk over onzekerheid. Een aanvraag wordt niet sterker door te doen alsof alles al vaststaat. Juist het bestaan van technische onzekerheid is de kern van WBSO.
Veelgestelde vragen van mkb-teams
Kun je WBSO krijgen als je bestaande AI-modellen gebruikt?
Ja, maar alleen als je eigen technische ontwikkeling substantieel is. Alleen prompten, finetunen of standaardintegratie is meestal onvoldoende. Je moet programmeertechnische knelpunten aantoonbaar oplossen.
Is no-code of low-code genoeg?
Meestal niet als hoofdmoot. WBSO voor programmatuurontwikkeling draait om eigen ontwikkeling in formele programmeertalen en technische onzekerheden die je met engineering oplost.
Hoeveel administratie is ‘genoeg’?
Genoeg betekent dat een buitenstaander kan volgen wat je technisch probeerde, bouwde en leerde. Wekelijkse logs, urenregistratie en versiehistorie zijn in de praktijk je minimale set.
Teamrolverdeling: wie doet wat in een klein bedrijf?
In veel mkb-bedrijven dragen dezelfde twee mensen product, techniek en operatie tegelijk. Juist daarom helpt een lichte rolverdeling. De productowner bewaakt scope en businesswaarde, de lead developer bewaakt technische onzekerheden en experimenteerlogica, en finance bewaakt uren, bewijs en timing. Drie rollen, niet per se drie personen.
Plan elke twee weken een kort ‘subsidie-ritmeoverleg’ van 25 minuten. Agenda: welke onzekerheden zijn opgelost, welke experimenten lopen vast, en welke documentatie ontbreekt nog. Dit overleg voorkomt dat je pas vlak voor indiening ontdekt dat cruciale onderbouwing ontbreekt.
Conclusie
WBSO in 2026 is voor AI-software geen loterij, maar een discipline. Ondernemers die winnen, doen drie dingen goed: ze formuleren het technische probleem scherp, documenteren hun leerproces consequent en koppelen administratie direct aan de sprintflow.
Als je vandaag begint met die structuur, verandert subsidie van ‘misschien ooit’ naar een concreet onderdeel van je productstrategie. Niet omdat je beter schrijft dan anderen, maar omdat je beter laat zien wat je team technisch echt oplost.
Zie WBSO daarom niet als afsluitende formaliteit, maar als ontwerpkader voor betere softwareontwikkeling. Teams die technisch duidelijk denken, bouwen vaak sneller, maken minder dure omwegen en nemen sterkere productbeslissingen — óók los van het subsidievoordeel.
Direct toepasbare prompt
"Geef me een praktische aanpak voor [probleem] voor een Nederlands mkb-bedrijf. Houd het kort, met concrete stappen en voorbeeldtekst."