Sven, eigenaar van een klein SaaS-bedrijf in Breda, wilde een AI-module bouwen voor foutdetectie in offertes. Zijn eerste WBSO-concept werd afgewezen: te veel businessdoel, te weinig technisch knelpunt.
Dat is een klassiek probleem. Ondernemers beschrijven waarom iets nuttig is, maar niet waarom de technische oplossing onzeker is. En precies die technische onzekerheid is de kern van WBSO.
In 2026 zie je veel AI-projecten die in theorie logisch lijken, maar in subsidiecontext onvoldoende technisch afgebakend zijn. Daardoor laten mkb-teams geld én momentum liggen.
Dit artikel geeft je een praktisch raamwerk voor drie dingen: technisch knelpunt formuleren, experimentele oplossingsrichtingen onderbouwen en urenadministratie auditproof inrichten.
TL;DR
- Beschrijf niet het productidee, maar het technische probleem dat nog geen standaardoplossing heeft.
- Formuleer minimaal twee serieuze oplossingsrichtingen met risico’s.
- Leg ontwikkeluren dagelijks vast per activiteit, niet achteraf per maand.
- Splits businessfunctionaliteit en speur- en ontwikkelwerk duidelijk in je planning.
- Maak je dossier leesbaar voor een beoordelaar die jouw context niet kent.
Wat WBSO wel en niet beloont bij AI-projecten
WBSO is bedoeld voor speur- en ontwikkelwerk met technische onzekerheid. Niet voor implementatie van bestaande tooling, en ook niet voor puur functioneel configuratiewerk.
Een chatbot op basis van standaard-API’s met bekende patronen is vaak onvoldoende. Een eigen classificatiemethode met prestatieproblemen onder specifieke constraints kan wél relevant zijn.
Je aanvraag moet dus laten zien dat je een technisch obstakel onderzoekt, niet alleen een productfeature bouwt.
Het technisch knelpunt scherp formuleren
Gebruik één zin met drie elementen: gewenste functie, concrete technische barrière en contextuele randvoorwaarde.
Voorbeeld: ‘We willen offertefouten automatisch detecteren, maar bestaande modellen halen onvoldoende precisie bij Nederlandse productspecificaties met korte domeintermen onder latency < 300 ms.’
In die formulering zit meteen waarom standaardoplossingen niet volstaan. Dat verhoogt de beoordelbaarheid van je project.
Oplossingsrichtingen: laat zien dat je echt moet onderzoeken
Een sterke aanvraag toont alternatieven. Niet één lineair plan, maar twee of drie plausibele technische routes met eigen risico’s.
Route A kan zijn: fijn-afstemming van taalmodel op domeindata. Route B: hybride regels plus embeddings. Route C: retrieval-gebaseerde validatielaag.
Per route beschrijf je waarom succes niet zeker is: datakwaliteit, fouttypen, rekentijd, modeldrift of foutpositieven.
Dat maakt duidelijk dat je speurt en ontwikkelt, in plaats van alleen implementeert.
Werkpakketstructuur die beoordelaars snappen
Deel je project op in werkpakketten met technische logica. Bijvoorbeeld: datarepresentatie, modelarchitectuur, evaluatiekader, performance-optimalisatie, integratietests.
Koppel elk werkpakket aan een technisch doel en een meetmethode. Denk aan F1-score, recall op kritieke foutcategorieën, of responstijd onder piekbelasting.
Zonder meetmethode blijft je verhaal abstract. Met meetmethode toon je systematische ontwikkeling.
Urenproof werken: waar het in de praktijk misgaat
Veel teams schrijven uren achteraf op basis van geheugen. Dat leidt tot onnauwkeurigheid en discussies bij controle.
Beter is een dagelijkse registratie per medewerker met korte activiteitencode en verwijzing naar taak of experiment.
Gebruik maximaal acht activiteitencodes, zoals EXP, DATA, TEST, OPT, DOC. Te veel codes maakt administratie zwaar en foutgevoelig.
Leg daarnaast uitzonderingen vast: vakanties, supportwerk, klantoverleg. Alleen echte S&O-uren tellen mee.
Praktijkvoorbeeld: van afwijzing naar toekenning
Sven herschreef zijn aanvraag met een heldere probleemdefinitie: hoge foutmarge bij samengestelde Nederlandstalige productspecificaties in korte tekstvelden.
Hij voegde drie oplossingsroutes toe en beschreef waarom elke route technisch onzeker was. Daarnaast voerde hij een dagelijkse urenregistratie met projectcodes in.
Resultaat: tweede aanvraag werd inhoudelijk sterker beoordeeld en intern werd het team veel scherper op experimentele discipline.
De grootste winst zat niet alleen in subsidie, maar in beter ontwikkelritme en snellere technische beslissingen.
Mini-template voor je aanvraagkern
1) Technisch doel: welke nieuwe technische werking wil je bereiken?
2) Knelpunt: waarom lukt dit niet met bestaande kennis of standaardoplossing?
3) Oplossingsroutes: welke benaderingen onderzoek je en waarom is uitkomst onzeker?
4) Evaluatie: hoe meet je per fase of een route werkt?
5) Afbakening: welk werk is expliciet géén S&O?
Als je deze vijf onderdelen concreet invult, stijgt je aanvraagkwaliteit direct.
Cijfers die je dossier sterker maken
Gebruik waar mogelijk precieze waarden: huidige foutpercentage, gewenste verbetering, datasetgrootte, responstijdgrens, verwachte testcycli.
Voorbeeld: ‘Huidige detectieprecisie 61%, streefwaarde 82%, testset 14.000 regels, latencydoel 250 ms bij 20 gelijktijdige verzoeken.’
Specifieke cijfers maken je technisch verhaal toetsbaar en minder marketinggedreven.
Veelgemaakte fouten in AI-WBSO
Fout 1: productroadmap verwarren met onderzoeksplan. Fix: apart hoofdstuk met technische onzekerheden.
Fout 2: generieke claims als ‘we gebruiken machine learning’. Fix: noem modelkeuze, data-eigenschappen en prestatiegrenzen.
Fout 3: urenmix van development, support en beheer. Fix: strikte scheiding en dagelijkse registratie.
Fout 4: geen dossier van tussenresultaten. Fix: bewaar experimentlogs, evaluatierapporten en besluitnotities.
Je 4-weekse voorbereidingsplan
Week 1: technische knelpuntenessie met lead developer en productowner, plus afbakening van niet-S&O-werk.
Week 2: uitwerken van drie oplossingsroutes en definiëren van KPI’s per route.
Week 3: opzetten urenregistratie, activiteitencodes en dossierstructuur.
Week 4: redactie aanvraag, interne review en consistentiecheck tussen planning, uren en technische claims.
Dit ritme voorkomt haastwerk en maakt je verhaal intern al bruikbaarder, los van subsidie-uitkomst.
FAQ
Telt integratie van bestaande AI-tools mee voor WBSO?
Meestal niet als het puur implementatie is. Alleen wanneer je aantoonbaar technische onzekerheid oplost in eigen ontwikkeling ontstaat kans op S&O-kwalificatie.
Moeten we een data scientist in dienst hebben?
Niet per se. Belangrijker is dat je team de technische keuzes en experimenten goed kan onderbouwen en documenteren.
Hoe gedetailleerd moet urenregistratie zijn?
Gedetailleerd genoeg om per dag en per activiteit herleidbaar te zijn, zonder bureaucratische overkill. Korte codes met duidelijke definities werken vaak het best.
Conclusie
WBSO 2026 voor AI-software in het mkb draait om discipline: technische onzekerheid helder benoemen, routes serieus onderzoeken en uren strak registreren.
Wie dat goed doet, vergroot niet alleen subsidie-kans maar bouwt een sterker ontwikkelproces. En dat is precies wat een AI-product in de praktijk nodig heeft.
Direct toepasbare prompt
"Geef me een praktische aanpak voor [probleem] voor een Nederlands mkb-bedrijf. Houd het kort, met concrete stappen en voorbeeldtekst."