Today, a RAND Corporation report estimates that more than 80% of AI projects fail, roughly twice the failure rate of comparable IT projects. Abandonment is another issue on the rise: Gartner projects that more than 40% of agentic AI projects will be canceled by the end of 2027.

What is failing is not the technology at hand. It's the same operational pattern that catches many businesses off guard, which happens when businesses move fast without putting the right systems and infrastructure in place.

The tell is always the same

When I look at why AI initiatives stall, the root causes are similar to the many hurdles businesses face when they look to implement a new solution with no clear definition of what success means, and no foundational operational capabilities in place. The excitement with AI tools supersedes the necessary steps required for a thought-out strategy. And with AI tools, they don't stay still once deployed, they drift, requiring a more robust system to just monitor them. As with anything in business, a disciplined approach to implementing new strategies is critical for success.

JPMorganChase offers a useful example of scale supported by operating discipline. The firm has reported more than 500 AI use cases in production and access to LLM Suite for 200,000 employees. Its public materials point to experimentation within teams and lines of business, an integrated technology and data foundation, orchestration across workflows, and guardrails in place before scaling. The firm also measures impact through cost avoidance, risk reduction, and revenue growth rather than assuming that adoption alone creates value. The lesson is not that every company should copy JPMorganChase's scale. It is that the right operating structure, governance, and measurement discipline make successful adoption possible.

The AI Curation Loop

So what does an effective operating structure and governance look like? This is the framework and questions I ask clients pursuing AI tools in their business.

Choose the pain, not the tool.

Before discussing AI tools, define the business outcome the workflow needs to improve. A use case should begin with a real need, not pressure to adopt AI.

  • Name the problem. What is costing the business time, money, quality, or capacity today?
  • Check readiness. Are the workflow, data, ownership, and handoffs clear enough for AI to support them?
  • Rank the use cases. Compare expected value, cost, complexity, and risk. Start with a useful, lower-stakes workflow that does not depend on sensitive or difficult data.
  • Set the baseline. Record how the work performs today and define the result that would make the AI investment worthwhile.

This keeps the decision tied to business value and gives the team a clear reason to proceed, pause, or choose a simpler solution.

Build the one measurable proof.

Start with one workflow and define what a good result looks like before launch. Map how people do the work today, find where it breaks down, and build the AI around that real process.

Before release, test what can go wrong:

  • Can one mistake quietly pass through several steps?
  • Could the system use old or incorrect information?
  • Could it give a convincing answer that misses what the user actually needs?
  • Which decisions must stay with a person?

Keep a human reviewer in place before the tool is allowed to act on its own. Set clear checkpoints and measurable results instead of relying on a vague sense that it is "going well." The higher the risk, the stronger the human review should be. You are proving both the tool and the process for using it safely before adding more use cases.

Adopt the use and trust.

Treat adoption in two buckets: use and trust. Adoption of use means people are actually opening the tool. Adoption of trust means people believe what it tells them enough to act on it, rather than clicking through it because it's now sitting in their workflow. High usage with low trust looks like a win on a dashboard and is actually a quality problem. You can't manufacture either one by announcing the tool is exciting. People adopt what visibly makes a specific part of their day easier, and that has to be demonstrated, not declared.

Operate the solution for sustainability.

The stage where it's sometimes an afterthought for businesses, and where the expensive surprises live. Set three systems for maintaining the deployed models:

  • Measure the drift:
    • Cost drift, where the tool still works but compute or labor spend quietly outpaces the value it delivers
    • Performance drift, where the model's accuracy degrades against its original baseline
    • Value drift, where the tool still works fine, but the business problem it solved stopped mattering because the organization moved on or strategies shifted
  • Staff appropriately. Engineers who build and engineers who monitor drift should be separate. Businesses can create internal AI education and champions to offset some of the operational or administrative work that will arise with these models.

Evolve with your business, not with the hype.

Scale what's proven. Shut down what isn't. Have a decommissioning process to effectively retire models that are outgrown or have not shown value. And most importantly, scale gradually. Just because the models are providing real business impact does not mean you need to add many more tools for the sake of having them. Business problems and desired outcomes should drive the solutioning, not the other way around.

The real question isn't "should we use AI"

It's what does success look like in six months, in a number you can point to, and who owns watching it after the launch excitement fades? If you can't answer that yet, that's not a reason to wait. It's a reason to build the operating structure first, the same way you would for any new hire, process, or system entering the business. AI is just the newest thing that's shown up needing one.

Sources