The direct answer
A process should not be automated if any one of these is true: nobody owns it, the rules change more often than the build would last, the input arrives in a different shape each time, an error is expensive to undo, or it simply does not run often enough to repay the maintenance.
That list is unglamorous, and it is most of the decision. The statistics usually wheeled out to justify automation caution add nothing to it, and most of them fall apart the moment you follow their sources.
The failure statistics do not survive checking
If you have read anything about AI projects failing, you have met one of four numbers. All four are weaker than they look, and they are weak in interestingly different ways.
“Gartner says 85% of AI projects fail.” Gartner said something else. The line comes from a press release dated 13 February 2018, and the actual wording is:
“Gartner predicts that through 2022, 85 percent of AI projects will deliver erroneous outcomes due to bias in data, algorithms or the teams responsible for managing them.”
It is a prediction. What it predicts is erroneous outcomes, not failed projects. And the window it covers, “through 2022”, closed four years ago with no published retrospective.
“RAND found that more than 80% of AI projects fail.” RAND’s 2024 report does contain that sentence, and it is worth reading closely:
“By some estimates, more than 80 percent of AI projects fail”, which the report puts at “twice the rate of failure for information technology projects that do not involve AI.”
“By some estimates” carries a footnote. The footnote points to a Fortune article from July 2022, whose only relevant sentence is that “business leaders have put the failure rate of A.I. projects at between 83% and 92%.” No survey is named. The article is a profile of the chief executive of an AI vendor. So the chain runs: RAND cites a magazine profile, which cites unnamed surveys of executive opinion. The institutional authority is entirely borrowed.
“87% of data science projects never reach production.” This traces to a 2019 VentureBeat post tagged Sponsored, reporting an off-hand remark from a conference panel. No study, survey or dataset is named anywhere in it. The 87% is simply the complement of the body’s 13%, and that body sentence does not hold together either. “Only 13% of data science projects, or just one out of every 10” describes 13% and 10% as the same number. A figure that has been repeated for seven years cannot survive its own sentence.
“70% of change programmes fail.” This is the ancestor of the others, and it was dismantled in a peer-reviewed journal fifteen years ago. Hughes (2011) traced five separate published instances of the claim and concluded:
“whilst the existence of a popular narrative of 70 percent organizational change failure is acknowledged, there is no valid and reliable empirical evidence to support such a narrative.”
The mechanism that produced the 70% figure is producing the AI ones now. The practical consequence is what matters here. If you decide against automating something because 85% of projects fail, you have made a real decision on a number that does not mean what you think it means.
What the evidence does support
Strip out the laundered percentages and a smaller, more useful body of evidence remains.
The constraint is process and people, not algorithms. BCG surveyed 1,000 executives across 59 countries in 2024 and found 74% of companies had yet to show tangible value from AI. Its breakdown of where the difficulty sits is the useful part: roughly 70% people and process, 20% technology, 10% the AI algorithms themselves.
Gartner’s own later predictions are worth reading the same way. Its June 2025 release forecasts that over 40% of agentic AI projects will be cancelled by the end of 2027. The reason given alongside the percentage carries more than the percentage does: “many use cases positioned as agentic today don’t require agentic implementations”. That is a selection problem.
Scaling is slow. Deloitte’s annual RPA surveys are often quoted as “only 3% of programmes scale”. The 3% is real and comes from the 2017 survey wave, but the trend line across the following waves is the story: 3%, then 4%, then 8%, then 13% of respondents running automation at scale. That is slow maturation. The frozen figure is also eight years old now, and Deloitte’s own later waves contradict it.
Stability is a hard precondition. The Process Mining Manifesto, written by the IEEE Task Force on Process Mining, describes a maturity model whose higher stages involve prediction, recommendation and intervention, which is the work automation does. Its constraint is blunt:
“Stages 3 and 4 can only be reached if the process is sufficiently stable and structured.”
Low error tolerance is a named failure factor. Schlegel, Schuler and Westenberger (2023) derived twelve failure factors from expert interviews. Under use case related issues they list missing value, complexity, and low error tolerance, meaning a process where mistakes are expensive. That is a property of the use case, and it settles selection before anyone picks a technology.
UK public bodies report the same barriers. The National Audit Office surveyed 89 government bodies in 2023 with a 98% response rate. Only 21% had an AI strategy, and limited access to good-quality data was reported as a barrier to implementation. Its conclusion generalises well beyond government:
“Achieving large-scale benefits is likely to require not just adoption of new technology but significant changes in business processes and corresponding workforce changes.”
Government guidance says out loud that sometimes the answer is no. The UK Government’s AI Playbook carries a section titled “Use cases to avoid”, and states in its principles:
“you should also be open to the conclusion that, sometimes, AI is not the best solution for your problem: it may be more easily solved with more established technologies.”
The eight factors
These are the qualifying questions asked before anything is scored. The scoring model itself is published on the readiness assessment page, and the two do different jobs. Both are public, so here is how they relate.
| Factor below | Role in the published seven-factor score |
|---|---|
| 1. Process clarity | Not scored directly. Failure caps input consistency at 2 and routes the workflow to fix-the-process-first |
| 2. Frequency | Scored, opportunity |
| 3. Reversibility | Scored, caution (error reversibility) |
| 4. Data quality | Scored, opportunity (input consistency) |
| 5. Decision risk | Scored, caution (output sensitivity) |
| 6. Exception rate | Not scored. Evidence check, gathered from the last fifty runs |
| 7. Ownership | The named-owner gate |
| 8. Observability | Not scored. Readiness check before a build is agreed |
The seven-factor score also carries two factors this screen does not ask about. Time per run and people involved are measured from the recording rather than answered in conversation. Factors 1, 6, 7 and 8 sit outside the score as gates, caps and evidence checks. The other four map onto scored factors.
| # | Factor | The question | Fails when |
|---|---|---|---|
| 1 | Process clarity | Can two people who do this task describe the same steps in the same order? | They cannot, or there is no written version and no agreement |
| 2 | Frequency | How often does it actually run? | Rarely enough that a year of maintenance costs more than the time saved |
| 3 | Reversibility | If it does the wrong thing, how hard is that to undo? | The mistake reaches a customer, a payment, or an external record |
| 4 | Data quality | Does the input arrive in a consistent, complete shape? | Required fields are frequently empty, or every run needs manual repair |
| 5 | Decision risk | Does a step commit the business to something? | A price, a legal position, an eligibility decision or a rejection |
| 6 | Exception rate | What share of runs need a human to intervene? | Exceptions are the norm rather than the tail |
| 7 | Ownership | Who is responsible after handover, by name? | Nobody, or “the team” |
| 8 | Observability | If it silently stopped, how long until anyone noticed? | Nobody would notice until a customer complained |
1. Process clarity, the first thing to establish
Ask two people who do the task to describe it separately. If the descriptions differ in ordering, in what counts as done, or in what happens to the awkward cases, the process does not yet exist in a form that can be automated. What exists is two processes with one name.
This is what the Process Mining Manifesto means by “sufficiently stable and structured”. Automating an unstable process freezes one version of it, hides the disagreement, and makes the disagreement expensive to discover later.
What to do instead. Write it down, agree it, run it manually for a month. Then reconsider.
2. Frequency, where irritation gets mistaken for cost
The tasks people most want automated are the ones they find most annoying, which is a poor guide. A task that runs quarterly and takes forty minutes costs under three hours a year. A build plus its maintenance will not repay that.
RAND’s practitioner interviews put a usable threshold on this. If a project is not worth a year of committed effort, it is most likely not worth committing to at all. The commercial version for a smaller build is simpler. An automation that takes longer to build and maintain than the work it removes over two years is a hobby.
What to do instead. Take the time from a screen recording. People overestimate the duration of tasks they dislike and forget the searching and waiting entirely.
3. Reversibility, the factor that changes the design
This is where NIST’s framework is more useful than any vendor material. The AI Risk Management Framework requires, under MANAGE 2.4, that mechanisms exist
“to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use”
and under MEASURE 2.6 that a deployed system “can fail safely, particularly if made to operate beyond its knowledge limits”.
In practice, ask what the worst plausible wrong output does. Filing a document in the wrong folder is a nuisance someone fixes in a minute. Sending a quote with the wrong price is a commercial position you may have to honour. Those two belong in different categories regardless of how similar the workflow looks. What changes between them is the design of the automation, and specifically where a person sits in it.
What to do instead. Split the process. Automate up to the point of commitment and leave the commitment with a person. Draft the quote; do not send it.
4. Data quality, the failure that surfaces late
Gartner’s February 2025 survey of 1,203 data management leaders found 63% of organisations either did not have, or were unsure whether they had, the data management practices needed for AI. Its related prediction is usually quoted with a clause dropped. Through 2026, organisations will abandon 60% of AI projects unsupported by AI-ready data, and that qualifier carries the whole prediction.
The test is concrete. Export a hundred records. Count how many carry the fields the automation would need to make a decision. If the field it would branch on is blank on most of them, the branch cannot exist, however sensible it looked on a whiteboard.
What to do instead. Fix the intake first. Replacing a free-text request with a form that has required fields is often a small piece of work that removes most of the branching the later build would otherwise carry.
5. Decision risk, separating preparation from commitment
Almost every process contains both. The preparation is assembling information, drafting, formatting, routing. The commitment is the moment something becomes binding: a price, an approval, a rejection, an eligibility decision.
The UK Government AI Playbook is unusually direct about which of those to leave alone, listing among use cases to avoid:
“fully automated decision making: be cautious about any use case involving significant decisions, such as those involving someone’s health or safety”
and
“high-risk or high-impact applications: AI should not be used on its own in high-risk areas which could cause harm to someone’s health, safety, fundamental rights or the environment”
“Keep a human in the loop everywhere” is a slogan standing in for a design. NIST is explicit that oversight should be proportionate:
“Some AI systems may not require human oversight, such as models used to improve video compression. Other systems may specifically require human oversight.”
What to do instead. Draw the line at the commitment, put the approval there, and automate everything up to it.
6. Exception rate, the number nobody measures first
If one run in twenty needs a person, the automation handles the nineteen and the person handles the one. If one run in three needs a person, you have built a system that mostly generates work for somebody to check, plus a new system to maintain.
The exception rate is knowable before you build. Take the last fifty runs and count how many departed from the standard path. If nobody can tell you, that is itself a finding, and it points straight back at factor 1.
What to do instead. Automate the majority path only, and route everything else to a queue with a named owner. Do not attempt to encode the exceptions in the first build; they are where the rules turn out to be undocumented.
7. Ownership, the gate
An automation with no named owner fails silently. An upstream system changes a field, the sync stops, and nobody notices until a customer asks why they never heard back. “The team owns it” means nobody owns it.
In our own model this is a gate. Whatever a process scores on the other seven factors, it is not built without a named person who knows they are the named person.
What to do instead. Name the owner before the build rather than at handover, and confirm they know.
8. Observability, how you find out it stopped
It will break. What decides the damage is the gap between breaking and somebody knowing.
The practical minimum is a throughput expectation and an alert when reality departs from it. If a form-to-CRM path normally carries around forty records a week and a whole working day passes with none, that is worth an alert. It catches a trigger that quietly stopped firing, a failure mode that produces no errors at all.
What to do instead. If you cannot describe how you would notice a silent failure, the process is not ready, however well it scores elsewhere.
Three processes, three answers
Illustrative, built from workflows we run inside our own company.
| Website enquiry to CRM | Monthly board report | Customer refund decision | |
|---|---|---|---|
| Process clarity | High. One path, documented | Medium. One person knows the order | High. Policy is written |
| Frequency | ~40/week | 12/year | ~15/week |
| Reversibility | Easy. Delete the record | Easy. Regenerate | Hard. Money has moved |
| Data quality | Good. Form has required fields | Poor. Four exports, columns shift | Good |
| Decision risk | Low. No commitment | Low. Internal | High. Binding on the business |
| Exception rate | ~1 in 20 | ~1 in 3 (manual repair most months) | ~1 in 10 |
| Ownership | Named | Named | Named |
| Observability | Throughput alert possible | Would be noticed immediately | Would be noticed immediately |
| Verdict | Build it | Fix the inputs first | Automate the preparation only |
The refund case is the one people argue about. Assembling the evidence, checking the policy conditions and preparing a recommendation are all automatable. Pressing the button that moves money stays with a person.
What this framework does not do
It produces no savings figure. The eight factors tell you whether a process is a candidate. What changing it is worth is a separate question, and a percentage offered before anyone has watched the work is arithmetic borrowed from a different company.
It says nothing about whether the change will stick. That depends on decisions made outside the process itself, by the people who manage it, and no scoring model reaches them.
It does not remove the need to test. A process can pass all eight factors and still fail on contact with the real data, which is why a first build should run alongside the manual method until the output has been checked on every run for a month.
What it comes down to
The case for caution has nothing to do with the 85% figure. It rests on a specific, knowable set of conditions that make a process unsuitable, and most of those conditions are visible before anybody writes code, in a screen recording, a hundred exported records, and the answer to “who owns this?”
An AI readiness assessment does that work. This screen is applied to your real workflows, the published seven-factor score is applied to whatever clears the gates, and the ones that fail are written down as failing with the reason recorded. Where processes do pass, how they get built is a separate question, and the worked examples by department show the shape of the result.
A shorter list than the one you started with is a perfectly good outcome, and often the most valuable one.