Automation or AI: how to decide

When the subject is making work easier, two things get conflated. Automation and AI promise the same outcome: that the work happens without a person. But they deliver different things, and confusing them tends to become visible only after something has already gone wrong.

In short

• Automation is deterministic: the same input gives the same result, and it can be reconstructed and explained.
• AI is probabilistic: the output is a likely answer, and a mistake looks exactly as convincing as a correct one.
• If the rule can be written down, write the rule. It is cheaper, verifiable, and needs no accuracy measurement.
• AI fits where the decision depends on free-form content and where a mistake is recoverable.
• AI does not fit calculations and totals: a result can look right without having been computed.

One question that almost always answers it

Try writing the decision rule as conditions. Not describing it — writing it: if this, then that; if not, then something else. If that works, you need automation. If the description keeps slipping into "it depends", "usually", and "a person can see it immediately", you need judgement, and judgement is AI territory.

In practice the most common discovery is a third one: the rule cannot be written not because the task is complex but because the company never agreed on it. Then neither automation nor AI is the answer — the answer is an agreement.

The nature of the error, not its probability

It is normal to ask how often a system gets things wrong. It is more useful to ask what a mistake looks like. An automation error is usually loud: the process stops, somebody does not get a reply, a line appears in an error log. An AI error is quiet: you receive a tidy, precisely worded answer that is wrong. A quiet error is noticed only by whoever checks.

So "can we automate this" often needs replacing with "who will notice if it is wrong". Without an answer, the solution cannot yet be used without review — whichever technology was chosen.

Where the line falls in practice

• Moving data between systems by defined rules — automation.
• Sorting incoming documents by content when the formats vary widely — AI with human review.
• Calculating invoice totals — automation. Never AI.
• Routing free-form enquiries to the right department — AI, if a mistake is easy to correct.
• Sending confirmation emails when something happens — automation.
• Drafting a customer reply that a person reads before sending — AI.

The best answer is usually both

A common and effective split: AI prepares a suggestion, a rule checks it and carries out the action. Document data is extracted by judgement, then a rule checks that the total matches the order, and only then does the record reach accounting. Uncertainty stays where it can be reviewed, and the action stays verifiable.

This combination usually costs less than an AI-only solution, because the accuracy requirement drops: the model no longer has to be right every time, only right often enough, with the rule catching the rest.

What proposals usually leave out

• Who will measure accuracy, and against which examples. Without your real cases, accuracy is a demonstration rather than a metric.
• Where the data goes and who can see it. This matters even when the data is not personal data.
• What happens when the solution does not know. The correct behaviour is to say so, not to fill the gap with a guess.
• Who will be able to change rules or settings after handover.
• How the process is returned to manual if it has to be.

Illustrative scenario, not a description of a client project

Imagine a company deciding to handle incoming email orders with AI: read the message, identify the products, create the order. It works well until one customer writes more loosely and a quantity is read incorrectly. The order is created, looks tidy, and nobody makes a visible mistake. The better design was different: use judgement to prepare a draft, and check the quantity and total with a rule before writing anything. This is an example of how we weigh the boundary, not a promise about accuracy.

What to answer before starting

• Can the rule be written as conditions? If yes — automation.
• Which errors are recoverable, and which are unacceptable?
• Who will notice a wrong result, and how quickly?
• Do you have real examples to measure accuracy against?
• Is this step needed at all? Sometimes the right answer is to remove it rather than automate it.

That last question sounds flippant but frequently delivers the most value. Automated unnecessary work is still unnecessary; it is merely no longer visible.