Fundamentals
When not to use AI — six cases from practice
One of the most valuable sentences an FDE can say is “no model belongs here”. Six situations where AI is a worse answer than a rule or a better form.
The most expensive mistake in AI projects isn’t poor execution. It’s that they started at all.
Six recurring situations where the right answer is no.
1. When the process can be described by rules
If the decision amounts to “if the amount is over €1,000 and the supplier isn’t on a framework agreement, route it to the finance director”, you don’t need a model. That’s four lines of code that always do the same thing, run instantly, cost nothing and never hallucinate.
Surprisingly often, an “AI project” turns out to be a rules engine that was never built.
2. When the input is bad and fixable
If the data is chaotic because there’s no form for it, AI treats the symptom. We had a customer who asked for an agent to process incoming requests — the real fix was a six-field internal form that took two weeks and eliminated 90% of the problem.
That was bad business for us. It was good business for them. Which is why they called back six months later with something bigger.
3. When the volume is too small
Automating a process with twelve cases a month rarely pays back. Not just because of the build: running, measuring and maintaining it carry fixed costs regardless of throughput.
The exception is when risk is high — if those twelve cases are €25,000 each. There the value comes from the error rate, not the time saved.
4. When the error is neither reversible nor visible
If a wrong decision moves money, signs a contract or files with a regulator, and the error would only surface weeks later, a human stays at the end of the process. The system can prepare, gather and propose — but not send.
That isn’t a technology limit. It’s a question of accountability, and it doesn’t resolve by the model getting better.
5. When there isn’t enough data to measure
If you can’t say what the correct output is because there are no historical cases, you can’t measure. If you can’t measure, you won’t know whether it works — not now, and not in six months.
The right order here: collect data properly for three to six months first, then come back.
6. When the organisation isn’t ready
The least technical, and the most common real reason.
If the affected team experiences the project as aimed at them, the system won’t spread. However good it is. They won’t sabotage it — they’ll simply not use it, and they’ll always have a good reason.
Here you either settle the trust question first, or start with a different area. Sometimes a successful deployment in a neighbouring, less sensitive process solves it — because then they can see it isn’t about their jobs.
What we say in those cases
We write it into the “no” box of the ROI matrix, with a reason — and with what would change the decision. So it can be picked up again in six months without redoing discovery.
The value of discovery isn’t only in what we build. It’s also in what we save you from.
Related: why most AI pilots fail.
Questions on this topic
Aren't you arguing yourselves out of work?
In the short term, yes. In the long term it's the only reason a customer calls us a second time. An unsuccessful deployment costs us more than a project we passed on.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.