A pilot that works is the most dangerous thing in enterprise AI. It generates a demo, a slide and a sponsor, and it creates the impression that the hard part is over. In most organisations the hard part has not started. The enterprise AI pilot to production journey is where the majority of initiatives stall, and the reasons have little to do with the model that passed the pilot.
The evidence for this is now unusually consistent, even where the headline numbers appear to contradict each other. McKinsey's State of AI survey, fielded in June and July 2025 across 1,993 participants in 105 nations, found that 88 per cent of organisations use AI regularly in at least one function, yet only about one-third report that they have begun to scale their AI programmes, and only 39 per cent attribute any EBIT impact to AI at all, most of them under 5 per cent of EBIT. The MIT NANDA report "The GenAI Divide", published in August 2025, was reported under the headline that about 95 per cent of enterprise GenAI pilots deliver no measurable profit-and-loss impact. EY India's survey of over 200 Indian enterprise leaders, published in November 2025, found 23 per cent still at the pilot stage, 47 per cent with multiple GenAI use cases live and 10 per cent scaling across the business.
These surveys measure different things, and the differences matter, which this article addresses first. But they agree on the shape of the problem: wide use, narrow value, and a thin funnel between the two. This piece sets out why that funnel is thin. It proposes the Pilot-to-Product Gap, six specific reasons that a pilot can pass every test set for it and still fail to become a sustainable product, with the practical tests that distinguish a pilot that will scale from one that will not.
What the surveys measure about the enterprise AI pilot to production funnel
The 95 per cent figure deserves scrutiny before it is used, and it has received it. The MIT NANDA report was based, according to its own methodology section as reported by secondary coverage, on a systematic review of more than 300 publicly disclosed AI initiatives, 52 structured interviews and 153 survey responses collected at four industry conferences between January and June 2025. Early press coverage, including Fortune, reported larger counts (150 interviews and 350 employees surveyed), a discrepancy the report's readers later noticed. The report was not peer reviewed. A detailed critique on the 80,000 Hours podcast in 2026 noted that the 95 per cent did not describe pilots failing in the ordinary sense: of surveyed organisations, around 80 per cent had never piloted custom enterprise tools at all, and of those that had, roughly a quarter succeeded, with success defined as a "marked and sustained" productivity or profit-and-loss impact within six months, terms the report does not define. The same critique observed that the authors work on agentic AI frameworks, including the NANDA project the report names as the remedy, without a conflict-of-interest disclosure.
None of this makes the report worthless. Its finding that customised tools built through external partnerships reached deployment about 67 per cent of the time against about 33 per cent for internal builds, drawn from the interview sample, is directionally useful and consistent with EY India's finding that 91 per cent of Indian leaders rank speed of deployment as the top buy-versus-build factor. Its observation that most GenAI systems "do not retain feedback, adapt to context, or improve over time" fairly describes why individual productivity tools stall when asked to carry a workflow. But the 95 per cent should be read as "95 per cent of organisations had not yet achieved a sustained P&L result from a custom GenAI tool within six months", a far narrower statement.
McKinsey's figures, by contrast, measure self-reported use and self-attributed EBIT impact across a large, GDP- weighted sample. The one-third scaling figure is the closest comparable to a production rate, and the 39 per cent attributing any EBIT impact is the closest comparable to a value rate. Read together, the two surveys describe the same funnel from different ends: roughly nine in ten organisations use AI, roughly one in three has scaled something, roughly one in three sees any profit effect, and a small minority (McKinsey's high performers are about 6 per cent of respondents, attributing 5 per cent or more of EBIT to AI) see a result that would survive a board review.
EY India's data adds the Indian texture. The 47 per cent of respondents who say that over 10 per cent of their proofs of concept have moved to production is usually quoted as good news. Its complement is that for about half of Indian enterprises surveyed, fewer than one in ten pilots reach production. That is the enterprise AI pilot to production gap in a single statistic.
The Pilot-to-Product Gap: six reasons pilots pass and products fail
A pilot is an experiment designed to answer a narrow question, usually "can the model do this task to an acceptable standard on our data?" A product is a system that performs the task every day, for every case, inside the organisation's controls, at a cost that is less than the value it creates, with someone accountable for it. Each of the six gaps below is a dimension on which the pilot was never tested and the product is tested continuously.
Gap 1 the metric changes
Pilots are scored on model metrics because that is what a pilot can measure in eight weeks. Products are scored on money because that is what a CFO can measure in a budget cycle. The two are related only through a chain of assumptions about volume, exception rates, review time and avoided cost that the pilot never tested. McKinsey's high performers differ from the rest of the sample less in their model quality than in their intent: they are more than three times as likely to say they intend to use AI for transformative change and nearly three times as likely to have fundamentally redesigned workflows. Redesigning a workflow is the act of writing down what the metric will be in production. Organisations that skip it carry an accuracy number into a meeting that wants a rupee number.
Gap 2 the data was borrowed
Almost every pilot runs on an extract. Someone pulls six months of records, removes the obviously broken rows, anonymises what legal asks them to, and hands the model a clean file. The product has no extract; it has a connection to a live system owned by another department, with fields that change, access that must be renewed, and a data- protection obligation that now attaches to a running service rather than a one-off study. In Indian manufacturing, where PanScience's industrial AI venture PredCo works on predictive maintenance for plants, the pattern is familiar: a model that performs well on historical sensor logs from one line must, in production, ingest signals from controllers of several vintages, each with its own tags and sampling rates, and the integration work exceeds the modelling work by a wide margin. The pilot proved the model. It did not prove the plumbing.
Gap 3 the exceptions were someone else's problem
A pilot that handles 85 per cent of cases is a success. A product that handles 85 per cent of cases has created a new job: the person who handles the other 15 per cent, under time pressure, with a system that has already made a wrong guess. If that job is not designed, staffed and costed, the production system is slower than the manual process it replaced, because the human now reviews everything to find the failures. The MIT NANDA report's observation that most GenAI systems do not retain feedback or improve over time is really an observation about this gap: without a loop from the exception handler back into the system, the exception rate never falls, and the cost line never improves. In judicial workflow automation, where PanScience's Nyaay AI reports deployments across 14 or more Indian High Courts, the exception path is not optional; a misclassified case record is not a statistical error but a matter a registry officer must correct, and the product is the correction workflow as much as the classifier.
Gap 4 the champion is not an owner
Pilots are funded from discretionary money by a champion who wants it to work. Products need a cost centre, a recurring budget line, a service level and a person whose appraisal depends on it. The two are rarely the same. When the champion is promoted, moves or loses interest, the pilot has no home. EY India's finding that 76 per cent of Indian leaders expect significant business impact from GenAI sits alongside the finding that only 10 per cent are scaling across the business; the distance between expectation and scaling is, in large part, the distance between a champion and an owner. The test is blunt: ask which budget pays for the model's inference, monitoring and support in the second year. If the answer is "the innovation budget", the product has not yet been born.
Gap 5 the pilot was exempt from the controls the product must pass
Pilots are routinely granted exemptions: a sandbox environment, synthetic or anonymised data, a waiver from the vendor-risk process, a verbal agreement with information security. Every exemption is a liability the product inherits. India's Digital Personal Data Protection Act 2023 and its Rules, notified on 14 November 2025 with an 18-month phased window, add obligations on significant data fiduciaries including local storage of specified data. The Reserve Bank of India's payment-data localisation circular of 2018 and SEBI's 2023 framework for cloud adoption bind their sectors. RBI's FREE-AI committee report of August 2025 sets out seven sutras and 26 recommendations for responsible AI in finance, not yet binding regulation but a clear signal of what examiners will ask. A pilot that has not been through these gates has not demonstrated that the product can exist. A practical rule: run the pilot through the same security questionnaire and data-protection assessment a production vendor would face, and treat the time this takes as part of the pilot's schedule. Organisations that do this find that it often takes longer than the modelling.
Gap 6 the pilot solved one case and the product must solve a class
A pilot is tuned to one site, one team and one workflow variant. A product must work at every site, be documented so that a team that did not build it can run it, be supported when it breaks at 2 a.m., and ideally be adopted by a second business unit that was not in the original meeting. None of this is funded by the pilot budget, and none of it is interesting to the people who built the pilot. This is the gap the venture-building world calls productisation, and it is the reason internal tools so rarely become durable assets: nobody was paid to make them general. A separate PanScience Research piece in the venture-studio cluster covers how enterprise capabilities are commercialised and the terms that keep a co-built product independent; the point here is narrower. If no one has budgeted for the second site, the second team and the documentation, the pilot will remain a pilot however well it performs.
Why pilots pass anyway
Three incentives explain why organisations run pilots that are structurally unable to become products. Pilots are cheap and visible: a few lakh rupees, a quarter, and a demo for the board, against a production system that costs an order of magnitude more, takes a year and produces a line in the operating budget. Vendors are paid for pilots: the MIT NANDA finding that externally sourced tools reached deployment twice as often as internal builds is partly a selection effect (a vendor with a product has already crossed gaps 2, 5 and 6 for someone else) and partly because an external party has a commercial reason to push for production, where an internal team's pilot was the deliverable. And the pilot's success criteria are set by the people who want it to succeed, whereas McKinsey's finding that 51 per cent of organisations using AI report at least one negative consequence is a reminder that the production system will be judged by auditors, customers, regulators and the finance team.
Closing the gap: design the product before the pilot
The six gaps are not discovered after the pilot; they can be written down before it, and a pilot can be designed to test them.
Write the unit-economics line first. State the cost per transaction the product must beat, including the human review time at the expected exception rate, and design the pilot to measure exception rate and review time, not only accuracy.
Pilot on the live feed, not an extract, even at low volume. A model that reads from the real system at one record a minute has tested the plumbing. One that reads from a spreadsheet has not.
Staff the exception path from day one, and build the feedback loop into the pilot. The rate at which the exception rate falls over the pilot period is a better predictor of production viability than the starting accuracy.
Name the owner and the year-two budget before the pilot starts. If no cost centre will commit to the second year, the pilot should be reclassified as research, which is a legitimate activity with different expectations.
Run the pilot through production controls. Treat the security review, the data-protection assessment and the procurement process as part of the pilot's scope and schedule.
Design for the second site. Document as you build, choose integration patterns that do not depend on one plant's or one department's quirks, and ask which other unit would adopt the product if it worked.
None of this is novel, and all of it is routinely skipped, because each step makes the pilot slower, more expensive and less likely to produce a clean demo in a quarter. That is the trade. Organisations that want products rather than pilots have to accept pilots that look worse and take longer, because they are testing the right things.
Conclusion
The surveys agree more than their headlines suggest. Use is near universal; scaling is a minority; measurable profit is a small minority; and the Indian data shows the same funnel with a slightly later starting point. The reason is not that the models fail. It is that a pilot answers "can the model do this?" and a product must answer six other questions about money, data, exceptions, ownership, controls and generalisation that the pilot was never asked. Enterprises that write those six questions down before the pilot, and design the pilot to answer them, will have fewer successful pilots and more products. That is the correct trade, and the one the current incentive structure makes hardest to choose.
Methodology and sources
This article is an analytical synthesis. The Pilot-to-Product Gap framework and its six gaps are the author's own classification and are illustrative; they are not drawn from a dataset. The worked examples from PanScience ventures (PredCo in industrial AI and Nyaay AI in judicial workflow automation) describe patterns of practice at the level stated on panscience.xyz and are company-reported; no client of any PanScience venture is named and no deployment figures beyond the company's published descriptions are used.
Survey figures are observed from the following sources. McKinsey, The state of AI in 2025, survey of 1,993 participants in 105 nations fielded 25 June to 29 July 2025 (https://www.mckinsey.com/capabilities/tech-and-ai/our- insights/the-state-of-ai-2025): 88 per cent regular use, about one-third scaling, 39 per cent any EBIT impact, high performers about 6 per cent, workflow redesign and transformative-intent multipliers, 51 per cent reporting a negative consequence. EY India, The AIdea of India: Outlook 2026, survey findings, 16 November 2025 (https://www.ey.com/en_in/insights/ai/agentic-ai-india/aidea-survey-findings): 23 per cent pilots, 47 per cent multiple use cases live, 10 per cent scaling, 47 per cent reporting over 10 per cent of PoCs in production, 76 per cent expecting significant impact, 91 per cent ranking speed of deployment first. MIT NANDA, The GenAI Divide: State of AI in Business 2025, as reported by Fortune, 18 August 2025 (https://fortune.com/2025/08/18/mit-report-95-percent- generative-ai-pilots-at-companies-failing-cfo/), Virtualization Review, 19 August 2025 (https://virtualizationreview.com/articles/2025/08/19/mit-report-finds-most-ai-business-investments-fail-reveals- genai-divide.aspx) and Let's Data Science (https://letsdatascience.com/news/mit-report-documents-genai-pilot-roi- gap-e0924d7d); methodological critique from the 80,000 Hours podcast, recorded 13 February 2026 and published 28 April 2026 (https://80000hours.org/podcast/episodes/ai-workplace-mit-study/). Regulatory references: DPDP Rules notified 14 November 2025 (PIB), RBI payment-data localisation circular of 6 April 2018, SEBI cloud framework of 6 March 2023, and the RBI FREE-AI committee report of August 2025 (RBI press release and KPMG summary), as held in the PanScience Research editorial register.