The Honest Case Against Using AI Here

A recommendation nobody wants to hear

The most useful thing we sometimes say in a discovery workshop is that the problem in front of us does not need AI. It is not a popular answer when a budget has been allocated, but it is considerably cheaper than the alternative of finding out in month six.

This is not scepticism about the technology. It is a view that AI is a tool with a specific shape, and that using it where a simpler tool fits produces a system that costs more, breaks in less predictable ways, and is harder to explain when it is wrong.

Signals that AI is the wrong tool

• The rules are already written down. If the logic exists in a policy document, a rules engine will be faster, cheaper and fully explainable.
• The task is deterministic. A calculation with one correct answer does not benefit from a probabilistic system.
• Volume is low. A task performed twelve times a month rarely justifies the build, evaluation and monitoring cost.
• Being wrong is expensive and undetectable. If nobody will notice a wrong answer until it has caused harm, the threshold for automation is much higher.
• The underlying data is unreliable. AI amplifies the quality of what it reads. Fix the foundation first.
• The process itself is broken. Automating a bad workflow makes it faster at being bad.

The cheaper alternatives worth checking first

Before proposing an AI system, there are usually three cheaper options worth ruling out honestly.

• Remove the step. A surprising number of manual tasks exist because of a decision made years ago that no longer applies.
• A deterministic script. Forty lines of code, fully testable, with behaviour that does not drift between versions.
• A configuration change. The capability sometimes already exists in a system you own and pay for.

Where AI genuinely earns its place

The inverse of the list above describes where AI is the right answer: high-volume work, with rules that resist being written down, where language or unstructured content is involved, and where being approximately right quickly is more valuable than being exactly right slowly.

Document understanding, triage and routing, drafting from source material, and multi-step tasks that span several systems all fit that shape. In each case the value comes from handling variation that a rules engine cannot enumerate.

Key takeaways

• If the rules are already written, a rules engine beats a model.
• Low-volume tasks rarely repay the build and monitoring cost.
• Unreliable data underneath makes any AI output unreliable.
• Check three cheaper options first: remove, script, configure.
• AI fits variation that cannot be enumerated: language, documents, multi-step work.

Frequently asked questions

When is AI the wrong solution for a business problem?

When the rules are already documented, the task is deterministic, volume is low, or the underlying data is unreliable. In those cases a rules engine, a short script or a process change will be cheaper, faster and easier to explain.

What should we do before starting an AI project?

Measure the baseline (how the task performs today in time, cost and error rate) and map the full process. That usually reveals steps that can be removed entirely, which changes the scope of what needs automating at all.