By: Kumar Dattatreyan

Your AI pilot did not fail because the model was weak. It failed because you pointed a very expensive machine at a process that was already broken, and it broke it faster. A magic bullet cannot fix a workflow nobody bothered to fix first.

I see this all the time. A leadership team announces an AI initiative. The CTO picks a vendor. Someone launches a pilot. Three months later the pilot is quietly shelved, the budget is gone and the only measurable outcome is a slide deck nobody wants to present at the next board meeting.

The pattern is so consistent it should have its own acronym.

Last week I wrote about The Great Flattening, the idea that AI will not rescue a broken org chart. This week I want to go one level deeper. AI will not rescue a broken workflow either. And most enterprise AI projects fail for exactly this reason: they automate a process a human was already doing badly, then act surprised when the machine does it badly at scale.

The Most Expensive Tool in the Kit

Ashwini Kumar is an AI/ML practitioner who has spent six years in the room when companies make their big AI bets. He put it plainly on the podcast: "Everybody believes AI is a magic bullet, but it's not. It is not the magic bullet we all think it is."

He calls AI "another tool in your tool set" and "the most expensive one."

That reframe matters. When you call something a magic bullet, you stop asking hard questions about fit. When you call it the most expensive tool, you start asking whether the problem justifies the cost.

Most organizations skip that question entirely. The pressure to show an AI win produces pet projects, disconnected pilots and numbers that look good on a dashboard but collapse under scrutiny. Ashwini described watching executive teams push AI so hard it becomes a pedestal project. It almost cannot fail because they have invested so much money into it. So "sometimes they tend to fudge the numbers a little bit to make it look good."

The projects try to tackle too much. As Ashwini put it, teams "build the solution and don't even know what the problem is they're solving specifically and then the five different solutions don't even talk to each other."

There is a gap between what he calls "the reality of AI and the hope of AI." That gap is where budgets go to die.

The Agile Mistake, Repeated

If this sounds familiar, it should. We made the same mistake with agile.

When agile first arrived by way of Scrum, the pitch was simple: take a two-day class and become an expert. Not true, as we all learned the hard way. Then came the over-investment in dogmatic framework adoption. Just implement this, sink a lot of money into it, and somebody will wave a magic wand once you are done. We know how that turned out for most organizations.

Sanjiv Augustine described it on the podcast this way: mindless agile adoptions failed by mindlessly adopting frameworks without understanding the context. We run the risk of doing the same thing with AI. Mindlessly adopting AI tools and technology, not using them fit for purpose within a context-sensitive way.

The numbers back this up. PMI data shows 70 to 80 percent of AI pilots are failing. Other estimates push that higher. Whatever the exact figure, the failure rate is large.

Failure itself is not always bad. If you are failing, you are learning. But only if you actually learn from it and do not repeat the same mistakes. If you are mindlessly adopting AI the way you mindlessly adopted agile, that is not experimentation. That is expensive repetition.

The Demo Trap

Suzel Wyvill-Jones ran a $120M technology portfolio. She described a pattern on the podcast that I have watched play out at multiple clients.

A Fortune 500 executive wants to solve a fraud detection problem with AI. A vendor comes in with a demo. The demo works beautifully because it runs on synthetic data. Everything is clean. Everything is perfect. Everyone in the room is delighted. They are certain this will solve all their problems.

Then they look at the actual environment. As Suzel put it, a fraud system "touches every single system in the company. If one of them doesn't have the data ready, there goes your fraud system."

This is the demo trap. Synthetic data produces synthetic confidence. And synthetic confidence produces real budget commitments that cannot deliver real results.

The fix is not to stop doing demos. The fix is to stop confusing a demo for a proof of concept. A demo shows what the technology can do. A proof of concept shows what the technology can do with your data, your systems, your people and your actual workflow.

The Subtler Trap

There is a version of this that is harder to see. A reader of last week's article on The Great Flattening put it better than I could: the middle layer was never just carrying information. It was the organ the whole organization felt reality with.

Data drift is the example that keeps pulling me back to this. The numbers stay clean. The dashboard glows green. And the person who has stood in that work long enough feels in their gut that the readings are lying. That is not information moving through a pipe. That is pattern recognition built on context and memory. No model replicates it.

When you automate a workflow, you are not just moving tasks to a machine. You are deciding which human judgments to keep and which ones to discard. If you cannot tell the difference between a step that is genuinely repetitive and a step where someone is quietly compensating for a broken upstream process, you will automate the compensation out of existence. The dashboard will still glow green. Nobody will feel the wind anymore.

So the question is not just "is this workflow clean enough to automate?" It is "do we understand which parts of this workflow are sense-making and which parts are just moving paper?"

Begin with the Decision

So how do you avoid the trap? James Taylor, founder of Blue Polaris and one of the pioneers of decision management, put it this way on the podcast: "You have to begin with the decision in mind."

Not the technology. Not the vendor. Not the use case your competitor announced in a press release. The decision. What specific business decision will this AI make or support? And can you measure whether it made the right one?

James described working with a commercial insurer whose underwriting system simply did not have the data their decision engine needed. The system was old. The data was incomplete. But he pointed out that the emails and attached documents coming into the process already contained enough information to make the decision. The problem was never the AI. The problem was that nobody had mapped the decision first.

This is a discipline problem, not a technology problem. And it maps directly to what we call Line of Sight in The Disruptor Method™. If the people doing the work cannot see a direct connection between their effort and a measurable business outcome, the work is misaligned. AI does not fix misalignment. It amplifies it.

A manufacturer we worked with tried to automate quality inspections using computer vision. The technology worked. But the inspection process itself was redundant. Two separate teams were inspecting the same components at different stages, using different criteria, logging results in different systems. Automating that process would have produced faster redundancy. They had to fix the workflow first, consolidate the inspection criteria, unify the data layer. Then the AI had something coherent to work with.

That is the pattern. Fix the process. Then automate the process. Not the other way around.

The Repetitive Work Test

If you are looking for a place to start, look at repetitive workflows. Not strategic decisions. Not creative work. Repetitive tasks where the steps are well-defined, the data is already being collected and the output is predictable.

Suzel recommended starting with project management areas because they have repetitive tasks and the data is usually already sitting in a system somewhere. Dashboards that get published every week are another candidate. The data is gathered, formatted and distributed on a predictable cycle. That is exactly the kind of work AI handles well.

Ashwini reinforced this from the practitioner side. His team built a proposal generator using agentic RAG that cut proposal turnaround from two weeks to two or three days. It worked because the task was well-defined: take an RFP, generate a proposal against it. Specific agents handled formatting, context and orchestration. The scope was narrow enough to measure.

The key is that these tasks do not rely on the AI making high-judgment calls. They rely on the AI repeating a known sequence accurately and consistently. That is a very different use case than asking AI to make credit decisions or diagnose complex problems, where the stakes of being wrong are catastrophic and the decision needs to be traceable.

Start where the cost of failure is low and the workflow is already clean. Prove the return. Then expand.

The SORI™ Test for AI Readiness

Before you commit budget to an AI initiative, run it through a SORI™ assessment. This is one of the core tools in The Disruptor Method™, and it works as well for AI projects as it does for any transformation.

Strengths: What does your current process do well? If the answer is "nothing," you do not have an automation problem. You have a process design problem. Fix that first.

Opportunities: Where is the specific, measurable gain? Not "efficiency" in the abstract. A number. A decision. A cycle time reduction. If you cannot name it, you are not ready.

Risks: What happens when the AI gets it wrong? If the answer involves regulatory exposure, customer harm or irreversible decisions, you need human oversight in the loop. Full stop.

Impediments: Is your data clean? Are the systems integrated? Do the people who will use this tool trust it? If the data is biased, the decisions will be biased. If the systems are fragmented, the AI will inherit the fragmentation.

Most AI projects that fail would have failed the SORI™ assessment before a single line of code was written. The assessment is not a bureaucratic exercise. It is a filter that keeps you from spending six months and a million dollars to discover what you could have learned in a week.

Common Objections

"We need to move fast or we will fall behind." Moving fast on the wrong problem is not speed. It is waste. Your competitor's press release about their AI initiative does not tell you whether it actually works. Most of the time, it does not. Disciplined scoping is faster in the long run because you do not have to restart.

"Our vendor says the platform handles everything." The vendor's demo ran on synthetic data. Your data is messy, fragmented and probably biased in ways you have not audited. The platform handles the technology. It does not handle your organizational dysfunction.

"We already committed the budget." Sunk cost. Redirect it to the process fix you should have done first. The AI will still be there when you are ready for it.

Three Things You Can Do This Week

One: Pick one decision. Not a workflow. Not a department. One business decision your team makes repeatedly. Map how it gets made today. Every input, every handoff, every data source. If the map reveals a mess, you just found the real problem.

Two: Run the demo trap test. For every active AI pilot, ask: are we running on real production data with real users, or are we still on the synthetic demo environment? If the answer is synthetic, the pilot has not started yet. It is still a sales presentation.

Three: Apply the SORI™ assessment. Take your highest-priority AI initiative and put it through the four-question framework. Strengths, Opportunities, Risks, Impediments. If it cannot pass all four, pause the initiative and fix the gaps before you spend another dollar.

The Bottom Line

AI is powerful. AI is real. And AI will absolutely transform the organizations that use it well.

But "use it well" has a prerequisite. The workflow has to work first. You cannot automate your way out of a process that was broken before the machine showed up. You just break it faster and at greater expense.

The organizations that will win the AI race are not the ones that move fastest. They are the ones that fix their workflows first, scope their AI to one measurable decision and prove the return before they expand. That is not glamorous. It will not make a good press release. But it is the discipline that separates real transformation from expensive theater.

Want to go deeper? Take The Disruptor Method™ Quiz and find out where your organization stands on the AI readiness spectrum. Or book a conversation and let's map out a plan that starts with the decision, not the technology.

Related Podcast Episodes

EP174: AI Is Not a Magic Bullet: What Enterprise AI Gets Wrong (Ashwini Kumar) Ashwini has spent six years in the room when enterprise AI bets get made. He described the pattern of executives pushing AI so hard it becomes a pedestal project, teams building five solutions that don't talk to each other, and the gap between what AI promises and what it actually delivers. His framing of AI as the most expensive tool in the kit anchors this entire post. 

EP173: The AI Decisions Are Wrong, And Your Data Isn't the Problem (James Taylor) James made the case that most organizations think they have an AI problem when they actually have a decisioning problem. His point that you have to begin with the decision in mind reframes the entire enterprise AI conversation from technology selection to process discipline. 

EP172: She Ran a $120M Portfolio. Now She's Telling CEOs the Truth About AI (Suzel Wyvill-Jones) Suzel described watching enterprise teams fall in love with demos built on synthetic data, then crash into reality when the actual systems could not support the initiative. Her take on starting with repetitive workflows and growing from there reinforces everything in this post.