The short answer: an AI project moves through six stages: scope, prove, pilot, harden, launch and run. Each handover between them is a gate, where a different person needs different evidence before they'll say yes. That's where most projects stall, and the biggest drop is between pilot and production. In our view, most stalls are set up a stage before they show. The pilot nobody can decide on usually had no baseline when it was scoped.
Why do AI projects stall?
AI projects stall at handovers, not in the middle of the work. Most get planned as two steps: build it, then launch it. In practice there are six stages, and at each handover someone new has to say yes.
That someone changes each time. The sponsor approves the idea. The data owner decides whether you can use the data. A team lead decides whether their people will change how they work. Security decides whether it can touch live systems. Finance decides whether it's worth the running cost. Each of them wants different evidence.
A project built to impress the first audience reaches the next gate without what that person needs. The numbers show how often that happens. In S&P Global Market Intelligence's 2025 survey, the average organisation scrapped 46% of its AI proofs of concept before production (S&P Global via CIO Dive, March 2025). Deloitte found only 25% of organisations had moved 40% or more of their AI pilots into production (Deloitte, January 2026).
The fix is mostly timing. We call it the one-stage-early rule: start the work each gate needs in the stage before it. Book the security review during the pilot, not after it. Set the baseline at scoping, not when finance asks.
The same rule applies between phases. Plan the next phase before the current one closes, or the project stalls in the gap while everyone waits for a decision.
Each gate also needs more than two answers. Go and no-go aren't enough: a project can go ahead, stop, drop back into a smaller experiment, or move to a different delivery path altogether.
That last answer matters more than it sounds. Plenty of AI projects turn out to be a data problem, a platform gap, a vendor decision or a broken process wearing an AI badge. Handing them to whoever owns that problem counts as a good outcome, and it's far cheaper than forcing them through the next gate.
The AI project lifecycle at a glance
A project moves down the left column one gate at a time. The right column is where it typically stops, and it only counts as a success once it passes the five checks 90 days after go-live.
What are the stages of an AI project?
The six stages are scope, prove, pilot, harden, launch and run. Each one answers a different question, and each has its own typical way of stalling.
1. Scope: is this worth solving?
Scoping picks one process, maps how it works today and puts a number on what it costs. It also checks that the data exists and that someone will own the result.
This is the stage to decide which projects go ahead at all, and it's where Intersect's Three Ps framework does its work. Test every candidate against People (will the team actually use it?), Profit (is the value measurable?) and Practicality (will it hold up on real data and systems?). A project that's weak on any one of the three gets harder to move at every gate after this.
In a larger organisation, scoping starts one step earlier, with intake. Ideas arrive from every team at once, and without a single front door the loudest one gets scoped first. A simple intake (one place to log ideas, one set of questions, one group that triages them) lets you compare candidates side by side before anyone spends weeks scoping one.
A business with two or three AI ideas doesn't need any of that machinery. It needs someone to pick the best one and scope it properly.
How it stalls: the solution looking for a problem. The project starts from the technology ("we should be doing something with agents") instead of a process with a measurable cost. Nobody can say what better looks like, so the idea sits in a steering committee backlog until it's quietly dropped.
To pass the gate: a named process, a baseline number, a business owner, and confirmation the data can actually be reached.
2. Prove: can AI do this task at all?
The proof of concept tests the core task on a sample of real data, in a sandbox, with the project team. It's a technical question, and it should be answered in weeks.
How it stalls: the data isn't there. The fields are missing, the documents are scans, or the data sits in a system nobody can export from. The other failure is a proof of concept with no pass mark ("let's see what it can do"), which can't fail, so it can't succeed either.
To pass the gate: results on representative data, not a cherry-picked sample, measured against a bar agreed before the build.
3. Pilot: will people use it, and is it worth it?
The pilot puts the system in front of a small group of the people who'll actually use it, inside their real workflow, for a fixed period. This is the first stage where behaviour matters more than accuracy.
It's also the first time the Three Ps get tested with real evidence rather than estimates. The scoping answers on People, Profit and Practicality either hold up here or they don't.
How it stalls: pilot purgatory. There's no agreed definition of success and no decision date, so the pilot gets extended instead of decided. Usage drifts down, value isn't measured, and every review ends with "let's give it another month".
To pass the gate: intended users using it, a measured result against the scoping baseline, and a go or no-go decision on a date set in advance.
4. Harden: will it survive the real business?
Hardening turns a working pilot into something the business can depend on. It means live connections to core systems, security and privacy sign-off, permissions, monitoring, a fallback for when it's wrong, and a budget for running it.
How it stalls: stuck in IT. The pilot ran on an export. Production needs the ERP or CRM, and the security review and legacy integration take longer than the whole pilot did. Meanwhile the running cost turns up for the first time and nobody has budgeted for it.
To pass the gate: IT and security sign-off, a named person to run it day to day, a tested fallback and an agreed running budget.
5. Launch: does it work beyond the keen group?
Launch rolls it out past the pilot team to everyone it's meant for, with training and support. The new users weren't hand-picked and didn't ask for it.
How it stalls: the launch nobody noticed. It goes out with an all-staff email and a training video. The pilot group was enthusiastic, the wider team isn't, and nobody knows who to ask when it gets something wrong. Usage never gets close to the pilot's.
To pass the gate: adoption across each rollout group, not just the first, and a support route people actually use.
6. Run: is it still earning its keep?
Running means owning the system as part of normal operations. Someone tracks the number it was built to move, watches for errors and updates it as the process changes.
How it stalls: the zombie system. It's technically live and nobody uses it, or it's used and slowly getting worse. AI systems drift as data and processes change, and with no owner watching, nobody notices until a customer does. When the original champion leaves, it goes with them.
There's no gate after this one. There's a test, and it comes 90 days after launch.
What does success look like after go-live?
Go-live is a date. Success is a state you can only check later. Most projects celebrate the first and never check the second, which is how zombie systems happen.
Go-live means the system is in production for its intended users, connected to the real systems, with someone named to run it and a way to tell when it's wrong. That's the start of the measurement, not the end of the project.
Ninety days later, run five checks. A project that passes all five is a success:
- Used: the intended users use it most weeks without being chased.
- Measured: the number from scoping has moved against its baseline, and someone reports it.
- Owned: a business owner and a run owner are named, with time and budget for it.
- Watched: errors and drift are monitored, and the fallback has been tested for real.
- Repeatable: the next use case can reuse the data, connections and approvals, so it goes faster.
The last check is the one that pays back. The first AI project in a business carries most of the setup cost: data access, security patterns, the approval path. A second project that reuses all of that should move through the stages much faster than the first.
When doesn't this lifecycle apply?
The six stages fit a custom AI system built into a core process. Plenty of AI work isn't that.
Buying an off-the-shelf tool, like rolling out Copilot or Claude to a team, mostly skips prove and harden. The vendor has done that work. Launch and run then carry nearly all the risk, so put the effort there.
A small internal automation can go through all six stages in a few weeks. The stages still happen, but one person might clear three gates in a single conversation. That's fine, as long as someone still asks each gate's question.
Regulated businesses add gates. In financial services, health or government, the data and model reviews can be as long as everything else combined. The one-stage-early rule matters most here: start those reviews at scoping.
And the stages overlap in real projects. They're a sequence of decisions, not a waterfall plan. Stopping at a gate because the evidence says no means the model is working, and it's much cheaper than a zombie.
What to do next
List every AI project you have running, and write the stage each one is in next to it. Then add the gate it's heading for and who decides at that gate. For each project, check whether anyone is collecting the evidence that person will ask for. Where nobody is, that's your stall, and you can see it before it happens.
If you're setting up a gating process across the whole business, run two real projects through it before you roll it out. The process will need changing, and it's better to find that out on two projects than on twenty.
Not sure where your projects really sit? Book a call and we'll map them against the six stages with you, gate by gate. Our AI Development Studio takes projects from proof of concept through to production.
FAQ
How long does it take an AI project to reach production?
It depends more on the harden stage than on the build. A small internal automation can go live in weeks. A system that touches core platforms in a regulated business can take many months, mostly waiting on integration and review.
What's the difference between a proof of concept and a pilot?
A proof of concept tests whether AI can do the task, on sample data, with the project team. A pilot tests whether it does the job, with real users on real data inside their workflow. Plenty of stalled pilots were proofs of concept with a bigger launch.
Who should own an AI project?
A business owner from scoping, accountable for the result, and a run owner from the harden stage, responsible for keeping it working. IT and the delivery partner support both roles but shouldn't hold either one. A project owned only by IT tends to become a zombie system.