When Not to Use AI
Most of the value in an AI programme comes from choosing the right problems. Here are the shapes where it reliably disappoints, and what to reach for instead.
When the rule is already known
If a problem can be stated as a rule someone can write down, write the rule. A model asked to apply a policy will apply it almost always, and "almost always" is a much worse property than a conditional that is correct every time and can be read by an auditor.
This is the single most common misapplication we see: a deterministic decision dressed up as an AI feature because the label is fashionable. It costs more per call, fails less predictably, and is harder to explain to whoever asks why an outcome happened.
Reach for a model when the input is unstructured or the rule genuinely cannot be enumerated — not when writing the rule is merely tedious.
When you cannot tell whether the output was right
The systems that work have a signal that closes the loop: a test passes, a schema validates, a downstream step succeeds. Where the output is open-ended and correctness is a matter of judgement, there is nothing to correct against and quality drifts without anyone noticing.
Before building, answer how you will know it worked, in a form a machine or a reviewer can check. If the honest answer is that someone will eyeball it occasionally, scope the feature to a size where eyeballing it is realistic.
This is also the practical test for autonomy: a system that cannot distinguish done from not-done should not be running unattended.
When a mistake is expensive and invisible
Risk is not just severity — it is severity multiplied by how long a mistake goes unnoticed. A wrong answer a user immediately recognises is cheap. A plausible wrong answer that silently enters a record and is trusted later is not.
Applications where errors surface immediately are good early candidates. Applications where an error quietly propagates deserve a human checkpoint regardless of how good the model looks in evaluation.
Ask what happens on the worst day, not the average one.
When the data is not there yet
Retrieval only helps if the material exists, is current, and is written down somewhere the system can reach. A great deal of the knowledge teams want to expose lives in people’s heads or in threads nobody has consolidated.
In that situation the AI project is really a documentation project with an interface attached, and it is more honest and much cheaper to say so before the build than after the pilot disappoints.
The upside is that the documentation work has value on its own, which the pilot would not have had.
What to do instead
Narrow the problem until the success condition is checkable. A model that drafts a structured summary a person approves is more useful than one that autonomously decides, and it is shippable now.
Automate the gathering and organising of information; keep the judgement with a person where consequences are real. That division holds up across hiring, support, operations and code.
And be willing to conclude that the answer is a rule, a form, or better data. Choosing not to use AI on a problem is a legitimate outcome of evaluating it, and teams that can reach that conclusion tend to get more out of the projects they do run.
Related Reading
AI-Powered Hiring in 2026: What Actually Works
Beyond the hype — a grounded look at where AI genuinely improves hiring outcomes, and where human judgement still wins.
Read articleDigital MarketingSEO and AEO Are Not the Same Job
They share tooling and get sold together, but they optimise for different outcomes — a click versus a citation. Treating them as one job is why teams rank well and still go unmentioned.
Read articleDigital MarketingAnswer Engine Optimization: Getting Your Brand Cited by AI Assistants
Search is turning into answers. A practical guide to AEO — making your content the source that ChatGPT, Perplexity, and Google AI Overviews quote.
Read article