Every IT and software organization we talk to has the same story: a Copilot pilot or an Azure AI proof of concept that impressed everyone in the room, then quietly stalled. Nobody killed it. It just never became something people used every day.
That pattern isn't a coincidence, and it isn't a Microsoft AI problem. Gartner's 2025 research puts the number at 50% of generative AI pilots abandoned after proof of concept, up from the firm's original 2024 prediction of 30%. MIT's Project NANDA study goes further: 95% of enterprise generative AI pilots fail to deliver measurable ROI. Meanwhile, Forrester has found that Microsoft 365 Copilot can deliver up to a 353% three-year ROI for small and midsize businesses, the top of a 132%-353% range tied to a high-impact deployment scenario, when it's deployed with a structured program behind it. The gap between those numbers is the entire story: the technology works, but most organizations aren't set up to carry a pilot across the finish line.
We wrote a full white paper on this, From Pilot to Production: Closing AI Gaps, that breaks down the framework we use with IT and software clients to move AI from a demo into a business capability. This post covers the short version: why pilots stall, and what to fix before you try again.
A pilot is designed to prove that a technology can work. It runs in a controlled group, with a small data set, and usually with someone technical in the room to smooth over the rough edges. Under those conditions, Microsoft 365 Copilot, Azure AI, and Copilot Studio perform well. That's not the question anymore. The question is what happens when the same tool is handed to 300 users who don't have a technical champion sitting next to them, pulling from data that hasn't been cleaned up in years.
That's usually where things go quiet. Nobody announces that the pilot failed. It just stops coming up in meetings. The Copilot licenses are still active. The Azure OpenAI environment is still provisioned. But nothing about how the team works has actually changed, and six months later, someone asks what happened to that AI project.
The honest answer is almost never "the AI didn't work." It's closer to one of these:
Across the IT and software organizations we work with, the pilots that stall almost always share the same three structural gaps. None of them are technology problems. All three are solvable, and all three have to be addressed before a second attempt is worth making.
Data readiness comes first. AI is only as useful as the data it can reach. When Copilot or an Azure AI agent goes looking for context and finds information that's outdated, duplicated, or inaccessible, it produces an answer that sounds confident and is wrong. Users notice fast, and once they stop trusting the output, they stop opening the tool.
Process definition comes second. AI doesn't fix a vague workflow, it amplifies it. If nobody has defined which workflow the AI is supposed to improve, who owns it, and what a good output actually looks like, the pilot has nothing to anchor to. It generates outputs that nobody is quite sure how to act on.
The companies we see fail at AI scale have one thing in common: they treated the pilot as the destination rather than the start.
Governance is the third gap, and it's the one IT leaders underestimate most. Someone has to own approving AI-generated outputs, watching for quality drift over time, and knowing what to do when something goes wrong. In a pilot with a dozen users, an ad hoc response works fine. Across hundreds of users and dozens of workflows, it doesn't hold.
If you can't answer those four questions today, that's the gap the next phase of your AI rollout needs to close, not a reason to add another pilot to the pile. We go deeper on this framework, including the data behind each gap, in the full white paper.
None of this means IT and software organizations should wait to try again. It means the next attempt should target a workflow that's specific enough to measure and important enough to matter. A few patterns are already producing results for companies in this space.
High-volume service desk queues are one of the clearest starting points for AI augmentation, because the inputs and outputs are already structured.
GitHub Copilot and Microsoft 365 Copilot together cover the full developer workflow, from writing code to reviewing it to documenting it.
Copilot Studio agents can handle a meaningful share of routine support volume without removing the human touch from complex cases.
For teams running on Dynamics 365, Copilot integration gives account managers a real edge on a large book of business.
If your organization already has a stalled pilot sitting in the background, the temptation is to relaunch it with more training or a wider rollout. That usually just spreads the same underlying gaps to more people. The better move is to treat the stall as diagnostic information about what's missing.
Organizations that get from pilot to production consistently do a few things differently, and they do them in this order, not all at once.
Skip any one of these and the second attempt tends to end up looking a lot like the first: promising in the room, quiet six months later.
If you've got a Copilot or Azure AI pilot that's stalled, or you're trying to figure out where to start before you launch one, the fastest way to make progress is an honest look at your current data, process, and governance readiness. That's the starting point of TrellisPoint's AI Value Engine, and it's covered in more depth in our white paper, From Pilot to Production: Closing AI Gaps.
TrellisPoint works with IT and software organizations to close the gap between a working demo and a deployed capability, using Microsoft 365 Copilot, Azure AI, and Copilot Studio, unified under a governance model your team actually owns.
Schedule a conversation with the TrellisPoint team to find out which workflows are ready for AI deployment and what's standing in the way.
Contact TrellisPoint