Most companies don’t struggle to launch an AI pilot. They struggle to turn that pilot into something people actually use every day. A demo works because it only has to answer a few carefully chosen questions. Production is different: the system has to pull real account data, follow company policy, handle the request nobody planned for, and know when to hand off to a person. That gap, between “the demo worked” and “this now runs the business,” is where most AI initiatives quietly die.

The numbers back this up. McKinsey’s November 2025 State of AI survey found that 88% of organizations now use AI regularly in at least one part of the business, but only about 39% can point to any real effect on company-wide profit, and just 5.5 to 6% see a meaningful one (5% or more of EBIT, the standard measure of operating profit). RAND’s 2024 research put the failure rate for AI projects above 80%, roughly double the failure rate of ordinary IT projects. MIT’s Project NANDA, publishing in August 2025 after reviewing 300 real deployments, found that about 95% of generative AI pilots never produce a measurable financial return.

These figures don’t argue against using AI. They describe what usually goes wrong, which is useful because it shows what to build differently. The model can usually do the job. The harder part is fitting it into the company’s existing systems, workflows, and decision-making: the unglamorous work of integration, ownership, and oversight that never shows up in a demo.

This roadmap is written for teams that have already run a pilot, or are running one now, and are asking a more specific question than “should we use AI.” They’re asking why the pilot isn’t turning into anything permanent, and what has to change so the next one does.

Where AI projects actually break down

It helps to know exactly where in the process things fall apart, because that determines the fix.

• Most pilots die before they ever reach production. S&P Global Market Intelligence’s 2025 research found the average company scrapped 46% of its AI proofs-of-concept (early working tests, short for POCs) before they reached production, and only 48% of AI projects reach production at all. The ones that do make it take about 8 months on average, long enough for the original sponsor to change jobs and for the project’s urgency to fade.
• Projects built entirely in-house fail more often than ones built with a vendor or implementation partner. MIT’s Project NANDA found in-house builds succeeded at roughly half the rate of vendor-supported ones. Connecting an AI tool to a company’s real systems (the ERP, the CRM, the ticketing platform, identity and access controls) is harder than it looks, and vendors who have done that integration work before tend to get there faster.
• Weak governance is now the top reason agentic AI projects get cancelled. Gartner’s June 2025 forecast, that more than 40% of agentic AI projects will be cancelled by the end of 2027, points to rising costs, unclear business value, and weak risk controls, not the technology itself. Gartner also estimates that of the thousands of products currently marketed as “agentic AI,” only about 130 vendors have genuine multi-step autonomous capability; the rest are existing chatbots or automation tools rebranded to ride the trend.
• The companies that do see results tend to redesign the work itself, not just add AI to it. McKinsey’s highest-performing organizations are 3.6 times more likely to pursue real organizational change alongside their AI rollout, and most rebuild the underlying workflow rather than bolt AI onto the old one.

Step 1: Check whether you’re ready to start

Most roadmaps begin with “pick a use case.” That’s premature if three earlier questions haven’t been answered, because the answers decide which use cases are even worth trying.

Is the data actually usable? Can you get to it programmatically, is it clean enough for the task, and does one named person own its accuracy? If the honest answer is “it exists somewhere but nobody’s responsible for whether it’s right,” that’s the real project: fix it first, or pick a different process where the answer is genuinely yes.

Is there a real owner? Every pilot needs one accountable business person, not an IT sponsor, who will still be in that role eight months from now, roughly matching S&P Global’s average time to production. If leadership can’t name that person today, it’s too early to start.

Is success actually measurable? Can the goal be written as one specific sentence before the pilot begins? “Cut average handling time for tier-1 support tickets from 12 minutes to under 6, measured weekly” is testable. “Use AI to improve customer service” isn’t; it has no way to fail, which is exactly how projects drift into permanent pilot status instead of scaling or getting shut down.

Readiness checklist:

• Named business owner who will still hold budget authority in 8+ months
• Data source identified, accessible, and owned by a named person
• Success metric written as one measurable sentence with a baseline and a target
• Kill criteria decided before the pilot starts, so everyone agrees what result ends it
• Systems the pilot needs to connect to are already identified
• Executive sponsor confirmed for the full 6 to 12 month horizon, not just pilot approval

If most of these are missing, close the gaps before starting. Starting anyway just delays the failure, it doesn’t prevent it.

Step 2: Choose a problem AI can actually solve

With readiness confirmed, weigh use cases on three things: how much value is actually at stake if it works, how many systems it needs to touch to be useful, and whether you can build a real evaluation set, not the 30 or 50 example prompts someone wrote in an afternoon, but something that covers edge cases and the ways this specific task tends to go wrong.

Picture a company piloting an AI tool to handle customer support chats. The demo looks great because it answers a handful of pre-selected questions well. In production, it has to pull up a real customer’s account, apply the company’s actual refund policy, deal with the angry customer who didn’t ask a clean question, and know when to hand off to a person instead of guessing. That’s usually where the trouble starts, not because the model got worse, but because the real job was always bigger than the demo showed.

Design the pilot as if it’s the first version of the real system, not a demo: real, access-controlled data, the actual system connections even if sandboxed, and a regular evaluation schedule instead of one review at the end.

Step 3: Build governance alongside the pilot, not after it

Gartner’s research on why agentic AI projects get cancelled points to weak risk controls built too late, not the technology itself. Build governance at the same time as the pilot, not after it proves itself. Before the pilot touches real data, you need:

• A human review step for any decision above a set risk level, with someone specific responsible for exceptions
• A record of what produced each output, which model version, which data, which prompt or settings (often called “lineage”), kept for later audits
• A process for approving changes to the model, prompts, or what an AI agent is allowed to do, so a vendor’s quiet model update doesn’t quietly change how the system behaves
• A plan for when it goes wrong, a hallucinated answer to a customer, an agent taking an action it shouldn’t have, a biased outcome. Most companies already have this for security incidents but few have adapted it for AI
• An early check on regulation: does this use case fall under a framework like the EU AI Act’s “high-risk” categories, or industry-specific rules in finance, healthcare, or hiring? As of mid-2026, the EU’s high-risk deadlines are being pushed back through a pending legislative process; treat that as a reason to build this capability on a sensible timeline, not a reason to skip it.

This is also where buying tends to beat building most clearly: governance tooling, audit logs, access controls, evaluation frameworks, is often faster to get from a vendor than to build from scratch.

These controls sit in four layers, each with a different owner. Treating them as one undifferentiated “governance” task is a common reason the work stalls, since no single role is positioned to own all four.

Governance framework layers

Layer	Purpose	Example controls	Typical owner
Policy & oversight	Sets risk appetite and who can approve what	AI governance charter, approval criteria, a cross-functional review group	Governance body / CIO or Chief AI Officer
Risk & compliance	Maps use cases to legal and regulatory exposure	Regulatory scoping, bias review, sector-specific rules	Legal / Compliance, working with the business owner
Technical controls	Enforces policy inside the running system	Human review gates, access controls, lineage logging, change control	Engineering / AI platform team
Operational	Keeps the system accountable day to day	Incident response, weekly evaluation, escalation paths	Business owner, with on-call engineering support

Step 4: Run the pilot like it’s already real

Test against the metric from Step 1, with three things most pilots skip. Use a comparison group, a similar team still using the old process, so you can tell whether the improvement actually came from the AI, rather than from the extra attention, training, or supervision that naturally comes with running a pilot. Evaluate weekly, not just at the end, so problems surface early instead of showing up as a surprise in the final report. And build a cost model that includes integration and governance work, not just the API bill: Neomanex’s 2026 analysis of enterprise AI adoption found that successful projects put about 47% of their budget into this foundational work, versus about 18% in projects that ultimately failed. That gap, more than the total spend, is the useful signal.

At the end of the pilot, make an actual decision: scale it, redesign and try again, or kill it. Skipping that decision is how organizations end up stuck in what McKinsey calls “pilot purgatory”: its data shows roughly two-thirds of organizations still experimenting rather than having either committed to or walked away from their AI initiatives.

Step 5: Get the system ready for everyday use

This is the step most in-house projects underestimate, and it’s where a pilot plan and a real production plan diverge.

1. Connect it properly to real systems: authenticated access to the ERP, CRM, ticketing platform, or knowledge base, with clear agreements about what data flows where, rather than a fragile one-off connection.
2. Test it under real load, not pilot-scale traffic. Many pilots run on a fraction of actual volume and never surface the latency, cost, or error-rate problems that only show up at scale.
3. Watch how it behaves in production: track output quality, catch it if performance drifts over time, monitor cost per transaction, and have a clear path to escalate when the system isn’t confident.
4. Review the security angle specific to AI: prompt injection, data leaking out through tool use (especially relevant for agents with access to internal tools), and confirming access controls for anything the AI can actually do, not just say.
5. Prepare the people, not just the system. Deloitte’s research and several other industry analyses point the same direction: most AI failures trace back to people and process, not the algorithm. The team whose job is changing needs training, a clear way to escalate when the AI is wrong, and enough notice that they’re not discovering the project on launch day.

Step 6: Scale what actually works

Scaling isn’t “turn it on for more people.” It’s repeating Steps 3 through 5 for each new team or use case, but with the governance and integration work now reusable instead of rebuilt from scratch. Companies that treat their first production system as a template, with reusable evaluation tools, reusable governance, and a documented way to connect to systems, scale faster than those treating every new use case as its own project. ModelOp’s 2026 benchmark found over 100 proposed AI use cases against fewer than 25 actually in production at the average enterprise: the bottleneck is reusable infrastructure, not ideas.

At this stage, add: a cross-functional group with real authority to approve, pause, or retire AI systems; ROI tracked across the whole portfolio, not just project by project; and a retirement policy for systems that no longer earn their keep, which matters just as much as the approval process does.

Roadmap timeline and gates

Step	Typical duration	What has to be true to move on
Step 1: Readiness check	1–3 weeks	Checklist items closed or each gap has a named owner and a date to close it
Step 2: Pick the problem, design the pilot	2–4 weeks	Evaluation set and pilot design signed off by the business owner
Step 3: Governance foundation	Runs alongside Steps 2–4	All four governance layers in place before real data is touched
Step 4: Run the pilot	6–12 weeks	A clear scale / redesign / kill decision against the original metric
Step 5: Production hardening	6–20 weeks (combined with Step 4, roughly matches S&P Global’s ~8-month average)	Load-tested, monitored, security-reviewed, and live with real users
Step 6: Scale	Ongoing	Governance and evaluation tools are reusable, so each new use case moves faster than the last

Build, buy, or partner

Choosing among the best enterprise AI solutions depends on more than the model itself. Companies also need to consider how quickly a solution can be deployed, how well it integrates with existing systems, and whether the business has the internal expertise to build and maintain it.

Factor	Favors building it yourself	Favors buying it	Favors a vendor/implementation partner
It’s a real competitive differentiator	Yes	No	Possible (co-build)
You have deep internal ML/data engineering capacity	Yes	N/A	N/A
Time-to-production is a hard constraint	No	Yes	Yes
It has to connect to many systems	Higher risk	Depends on the vendor	Yes, usually a vendor’s strength
Compliance requirements are well-defined and common	N/A	Yes, the vendor likely already handles it	Yes
You have budget for ongoing internal maintenance	Yes	Lower ongoing burden	Shared

MIT’s finding, that vendor-supported deployments succeed roughly twice as often as in-house ones, isn’t an argument to buy everything. It’s an argument to be honest about which of the factors above actually apply before defaulting to building it yourself, which often turns out slower and more expensive than it looks on a budget line.

Common pitfalls

1. No measurable success metric at approval, the reason that comes up most often across the RAND, MIT NANDA, and S&P Global research.
2. Treating the pilot’s evaluation set as good enough for production, a handful of hand-picked prompts doesn’t represent real production traffic.
3. Underestimating integration as “a few API calls,” usually where in-house timelines blow past the 8-month average.
4. Building governance after the pilot succeeds, rather than alongside it.
5. No accountable business owner past the pilot, IT-sponsored projects without one rarely survive a budget review.
6. Buying “agentic” without checking whether it actually is, given how few vendors marketing agentic AI have genuine capability, this deserves a specific vetting step.
7. No kill criteria, without a defined way to fail, pilots don’t die, they just quietly consume budget.

Measuring ROI in a way that survives a board meeting

With boards increasingly asking how companies can make money with AI, and most organizations still unable to show enterprise-level impact, ROI needs three things to hold up under scrutiny: a comparison group, so the result can be attributed to the AI rather than to concurrent process changes; a fully loaded cost that includes integration, governance, and the human oversight time the system actually requires, not just the license fee; and a measurement window agreed before the pilot starts, so the final number can’t be accused of being cherry-picked from the best week.

A hypothetical example

This scenario is a composite, built to show how the pieces above fit together. It doesn’t describe a real company, a real Madeesy client, or actual figures.

A mid-market logistics company pilots an AI tool to draft responses to routine shipment-status questions. It does what Step 1 asks: a named owner (the customer service director), a measurable goal (cut first-response time from 6 hours to under 1, measured weekly), and a small evaluation set. Six weeks in, the goal is met.

Then the project stalls for four months, not because the AI stopped working, but because Step 3 was never scoped alongside the pilot. There’s no process for when the vendor updates its model, no record of what produced a wrong answer that got escalated to an angry customer, and no one assigned to review the roughly 3% of responses flagged as low-confidence. Governance was never made responsible for lineage logging during Step 2, so nobody owned it until the pilot’s own success forced the question.

Done the way this roadmap describes, the same company assigns governance as responsible for lineage logging from the start, builds the technical-controls layer alongside the pilot instead of after it, and reaches “production-ready” inside the original pilot window, not four months later.

FAQs

How long should a pilot run before deciding to scale or kill it? Usually 6 to 12 weeks for a well-scoped pilot with real data, long enough to trust the result, not so long that urgency fades. Companies that reach production average about 8 months total, so the pilot itself should be a small piece of that, not most of it.

What predicts whether a pilot reaches production? Having a specific, measurable goal before the pilot starts. It’s the factor that comes up most consistently across the RAND, MIT NANDA, and S&P Global research reviewed here.

Should we build our own AI agents or buy from a vendor? Use the build/buy/partner table above rather than a blanket rule. Vendor-supported projects succeed more often mainly because integration is harder than expected, but building in-house still makes sense when the use case is a genuine differentiator and your team has the capacity.

How many AI use cases should be in production at once? Fewer than most companies attempt. ModelOp’s 2026 benchmark found over 100 proposed use cases against fewer than 25 in production; the gap is rarely a shortage of ideas.

Does the EU AI Act matter if we’re not based in Europe? Possibly, it applies to AI systems that affect people in the EU, regardless of where the company is based. The high-risk deadlines have been shifting, so confirm the current timeline directly rather than relying on any single article.

Closing thought

The companies beating these failure rates aren’t using better models or bigger budgets. They have a named owner, a measurable goal set before the pilot starts, and governance built alongside the work instead of after it succeeds. None of that is a technology problem, which is also why a better vendor alone won’t fix it. Treat this roadmap as how you run AI projects going forward, not a one-time plan for a single pilot.

Sources

1. RAND Corporation, AI project failure rate analysis, 2024
2. MIT Project NANDA, “The GenAI Divide” (Aditya Challapally et al.), August 2025
3. McKinsey & Company, “The State of AI: Global Survey 2025,” November 5, 2025, mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
4. Gartner, Inc., “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” press release, June 25, 2025, gartner.com/en/newsroom
5. S&P Global Market Intelligence, enterprise AI proof-of-concept and production research, 2025
6. ModelOp, 2026 enterprise AI production benchmark (cited via secondary reporting)
7. Deloitte, enterprise AI failure cause analysis, organizational vs technical (cited via secondary industry reporting)
8. Neomanex, 2026 enterprise AI adoption analysis (cited via secondary reporting)
9. EU Digital Omnibus on AI, provisional political agreement, May 7, 2026, and related EU AI Act timeline tracking (cross-verified across multiple legal-industry trackers)