Automation and AI Assistance Are Not the Same Thing

Automation and AI tend to arrive in the same sentence, which makes them sound like one decision. They are not. They solve different kinds of problem, they fail in different ways, and the work of separating them is usually what makes the rest of the conversation productive.

Most processes contain three kinds of step, and it is worth telling them apart before any tool is chosen.

Rule-based automation

The first kind is deterministic. If X happens, do Y. It applies wherever both the condition and the response can be written down in advance.

• routing a request to the right team or queue
• notifying someone when a record reaches a particular state
• assigning ownership based on region, value or type
• running a scheduled action, such as a reminder, a recurring report or a status change
• validating that required information is present before work continues
• moving a record to the next step once its conditions are met

What makes this category valuable is that it is predictable. The same input produces the same result every time, the logic can be read by a person, and when something behaves unexpectedly the reason is findable. A large share of the work people describe as “admin” lives here. It is unglamorous, and it is often the highest-value thing to fix first.

The limitation is just as clear. The rule has to be written, and anything it did not anticipate falls through to a person — which is fine, as long as the process expects that and someone is watching the exceptions.

AI assistance

The second kind does not reduce to a rule, because it involves reading, interpreting or organising something that arrives in an unpredictable shape.

• summarising a long thread, document or record history so somebody can pick it up quickly
• categorising information that arrives as free text
• organising context, by gathering what is already known about a customer, a case or a request into one view
• preparing a draft or a working document for a person to review
• identifying patterns across a set of records that would take a long time to read manually

The important word in all of those is assistance. The output is an input to somebody’s work. A summary is a starting point rather than a decision. A suggested category can be wrong, which means something has to be able to correct it. A prepared draft exists to save the first ten minutes, not to remove the review.

That framing also gives a practical test for evaluation. The question is not whether the output looks impressive, but whether a person can check it quickly. Work where verifying the result takes as long as doing it yourself is a poor candidate, however capable the tool.

Human judgment

The third kind should stay explicitly with people, and naming it is what keeps the other two honest.

• approvals, particularly where money, commitment or risk is involved
• exceptions, meaning the cases the process did not plan for, which are frequently the ones that matter most
• anything carrying a compliance, legal or contractual consequence
• decisions somebody has to be accountable for afterwards

A process design that cannot say where its human checkpoints are has not been finished. The useful goal is not to reduce the number of decisions a person makes. It is to make sure the person reaches each one with the context already assembled.

Working out which is which

Take one process and describe it as a sequence of steps in plain language, without naming any software. Then ask what each step actually requires.

• Can the condition and the response both be stated in advance? That step is a candidate for a rule.
• Does the step involve reading something unstructured and turning it into something usable? That is where assistance may help, with a person reviewing the result.
• Does the step commit the business to something? That one stays with a person, and the steps around it should make it faster to reach rather than being automated past.

Two conclusions usually come out of this, and they pull in opposite directions.

Not every process needs AI. A large proportion of routine operational work is deterministic, and deterministic work is better served by a rule that behaves identically every time than by anything that has to be checked.

Not every process should stay manual either. Work that is repeated, rule-shaped and predictable does not become more reliable because a person does it. It becomes slower, and it becomes the first thing skipped when the day gets busy.

Start from the workflow

The common failure is choosing a capability first and then looking for somewhere to apply it. That produces change in the places that were easiest to change, rather than the places that were costing the most.

Starting from the workflow gives a different answer. Map the steps, mark which of the three kinds each one belongs to, then decide what to alter. The highest-value change is often unremarkable: a routing rule, a validation, or one notification that stops a request sitting unnoticed for two days.