AI subsidy & WBSO 2026: how Dutch SMEs cut AI project cost

Planning an AI subsidie for your MKB: timing is the lever most teams miss

The size of a Dutch AI subsidie matters far less than when you apply. WBSO, the MIT-regeling and the SLIM-subsidie each run on their own calendar, and the most common reason an SME leaves funding on the table is not ineligibility — it is applying after the work has started or after the round has closed.

WBSO is the steady backbone: you can file ahead of almost any quarter, and the deduction applies to R&D hours and costs from the period the application covers onward, never retroactively to work already booked. That single rule shapes the whole plan. If you want the development hours of an AI proof of concept to count, the WBSO application has to be in before those hours are logged — which means the conversation about funding belongs at the scoping stage, not after the build.

The MIT-regeling and the SLIM-subsidie are different animals. Both open in fixed windows. MIT feasibility grants typically open mid-year and are frequently allocated on a first-come basis once the window opens, so a polished application submitted on day one beats a perfect application submitted in week three. SLIM has set application periods for SMEs across the year. Treat these as hard dates and work backwards from them.

A realistic sequence for a first AI subsidie 2026 Nederland application

• Scope first. Define the technical uncertainty and the R&D boundary before any code is written — this is what an AI audit and strategy engagement produces.
• File WBSO before development hours begin, so the proof-of-concept build sits inside the covered period.
• Check the MIT window if a feasibility study or an R&D collaboration is part of the plan, and be ready to submit the moment it opens.
• Layer SLIM for the training and adoption phase, which usually lands after the technical build, when your team needs to learn the new tools.

Note again the boundary that runs through this whole page: Crux Digits is an AI development partner, not a tax advisor. The procedural guidance here on WBSO, MIT and SLIM is to help you plan the engineering side around the funding calendar; the formal filing, the wage-base calculation and the binding eligibility call belong with RVO or a qualified subsidie consultant. What we control is making the technical project clean enough to fund.

How custom AI development reads as R&D — and how to document it

WBSO assesses whether your project contains genuine technical uncertainty: a problem where the outcome is not knowable in advance from existing knowledge or off-the-shelf tools. Most serious AI work clears this bar comfortably. Training a model on your own proprietary data, building a computer-vision pipeline for an inspection task that has never been automated, or engineering a retrieval system that has to hit a specific accuracy threshold on messy real-world inputs — these are research-and-development questions, not configuration tasks.

What does not qualify is equally clear. Buying seats in a SaaS product, wiring up a no-code chatbot, or restyling a website does not constitute R&D, no matter how "AI" the marketing copy is. This is precisely the line that separates serious engineering from the weekend-rebranded "AI" agencies — and it is the line a WBSO reviewer is trained to find. A project that cannot articulate its technical uncertainty is both a weak funding application and, usually, a weak project.

The hours administration that makes or breaks the claim

WBSO is reconciled on actual R&D hours. The deduction you apply for is provisional; what you keep depends on a defensible record of who did qualifying development work and when. SMEs lose money here not because the work was ineligible but because the administration was thin. A fundable AI project therefore needs:

• A documented R&D scope that names the technical uncertainty in plain terms.
• A clean separation between qualifying development hours and non-qualifying work such as routine integration, account management or hosting.
• Milestones that map to the research questions, so each phase has an auditable purpose.
• A cost breakdown that ring-fences the directly attributable R&D spend.

This is where fixed-step, milestone delivery earns its keep. Because the Crux ladder runs in defined stages — audit, proof of concept, production — the eligible development portion is already isolated in the structure of the engagement rather than reconstructed afterward from a single lump invoice. The R&D boundary is visible in the project plan, which is exactly what an hours administration wants to point to.

Combining WBSO, MIT and SLIM without double-funding the same cost

The schemes are designed to cover different layers of the same innovation, and the value comes from stacking them across phases rather than pointing several at one invoice. The rule of thumb that keeps you compliant: a given euro of cost should be claimed under one instrument, not two. The art is in mapping each phase of an AI project to the scheme built for it.

• WBSO — the build. The development wage and directly attributable R&D costs of the proof of concept and the production engineering. This is the largest and most reliable lever for an innovatiesubsidie strategy because it follows the actual engineering hours.
• MIT-regeling — the feasibility and collaboration. A feasibility study before you commit to a full build, or an R&D collaboration with a knowledge partner. MIT is a regional, provincie-driven top-up, so the exact terms vary by region — relevant for an SME in the Utrecht region where Crux is based, as well as nationwide.
• SLIM-subsidie — the people. Training and upskilling your staff on the new AI tools once they exist. An AI capability that nobody internally can operate is a stranded asset; SLIM funds the adoption phase that turns a delivered model into a used one.
• KIA (investment allowance) — the assets. Where qualifying investment spend is involved, the small-scale investment allowance can sit alongside the above on the appropriate cost lines.

Read together, these turn a single AI initiative into a sequence of fundable stages: scope it under an audit, build the proof of concept under WBSO, run a feasibility leg through MIT where it fits, and fund the rollout training through SLIM. Each scheme touches a different cost, so nothing is funded twice.

Why an AI subsidie favours a build you actually own

There is a strategic reason the funding logic and the Crux delivery model point the same way. WBSO rewards your R&D — work that builds capability inside your own business. The schemes are an instrument of Dutch industrial policy: the state co-funds innovation on the understanding that the innovating company keeps the resulting know-how. That is fundamentally at odds with the black-box arrangement where a vendor builds something opaque, retains all the knowledge, and bills a subscription forever.

This is the same principle that defines the boutique, senior-led alternative to both big enterprise consultancies and the rebranded web shops. Senior engineers stay on the project; the documentation, the data pipelines and the model artefacts transfer to you; and at the end you own the solution rather than renting access to it. A project structured for ownership is, not coincidentally, a project that documents cleanly enough to fund — the auditable trail a WBSO claim needs is the same trail that proves the capability now lives with you.

Where Dutch MKB sectors find the strongest fit

Across the delivered work — 13 case studies spanning healthcare, computer vision, NLP and forecasting — the projects that fund most cleanly share a profile: a real operational problem, proprietary data, and a measurable target. That maps directly onto the sectors where the Dutch MKB is investing:

• Healthcare — diagnostic support and document-heavy workflows where accuracy and privacy both have to be engineered, not assumed.
• Logistics — forecasting, routing and computer-vision inspection, where the R&D question is hitting reliability on noisy real-world inputs.
• E-commerce and marketing — search, personalisation and content systems; here Crux works as the AI engineering partner behind agencies rather than as a marketing agency itself.
• Finance — risk, classification and forecasting models where explainability and auditability are part of the technical spec.

Compliance and cost: the EU AI Act, the AVG and the net number

A funded AI project still has to be a legal one. Both the EU AI Act and the AVG (GDPR) apply from the first design decision, and for many MKB use cases — especially in healthcare and finance — the compliance work is not an afterthought but part of the technical specification. Building these in from day one rather than retrofitting them is cheaper, and it keeps the documented R&D scope honest: a model whose data handling cannot be explained is neither fundable nor deployable.

The point of getting all of this right is the net number. The worked example earlier showed how the WBSO rate compresses the effective cost of a proof of concept; the planning, the hours administration and the scheme-stacking described here are what make that compression real. The pre-subsidie figures stay fixed and transparent — an audit and strategy engagement, a proof of concept, then a production launch — so the eligible R&D portion is legible from the start, with day-rate guidance of roughly 150 euro per hour underneath the milestones.

If you want to scope an AI initiative that is engineered to be funded and built to be owned, the practical next steps are to review the transparent fixed-step pricing, look at the range of delivered work in the case studies, and read how the boutique model differs from the alternatives on the about page. For deeper engineering context, the AI consulting in the Netherlands overview and the AI automation service explain how a fundable proof of concept becomes a production system. The funding is the lever; a clean, owned, compliant build is what lets you pull it.