Insights

Why AI automation projects fail inside otherwise healthy companies

By Darshan R Krishnan · 28 July 2026 · 7 min read

There's a particular kind of failure I've watched enough times to recognise the shape of it early.

A company decides to automate something. The scoping is reasonable. The build goes fine — no heroics needed, delivered close to schedule. It gets deployed, there's a launch message in a channel somewhere, and for about three weeks it works exactly as specified.

Then, quietly, people stop using it. Nobody announces this. Six months later someone asks what happened to the thing and gets a vague answer. The system is still running. It just isn't part of how work gets done anymore.

Nothing broke. That's what makes this failure mode so hard to catch — every technical metric says success. And because nothing broke, the post-mortem, if there is one, concludes that the technology wasn't quite ready, and the company waits a year and tries again with a newer model.

The technology was almost never the problem.

The process was never examined, only described

When you scope an automation, you ask how the process works. Someone tells you. You build to that description.

The trouble is that the description is a reconstruction. It's how the process is supposed to work, assembled after the fact by someone who mostly does it on autopilot. It leaves out the parts they don't think of as steps — the glance at a field to check something looks off, the message to a colleague when a case seems unusual, the thirty-second judgement call that happens so fast it doesn't register as a decision.

Those omitted parts are frequently where the actual value of the process lives. Automate the described version and you've automated the skeleton while discarding the judgement. The output looks correct. It just isn't as good, in ways that are hard to articulate and easy to dismiss — which is why the feedback never arrives as a bug report. It arrives as people slowly routing around the system.

The fix isn't a longer requirements document. It's watching the process actually happen, at least a few times, ideally with someone who does it badly and someone who does it well, because the difference between them is exactly the judgement you're at risk of throwing away.

Automation relocates work more often than it removes it

The pitch is almost always time saved. Ten hours a week of manual effort, gone.

What frequently happens instead is that ten hours of doing the work becomes four hours of a different kind of work: checking outputs, handling the cases the system punts on, correcting the ones it got confidently wrong, and — the cost nobody forecasts — maintaining the thing as the surrounding business changes.

Four hours instead of ten is a real gain. But it's a 60% gain, not the 100% that was pitched, and the four hours are qualitatively worse: fragmented supervision work rather than continuous focused work. People are worse at that and enjoy it less.

This matters because of who ends up holding the new work. It's rarely the person whose time was being saved. Verification usually lands on someone more senior, because verification requires judgement. So a project justified by saving junior time ends up consuming senior time, and the economics quietly invert while everyone's still calling it a success.

Ask early: after this ships, who checks the output, and what were they doing before?

Nobody owned adoption

Most implementations have a technical owner. Far fewer have an adoption owner.

The distinction matters because adoption isn't a training problem — that's the standard misdiagnosis, and it leads to a training session that changes nothing. Adoption is an operations problem. It's about whether the new way is genuinely easier than the old way on a bad day, whether the workarounds people had built still work (if they do, people will keep using them), and whether anyone's actual performance measurement changed to reflect the new process.

That last one decides it more often than anything else. If someone is still measured on a metric the old process served better, they will keep using the old process, and they will be right to. No amount of training overcomes an incentive pointing the other way.

The pilot was designed to succeed

Pilots get run on clean data, selected cases, and an engaged team who knows they're being watched. Then the results get extrapolated to messy data, all cases, and a team that has other priorities.

The gap between those two conditions is not a rounding error. It's often the entire difference between a project that works and one that doesn't.

A pilot worth trusting includes the ugly cases deliberately. Not as a stress test at the end — as part of the sample from the start. If the pilot can't handle the messy 20%, that's not a limitation to note in an appendix; it's a finding about whether the whole thing is viable, because the messy 20% is usually where most of the human time actually goes.

The company automated a problem it should have deleted

The hardest version of this failure, and the one nobody wants to name.

Sometimes the process being automated shouldn't exist. It's a workaround for a system nobody wants to replace, a report nobody reads, a reconciliation step that exists because two teams don't talk. Automating it makes it faster, cheaper, and permanent — you've now invested in the survival of something that should have been questioned.

This is genuinely difficult to raise, because by the time you're scoping automation the decision to automate has usually already been made, budget has been allocated, and someone's quarter depends on it. Asking "should this process exist?" reads as obstruction rather than diligence.

But it's the highest-leverage question in the entire engagement. Deleting a process beats automating it, every time, and costs nothing.

What I'd actually do

If I had to compress this into practice:

1. Watch the process before you describe it. At least twice, ideally with people of different skill levels.
2. Name the post-automation work explicitly. Who verifies, how long it takes, and what they stop doing to make room.
3. Assign an adoption owner who is not the technical owner, and check whether any performance measure needs to change.
4. Put the ugly cases in the pilot from the start, not as a follow-up phase.
5. Ask once, seriously, whether the process should exist. Early enough that the answer can still change the plan.

None of this is about the technology. The models are, for most business processes, more than good enough — they have been for a while. The constraint has moved. It sits in the operational layer now: process understanding, work design, incentives, ownership.

That's less exciting than a model release. It's also where the returns are.