AI or ordinary automation? Match the tool to the problem

There is enormous pressure right now to have an AI answer to everything, and it produces a specific and expensive mistake: applying a probabilistic tool to a problem that was already solved deterministically, then spending months trying to make it reliable.

The distinction that matters is not how advanced the technology is. It is whether the task has one correct answer.

Problems with one right answer

Routing a lead by postcode. Calculating a price from a rate card. Moving a record between two systems. Sending a reminder two days before an appointment. Each of these has exactly one correct output for a given input, and the rules are fully knowable.

Use ordinary automation. It will be right every time, cost almost nothing to run, fail loudly rather than silently, and be explainable to an auditor. A language model doing the same job is slower, more expensive, occasionally wrong, and much harder to debug — you have taken a solved problem and made it probabilistic.

Problems where AI genuinely earns its place

The tasks worth pointing a model at share one property: the input is unstructured and the rules cannot be enumerated in advance.

• Understanding what a caller wants when they describe it in their own words
• Summarising a long email thread into what changed and what is needed
• Extracting structured fields from documents that arrive in twenty different layouts
• Answering the long tail of questions where each is rare but collectively they are constant
• Classifying free text where the categories are fuzzy and overlapping

Note what these have in common: the task was previously done by a person reading something, and no rule set would have covered it. That is the actual signal.

The design decision that determines whether it works

Most AI automation that fails in production does so for one reason: it was given authority to act rather than authority to prepare.

A model that classifies an enquiry and drafts a reply for a person to send is useful at ninety per cent accuracy, because the person catches the tenth case as part of work they were doing anyway. The same model sending that reply unsupervised is a liability at ninety per cent, because one in ten customers receives something wrong and nobody knows.

The practical version of this is a hybrid: the model handles the understanding, deterministic code handles the doing. It interprets "can someone come out about a leak, ideally Thursday" — that is the unstructured part — and then ordinary automation checks the calendar, applies your booking rules and writes the record. Neither component is asked to do the thing it is bad at.

Before you commit budget

• Write down the rule. If you can, you do not need a model.
• Decide the acceptable error rate, then who catches errors — if the answer is nobody, redesign it.
• Check the volume. Judgement-heavy, low-volume tasks rarely repay the setup.
• Confirm you can measure accuracy in production, not just in a demo.
• Make sure it says "I do not know" rather than inventing an answer.

That last point is not a technical detail. An automation that confidently invents an answer to a customer question causes more damage than one that escalates, and the difference is a design decision made early rather than a model capability.

This is the thinking behind AI & Intelligent Automation.