Anti-Automation: The Tasks You Should Never Automate

In a 2016 EY analysis, 30 to 50 percent of initial robotic process automation projects failed to deliver as planned (EY, Get Ready for Robots). That number points at something most automation guides skip: the tasks you should never automate. Plenty of work is repetitive, reversible, and safe to hand off. But some work is high judgment and hard to undo, and automating it quietly removes the one person who would have caught the exception.

I have written before about the parts of this that are comfortable: automation maintenance is the real job, and there is a clear line for when to automate and when to hire. This is the other half. Not everything that can be automated should be, and knowing which is which is an operations skill, not a technology one.

What actually makes a task safe to automate?

Automation earns its keep on work that is repetitive, well defined, high volume, and reversible. If a rule can describe the task completely, and a wrong output can be undone without lasting harm, a machine will do it faster and more consistently than a person will.

The trouble starts when businesses treat every task as if it were that kind of task. A Deloitte survey of global firms found that 63 percent did not meet delivery deadlines on their RPA projects, often because they mistook complex, judgment heavy processes for simple, rules based ones (Deloitte Global RPA Survey).

So the first question is never "can this be automated." Almost anything can be, badly. The real question is whether the task belongs to the safe category at all.

Which are the tasks you should never automate?

A short list holds up across almost every business. These are the tasks you should never automate, or at least never automate without a human explicitly in the loop.

High judgment calls, where the right answer depends on context a rule cannot see. Irreversible decisions, where a wrong output cannot be pulled back: deleting data, sending money, terminating an account. Relationship and trust moments, like a hard conversation with a client or a hire, where the point is that a person showed up.

Edge case handling, where the whole value is recognizing that this instance does not fit the pattern. And anything where a silent failure is catastrophic, meaning the system can be wrong for a long time before anyone notices. This is where I stay conservative, the same instinct behind what I stopped outsourcing even when a vendor could technically do it.

Why does automating judgment hide accountability?

The deepest reason to keep these tasks human is not sentiment. It is a documented pattern. In her 1983 paper "Ironies of Automation," researcher Lisanne Bainbridge showed that automating most of a job leaves the human responsible only for the rare, hard interventions, while stripping away the routine practice that kept them sharp for exactly those moments (Bainbridge, Automatica, 1983).

It gets worse when the automation is good. A 2010 review in Human Factors found that automation complacency and automation bias appear in both novices and experts, cannot be trained away, and lead people to miss errors precisely because the system usually works (Parasuraman and Manzey, 2010). The better the bot, the less anyone watches it.

Aviation learned this the expensive way. The FAA's 2013 review of flight path management found pilots sometimes rely too much on automated systems and grow reluctant to intervene, with over 60 percent of reviewed accidents involving a manual handling error (FAA Flight Deck Automation findings).

A four part test: reversibility, frequency, judgment, blast radius

You do not need a framework to feel when a task is risky, but a simple test makes the call defensible. Run any candidate through four questions before you automate it.

Reversibility: if the output is wrong, can you undo it cheaply? Frequency: does this happen often enough that a rule is worth building and maintaining? Judgment: could a competent person disagree about the right answer? Blast radius: if it fails silently for a week, how far does the damage spread?

High frequency, high reversibility, low judgment, small blast radius is green. Automate it and move on. The opposite corner, rare and irreversible and judgment heavy with a wide blast radius, is where automation quietly removes the human who would have caught the problem. That is the same reasoning behind knowing that the hire you think you need is often a tool, and knowing when it is emphatically not.

Human in the loop without slowing everything down

Keeping these tasks human does not mean doing everything by hand. It means designing the automation so a person owns the decision even when a machine does the work around it.

In practice that looks like a few habits. Automate the preparation, not the commit: let the system draft, gather, and stage, then require a human to approve the irreversible step. Make the exception loud, so an edge case surfaces to a person instead of being silently forced into the nearest pattern. And keep an audit trail, so you can audit what the automation is actually doing rather than assuming.

This matters even more as AI agents take on real work. The gap between an agent that runs at 3am and one that only demos well is almost entirely about how it handles the cases nobody scripted. Delegating a capability to a system is fine, but stay clear eyed about the moment that capability becomes theirs and the accountability moves with it.

None of this is anti automation. It is how we build managed operations at LTFI: automate aggressively where the work is repetitive and reversible, and keep a person on the calls where a silent failure would cost more than the automation ever saved.

Related reading

• When to Automate and When to Hire
• Automation Maintenance Is the Job, Not the Launch
• What I Stopped Outsourcing (and What I'll Never Build In-House)
• AI Agents That Run at 3am vs. AI Agents That Demo Well
• AI Capability Transfer: The Moment It Becomes Theirs

Frequently Asked Questions

What are the tasks you should never automate?

High judgment calls, irreversible decisions like moving money or deleting data, relationship and trust moments, edge case handling, and anything where a silent failure would be catastrophic. These are the tasks you should never automate without a human explicitly owning the decision, because the automation removes the person who would catch the exception.

How do I know if a task is safe to automate?

Run it through four questions: is the output reversible, does it happen often, could a competent person disagree about the right answer, and how far would the damage spread if it failed silently. High frequency and high reversibility with low judgment and a small blast radius is safe. The opposite corner is not.

Does keeping a human in the loop defeat the point of automation?

No. You automate the preparation and staging, then require a person to approve the irreversible commit. The machine still does the volume of work. A human only owns the small number of decisions where being wrong is expensive or permanent, which is where their attention was always most valuable.

Why do good automations make people less careful?

A 2010 Human Factors review found that when a system usually works, both novices and experts stop watching it closely, a pattern called automation complacency that training cannot fully remove. The more reliable the automation, the fewer people monitor it, so failures in the rare cases go unnoticed longer.