AI workflow automation: what to automate first, and what to leave alone

Published: 2026-10-29 · Updated: 2026-11-06

Most teams start AI workflow automation in the wrong place. They pick the process everybody complains about most, hand it to a model, and find out six weeks later that the process was never the problem. The work that pays back is the work that is frequent, rule-shaped and checkable, and finding it takes a filter rather than a model. This is the checklist we run before we write a scope for an EU operations, HR or back-office team.

What AI workflow automation actually is

AI workflow automation is the automation of a business process in which at least one step is handled by a language model rather than a fixed rule. The distinction matters, because much of what is sold under this name is not AI at all: it is a rule engine with a spreadsheet in the middle. A rule engine moves data from A to B when a condition is true. A workflow with an AI step does something a rule cannot do at all — it reads a free-text request, a contract or a scanned invoice, and works out what the next step should be.

The honest version has three parts, and a project missing one of them is usually in trouble.

1. A rule. Something deterministic decides what happens: a threshold, a routing table, a checklist. Rules carry the accountability, and they are the part you can test exhaustively.
2. A model step. A language model handles what no rule can: classification, extraction, drafting, summarisation. It proposes. It does not decide.
3. A human decision point. Where the outcome carries accountability — a price, an approval, a commitment to a customer — a named person confirms it, and the workflow waits for them.

Drop the third part and you have a liability rather than an automation. Skip the second and you have a rule engine with a misleading name. The third part is the one a buyer should insist on, because it is the difference between a system you can defend to a customer or a regulator and one you cannot.

The three-question filter

Before a process reaches a scope, it answers three questions. A candidate that fails any one of them is not an AI workflow automation candidate yet.

1. Is it frequent? If the manual cost does not repeat every week, the automation will not repay itself. Frequency is the only reason the numbers work, and it is the first thing to check because it costs nothing to check.
2. Is it rule-shaped? Can you write down the rule that decides what happens next? If nobody can state the rule, the process is not understood yet — and a model will hide that gap rather than close it.
3. Is the output checkable? Can a person look at the result and say yes or no in a second? If yes, the workflow can route the doubtful cases to a human and run unattended on the rest. If no, you do not have a process. You have a hope.

The third question is also what decides whether you need a model at all. It is the one teams skip, and skipping it is the reason so many automation projects end as a demo that nobody trusts in production.

Three workflows that usually qualify

Lead routing and follow-up

An inbound request arrives as free text. The workflow classifies it, routes it to the right owner, chases it, and stops the moment a reply lands. The rules decide the queue and the escalation; the model reads the message. It qualifies because the volume is weekly, because the routing criteria already exist in somebody’s head, and because the output — a routed request — is checkable at a glance.

Document intake and extraction

Contracts, invoices, forms and CVs arrive by e-mail or from a shared folder and are parsed into structured records. A deterministic parser handles the fields it is certain about, an extraction step handles the rest, and a human checks only the doubtful ones. It qualifies because the volume is daily, because the field list is a known schema, and because every extracted field can be compared against the source document.

Recurring reporting and internal alerts

Scheduled reports are assembled from the systems you already run and delivered where the team already reads them, and a number crossing an agreed threshold raises an alert instead of waiting for somebody to notice it moved. It qualifies because it runs on a timer, because the threshold is a number somebody chose, and because a wrong report is visible rather than silent.

What to leave to people

Automation earns its keep on rules, and judgement stays with people. Three kinds of work resist automation and should stay in a human role.

• Decisions that carry accountability. A refund, a discount, a contract commitment, a hiring decision. The workflow can prepare the decision and the evidence, but a named person makes it.
• Anything that needs a negotiation. A conversation with a customer or a supplier is not a rule, and pretending it is produces a workflow that fails in the worst moments.
• Work whose rules nobody can state out loud. If the process lives in the experience of one person, automate the steps around that person — the routing, the chasing, the reporting — and leave the judgement itself where it is.

What a fixed first milestone contains

One workflow, one metric, one out-of-scope list, written down and signed before any code ships. That is the whole unit. It is deliberately small, because the point of a first milestone is not to deliver the back office — it is to deliver one production-ready slice end to end, with monitoring and backups wired, and to find out whether the assumption behind the whole idea holds.

How we scope that unit, and what the fixed-price engagement around it looks like, is described on our AI workflow automation service page. A scope that names three workflows is not a first milestone; it is a proposal for a programme, and programmes without a stopping point are how automation projects lose their budget and their sponsor at the same time.

What drives the running cost

The build is one number and the running cost is another, and the second one surprises people. Four things drive it: the volume of model calls, the fraction of items a human has to review, the monitoring and backup work, and the maintenance that follows whenever a source system changes. None of them is exotic, and all of them are knowable before you sign anything. A supplier who cannot size them is guessing.

Ask for the running cost per month at a stated volume, and ask what happens to it when the volume doubles. The answer tells you whether the workflow is an asset or a growing bill.

Questions to ask before you sign

Six questions that separate a serious supplier from a slide deck.

1. Where does the data live, and in which region is it processed?
2. Who can read the data, and is every subprocessor named in public?
3. What happens when the model is unsure — who confirms, and what is written to the audit trail?
4. What does the first milestone contain, what is explicitly out of scope, and what is the success metric?
5. What is the running cost per month at our volume, and what happens when the volume doubles?
6. How is a backup restored, and when was that last rehearsed?

If a supplier cannot answer the third and the fourth question, they are selling a demo rather than an operating system. The process page is the version of this we run ourselves, the security page is the default posture we ship, and the trust index lists the artifacts a procurement or DPO team asks for.

Questions teams ask