10 min. read

The demo worked. The pilot hit its numbers. The steering committee approved the next phase. Six months later, it’s still a pilot, and nobody can quite say why.

If you run a PMO, you’ve probably watched this happen more than once. Pilot purgatory is the most common outcome in enterprise AI, and it rarely traces back to the model. This guide covers what the research says about why AI projects fail, the five places pilots stall, and who in your organization should own each fix.

How often AI projects fail

The two studies quoted most often measure different things. MIT’s Project NANDA found that 95% of organizations in its 2025 study were getting no measurable return from generative AI, despite an estimated $30–40 billion in enterprise investment. For custom and vendor-sold enterprise AI tools the drop-off was steep: 60% of organizations evaluated them, 20% reached a pilot and just 5% reached production. The study is preliminary, built on 300+ public initiatives, interviews with 52 organizations and surveys of 153 senior leaders, and it judged success six months after the pilot.

RAND, working from interviews with 65 experienced data scientists and engineers, cites estimates that more than 80% of AI projects fail, about twice the rate of IT projects that don’t involve AI.

The exact number matters less than the pattern. Neither study found that the models were the main problem. We made a related argument in The Governance Gap: the hard part of AI inside an organization is delivery, not the technology.

Where the gap sits. NVIDIA’s Jensen Huang has described AI as a five-layer stack: energy, chips, infrastructure, models and applications. Every stall point below happens one level up, where an application meets a real organization with its own data, workflows, people and rules. No model benchmark measures that layer. People run it.

The five places AI pilots stall

Each stall point below comes from the MIT and RAND findings. Each one also has an owner, or should.

1. Nobody pinned down the problem

RAND found that the most common root cause of AI project failure was misunderstanding or miscommunicating the problem the project was meant to solve. The technical team builds what it thinks the business asked for, the business expected something else, and nobody wrote the goal down in terms both sides could test.

Whose job it is: whoever scopes the use case. That means defining the business outcome, the production criteria and the decision the AI is supposed to improve, before the pilot starts.

2. The tool doesn’t fit the workflow

MIT traced most failures to brittle workflows and tools that didn’t match how people actually work. Its researchers described a mid-sized firm that spent $50,000 on a specialized contract-analysis tool. The lawyer it was bought for kept drafting in ChatGPT instead, because the purchased tool was too rigid to adjust. Across the study, only 40% of companies had bought an official AI subscription, yet workers at more than 90% of them were using personal AI tools for their jobs.

Your entry could not be saved. Please try again.

We sent links to your email! You should have received an email from us already. If you did not receive, make sure you check your spam folders and add masterofproject.com to safe senders list to receive our emails.

Whose job it is: whoever maps the workflow before the tool is chosen, and measures adoption after it ships.

3. The data and infrastructure weren’t ready

Two of RAND’s five root causes sit here: organizations that lack the data needed to train an effective model, and organizations that lack the infrastructure to manage that data and deploy what they build. Both are usually known risks that surface late because nobody sequenced them into the plan.

Whose job it is: whoever owns the integrated schedule, the one that puts data access, security review and infrastructure work on the critical path instead of discovering them at go-live.

4. Nobody owns adoption

When MIT asked executives and frontline users to rate the barriers to scaling AI, unwillingness to adopt new tools topped the list. The rest included model-quality concerns, poor user experience, lack of executive sponsorship and difficult change management. Most of that list is people work, not engineering.

Whose job it is: whoever runs stakeholder engagement and change management for the rollout, and reports adoption as a real metric.

5. Nobody holds the vendor to a business number

MIT found that buying AI through external partnerships reached deployment about twice as often as internal builds. But the buyers who succeeded treated vendors more like service providers than software sellers. They demanded customization to their own processes, judged tools on operational outcomes rather than model benchmarks, and stuck with partners through early failures. A vendor’s forward deployed engineers can make that vendor’s product work in your environment. Holding every vendor to your numbers is a different job, on your side of the table; we compare vendor-side vs. organization-side deployment in a separate post.

Whose job it is: whoever owns vendor governance and benefits realization across the AI portfolio.

The five stall points at a glance

Stall point	What the research found	Who owns the fix
Problem not pinned down	RAND’s most common root cause: misunderstanding or miscommunicating the problem	Whoever scopes the use case and sets production criteria
Tool doesn’t fit the workflow	MIT: brittle workflows and misalignment with day-to-day operations	Whoever maps the workflow and measures adoption
Data and infrastructure not ready	Two of RAND’s five root causes	Whoever owns the integrated schedule
Nobody owns adoption	MIT: unwillingness to adopt new tools is the top barrier	Whoever runs change management
Vendor not held to a business number	MIT: successful buyers judge vendors on operational outcomes	Whoever owns vendor governance and benefits

A legacy lesson: Hershey, 1999

AI didn’t invent this failure pattern. In September 1999, Hershey told analysts that problems with its new order-taking and distribution system, a $112 million combination of software from SAP, Siebel and Manugistics, would keep it from delivering $100 million worth of Kisses and Jolly Ranchers for Halloween. As CIO magazine later noted, the system went live just as Halloween orders were pouring in, and the timing was the real failure.

The software mostly worked. The go-live decision didn’t. Deciding when a system is ready, against the business calendar and with the authority to say “not yet,” is a project-management call. It’s the same call that strands AI pilots today.

Why it keeps falling between chairs

Look at who owns what in a typical AI initiative. The data science team or AI Center of Excellence owns the model. The vendor owns its product, often through its own forward deployed engineers. The business unit owns the process. IT owns the infrastructure. Each owner is competent at its piece, and none of them owns the deployment across all of them.

That gap shows up as time. MIT found that top-performing mid-market companies moved from pilot to full implementation in about 90 days, while enterprises took nine months or longer, despite running more pilots and assigning more staff. More hand-offs, same missing owner.

The research also points to the fix. MIT’s most successful organizations pushed implementation authority out to the managers closest to the work while keeping accountability clear. That is the job description of an AI project manager.

What your PMO can do this quarter

If your organization is also standing up AI governance, the same discipline applies there; our playbook for running AI governance as a project, from charter to closeout covers that side. For deployment, start with these six moves:

Name one accountable owner per AI initiative. One person, not a committee, with authority across the model team, the vendor, the business unit and IT.
Write the production criteria before the pilot starts. Define the business outcome, the metric that proves it and the date you’ll judge it. A pilot without exit criteria never exits.
Gate on workflow fit and adoption, not the demo. Judge each pilot on operational outcomes, the way MIT’s successful buyers did, rather than on model benchmarks.
Put every vendor on a business number. Make the vendor’s success metric your metric, and review it on the same cadence as the rest of the portfolio.
Track pilot-to-production conversion as a portfolio KPI. If the PMO doesn’t measure it, nobody will.
Choose problems that will still matter in a year. RAND’s authors advise picking enduring problems, because AI projects take time and patience to finish.

Building the person who owns it

Most organizations don’t have an AI project manager because, until recently, there was no formal way to build one. That changed on September 8, 2026, when the Maryland Apprenticeship and Training Council registered the first Registered Apprenticeship in the United States dedicated to AI project management: MATC Program #2575, sponsored by Master of Project Academy.

“Enterprise AI doesn’t fail at the model layer — it fails where an application meets a real organization,” said Chris Monroe, CEO of Master of Project Academy, when the program was announced via Business Wire. “Every company deploying AI needs people on its own payroll accountable for that last mile — across every vendor and every model type.”

The program is built around the stall points above. Apprentices complete 4,000 hours of mentored on-the-job learning across eleven registered work processes, including AI System Integration & Governance, alongside 340 hours of related instruction. Of those instruction hours, 259 (76%) are AI-specific. Over the 24-month term, apprentices earn five stackable credentials: CAPM, PMP, an AI Specialization, the Apprenticeship Certificate of Completion and 60 PDUs.

Apprentices are full-time W-2 employees of their employer from day one, and they contribute to live AI initiatives from their first week of on-the-job learning. Master of Project Academy handles sponsorship, instruction, certification, and registration and reporting; your organization provides the seat and a mentor. Employers in Maryland and Pennsylvania can join as a participating employer today, and recognition in additional states is in progress. If you’re weighing this against hiring or contracting, see what each AI talent option costs.

Frequently asked questions

Why do most AI projects fail?

Mostly for organizational reasons rather than technical ones. RAND found the most common root cause is misunderstanding or miscommunicating the problem a project is meant to solve. MIT traced most failures to brittle workflows and tools that don’t fit how people work. Data readiness, infrastructure, adoption and vendor accountability account for much of the rest.

What percentage of AI pilots reach production?

Few. In MIT Project NANDA’s 2025 study, 60% of organizations evaluated custom or vendor-sold enterprise AI tools, 20% reached a pilot and 5% reached production. RAND cites estimates that more than 80% of AI projects fail. Both figures depend on how success is defined, so treat them as a direction rather than a precise rate.

Who should own AI deployment in an organization?

One accountable owner per initiative, on the organization’s own payroll, with authority across the model team, vendors, the business unit and IT. A vendor’s forward deployed engineers can own their product’s integration, but someone inside has to own the outcome across every vendor. That is the role of an AI project manager.

Build the person who owns your AI deployments.

A 30-minute curriculum review scopes your vertical, your cohort size and which incentives apply in your state.

Book a 30-minute curriculum review →

About Master of Project Academy

Founded in 2012, Master of Project Academy has trained 500,000+ learners across 180+ countries in project management, with a 99.6% first-attempt PMP pass rate in delivered cohorts. Master of Project Academy is the registered sponsor of MATC Program #2575, the nation’s first AI Project Management apprenticeship. Learn more at masterofproject.com/p/aipmapprenticeship.

Sources

Why AI Pilots Stall — and Whose Job It Is to Fix Them