Almost every AI strategy you can read was written for a company of a thousand people. Copy it into a firm of thirty and you inherit the artefacts without the conditions that made them work: a strategy document nobody opens twice, a steering group that meets monthly to hear that things are going fine, a data platform that outlives the reason anyone wanted it. A small company needs a short answer to three questions and the discipline to stop there.
I have run an AI consultancy for Dutch and Flemish businesses since 2022. The most common thing I am handed in a first meeting is not a bad idea. It is a good idea wearing a costume two sizes too big.
Why is most AI strategy advice written for enterprises?
Because that is who pays for it. Large consultancies publish the thinking their largest clients buy, and platform vendors write for procurement committees, because procurement committees are who sign the contract. Neither is being dishonest. The advice is simply addressed to somebody else, and it arrives at your desk with the address torn off.
An enterprise reading that advice has four things you do not have. It has a data function whose job is data. It has a compliance function that already reads regulation for a living. It has budget that survives a quarter of no results. And it has enough transaction volume that a two percent improvement is worth a salary. Those four conditions are load-bearing. Take them away and most enterprise AI doctrine does not degrade gracefully. It falls over quietly, and the failure looks like slow progress rather than a mistake, which is what makes it expensive.
The reverse is also true and worth saying, because it is the honest half. You have things an enterprise would pay a great deal for. The person who knows how quoting really works sits two desks away. You can change a process on Tuesday without a change advisory board. Nobody needs to socialise a decision across four departments before it is allowed to be true. A strategy that ignores those advantages is as badly fitted as one that ignores your constraints.
The Interpolis lesson: the furniture travelled, the operating model did not
There is a Dutch precedent for this exact mistake, and it is not a technology one. In 1996 insurer Interpolis opened a headquarters in Tilburg with no fixed workplaces at all. There were around thirty percent fewer workplaces than there were staff, and nobody kept a desk of their own: the three-person board gave up its own desks along with everybody else. The time clock went. People were judged on what they produced rather than when they arrived. It became the reference case for what the Netherlands later called Het Nieuwe Werken.
What spread across the country afterwards was the flexplek. The furniture travelled beautifully. What travelled far less well was the part that made it work: management giving up their own rooms first, the clock actually being switched off, and output being the thing that got measured. Plenty of Dutch offices ended up with hot desks and exactly the same attendance culture they had before, which is the worst of both arrangements. You lost your desk and kept the surveillance.
That is precisely how enterprise AI doctrine lands in a company of thirty. The artefacts are portable. A governance charter is a document. A centre of excellence is a slide with boxes on it. A data platform can be bought this afternoon. The preconditions are not portable at all, and nobody writes them down because in the company the advice was written for they are simply the weather.
Does a small company need an AI strategy, and what is it actually for?
Yes, but not the document you are picturing. It exists to make three decisions, in writing, before anyone builds anything. That is all. If your document does more than this, the extra part is a project plan wearing a strategy's clothes.
- Which processes are in scope this year, and which are explicitly not. The second half is the one that does the work. A list of what you will not touch until next year is what stops the third good idea in March from quietly eating the first one.
- What you will not do with AI regardless of the business case. Which data never leaves your own systems. Which decisions stay with a person even when the model is right most of the time. Which customers or which cases are always handled by a human. Write this before someone builds something that makes the question awkward.
- Who decides when the system is wrong. Not who sponsors it, not who signs the invoice. Who looks at a refused output on a Wednesday afternoon and rules on it.
One page. Reviewed twice a year, or the first time one of the three answers stops being true. I have never seen a longer document change what a small company actually did.
What is an AI Center of Excellence, and does a small company need one?
No, and it is worth understanding why not, because the underlying job is real. A centre of excellence in a large organisation does three things: it concentrates expertise that is too scarce to spread thin, it stops forty teams solving the same problem forty different ways, and it holds a standard that no single team has the standing to enforce. Those are genuine problems at scale.
You do not have forty teams. You have one process, one person who understands it, and a week that is already full. The scaled-down version of a centre of excellence is not a smaller committee. It is a named owner with hours protected in their calendar and a written standard they are allowed to enforce. A committee in a company of thirty produces agreement, and agreement was never the part you were short of.
The related trap is deciding you need to hire an AI engineer before you have decided anything else. I have written at length about why the skills gap in a small company is rarely the technical one. The short version: the depth is available to rent, and the process knowledge is not.
Six pieces of enterprise doctrine, and the small-company version
This is the translation table I actually use. The left-hand side is not wrong. It is right for a company you are not.
1. Build the central data platform first
Read from the systems you already run. Your ERP, your bookkeeping package, your ticketing tool. You very probably do not need a data warehouse to start, and postponing everything until the data is clean is the single most reliable way for three years to go by with nothing shipped. Build the platform when a second and third use case are both blocked by its absence, which is a real signal and a rare one.
2. Stand up an AI governance board
Put one rule on one process instead. Who approves an output before it goes to a customer, and where the refusals are recorded. Four eyes on a single workflow, with a log you can read at the end of the month, will teach you more about your risk than a charter that describes a body which has never met about anything specific.
3. Run a portfolio of use cases
Run one process end to end, exceptions included. A portfolio is a way of spreading attention, and attention is the resource you are shortest of. Three half-built things at seventy percent are worth nothing at all, while one finished thing at ninety percent changes a working week. The second project is where a portfolio starts to make sense, and it is much less expensive than the first because you have already paid for the plumbing.
4. Build a model evaluation framework
Copy this one almost verbatim, because it is the enterprise practice that scales down best. Write down thirty real cases from last month with the answer you would accept, before anyone builds. Then you have a number instead of an argument. What you choose to measure in a pilot decides whether the conversation afterwards is about evidence or about who felt more strongly.
5. Hire an AI lead
Borrow the depth, keep the process. A senior engineer for a fixed period is a known cost. A permanent hire at that level, in a company where there is not yet a second AI project to give them, is a bet on a roadmap you have not written. If the day comes when the roadmap justifies the salary, you will know, because the queue of blocked work will be visible without anyone arguing for it.
6. Run a change programme
Sit with the two people who do the work. A full day, twice, a few weeks apart. Every failed rollout I have watched had this in common: the people who would have to live with the system were consulted after the design was fixed, which is not consultation. It is notification with better manners.
What actually survives the translation
Three enterprise habits scale down completely and are worth adopting on day one, because they are what makes your second project less expensive than your first.
- Written evaluation cases. Thirty real examples with agreed answers. This is the closest thing to a free asset in this whole field, and it stays valid when the model underneath changes.
- A decision record. What we chose, what we rejected, why, dated. Four lines each. In eighteen months somebody will ask why the system does not do the obvious thing, and the honest answer is usually a good one that nobody can remember.
- An exception log. Every case the system refused or got wrong, with what happened next. This is your requirements document for version two, and it writes itself if you set it up on day one and does not exist at all if you do not.
None of these needs a tool. All three fit in the software you already pay for. What they need is somebody whose job it is to keep them, which brings the whole thing back to ownership, as it usually does.
Where small companies get this wrong in the other direction
The mirror error is refusing to write anything down at all, on the grounds that formality is for large firms. That produces a system whose logic lives in one person's head, and the day that person is on holiday the organisation quietly stops trusting it. Nobody announces this. Usage just drops, and six months later the project is described as something that did not really take.
There is a compliance edge to it too. Under the EU AI Act you have to take measures that support AI literacy among the people who use AI on your behalf. Since the Digital Omnibus rewrote Article 4 in July 2026 you no longer have to guarantee a particular level in any individual, but if you cannot show what your people were told and what the system is allowed to decide, you are relying on memory. Our AI Act checklist for Dutch SMEs walks through what a firm your size is actually on the hook for, which is considerably less than the headlines suggest and not nothing.
So the target is not no documentation. It is one page that is true, kept by a person, instead of forty pages that were true in the week they were signed off.
How I would write it, for a company of thirty
On one side of A4, in your own language, with a date on it. In scope this year: the quoting process and the inbound email that follows it. Not in scope: anything touching payroll, and anything customer facing that goes out unread. Never: personal data leaving our own systems, and a price quoted to a client without a person having looked at it. The owner: one named person, four hours a week, with the authority to change how the work is done. Success: the thirty test cases, and the number we will accept on them.
That is a strategy. Everything after it is scheduling and budget, and what an AI project actually costs is a much easier conversation once the three decisions above have been made, because most of what inflates a quote is unresolved scope. If you want a second pair of eyes on the page before you commit money to it, that is roughly what we do with SMEs in the first two conversations, and the answer is quite often that you need less than you thought.
The Interpolis building is still there, and the idea in it was a good one. It worked because the people who ran the company changed how they behaved before they changed the furniture. That is the whole lesson, and it costs nothing to apply. Decide the three things. Write them on one page. Then buy only what that page asks for.
