When not to use AI

There is a question that decides more AI value than any model choice, and most programmes skip it: should we, rather than could we?

Could we is nearly always yes. Language models are general enough that you can point one at almost any task and get something back. That generality is exactly what makes could we a useless filter. Every process in an organisation passes it, which means it sorts nothing.

The four cheaper answers

Before a language model earns the work, four alternatives deserve a hearing.

Do nothing. Some constraints cost less to live with than to remove. This is a legitimate conclusion, and the reason it is rarely reached is social rather than analytical: nobody gets promoted for the initiative they declined to start. Writing it down — the constraint, the estimated cost of solving it, the decision to accept it — is what turns inaction from negligence into a choice.

Delete the step. If the manual approval exists because a system in 2009 could not hold state, the correct intervention is removal, not automation. Automating a step that should not exist makes it permanent, because now it has infrastructure.

Buy the thing that exists. A surprising share of “we need AI for this” is a configuration problem in software the organisation already owns.

Write the rule. This is the one I argue for most often and the one that gets dismissed fastest. If the rules are knowable and reasonably stable, deterministic automation beats a language model on every axis that matters in production: it is cheaper per unit, faster, auditable, testable, and it fails in ways you can enumerate in advance. A model that is right 94% of the time is worse than a rule that is right 100% of the time on the 80% of cases the rule covers — because you can route the remaining 20% deliberately, instead of discovering the 6% at random.

The place I keep meeting this in my own work is in what looks like model failure. Hardening an extraction pipeline after a run where most real cases failed, I found five root causes. Four were fixed with ordinary code — cleaning input before it reached the model, widening a truncated candidate set, decoupling a rule from an unreliable signal, protecting a field from being overwritten. One touched the model, and it was to make it less generative. Four out of five. That ratio is not a quirk of that system; it is what most “the AI is not good enough” investigations find when someone reads the intermediate state instead of the final answer.

Where a model genuinely wins

I am not arguing against language models. I use them daily, and there are shapes of problem where nothing else works:

• The input is genuinely unstructured or arbitrarily variable — free text, images, documents nobody standardised.
• The rules cannot be enumerated, either because there are too many or because they change faster than they can be written.
• A probabilistic answer with a known error profile is acceptable to the person receiving it.
• The work is currently not being done at all because it was never economic — and the alternative to imperfect coverage is no coverage.

That last one is the strongest case for AI and the most underused in business cases, because it does not show up as a saving against a current cost line.

Price the wrong answer

The number missing from almost every AI business case is the cost of an incorrect output.

It has three parts: detecting it (which sometimes never happens), repairing it, and the consequence of having acted on it. Once you put that number next to volume and error rate, some use cases invert immediately. A system that is 95% accurate over 10,000 monthly items produces 500 wrong outputs. If each costs an hour of senior time to catch and unwind, the automation has generated more work than it removed, and it has done so invisibly — because the failures are distributed and the saving is aggregated.

This is also why “we will keep a human in the loop” is not automatically a safe answer. If a person must verify every output, the task has not been automated; it has been converted from doing into checking, which is often slower and reliably more boring. Human-in-the-loop only works when the error rate is low enough, and known well enough, that sampling is defensible.

Speed is part of the answer

One argument that legitimately favours moving: how quickly it can reach production. A capability delivered in two or three months can hold an advantage that a perfect design landing in eighteen never catches. This cuts both ways — it argues for doing the tractable thing now, and against the platform rebuild that must finish before any value is allowed to appear.

What I would put on the table

For each candidate use case: the constraint, evidence it is real, the four cheaper alternatives with why each was rejected, the cost of a wrong output, the time to production, and whether it builds anything a competitor cannot buy next quarter.

The output of that exercise is a shortlist with explicit “no” and “not yet” entries. Those entries are the deliverable. Any advisor can produce a list of things AI could do; the value is in the shorter list of things it should.