Kronehoefstraat 85
5612 HL Eindhoven
BTW NL863902509B01
AI Strategy Is Not a Tool Choice
qw
vc
mshm
.svg)
An AI strategy is not a tool choice. It's a series of deliberate decisions about which process you tackle first, how you limit dependency on a single vendor, and how you make data retrieval and quality measurable before you invest further.
Many leadership teams think the AI strategy is done the moment the license is signed. Copilot, Gemini, or ChatGPT Enterprise goes live, everyone gets access, and the next meeting has already moved on to something else.
Six months later, the picture looks different. A lot has been tried, little is in production, and nobody can point to a process that's actually faster or more accurate now. That's not a one-company problem. Gartner predicts more than 40% of AI agent projects will be canceled by the end of 2027, mainly due to rising costs, unclear business value, or insufficient risk controls (Gartner, 2025).
MIT research confirms the pattern at larger scale. Of the generative AI pilots studied, 95% delivered no measurable gain in business results, despite 30 to 40 billion dollars in investment worldwide (MIT NANDA, 2025). The cause is rarely the model itself: it's what's missing around it.
A more recent Gartner survey of 782 operational leaders shows the same picture on the ground: only 28% of the AI applications studied fully met expected business value, and 20% failed outright (Gartner, 2026). The technology is rarely the problem. The missing answer to which work actually needs to get better, is.
The Netherlands is doing relatively well: nearly 30% of businesses with 10 to 249 employees now use AI, a sharp rise from two years ago (CBS, 2025). See also our broader view in the state of the AI economy. So the problem isn't that businesses use too little AI. The problem is that "we're doing something with AI" gets mistaken for a strategy.
Choosing a platform is a procurement decision. A strategy answers a different question: which work actually gets better, for whom, and how do you know for sure. Without that answer, every model switch, every new feature, and every vendor sales pitch resets the course, and the boardroom discussion starts from zero again.
The first question in an AI strategy is never "which model do we use." It's: which process is structurally costing our team time, money, or quality, and how often does that happen.
That sounds simple, but in practice most businesses skip this step. They start with the tool, look for a use case afterward, and discover the tool fits everywhere a little and solves nothing fully. Reversing that order is the difference between an experiment and a project that keeps running.
Three questions determine which process is worth tackling first:
Processes that happen often, touch many people, and carry manageable risk when they go wrong are the best candidates for a first project. That's exactly where intelligent process automation starts: not with the technology, but with the process you map out first. We wrote earlier about how that scoping works in practice in intelligent business process automation.
Once the process is set, the model choice is a detail. That sounds counterintuitive to anyone who's just seen a handful of AI demos, but it's exactly the order that lets a project survive well past the first model switch. Businesses that start with the technology build something that works for the demo. Businesses that start with the process build something that keeps working when the model behind it has a different name a year later.
Models change faster than most businesses revise their strategy. A large language model (LLM) that performs best this quarter can be overtaken on quality, price, or speed the next. That's not a reason to wait before building. It's a reason not to build around a single vendor.
Designing model-independently means the model is a setting, not a foundation. The agent logic, validation rules, and system integrations stay in place. The model behind them changes, when needed, without a rebuild.
That principle doesn't apply everywhere. Some applications are tested so specifically against one model's behavior that switching creates more risk than it solves. Model independence is a design choice made per situation, not a dogma. The question isn't which vendor you choose, but what you lose if you have to switch in a year, and whether that loss is acceptable.
In practice, this means we build agents with a clear layer in between: the agent calls a model through a fixed interface, not directly with vendor-specific code woven through the entire application. That layer costs a bit more time to build. It pays for itself the moment the next generation of models ships, which realistically happens within a year.
An AI model can analyze, flag, and propose. It should never invent the facts that analysis runs on. That distinction sounds technical, but it's the difference between an AI strategy leadership can trust and one that eventually lets a wrong number slip into a decision.
Language models are good at recognizing patterns and producing text. They're not built to copy numbers exactly. Research into language models applied to financial data shows how quickly that breaks down: the accuracy of the best models drops from over 95% on simple lookups to near zero on multi-step calculations (OWASP GenAI Security Project, 2025). A model that copies a figure "roughly" is unusable for a board decision.
The solution is a separation fixed upfront on every project. Retrieving data, such as invoices, bookings, or time entries, happens with code: exact, reproducible, no interpretation. Analysis and flagging is where AI adds value: spotting patterns, marking anomalies, preparing a summary for a human who makes the decision. That last part is called human-in-the-loop: not because you don't trust the model, but because some decisions should stay with a human. That also lines up with the EU AI Act, which explicitly requires human oversight for higher-risk AI applications (European Commission, 2026).
This distinction existed before the current AI wave, and it's exactly why pre-AI automation and AI itself complement rather than replace each other. We expanded on that in RPA versus intelligent automation. An AI strategy that ignores this distinction builds on a foundation that shifts the moment someone checks the source data.
The same separation is the foundation of what we call an AI business brain: reliable data access first, AI that analyzes and flags on top of it, never the other way around.
Without a yardstick, nobody knows if a model switch is an improvement or a regression. That's the problem most businesses only discover after the switch, when a colleague reports that "the AI responds differently now" and nobody can say whether that's better or worse.
The solution is called an eval set: a fixed list of representative prompts and inputs, each with a clear criterion for a good answer. You run that set on every change: a new model, a tweaked prompt, a new version of your data. Anthropic describes an evaluation aptly as a test for an AI system: an input goes in, clear grading logic runs over it, and a score measures whether the system passed (Anthropic, 2026).
Without that set, nobody steers on facts, only on feel. An eval set isn't a luxury for big tech companies, it's the only way to justify a model switch instead of just sensing it. For an SME without its own AI team, this doesn't need to be a heavy instrument: ten to twenty representative cases, run a few times a month, is enough to see a trend instead of a one-off impression.
That way you measure three things at once, and that distinction is exactly where businesses without a yardstick get lost. The prompt: does the right instruction produce the right result. The model: does vendor A outperform vendor B on your specific task. The output: is the result usable for whoever receives it, without rework. Change any one of the three, and an eval run tells you whether you're moving forward or backward, instead of hoping.
McKinsey flags a similar gap at larger scale: nearly two-thirds of organizations haven't yet started scaling AI across the enterprise, often because pilots never get a hard benchmark to scale from (McKinsey, 2025). An eval set is the smallest step an SME can take to avoid falling into that same gap.
The first project shouldn't solve the biggest problem. It should deliver the clearest proof that the approach works. A well-scoped proof of concept, such as a 13-week cash flow forecast for the finance function, makes risk, cost, and value concrete before a bigger investment is made.
A good first project has three traits: a clear boundary, one process, not an entire department, a success criterion fixed in advance, and an owner who stays accountable for the result after completion. Without those three, a pilot quietly fades once attention shifts to the next idea.
Businesses usually discover that difference halfway through the build, once the budget has already mostly gone to licenses. The AI itself is rarely the most expensive line on the invoice. Data access, process logic, and testing what happens when something goes wrong are, and that's exactly the work most platform choices skip.
Once the first project is running and has hit its own success criterion, the roadmap emerges almost automatically. Not as a thick strategy document, but as a running list: which process is proven, what did we learn about data access and validation, and which next process meets the same criteria as the first. That's exactly where a well-scoped AI pilot project delivers value: it pays for itself in insight, even if the financial result falls short on paper.
In practice, that build-up follows a fixed order:
That way, an AI strategy never becomes a document that disappears into a drawer. It's a series of proven steps, each with its own yardstick, that together form a direction that holds even when the next model hits the market.
No. A license determines which tool your team uses, not which problem you're solving or how you know it's working. An AI strategy starts with the process you want to improve and defines how you measure that. Without that second part, a platform choice is a procurement decision, not a strategy.
Start with one process that happens often, touches many people, and carries manageable risk if it goes wrong. Within that, choose a well-scoped proof of concept with a success criterion fixed in advance. You don't need an in-house AI team to take that first step, but you do need a clear owner who stays accountable after completion.
Not by default. Keep the agent logic, validation rules, and system integrations separate from the underlying model, so a vendor switch becomes a setting rather than a new project. For applications tested heavily against one model's behavior, committing is sometimes still the smarter choice: judge that per situation.
By running a fixed eval set: representative examples with a clear criterion for a good answer. Compare the new model's score to the old model's score on the exact same set. Without that yardstick, a model switch feels like an improvement or a regression, but you don't actually know.
Not without a check. Language models aren't built to copy numbers exactly, and accuracy drops quickly on more complex calculations. Run data retrieval through code, exact and reproducible, and let AI play the role of analyzing and flagging, with a human making the final call.
Most of the budget rarely goes to the model or the license. It goes to reliable data access, validation, error handling, and testing: the layer that makes sure the agent still works when something goes wrong. Businesses that budget for this upfront run into fewer surprises halfway through the build.
Small enough to give a clear answer within a few months. One well-scoped process, one success criterion, one owner. A project that starts too broad rarely delivers clear proof, and without proof there's no basis for the next step.
We map your processes, pick the use case that works reliably fastest, and lay a foundation underneath it that can carry the next ten.
.svg){kind=icon}