When should you NOT use AI in your business?

Why this guide exists

Most AI advice is written by people selling AI. This is the other list — the cases where we tell clients not to, and why.

Knowing where it does not belong is most of what makes the rest work.

1. When the answer must be exact

Totals, tax, payroll, invoice reconciliation, regulatory returns, anything where “nearly right” is the same as wrong.

Language models are not calculators. They produce plausible output, and plausible is a catastrophe in a payroll run.

Do instead: use AI to extract the numbers from a messy document if you must, then let ordinary code do the arithmetic and the checking.

2. When nobody can tell whether it’s wrong

This is the one that bites hardest, because it fails silently.

If the output goes straight into a system, or straight to a customer, and no person or process would notice an error, you have not automated the work — you have removed the only quality check and kept the cost.

The test: if this is wrong on a Tuesday, how do we find out? If there is no answer, don’t build it.

3. When a rule would do

If you can write the logic down in a sentence — “orders over £500 need approval”, “anything from this domain goes to that team” — write the rule.

A rule is faster, free to run, auditable, and cannot have an off day. Reaching for a model here adds cost and uncertainty to a solved problem.

4. When search would do

A lot of “we need an AI assistant” is really “we cannot find anything”.

If your team’s actual problem is that the right document exists but nobody can locate it, a good search box over well-organised content solves it more cheaply and more predictably — and you will know when it fails, because it returns nothing rather than something wrong.

5. When the volume is too low

Automating a task that happens twice a year costs more than doing it twice a year. The build, the testing, the maintenance and the eventual debugging all have to be repaid by saved time that does not exist.

Rough line: if it does not happen at least weekly, or does not take real time when it does, leave it.

6. When the process underneath is broken

Automating a broken process preserves it permanently and makes you do the wrong thing faster. It also makes it harder to fix, because now there is software depending on the bad shape.

Do instead: simplify the process first. Quite often that removes the need for the software entirely — which is a good outcome, even though nobody gets to announce it.

7. When the real problem is your data

If records are duplicated, out of date or inconsistent, an AI layer on top will produce confident answers from bad inputs. You will have made the data problem less visible rather than smaller.

Fix the data first. Often that is the project — and it is usually ordinary software, not AI. For Yeppe, the valuable work was making contact data self-maintaining; AI handles only the pages that defeat ordinary parsing.

8. When it is customer-facing and unreviewed

Generated text going straight to customers, with no one reading it first, is a reputational risk that very rarely justifies the saving.

Use it for the draft. Keep the human on the send button.

A useful question to end on

Before building an AI feature, ask: if this worked perfectly, what would change?

If the answer is vague — “we’d be more efficient”, “we’d be using AI” — it is not a project yet. If it is specific — “nobody would re-type invoice totals again” — you have something worth scoping.

Still weighing it up? Should I use AI in my business? covers the other side of the decision, and the Digital Opportunity Scan will tell you where software of any kind might help — often the answer is not AI at all.