There is an informal tax that Belgian mid-market companies pay on AI projects. Nobody sends them an invoice for it. It accumulates quietly, through a series of decisions that each seemed reasonable at the time.
It looks like this: €80,000 spent with a Big-4 consultancy on an AI strategy document that describes in precise detail what your company should do with AI but leaves the building entirely to you. Or: €35,000 on a vendor whose platform does roughly what you need, plus a €12,000 per year licence for a feature you use once a quarter, plus a €15,000 integration project when you discover their API doesn't connect to your ERP the way the sales pitch implied. Or: a €25,000 internal pilot that ran for eight months, produced genuine results in the test environment, and then quietly stalled when nobody had the time or mandate to move it to production.
The total? Call it €60,000–€120,000 across a typical eighteen-month AI initiative, with nothing in production at the end of it.
This is the KMO AI tax.
Why it happens
The mid-market sits in an uncomfortable gap. Large enterprises have dedicated AI teams, transformation budgets, and the political weight to force an AI project through the organisation. Startups and scale-ups have technical founders, investor capital, and a cultural appetite for experimentation.
KMOs — Belgian businesses in the 30–200 employee range — have none of these things. They have good businesses that are under genuine pressure to adopt AI, limited technical capacity, tight budgets, and boards that want to see something concrete relatively quickly.
Into this gap come three types of providers, each of whom extracts value in a different way.
The Big-4 premium
The large consultancies are excellent at producing thorough, defensible strategic documents. They interview stakeholders, benchmark against peers, model scenarios, and deliver a report that covers every consideration you could think of — and several you couldn't.
What they are less good at is building the thing. Their AI strategy documents often recommend projects that require a dedicated ML team (which the KMO doesn't have), custom data infrastructure (which needs to be built first), and an 18-month implementation roadmap (which requires someone to own it full-time).
The document is defensible. The implementation is not realistic for the client it was written for.
Cost: €60k–€120k for the strategy. Implementation, if it ever starts, is billed separately.
The platform vendor trap
The AI SaaS market has expanded rapidly. There are platforms for document processing, customer service automation, data analytics, process orchestration, and virtually every other operational function. Many of them are genuinely good products.
The problem for KMOs is the gap between "this platform can do that" and "this platform does that for us, reliably, connected to our systems, at a price we can sustain."
The gap is filled by: integration work that was not in the original quote, customisation that requires the vendor's professional services team, data migration that nobody scoped properly, ongoing licence fees that were reasonable in year one but compound, and the eventual discovery that the platform does 80% of what you need but the missing 20% is exactly the workflow that matters most.
Switching costs, once you are embedded, are high. The vendor knows this.
The pilot that never ships
The internal pilot is the most common pattern and the most demoralising. A team — sometimes with outside help, sometimes internal — builds something that genuinely works. The demo is good. The test results are encouraging. The business case is clear.
And then it stalls.
It stalls because moving from pilot to production requires someone to own the integration into existing systems. It requires agreement from IT, from the data team, from the business unit, from legal. It requires the kind of sustained organisational attention that is very hard to maintain when there are seventeen other priorities and the pilot was already a side project for everyone involved.
The pilot is not a failure. It is a success that never reached the line.
Cost: the direct cost of the pilot (€15k–€40k) plus the opportunity cost of eight months of attention that produced nothing deployable.
The three mechanisms of the tax
Looking across these patterns, the KMO AI tax is produced by three specific mechanisms.
1. Scope that exceeds capability
The most expensive AI projects for KMOs are the ones that were right-sized for a company three times their size. A platform that requires a dedicated administrator. A strategy that assumes internal ML expertise. A custom build that needs ongoing engineering maintenance the company cannot staff.
The cost here is not just the project budget. It is the ongoing cost of running something that the organisation is not actually equipped to maintain.
Right-sized AI for a KMO means: it runs reliably without a specialist to babysit it, it handles failure gracefully, it can be understood and monitored by a generalist, and the vendor or partner relationship is sustainable at the company's scale.
2. Vendor lock-in compounding over time
Every AI platform has an integration cost and a switching cost. The integration cost is usually visible — it is in the project quote. The switching cost is almost never discussed because no vendor wants to emphasise how hard it will be to leave.
The switching cost compounds over time. After two years of data in a vendor's system, two years of integrations built around their API, and two years of staff trained on their interface, the real cost of switching is not the price of the new platform. It is everything else.
For KMOs with limited technical capacity, the switching cost is often so high that the effective choice is: stay on the platform even if it no longer serves you, or rebuild significant parts of your operational stack.
The antidote is not to avoid platforms — it is to evaluate them with switching costs in mind from the start. What does the data export look like? What happens if the vendor raises prices by 40% in year three? What would it cost to rebuild the critical integrations on a different platform?
3. Production deployment treated as an afterthought
The most common single failure mode in KMO AI projects is treating production deployment as something that happens at the end, once the pilot has proved the concept.
This is backwards. Production deployment is the hard part. Proving the concept in a controlled environment is the easy part.
When the production deployment is not planned from the beginning — when the integration architecture, the change management, the staff training, the monitoring, and the handover process are not scoped before the build starts — those things do not happen cleanly. They happen under time pressure, with incomplete information, after the budget is mostly spent.
The result is a system that is technically deployed but operationally fragile: nobody fully understands how it connects to the surrounding systems, the monitoring is thin, the documentation is incomplete, and the team that built it has moved on.
This is the pilot that technically shipped but practically stalled within three months.
What not overspending looks like
The KMOs that get AI right tend to have a few things in common.
They start with a specific problem, not a technology. "We spend forty hours a month classifying and routing supplier invoices" is a specific problem. "We want to be more AI-driven" is not. Specific problems can be evaluated, scoped, and measured. Technology-led initiatives cannot.
They build for production from day one. The pilot and the production build are the same thing — designed for production, tested against real data, integrated with real systems, with monitoring and documentation included in the scope. The distinction between "pilot" and "production" disappears. You are either building a production system or you are doing research. Research is valuable, but call it research — it costs less and has different deliverables.
They treat deployment as a first-class deliverable. Handover documentation, staff training, monitoring dashboards, a defined support process — these are in the project specification, not the "nice to have" section.
They choose platforms with exit routes in mind. Open standards where possible. Data exports that work. API contracts that are not proprietary. The cost of vendor lock-in is invisible until it is very expensive.
They keep it narrow. The most reliable AI projects at KMO scale do one thing well. The temptation to expand scope mid-project — "while we're at it, could we also..." — is the main reason projects exceed budget and stall before shipping.
The actual cost of getting it right
The KMO AI tax is not inevitable. The alternative is not cheaper in the headline number — a well-scoped AI project with a good partner costs real money. But the comparison is:
- €30,000 for a production-deployed AI integration that runs for three years and delivers measurable value
- vs. €80,000 across two years for a strategy document plus a pilot that stalled plus a platform licence you are paying for but not using
The second number is not hypothetical. It is the median Belgian KMO AI experience as WDC has observed it.
The right scope, the right partner, the right deployment approach, and a realistic assessment of what your organisation can actually maintain — that is how you avoid the tax.
Where to start
Before commissioning any AI work, three questions worth answering honestly:
-
What is the specific operational problem? If you cannot describe the input, the current process, the desired output, and how you will measure success — you are not ready to scope a build.
-
Who will own this in production? After the project team hands over, who monitors it? Who handles edge cases? Who updates it when the upstream system changes? If the answer is "we'll figure that out," that is a warning sign.
-
What does success look like in 18 months? Not "the system is deployed" — what is the measurable operational difference? If you cannot name it, the project scope is probably wrong.
WDC's AI Opportunity Assessment is designed specifically to answer these questions before any build starts: map the operational problem, evaluate the AI options honestly, scope for production deployment, and produce a written roadmap that is realistic for a company of your size. Fixed price, three weeks. If you have already started something and want a second opinion on whether it is on track, the AI Readiness Audit is the right place to start. Book a 30-minute call if you want to talk through your situation first.