The most common question I hear in 2026 is some version of "which AI model should we use?" GPT-5.6, Claude Fable 5, Gemini, or the open-weight model everyone suddenly rates? It is the wrong question. A serious AI strategy is built around the decision you want to change, the data you already own, and the people who have to trust the result — not around whichever model happens to top the leaderboard the week you sign off.
I run an AI consultancy. I have watched this one question sink more budgets than any technical limitation of a model ever has. So this is the essay I wish I could hand every owner before the first meeting: why the model is the least strategic choice you will make, and what an AI strategy is actually made of once you stop staring at benchmarks.
Why “which AI model should we use?” is the wrong question
Start with what the leaderboard actually does. Every few weeks a new model claims the top of some benchmark. GPT-5.6 edges ahead on reasoning, Claude takes long context and code, Gemini wins on cost and multimodal work, and an open-weight model from DeepSeek or a Chinese lab quietly matches all of them for a tenth of the price. If you build your plan around “the best model,” you have anchored a twelve-month commitment to a number that changes faster than your quarterly reporting.
The economics make the point better than I can. Stanford’s AI Index found that the cost of running a query at GPT-3.5 quality fell from twenty dollars per million tokens in late 2022 to seven cents by late 2024 — a 280-fold drop in about eighteen months. In the same window models got cheaper and better at once, and open-weight models closed the gap with the closed frontier from eight percent to under two percent on some benchmarks in a single year. The model layer is the fastest-commoditising part of the entire stack. Betting your strategy on today’s leader is like buying a house because you liked this month’s phone.
There is a quieter reason, too. The people building these models keep changing chairs. 2026 has been one long talent war — researchers moving between labs, new outfits spun up overnight, roadmaps rewritten the moment a founder leaves. I do not raise it to gossip; I raise it because a strategy that depends on one lab’s direction is hostage to decisions made in a building you will never enter. Model independence is not a technical nicety. It is insurance.
And the cost of chasing is not only wasted licence fees. Every time a team re-platforms onto the newest model, someone rewrites the prompts, reruns the tests, and re-trains the people who had just started trusting the old output. That churn has a name in the businesses I work with: it is the reason the AI project is still “nearly live” eight months later. The leaderboard moved four times and the team dutifully followed it four times, and the Tuesday-morning task it was supposed to fix is still being done by hand.
What an AI strategy is actually made of
When I audit a company that thinks it has an “AI strategy,” I usually find a shopping list of tools. A real strategy has four layers, and only one of them is the model.
The tell is easy to spot. Ask the team to describe the strategy and you hear a vendor’s name in the first sentence. Ask what changes for the business and the room goes quiet. That order — tool first, outcome second — is exactly backwards, and it is how a company ends up owning six pilots and zero shipped systems. Reverse it. Name the outcome first and the model becomes an implementation detail you can argue about later, cheaply, once you know what it has to do.
The first is the decision. Not a capability — a decision: the specific thing someone will do differently on a Tuesday morning once the system works. “Auto-triage these four hundred daily tickets and route the top ten percent to a specialist” is a decision. “Leverage AI for better insight” is a wish. If you cannot name the decision, no model will save you — a point I have made until I am blue in the face about how I know a project will fail before it starts.
The second layer is your data — where it lives, who owns it, how clean it is, whether the model can even reach it without a compliance headache. The third is integration: the unglamorous plumbing that pushes a result back into the ERP, the planning tool, the inbox where work actually happens. The fourth is the people who have to trust the output enough to act on it. None of these four churn. Your ticket data will still be your ticket data next year. Your technicians will still be your technicians. The model is the one component you can swap over a lunch break.

This is not a theory I invented. McKinsey’s 2025 State of AI found that most organisations have crossed the adoption line — nearly everyone is using AI somewhere — yet only a small minority capture real enterprise-level value, with the majority stuck in the gap between use and impact. The projects that stall almost never stall on model quality. They stall on the other three layers: messy data, no integration, no adoption. Which is exactly where a model-obsessed strategy spends none of its attention.
The model is a commodity; your data and process are not
So design for that. The single most useful architectural decision a Dutch SME can make is to put the model behind its own thin layer — your prompts, your evaluations, your data pipeline, your guardrails on your side of the line — so that swapping GPT for Claude for an open-weight model is an afternoon’s work, not a rebuild. If you have compared the options yourself you already know they are close enough to be interchangeable for most tasks; I wrote about that trade-off in OpenAI vs Anthropic vs open-source LLMs.
In practice that layer is not exotic. It is a small amount of code every model call passes through, a folder of prompts you version like any other source, and — the part most teams skip — a set of evaluations that score a model on your actual tasks with your actual data. Those evaluations are the real asset. They turn “is the new model better?” from a matter of opinion and press releases into a number you can read on a Friday afternoon. Without them you are trusting a benchmark someone else ran on someone else’s problem, and hoping it maps to yours.
When the model is swappable, three good things happen. You are never trapped by one vendor’s pricing or one lab’s outage. You can let a cheaper or open model take the routine volume and reserve the expensive frontier model for the hard ten percent. And when next month’s leader appears — it will — you test it against your own evaluations and adopt it in a day if it wins, instead of re-justifying the whole programme. The moat was never the model. The moat is the proprietary process and clean data you built around it, and those you actually own.
What this looks like for a Dutch SME
Concretely: do not open the conversation with “let’s use model X.” Open it with one high-frequency, boring, expensive task — the quotes that take a day to produce, the invoices someone retypes by hand, the tickets nobody triages until Thursday. Build something thin against that one decision, keep the model behind your own layer, measure whether the Tuesday-morning behaviour actually changed, and only then widen. I have watched two companies start the same month with the same budget: one anchored to a model and spent the year migrating every time the leaderboard moved; the other anchored to a process, quietly shipped, and swapped models underneath without anyone noticing. Same tools. Completely different outcome.
If you want a defensible order of operations, it is boringly consistent: understand where you stand before you buy anything. That is the whole point of an honest AI readiness assessment — it tells you which of the four layers is your real constraint, and it is almost never the model. Nine times out of ten the bottleneck is data or adoption, and a hundred thousand euros of frontier model does nothing for either.
When the model does matter
I am not going to pretend the choice never matters — that would be its own kind of hype. There are real cases where the model, or where you host it, is genuinely strategic. If you need very long context, specialised reasoning, on-premise deployment for data residency, or EU-hosted inference to stay clean under the AI Act and the GDPR, then the class of model you choose is a first-order decision, not a detail. But notice the word class. You are choosing a category that meets a requirement — open-weight and self-hosted, or EU-region, or long-context — not a rank on a leaderboard. The requirement is durable. The rank is noise.
The same logic applies to cost at scale. If you are pushing millions of calls a month, the gap between two models stops being a rounding error and becomes a line on the P&L — but even then you are choosing on a durable requirement, price per useful outcome, not on which model won last week’s benchmark. Requirements like these are worth writing into the strategy in ink. A leaderboard position never is; by the time the document is printed it is already out of date.
That distinction is the whole discipline. Choose a class of model for a reason you can write down, then treat the specific model inside that class as replaceable. Where all of this is heading over the next few years only sharpens the point — I laid out my read of it in where AI is heading in 2026 — but the through-line is simple: capability keeps rising and prices keep falling, so the worst thing you can do is freeze a strategy around one snapshot of a market that reprices itself every quarter.
Start with the decision, not the download
If you take one thing from an AI consultant who makes his living building these systems, make it this: the model you choose today is the most replaceable part of your AI strategy. Spend your scarce attention on the parts that last — the decision, the data, the integration, the trust — and keep the model on a leash you can shorten or swap at will. That is not caution for its own sake. It is how you stop paying the leaderboard tax, and it is usually the difference between a programme that compounds and one you rebuild every quarter.
When people ask what that discipline costs to set up properly, the honest answer is that it is far cheaper than the migrations it prevents — I keep an open breakdown of what AI consultancy costs so nobody has to guess. And if you would rather start from a decision than a demo, that is exactly the conversation our AI audit & strategy work is built around. Bring the Tuesday-morning problem. We will worry about the model last, the way you should.
Frequently asked questions
Which AI model should a small or mid-sized business use in 2026?
For most tasks, the honest answer is that almost any current frontier model will do, so choose the one that is easiest to swap out later. GPT-5.6, Claude and Gemini are close enough that the pick rarely determines success. Decide on integration, price and data residency, keep the model behind your own layer, and re-test when a new leader appears — do not rebuild around it.
How do you build an AI strategy that survives new model releases?
Anchor it to the things that do not change every quarter: the specific decision you want to improve, your data, the integration into existing systems, and user trust. Treat the model as a swappable component behind your own prompts and evaluations. When a better model ships, you test and adopt it in a day rather than re-justifying the whole programme.
Should we wait for a better AI model before we start?
No. Models get cheaper and better continuously — inference costs fell roughly 280-fold in eighteen months — so “wait for better” is a permanent excuse. Start now on a real decision with a model kept deliberately replaceable; you capture value today and inherit every future improvement almost for free, because upgrading becomes a swap rather than a rebuild.
Does it matter which model we pick if we might change it later?
Less than most people fear, provided you designed for change. If the model sits behind your own thin layer — your data pipeline, prompts and guardrails on your side — then switching is an afternoon, not a project. The real mistake is welding your business logic directly onto one vendor’s API, which turns every model change into a migration.