You Don't Have an AI Skills Gap

Ask me whether Dutch SMEs have an AI skills gap and the honest answer is yes — just not the one making headlines this month. The shortage everywhere in the news describes a market a twenty-person company will never enter; the gap that actually kills AI projects here is smaller, more ordinary, and has almost nothing to do with machine learning.

Why every headline says there's a shortage

Open any hiring newsletter this summer and the numbers are dramatic. AI and ML roles now take an average of 89 days to fill — the longest of any tech category, with some estimates putting the global cost of the skills shortfall as high as $5.5 trillion in delayed products and missed revenue. Meanwhile the frontier labs are cannibalising each other's payrolls in public: Andrej Karpathy left his own startup for Anthropic's pretraining team, Nobel laureate John Jumper moved from DeepMind to Anthropic, Noam Shazeer went the other way to OpenAI, and at least twenty-two professors have taken leave from Stanford, Berkeley and Harvard this year to join a lab. I wrote about what that particular talent war actually means for smaller companies a couple of weeks ago; the short version is: almost none of it.

That shortage is real, and it is worth taking seriously — for the handful of organisations it actually applies to. It is a market for people who can improve the model itself: researchers who understand attention mechanisms, reinforcement learning from human feedback, distributed training at a scale almost nobody outside a hyperscaler will ever touch. There are perhaps a few thousand of those roles in the world, and nearly all of them sit inside a dozen labs and cloud providers. A Dutch company with twenty people, an ERP system and a shared customer service inbox is not competing for that talent, has never competed for it, and will not start now.

The skills gap I actually see in practice

The gap that shows up in real conversations with SMEs looks nothing like a hiring shortage. In most first meetings, the technical questions get answered within the hour: what a model can and can't do, what data already exists, what a rough first version might look like. The slow part, almost every time, is a different question entirely — who in this company is going to own this once the project is delivered and we've moved on?

That is not a skills problem in the way the headlines mean it. It is a decision-rights problem. Somebody has to be willing to approve a change to a process that has worked, badly but predictably, for years. Somebody has to notice when the output is wrong and correct it, rather than quietly working around it and letting the tool rot unused by December. Somebody has to be the person a colleague asks when it does something strange. None of that requires a machine learning degree. All of it requires a person with enough standing in the company to make a call, and enough curiosity to actually sit down and use the thing.

I have sat across the table from technically excellent teams that could not agree on who was allowed to change a workflow, and watched the project stall for months over a decision that took thirty seconds once someone was finally given the authority to make it. I have also worked with teams with almost no technical background who moved faster, simply because one person had clear ownership from day one and the standing to say "we're doing it this way" without a committee. The second group wins far more often than the first, and it is rarely close.

Does this look different for a five-person company than a fifty-person one?

Yes, and the size band changes the advice more than most articles admit. In a micro business — a handful of people, often the owner still doing the books themselves — the ownership question mostly answers itself: it is the owner, because there is nobody else it could reasonably be, and the goal is picking off-the-shelf tools that need almost no internal maintenance rather than anything custom. In a small business of twenty to fifty people, the pattern that actually works is different again: someone who already runs the process being automated — the person who owns quotes, or invoicing, or the customer inbox — becomes the internal owner, paired with outside technical help for the actual build. By the time a company reaches a few hundred people, the conversation genuinely does shift toward something closer to governance, because a decision that used to take one person a single afternoon now touches multiple departments and needs a lighter version of the process a large enterprise would use. Almost none of the generic "AI skills gap" coverage makes this distinction, because almost none of it is written with a twenty-person company in mind.

Do you actually need to hire an AI engineer?

For the overwhelming majority of the companies we work with, no. What pays off is not adding a machine learning specialist to the payroll. It is finding the person who already understands the business process well enough to know what is actually worth automating, and pairing them with outside technical help for the build itself. The wider research on the 2026 skills gap keeps landing on the same conclusion from a different direction: companies need fewer pure AI specialists and more people who can use AI tools to solve a real business problem — analysts, operations staff, team leads who can explain a result in plain language to a customer or a partner.

If you are hiring at all this year, hire for that. Someone who can sit with a customer complaint and a spreadsheet in the same afternoon is worth more to an AI project than someone who can explain a transformer architecture and has never spoken to your finance team. The technical build is the part you can buy in — from us or from anyone competent — and it is also the part getting cheaper every quarter as the tooling matures. If you are weighing up outside help for that part, I've written before about the one question worth asking any AI consultant you're considering. The judgment about what is worth building, and what to leave alone, rarely is for sale, and it is the harder thing to find.

What "AI literacy" actually requires from August 2026

There is one piece of this that is genuinely time-bound, and it is worth getting right rather than panicking about. Article 4 of the EU AI Act has required providers and users of AI systems to ensure a sufficient level of AI literacy among their staff since February 2025 — that part is not new and never was a August 2026 story. What changes on 2 August 2026 is that national market surveillance authorities get the formal power to enforce it. The Digital Omnibus, finalised at the end of June this year, also softened the wording — from an obligation to ensure a sufficient level of literacy to an obligation to support its development. That is an obligation of effort, not of a guaranteed result, and it is a real, recent, and useful change that most compliance content published before June has not caught up with yet.

In practice, for a small company, none of this means hiring a compliance officer or a data scientist. It means being able to show that staff who touch an AI tool have had some structured explanation of what it can and cannot do, documented somewhere, and updated when the tools change. We help clients write that policy in an afternoon, run a short internal training session to back it up, and if you want the fuller picture of what the AI Act does and does not require of a company your size, that is a separate and more thorough read. Either way: it is not a skills gap, and it does not require a new hire. It is paperwork with a deadline, and it is smaller than the headlines make it sound.

Who should own AI in a twenty-person company

Most of the governance frameworks written for this problem assume a company that already has a governance function — a risk committee, a data office, a change advisory board. Almost none of our clients have one, and building one for its own sake wastes the one advantage a small company actually has, which is that a decision can move in a single afternoon instead of a single quarter. What works instead, in practice, is smaller: name one person — not necessarily the most technical person in the building — as the owner. Their job is not to build anything themselves. It is to decide what gets tried, check whether it is actually working three months later, and have the standing to kill whatever isn't. In a company that size, that person is usually the owner, an operations lead, or whoever already runs the process being touched. It is almost never a committee, and it is almost never the newest hire.

The businesses that struggle with this are almost never the ones without technical talent in the building. They are the ones where that ownership question never gets a clear answer, so every small decision — do we trust this output, do we change the process around it, do we tell the whole team to start using it — gets relitigated from scratch every time it comes up. That is exhausting in a way that has nothing to do with the model and everything to do with how the company makes decisions.

What this changes about the hiring conversation

If you take one thing from this into your next hiring conversation, make it a short checklist rather than a job title:

• Who owns this once we leave? If nobody in the room can answer that in one sentence, that is the gap worth closing first — before any recruiting starts.
• Can they explain a result to a customer, not just to a developer? Judgment and communication travel further than a credential in a market this small.
• Do they already understand the process being automated? Someone who has run the workflow for two years will spot a bad AI output faster than someone who only understands the model.

If a management team asks me whether they have an AI skills gap, my honest answer is usually: probably not the one you are worried about. Check whether someone in the building actually owns the decision before you check whether anyone can write a good prompt. Hire for judgment and process knowledge before you hire for a credential that a handful of labs in San Francisco, London and increasingly Amsterdam are already fighting each other over. The talent war at the frontier is real, well documented, and almost entirely irrelevant to whether your next AI project actually works.

None of this is an argument against training, and it is not an argument against ever hiring technical people — some businesses genuinely do reach a size where an internal data or automation lead pays for themselves. It is an argument against solving the wrong shortage. I have watched a company delay a project for two quarters trying to recruit a machine learning engineer it did not need, while a competitor down the road shipped something useful in six weeks with an existing operations manager, a clear owner, and a consultant brought in for exactly the part that required one. The second company was not more technical. It just answered the ownership question on day one instead of leaving it open.

The AI talent shortage making headlines this year is real. It just is not the one that decides whether your project works.

Frequently asked questions