Decision Automation

What Decision Automation is

Decision automation is handing a call that carries judgement to a system. Which candidate gets a callback, which claim is flagged as fraud and which client gets an exception to a policy are all examples. The system does not only do work, it settles an outcome for someone.

The line that matters is between a decision and a task. A task can be checked against a right answer. A decision cannot, because it weighs factors that have no fixed answer. The task and decision article says a wrong decision costs something a checked task never costs, because a person somewhere has to explain the outcome. That is why automating a decision transfers accountability along with the work, and why it needs to be a deliberate choice and not a side effect of approving a project.

Why a Decision is not a task

The article gives plain examples of each. Formatting a report, pulling figures into a template and routing a ticket to the right queue are tasks. They have a standard to be checked against, and they are safe to hand over completely once the rules are set. Deciding which candidate gets a callback, which claim gets flagged and which client gets an exception are decisions. Getting one wrong is not fixed by checking the output, because the damage is to a person who has already been told the outcome.

The task automation page covers the other side of the line. The two are easy to blur because they usually sit in the same workflow, and a tool that does the task part very well can make the decision part feel equally safe.

Why Decisions hide inside a Process

“Automate the process” usually means a chain of tasks with one or two decisions buried inside it. The article gives an intake process as an example: collect the form, check it against a list, flag anything unusual and decide what happens next. The first two steps are tasks. The third may be a task if the rules are genuinely fixed, or it may be the decision the whole process exists to make.

When the chain is approved as one block, a business ends up with a system quietly making calls nobody scoped it to make. The article says this is found only once a result looks wrong and somebody asks who signed it off. By then the decision has been running for some time, and the answer to “who signed it off” is often that nobody did, because nobody saw it as a decision.

What the Accuracy figures say

The article gives figures for why the line matters, and they are not the site’s own measurement. It reports analysis compiled by SkillSeek that AI can automate up to 45% of work activities, while only 5% of jobs are fully automatable. The article reads the gap between those two numbers as the task and decision distinction, not a rounding error.

On accuracy, it cites a meta-analysis through the same source. AI decision accuracy drops to around 65% in ambiguous, judgement-heavy situations, against roughly 85% for experienced humans on the same calls. On structured, data-rich predictions such as candidate shortlisting, AI reaches about 75 to 80%, against 85 to 90% for experienced people.

The article’s reading is careful. The second gap is close enough for the output to be a useful second opinion, ranking or flagging cases for a person to look at first. It is not close enough to hand the call over and stop checking it. Neither number is a verdict on the technology. They are the evidence for treating decisions and tasks as two different jobs, and for deciding how much authority to give. The accuracy gap page covers where AI trails experienced people.

The four levels of Authority

The article sorts work onto a four-level ladder, the delegation ladder. The levels are Assist, Recommend, Execute and Never delegate.

• Assist. AI drafts, gathers and compares options, and the person decides. It fits ambiguous, strategic calls.
• Recommend. AI ranks or suggests, and a person stays accountable. It fits structured, data-rich calls such as fraud alerts or shortlisting.
• Execute. AI acts inside clear rules without supervision. It fits high-volume, low-consequence, reversible steps.
• Never delegate. Hiring, dismissal and anything with legal, safety or rights implications. These stay human whatever the technology can do.

Decision automation, in the strict sense, is anything that moves a decision towards Execute. Assist and Recommend keep a person as the one who decides, which is why the article treats them as support and not as automation of the decision.

Which rung a Decision sits on

The rungs are not set by what the technology can attempt. They are set by five questions: how often the work happens, what a wrong outcome costs, whether it can be undone, how clear the governing rules already are, and whether the outcome needs a kind of legitimacy a model cannot hold.

The article’s pair of examples shows how this works. A password reset scores low on every risk factor and high on volume, so it sits at Execute. It is reversible in moments and governed by a rule with no ambiguity: the request either matches the account or it does not. Candidate shortlisting happens far less often, is harder to undo once a candidate has been told no, and is judged against criteria that are never perfectly fixed in advance. It stops at Recommend, one rung lower, because a person has to stay accountable however good the ranking is.

Both can be described as “deciding something about a request”. They land on different rungs for reasons that have nothing to do with which one the AI is capable of doing. The reversibility page covers the third question.

What always stays with a Person

Hiring, dismissal and anything with legal, safety or rights implications sit permanently at Never delegate. The article is firm on this: no amount of model capability moves them off that rung. A dismissal scores the opposite of a password reset on every factor that matters.

The reason is not that a system could never produce a plausible answer. It is that these outcomes carry enough consequence, and need enough legitimacy, that a person must be able to answer for them. Human in the loop describes the named reviewer who keeps that responsibility. The candidate shortlisting page shows a decision that is allowed to use AI and still stops short of handing the call over.

Assist and Recommend in practice

Keeping a decision at Assist or Recommend is not a half measure. The article says the return at those levels is a better-informed person making the call faster, not a person removed from the loop. The return is different from the one at Execute, and it takes longer to show.

That matters for how a project is judged. Expecting an Assist-level step to deliver Execute-level speed is a common reason a workflow gets called a disappointment when the real fault was in how it was scoped. The steps correctly sorted onto Execute deliver a fast, measurable return, because nobody second-guesses a step that never needed a person watching it. The decision steps return something else: better calls, made sooner, by someone who still answers for them.

How to find the Decisions in a Workflow

The practical use of the ladder is a scoping exercise. Every real AI workflow is a chain of steps, and each step belongs on its own rung. The intake may be Execute, the triage may be Recommend and the final call may be Assist at best, or Never delegate outright.

The article’s advice is to place each decision on the ladder at scoping, with a named reviewer built in from day one. It reports that projects stalling after a promising early test were disproportionately ones where a Recommend step had been treated as Execute once the demo looked good. Catching that at scoping costs an afternoon. Catching it after launch costs a rebuild, and sometimes an apology to whoever the wrong call affected. The well-scoped workflow page describes what a workflow looks like once every step has been sorted.

Governance and the EU AI Act

The article treats governance and workflow design as one subject. A written AI governance policy is, among other things, a record of which rung each automated process sits on and who signed off on putting it there. Without it, a business learns that a process crossed into Never delegate territory only after something goes wrong.

The legal backdrop makes the stakes concrete. The EU AI Act draws its own line around what counts as a high-risk AI system, and the categories it names, employment decisions among them, map closely onto the Never delegate rung. The article does not call that a coincidence. Both the law and the practical test answer the same question: which decisions carry enough consequence that no amount of model accuracy changes who must be accountable.

A worked example

An illustration, not a case study. A small recruitment team asks for AI on its application intake. On the first pass, the request is approved as one thing: “AI for intake”.

When someone lists the steps, the picture changes. Collecting the form and checking it against a list of required documents are tasks, and they move to Execute. Sorting applications into a likely order is a structured prediction, so it moves to Recommend, with a named person reviewing the ranking. Deciding who gets a callback is a hiring decision, so it stays at Never delegate.

The team writes down the rung for each step and who signed off on it. Months later a candidate asks why they were not called back. There is an answer, because a person made the call and the ranking was only one input. The same candidate asking under the first approval would have met a system nobody had scoped to decide, and a question nobody could answer.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is approving a whole process as one automation, when it hides decisions that each need a rung. The second is reading a good accuracy figure as permission to stop checking, when the article says a system can be useful as a second opinion and still not clear the bar for the call. The third is treating Assist and Recommend as failed automation, when the return there is a better-informed person deciding faster. The fourth is believing capability decides the rung, when the five questions about volume, cost, reversibility, rules and legitimacy do.

How we use it

The article’s advice is to place each decision on the delegation ladder at scoping, with a named reviewer, a human in the loop, built in from day one. It says a written AI governance policy records which rung each process sits on and who signed off on putting it there.

If you would like to talk through which steps in your own processes are decisions, a discovery call is a quick way to start.

Sources

• The difference between automating a task and automating a decision: the task and decision line, the 45% and 5% figures, the 65% against 85% and 75 to 80% against 85 to 90% accuracy figures (quoted from the analysis it cites), the four levels, the five questions, the password reset and shortlisting pair, Never delegate, a named reviewer, the governance record and the EU AI Act overlap.
• Task automation, Delegation ladder, Human in the loop, High-risk AI system, Reversibility, EU AI Act, AI governance, Accuracy gap, Candidate shortlisting, AI workflow and Well-scoped workflow: the neighbouring terms this page links to.