5 cases where AI does not pay off, and what to do instead
Missing data, low volume, a moving process, a rule that does the job, no owner. Five cases where AI costs more than it returns, and what to do instead.
5 min read
Your board asks for an AI plan, and a competitor just announced an assistant. Someone on the team has a demo that works on ten examples, and a vendor quote for the next ten thousand. Most of that pressure points at building something fast.
Some of those projects should not be built. AI works; the conditions around it are not there yet. We build AI for a living, and in our audits we still advise against some of the projects we are asked about.
Here are the five cases we see most often, how to spot each one, and what to do with the budget instead.
1. The data is not there (yet)
The idea sounds simple: a model that reads past tickets and drafts the answer. Then someone opens the ticketing tool. Half the history sits in personal inboxes, the categories changed twice in three years, and nobody wrote down which answers were right.
A model learns from what you give it, and it is graded against what you call correct. When neither exists, the project turns into a data clean-up with an AI label on it. It takes months, and the demo still looks good the whole time, which is the trap.
What to do instead. Fix the capture first: make the ticket form ask the right questions, store the answers in one place, mark which ones were correct. That is a few weeks of product work, and it pays off on its own with better reporting and cleaner handovers.
The AI project becomes possible a few months later, on data you trust.
2. The volume is too low to pay back
A task that takes someone two hours a week is a real annoyance. It is rarely worth a model.
Count it out. Two hours a week is about 100 hours a year. The sum fits on a whiteboard: hours saved per year × loaded hourly cost, against build cost plus a year of running costs (model calls, monitoring, updates).
Take your own loaded hourly cost: at €60, that is €6,000 a year. Set that against the quote for a feature wired into your tools, plus its running costs. For a task this size, the payback often sits years away, if it ever arrives.
Low volume also hurts quality. With forty cases a month, you cannot tell whether the model is right 90 % of the time or 70 %. You find out when a customer complains.
What to do instead. Keep the task human and make it faster: a template, a checklist, a shared view of the information the person keeps looking up. Come back to AI when the volume grows, or when you can group several small tasks that share the same inputs into one project worth building.
3. The process changes every quarter
Sales qualification rules rewritten after each board meeting. A pricing grid with exceptions nobody listed. An onboarding flow the ops team redesigns every spring.
AI built on top of a moving process automates last quarter's version of it. Each change means new instructions, new tests, sometimes new data. The team spends its time keeping the model in line with a target that has already moved.
What to do instead. Stabilise the process before you automate it. Write down the rules as they are applied today, with the exceptions, and run them by hand or in a simple internal tool for a quarter.
If they hold, you have a spec. If they keep changing, you have learned that the problem is the decision, not the execution.
4. A plain rule or a no-code tool does the job
Routing an email by the word "invoice" in its subject. Sending a reminder three days after a quote. Copying a form into the CRM. We see all three pitched as AI projects.
A rule is predictable, costs nothing to run and anyone can read it. A model is probabilistic, has a running cost per call and needs testing every time it changes. When the logic fits on one page, the rule wins.
What to do instead. Start with the rule. Zapier, Make or the automations already built into your CRM cover most of these, at a fraction of the running cost.
Then measure what the rule misses. If the misses are rare, you are done. If they pile up in one place, say emails with no clear subject, put AI on that slice only, behind the rule.
Rules first, a model only where the rules stop working. It is less impressive in a demo and much easier to run.
5. Nobody owns the AI after launch
This one is the least visible on day one, and the most expensive by month six. The project ships, and the person who pushed for it moves on to the next priority. Six months later the model answers questions about a product line you discontinued, and no one has checked its output since spring.
An AI feature is not a one-off delivery. Its inputs drift, the underlying models get updated, users find edge cases nobody tested. Without an owner, quality decays quietly until someone notices, usually in front of a customer.
What to do instead. Before you start, name the person who will own it after launch, and give them time for it. Decide what you will measure each week and what level triggers a fix.
If no one inside can take it on yet, the team that built it can operate it after launch while you find that person (that is how we work on AI in production), or a fractional AI lead can hold the seat a few days a month.
Before you sign anything
Five questions, one per case. Forward them to whoever is writing the AI plan:
- Do we have the data, in one place, with the right answers marked?
- Does the task happen often enough to measure?
- Has the process held still for a quarter?
- Have we tried a rule first?
- Who owns it in six months, by name?
If one answer is no, fix that first. If all five are yes, the hard part is done: on projects like that, we usually have a first version in production within 3 to 6 weeks of kick-off.
A free audit tells you which side of the line your project sits on. One hour on your business, then a short document with the opportunities we see, and the ones we advise against. Book a free audit and bring the project you are unsure about.
