MIT’s research says 95% of AI pilot programs fail to deliver measurable financial impact. I have spent 25 years in enterprise security, and that number does not surprise me. Most pilots are set up to prove a model can do a task. Almost none are set up to prove the company can run it.
The 5% that make it share a few habits, and two of them are well documented.
The CEO has to own it
McKinsey’s March 2025 State of AI report found that CEO oversight of AI governance is the single factor most strongly correlated with bottom-line impact, particularly at larger companies. Only 28% of organizations using AI report direct CEO involvement in AI governance, and the share drops at companies with more than $500MM in revenue.
So the bigger the company, the less likely the person accountable for the results is anywhere near the decisions. A pilot that lives in an innovation lab has no one to answer for it when it works and no one to defend it when it does not.
Redesign the work, do not just speed it up
The same McKinsey research ranked workflow redesign as the biggest factor affecting EBIT impact from generative AI, ahead of 24 other attributes it tested, including technology choice, investment level and talent. Only 21% of organizations have fundamentally redesigned workflows around AI.
Automation takes an existing process and makes it faster. Redesign asks whether the process should exist at all. MIT Sloan’s “Work Backward” method is a practical way in: break the work into tasks, then sort them into ones AI can replace, ones AI can augment and ones where AI makes a new approach possible.
MIT’s study also found that purchased AI tools succeed about twice as often as internally built ones. That fits. A vendor has already done the redesign work. An internal team tends to automate the process it already has.
The question a pilot does not have to answer
Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by the end of 2025. The proof of concept is the easy part. The hard part is the moment someone asks to put it in front of customers, connect it to production systems and let it act.
At that point the pilot meets a CISO, and the CISO asks a question the pilot was not built to answer: what is this AI allowed to do, and can you show me what it did afterward? A demo does not need an answer. A production system does, and so does the auditor who shows up six months later.
NIST’s AI Risk Management Framework gives this a structure through its four functions, Govern, Map, Measure and Manage. Govern comes first. The framework will not write your policy for you, but it tells you a policy has to exist before the model touches anything that matters.
Where Mountain Theory sits
Pilots that reach production are the ones where someone can answer what the AI is allowed to do and prove it afterward. That is the gap we built for.
Mountain Theory checks the action an AI is about to take against policy written in plain English, before it runs, and returns ALLOW, HOLD or BLOCK. Every decision is logged. The policy is readable by the people who own the risk, and the log is readable by the people who audit it.
That is what turns a pilot into something a CISO, an auditor and a CEO will sign.
If you are running a pilot right now, check three things before it scales: the CEO owns it, the workflow changed rather than getting a model bolted onto it, and you can state in writing what the AI may do and prove what it did. The research covers the first two. We built for the third.