Een ondernemer met een goed AI-idee komt vaak te laat bij subsidie uit. Eerst is er enthousiasme, dan een prototype in ChatGPT of n8n, daarna een leverancier die “wel iets met AI” kan bouwen, en pas dan de vraag: kunnen we hier nog MIT of WBSO voor gebruiken? In juli 2026 is die vraag extra praktisch. De specifieke MIT R&D AI-samenwerkingstender is voor dit jaar gesloten, maar haalbaarheidsonderzoek en bredere innovatieroutes kunnen nog steeds relevant zijn.
Dit artikel is voor mkb-ondernemers die een AI-project serieus willen onderzoeken zonder meteen een groot traject te starten. Denk aan voorspellende planning, automatische offertecontrole, klantservice met eigen kennisbank, kwaliteitsinspectie, documentanalyse of een agent die administratieve stappen voorbereidt. Het doel: in vijf werkdagen een dossier maken dat duidelijk genoeg is voor een adviseur, partner of aanvraagportaal.
TL;DR
- Begin niet met subsidievoorwaarden, maar met een technisch onzeker punt dat echt onderzocht moet worden.
- Maak onderscheid tussen haalbaarheid, R&D-ontwikkeling, training en gewone software-implementatie.
- Verzamel in vijf werkdagen: probleem, doelgroep, technische vraag, experimentplan, uren, kosten, risico’s en verwachte opbrengst.
- Vermijd vaag taalgebruik als “AI inzetten voor efficiëntie”; beschrijf meetbare processen en beslismomenten.
- Gebruik het dossier ook als interne go/no-go, zelfs als subsidie niet lukt.
Waarom veel AI-subsidievragen zwak beginnen
AI voelt innovatief, maar niet elk AI-project is automatisch subsidiabel. Een chatbot installeren, Copilot-licenties kopen of een standaard OCR-tool gebruiken is meestal digitalisering, geen onderzoek. Dat kan nog steeds waardevol zijn, maar het vraagt een ander budget en soms een andere regeling. Subsidies worden sterker wanneer er een echte onzekerheid is: kan dit model met onze data betrouwbaar genoeg voorspellen, classificeren of adviseren?
Een goed haalbaarheidsdossier begint daarom met twijfel. Niet commerciële twijfel, maar technische of organisatorische onzekerheid. Bijvoorbeeld: kunnen we uit 3 jaar orderhistorie leveringsvertragingen 7 dagen eerder signaleren? Kunnen we 80% van offerteaanvragen automatisch voorbereiden zonder margelek? Kunnen we Nederlandse klantvragen routeren met minder dan 5% verkeerde escalaties? Zulke vragen zijn concreet en toetsbaar.
Wie subsidie ziet als gratis geld, schrijft wollig. Wie subsidie ziet als gestructureerde risicoreductie, schrijft beter. Je onderzoekt niet omdat het moet voor een formulier. Je onderzoekt omdat je anders te vroeg te veel geld uitgeeft.
Werkdag 1: formuleer het probleem in cijfers
Begin met een proces dat pijn doet. Niet “we willen AI gebruiken”, maar “we verliezen elke week 12 uur aan handmatige offertevoorbereiding” of “support beantwoordt 500 terugkerende vragen per maand”. Noteer minimaal drie cijfers: volume per week, huidige doorlooptijd en fout- of herstelpercentage. Als je die cijfers niet hebt, meet één dag steekproefsgewijs en maak je aannames expliciet.
Beschrijf daarna wie profiteert. Een AI-project voor “het bedrijf” is te breed. Kies een eigenaar: verkoop, planning, administratie, klantenservice of productie. Schrijf ook op wie geraakt wordt door fouten. Bij klantservice is dat de klant en supportmedewerker. Bij boekhouding is dat administratie en accountant. Bij planning is dat buitendienst en klant.
Eindig dag 1 met één scherpe probleemzin: “Wij willen onderzoeken of AI op basis van historische orderdata en actuele capaciteit een planningsvoorstel kan maken dat minimaal 30% minder handmatige correcties vraagt.” Deze zin is nog geen aanvraag, maar hij dwingt helderheid af.
Werkdag 2: benoem de technische onzekerheid
De subsidieachtige kern zit vaak in deze vraag: wat weten we nog niet? Voor AI kan dat gaan over datakwaliteit, nauwkeurigheid, uitlegbaarheid, integratie, veiligheid of menselijke controle. Kies maximaal twee onzekerheden. Te veel onzekerheden maken je project ongericht.
Voorbeelden: “Onze data bevat vrije tekst en onvolledige velden; onbekend is of classificatie betrouwbaar genoeg wordt.” Of: “De agent moet acties voorbereiden in Exact Online, maar mag nooit zelfstandig boeken boven €500.” Of: “Nederlandstalige klantvragen bevatten dialect, typefouten en productnamen; onbekend is of de routering boven 85% juistheid komt.”
Zet naast elke onzekerheid hoe je hem test. Gebruik kleine experimenten: 100 historische cases, 30 facturen, 50 chatgesprekken, 10 planningsweken. Definieer succes vooraf. Niet “werkt goed”, maar “minimaal 80% juiste classificatie, maximaal 5% kritieke fouten, menselijke review onder 2 minuten per case”.
Werkdag 3: schets het experimentplan
Een haalbaarheidsonderzoek hoeft geen volledig product op te leveren. Het moet aantonen of doorontwikkelen verstandig is. Maak daarom een plan in drie fasen. Fase 1: data en procesanalyse. Fase 2: prototype of simulatie. Fase 3: evaluatie met go/no-go. Per fase noteer je activiteiten, mensen, uren en output.
Bij een klantserviceproject kan fase 1 bestaan uit het labelen van de top 100 vragen. Fase 2 bouwt een testbot op basis van een kennisbank, zonder live klanten. Fase 3 vergelijkt botantwoorden met menselijke antwoorden en meet overdrachten. Bij een administratief project kan fase 1 factuurtypes ordenen, fase 2 OCR en AI-classificatie testen, fase 3 uitzonderingsregels ontwerpen.
Zorg dat menselijke controle onderdeel is van het experiment. In 2026 is een AI-project sterker als je niet belooft dat de mens verdwijnt, maar laat zien waar de mens nodig blijft. Een goede uitkomst kan zijn: 70% automatisch voorbereiden, 30% bewust naar review. Dat is vaak realistischer én veiliger.
Werkdag 4: maak budget en planning geloofwaardig
Subsidiedossiers verliezen vertrouwen door ronde getallen zonder onderbouwing. Splits kosten uit: interne uren, externe begeleiding, prototypebouw, datavoorbereiding, testomgeving, security of privacycheck en projectmanagement. Gebruik realistische blokken. Een mkb-haalbaarheidsonderzoek van 6 tot 12 weken is vaak geloofwaardiger dan een wonderplan van 10 dagen.
Koppel uren aan mensen. De eigenaar levert proceskennis, een medewerker labelt cases, een technische partner bouwt het prototype, een privacyverantwoordelijke checkt data. Noteer ook wat je niet doet: geen volledige productie-implementatie, geen live klantbesluiten, geen automatische betaling, geen HR-besluitvorming zonder specialistische beoordeling.
Beschrijf de verwachte opbrengst voorzichtig. “We verwachten 8 uur per week tijdwinst als 60% van de aanvragen automatisch wordt voorbereid” is beter dan “AI bespaart 50% kosten”. Zet er een terugverdienlogica bij: urenwinst, minder fouten, snellere reactietijd, hogere conversie of lagere werkdruk. Subsidieadviseurs en ondernemers houden allebei van nuchtere rekensommen.
Werkdag 5: maak de go/no-go en bewijsstukken af
De laatste dag is voor besluitvorming. Schrijf drie mogelijke uitkomsten. Groen: prototype haalt de drempels, we bouwen door. Oranje: techniek werkt deels, eerst data opschonen of scope verkleinen. Rood: foutpercentage of risico is te hoog, project stopt of wordt handmatig procesverbetering. Deze go/no-go maakt je dossier volwassen omdat je niet doet alsof succes gegarandeerd is.
Voeg bewijsstukken toe: procesbeschrijving, voorbeelddata zonder persoonsgegevens, screenshots van huidige workflow, export van volumes, offerte of aanpak van leverancier, interne urenraming en privacy-aantekeningen. Bewaar gevoelige data apart. Een subsidiedossier hoeft geen klantgeheimen te bevatten om concreet te zijn.
Laat daarna iemand buiten het project het dossier lezen. Vraag niet: klinkt het innovatief? Vraag: begrijp je welk probleem we onderzoeken, waarom het onzeker is, hoe we testen en wanneer we stoppen? Als het antwoord ja is, heb je een bruikbaar dossier.
Veelgemaakte fouten bij AI-haalbaarheid
De eerste fout is te breed starten. “AI voor onze administratie” is geen project. “Automatische controle van inkomende facturen met uitzonderingswachtrij” wel. De tweede fout is doen alsof standaardsoftware R&D is. Soms is kopen beter dan bouwen. De derde fout is privacy pas achteraf checken. Als je test met klantdata, moet dat vanaf dag 1 verantwoord gebeuren.
De vierde fout is geen eigenaar kiezen. Een AI-project zonder proceseigenaar wordt een speeltuin van tools. De vijfde fout is alleen tijdwinst meten. Meet ook foutkosten, klantimpact, overdrachtstijd en adoptie door medewerkers. Een prototype dat technisch werkt maar door niemand wordt vertrouwd, is geen haalbare businesscase.
Conclusie
De beste MIT Haalbaarheid AI-aanpak begint niet met formulieren, maar met een scherpe onderzoeksvraag. In vijf werkdagen kun je genoeg verzamelen om serieus te beslissen: probleemcijfers, technische onzekerheid, experimentplan, budget, risico’s en go/no-go. Misschien leidt dat tot een subsidieaanvraag. Misschien tot WBSO, SLIM-training of gewoon een intern pilotbudget. In alle gevallen voorkom je de duurste route: bouwen aan een AI-oplossing waarvan niemand vooraf heeft bewezen dat hij kan werken.
Direct toepasbare prompt
"Geef me een praktische aanpak voor [probleem] voor een Nederlands mkb-bedrijf. Houd het kort, met concrete stappen en voorbeeldtekst."