Library
Automation vs AI: A Decision Framework
A rule, a model, and a person are three different tools. Use a rule when the path is stable and the answer is known. Use a model when the input varies and a person will still confirm. Leave it with a person when the volume is low, the judgement is high, or the failure is expensive.
Last reviewed
MikeFounder & developer
- Workflow
- AI governance
On this page
Who this is for
- Teams who have been told to “add AI” before the work was named
- Operators choosing between a glue job, a model, and leaving the step alone
- Readers of When Not to Automate who want the table, not the essay
Use this after the twelve questions
If you cannot name the core problem, do not open this page. Run the twelve questions first.
The framework
Ask, in order:
| Question | If yes | If no |
|---|---|---|
| 1. Is the path stable, with a known right answer (same input → same output)? | Plain automation: a rule, a template, an integration, a form that does not re-key. Stop. You do not need a model. | Go to 2. |
| 2. Does the input vary (language, layout, messy evidence) in a way a rule cannot cheaply catch? | A model may earn its keep, only if a person still confirms before anything lands. See Human Oversight by Design. | The variation is probably a training or process problem, not a software problem. |
| 3. Is the volume low, the judgement high, or the failure expensive? | Leave it with a person. Fix the file they look at (one place, less re-keying). Do not automate the judgement. | A model-plus-confirm, or a rule, may still be right. Go back to 1 and 2 on the remaining steps. |
Worked through a single process, you will often split it: automate the re-key, model the draft, leave the credit decision with a named human.
A short picture
Named the core problem? --no--> Stop. Twelve questions first.
|
yes
v
Same input, same output? --yes--> Rule / integration / template.
|
no
v
Messy input, useful draft? --yes--> Model + confirm. Never auto-send.
|
no
v
Low volume / high judgement / expensive failure? --yes--> Person. Leave it.
|
no
v
Split the process. Repeat per step.
What each choice is for
Plain automation. Moving a fact that is already true from system A to system B. Generating a PDF from fields you already trust. A scheduled export. This is most of the wasted money in “AI projects”.
AI (a model). Classification, drafting, transcription, extraction from messy documents, where a person will check. The model is a junior who never sends.
Human judgement. Credit on a new supplier. A safeguarding call. Publishing a rate that will hit every channel. A hiring yes/no. The when not to automate post is the argument for keeping these.
What this is not
This is a picker, not a maturity model or a score. If two steps want two answers, that is a good outcome.
If the step takes a significant decision about a person, read UK ADM or GDPR Article 22 before you remove the human. The framework will often tell you to keep them anyway.
Questions
The vendor demo classified our emails perfectly. Does that skip step 1?
No. A demo on yesterday's happy path does not answer whether the path is stable, or who confirms. Ask what happens to the 4% that are wrong, at 4pm, with the usual person away.
Can we automate the confirm step later?
That is how auto-send happens. If you need the confirm step to be legal or safe, it is not a phase.
Where does “custom build” sit?
After you know which of the three you are building. A custom tool can be a rule, a model-plus-confirm, or a better file for a person. The build is not a fourth category.
What changed
- 13 August 2026: First publication. Cadence: stable / evergreen (180–365 days). Next review due 13 May 2027.
When you want this applied to a live process, see Workflow auditing.
Was this helpful?
Also in the library
- The AI Vendor Risk ChecklistA procurement list you can actually use. Data handling, training-on-your-data, sub-processors, audit rights, and model-change notifications: the clauses that decide whether a vendor is safe to put on a live path.
- Building an AI System InventoryStart with a list. Most governance programmes stall because nobody has an honest register of what is already in use, including the vendor copilots people forget to mention. The sheet below is the one we use in an audit. Copy it.
- What Counts as High-Risk Under Annex IIIAnnex III is a use-case list, not a model list. Most Lathestone clients who over-classify do it because the tool is 'AI'; most who under-classify miss internal HR and customer-decision systems. Article 6(3) exemptions exist. They are narrow, and profiling is not one of them.