PanScience Innovations
← Media & insights
BlogOctober 25, 2026

Enterprise AI commercialisation: how an internal tool becomes a company, and the five tests that tell you whether it should

PanScience Research
Enterprise AI commercialisation: how an internal tool becomes a company, and the five tests that tell you whether it should

Every large enterprise that has spent the last three years on AI now owns something it did not plan to build: a stack of internal tools that work. A document classifier the compliance team cannot live without. A retrieval system over maintenance logs that the plant engineers trust more than the vendor manual. A gateway that routes model calls, logs them and strips out personal data before anything leaves the network. None of these was commissioned as a product. Each was built to solve one team's problem, and each now has a small group of people inside the company who suspect that other companies have the same problem and would pay to have it solved.

That suspicion is the starting point of enterprise AI commercialisation: the process by which a capability built for internal use becomes a product sold to others, and sometimes a company in its own right. It is an old corporate instinct with a new object. What is different about AI tools is that the capability is usually inseparable from the data it was trained or tuned on, the people who built it are scarce and expensive, and the thing that makes it valuable inside the enterprise, its fit to one organisation's workflows and vocabulary, is precisely what makes it hard to sell to a second.

This article sets out why the question is arriving on boards' agendas now, what the evidence from corporate venture building says about the odds, and a five-part readiness test that an enterprise, a GCC or a venture builder can apply to any internal AI capability before deciding whether to productise it. The test is this article's original contribution. It is deliberately severe, because most internal tools should stay internal, and the cost of discovering that after a spin-out is far higher than the cost of discovering it before.

Why enterprise AI commercialisation is a live question in 2026

Two sets of survey evidence explain the timing. The first is about how much AI capability now sits inside enterprises. McKinsey's State of AI 2025 survey of 1,993 participants in 105 nations found that 88 per cent of organisations use AI regularly in at least one function, up from 78 per cent a year earlier, and that about one-third have begun to scale AI programmes across the enterprise. Scaling is the point at which a tool stops being an experiment and acquires an owner, a budget and a roadmap, and about a third of large organisations have reached it somewhere.

The second is about what enterprises intend to do with that capability. McKinsey's sixth annual survey on corporate venture building, published in October 2025 and fielded among 715 senior managers and C-level executives in 66 nations at companies with at least $100 million in revenue, found that 56 per cent plan to build data, analytics or AI- driven businesses within five years, up from 49 per cent in 2024. About 72 per cent of companies that built ventures from underused assets reported above-average growth. The same survey found that nearly one-third of data- or IP- focused ventures broke even with under $1 million invested, a far higher share than physical-product ventures, and that digital products and services generated the highest average revenue of any venture type.

The earlier edition of that survey, published in October 2024 among 1,176 executives, put the stakes in enterprise terms: ventures launched in the previous five years generated 13 per cent of enterprise-wide revenue and 16 per cent of enterprise value, and respondents expected new ventures to supply 24 per cent of revenue within five years. BCG's 2022 analysis of corporate venturing models, drawn from its own record of more than 200 launched ventures, reported a 66 per cent success rate for a disciplined corporate venture-building approach against 20 to 30 per cent for traditional and corporate venture capital. That figure comes from a venture builder describing its own method and should be read as such, but the direction of all three sources is the same: enterprises are increasingly treating internal digital capabilities as candidate businesses, and the ones built on data and software are the cheapest to prove.

There is an India-specific reason the question is sharp here. India's enterprises, its IT services firms and the more than two thousand global capability centres operating in the country have, between them, built an enormous volume of internal AI tooling for parents and clients. A separate PanScience Research piece, on GCCs and where India's enterprise AI capability sits, examines who owns that capability. This article is about what happens when someone decides to sell it.

Three routes out of the building

An internal AI capability can leave the enterprise by three routes, and they are not interchangeable.

The first is licensing: the enterprise keeps the tool and the team and sells access to peers or through a vendor. This is the lowest-risk route and the lowest-ceiling one. It works for clean components, an evaluation harness, a domain tokeniser, a labelled dataset, and fails when the buyer needs the tool adapted, supported and roadmapped, because the enterprise is not organised to do any of those for an outside customer.

The second is the spin-out: a new company, a transferred team, an IP assignment or licence, and the parent as first customer and shareholder. This is the route the corporate venture-building surveys describe. Its central difficulty is that the parent is simultaneously the venture's largest customer, largest shareholder and the author of its specification. McKinsey's 2024 survey found that expert venture builders were twice as likely as novices to give new ventures a high degree of decision-making independence from the core business. Independence is what separates a company from a captive supplier.

The third is the co-build: the enterprise contributes the problem, the data access and the first contract, a venture builder contributes the team, the product discipline and the second customer, and both hold equity in a company neither controls outright. A separate PanScience Research piece, on co-build as a de-risking engine and the terms that keep the venture independent, sets out the contractual mechanics. The relevant point here is that the co-build is designed around the two failure modes the readiness test below is built to catch: the venture that never finds a second customer, and the venture that never owns its data rights.

The enterprise AI commercialisation readiness test

The test has five parts. Each is framed as a question with an observable answer, because the purpose is to replace the sponsor's conviction with evidence that a sceptical board, an investor or a venture builder can inspect. A capability that fails two or more should not be commercialised in its current form. A capability that passes all five is rarer than its sponsors believe.

TestThe questionWhat a pass looks likeWhat a fail looks likeWhy it matters
1. Second customerHas an organisation that is not the parent, and not a subsidiary or supplier of the parent, agreed to pay for this?A signed paid pilot or contract with an unrelated buyer, or a written letter of intent with a price, from a buyer who did not see the tool through the parentInterest from peers at conferences; a parent subsidiary as "second" customer; a free pilot with no conversion termsThe parent's willingness to pay proves nothing about the market. The first unrelated buyer reveals whether the tool is a product or a bespoke fit to one organisation
2. Data rightsCan the venture lawfully train, tune, evaluate and operate the product for other customers using what it has today?Written assignment or licence covering training data, fine-tuned weights, prompts and evaluation sets; personal data handled under DPDP Act obligations with consent or lawful basis that survives the transfer; no third-party vendor terms that prohibit resaleModel tuned on customer data the parent cannot share; weights derived from a vendor model whose licence forbids commercial redistribution; "we will sort out the data later"An AI product is inseparable from its data lineage. A venture that cannot prove the right to its own weights cannot pass a buyer's security review or an investor's diligence
3. Dedicated teamWill the people who built it move to the venture full time, and do they include the ones who understand the data?Named engineers, a product owner and a domain expert with signed transfer or secondment terms; parent has agreed a backfill planBuilders remain in the parent and support the venture "as needed"; the only person who understands the data pipeline stays behindMcKinsey's 2024 survey found expert builders more than twice as likely to have a dedicated leader for venture building. Part-time teams build part-time products
4. MarginDoes the unit economics of serving an outside customer leave a software-like gross margin after inference, integration and support?A costed model of one customer deployment showing inference, hosting, integration and support per account, with a gross margin a software investor would recognise; the pilot priced on that model, not on cost recoveryPrice set at what the parent's budget allows; integration effort per customer equal to the original build; margin unknownA tool that costs as much to deploy for the second customer as it did to build for the first is a services business. That can be a good business, but it is not the one the sponsor is pitching
5. IndependenceCan the venture say no to the parent?Parent holds a minority or a defined non-controlling position; roadmap owned by the venture; parent contract on commercial terms with a defined term and no exclusivity beyond a short window; venture can sell to the parent's competitorsParent controls board and roadmap; perpetual exclusivity; parent pricing below cost; venture staff still on parent payroll and performance reviewsWithout independence the venture is an outsourced engineering department with a cap table. Buyers, investors and talent all price this correctly

Three features of the test deserve explanation.

The first is the strictness of the second-customer test. Sponsors of internal tools routinely report demand from peers, and the demand is usually real, but it is demand for the outcome, not for the tool. A peer bank wants its compliance team to read regulatory feeds faster; whether it wants this particular classifier, trained on this bank's taxonomy, on this stack, is a question only a contract answers. Gartner's research on B2B buying, with buying groups of six to ten people and suppliers getting about 5 per cent of a buyer's time, describes why interest and purchase sit so far apart. EY India's AIdea of India survey of over 200 enterprise leaders, published in November 2025, found that 91 per cent rank speed of deployment as the top buy-versus-build factor. A second customer who has actually deployed is the only evidence that the tool is fast to deploy anywhere but home.

The second is that the data-rights test is where Indian enterprises most often discover a problem they did not know they had. The Digital Personal Data Protection Rules, notified on 14 November 2025 with an eighteen-month phased window, impose additional obligations on significant data fiduciaries, including local storage of specified data. A tool tuned inside a bank on customer interactions, under the bank's consent terms, may be perfectly lawful for the bank and unlawful for a spun-out venture serving other banks, because the consent did not contemplate the transfer. The same applies to vendor terms: a fine-tune of a commercially licensed model may be permitted for internal use and prohibited for resale. Neither problem is fatal if found before the spin-out. Both are expensive if found during a buyer's security review.

The third is that margin and independence are tested together because they fail together. A parent that controls the venture's roadmap will specify features for itself, which drives up per-customer integration cost, which destroys margin, which makes the venture dependent on the parent's contract, which reinforces the parent's control. The McKinsey 2025 survey's finding that ventures passing $10 million in revenue averaged 31 months old, down from 38 months a year earlier, describes the speed at which a well-run venture should be finding customers beyond its parent. A venture still deriving most of its revenue from its parent after three years has usually failed the independence test, whatever the shareholder agreement says.

Reading the pattern of results

Applied honestly, the test tends to produce one of four patterns, and each points to a different decision.

A capability that passes tests 2, 3 and 5 but fails 1 and 4 is an internal asset with no proven market. The right move is not to spin it out but to run a structured search for a second customer, ideally with a venture builder or sector partner who can reach unrelated buyers, and to cost a real deployment. Many such capabilities are best licensed as components rather than sold as products.

A capability that passes 1 and 4 but fails 2 is a product with a legal problem. It can usually be fixed, by rebuilding the training set from lawfully transferable data, renegotiating vendor terms, or designing the product so each customer's data stays within that customer's tenancy, but the fix must precede any external sale. This is the pattern most often found in BFSI and health, where the data that made the tool good is exactly the data that cannot travel.

A capability that passes 1, 2 and 4 but fails 3 and 5 is a captive supplier in the making. The parent wants the upside of a venture without releasing the team or the control. This is the pattern co-build structures exist to address, by bringing in a second shareholder whose interest is the venture's independence, and it is the pattern that most often ends in quiet re-absorption into the parent two years later.

A capability that passes all five is ready, and should move quickly, because the window in which an internal tool is ahead of the vendor market is short. The MIT NANDA report of August 2025, whose methodology has been criticised and whose headline figure of 95 per cent of enterprise GenAI pilots delivering no measurable P&L impact should be treated with care, made one finding that bears directly on commercialisation: purchased vendor tools reached production roughly twice as often as internal builds. A spin-out, the moment it leaves the parent, competes with vendors who have already solved deployment, and must do so on product quality and domain fit rather than on its parentage.

What the economics of data and IP ventures suggest

The corporate venture-building data offers a rough calibration of what a well-chosen commercialisation should cost and when it should pay back. In the McKinsey 2025 survey, the weighted average investment to break even fell to about $77 million from about $125 million a year earlier, an average dominated by physical and industrial ventures with long build periods. The relevant benchmark for an AI tool that already exists is the report's observation that nearly one-third of data- or IP-focused ventures broke even with under $1 million invested, and that more than eight in ten ventures broke even within three years. The capability is built; the money goes into finding customers and hardening the product.

Serial builders did better than first-timers on every measure. Companies that had launched three or more ventures generated 1.9 times revenue per dollar invested before break-even against 1.3 for those with one or two, and 59 per cent of them said venture building provided over 10 per cent of enterprise revenue, compared with 32 per cent of those who had launched one. For an enterprise contemplating its first spin-out, this is an argument for partnering with someone who has done it before rather than for building the muscle alone, and it is the economic logic behind the venture studio model that a separate PanScience Research piece on how venture studios make money sets out.

Venture builders with a portfolio in AI infrastructure see the pattern from the other side. PanScience Innovations, the New Delhi deep-tech venture studio, reports that eight of its 24-plus co-founded ventures sit in AI infrastructure, including an LLM gateway, an on-premise enterprise RAG and agent platform, and a control plane for AI-native enterprises. These are company-reported descriptions and this article has no independent measure of their performance, but the categories illustrate the layer at which internal tools most often become products: the plumbing every enterprise builds for itself, once and imperfectly, and that a specialist can build well and sell many times. The readiness test is harshest on exactly this layer, because a gateway that passes the second-customer test is a product, and one that does not is a utility the parent should keep running.

Conclusion

Enterprise AI commercialisation is attractive for the same reason it is dangerous: the capability already exists, the sponsors already believe in it, and the parent is already paying for it. Those three facts make the decision feel cheap. The test set out here is designed to make it honest. A second customer who is not the parent, data rights that survive the transfer, a team that actually moves, a margin a software investor would recognise and a venture that can say no to its parent are not aspirations to be reached after the spin-out. They are the conditions under which a spin-out is worth doing at all.

Most internal AI tools will fail at least two of the five, and that is a verdict on the route, not the tool. A tool that fails the second-customer test may be a fine component to license. A tool that fails independence may be a fine co-build if a second shareholder can be found whose interest is the venture's freedom. The only costly outcome is to spin out a capability that fails the test and discover, two years and one abandoned Series A later, that the market agreed.

Methodology and sources

This article's five-part readiness test is the author's original framework; the pass and fail conditions are illustrative descriptions of practice, not measured thresholds, and the four result patterns are an analytical reading rather than an empirical classification. Survey figures on enterprise AI use are from McKinsey, The State of AI in 2025 (mckinsey.com/capabilities/tech-and-ai/our-insights/the-state-of-ai-2025), fielded 25 June to 29 July 2025 among 1,993 participants in 105 nations. Corporate venture-building figures are from McKinsey, "The way to win in corporate venturing: serial building and AI" (mckinsey.com/capabilities/business-building/our-insights/the-way-to- win-in-corporate-venturing-serial-building-and-ai), published 28 October 2025, a survey of 715 executives in 66 nations fielded 13 to 28 May 2025, and from McKinsey, "How CEOs are turning corporate venture building into outsize growth" (mckinsey.com/capabilities/mckinsey-digital/our-insights/how-ceos-are-turning-corporate-venture- building-into-outsize-growth), published 22 October 2024, a survey of 1,176 executives. The 66 per cent success rate is from BCG, "Corporate venturing models" (bcg.com/publications/2022/corporate-venturing-models), June 2022, and describes BCG Digital Ventures' own record. The EY India figure is from The AIdea of India: Outlook 2026, chapter 2 survey findings (ey.com/en_in/insights/ai/agentic-ai-india/aidea-survey-findings), 16 November 2025. Gartner B2B buying figures are from Gartner's published research on the B2B buying journey. DPDP Rules details are from the PIB release on the notification of 14 November 2025. The MIT NANDA finding is from "The GenAI Divide: State of AI in Business 2025", August 2025, whose methodology has been publicly criticised. PanScience Innovations facts are company-reported from panscience.xyz, read 24 October 2026. No client of any PanScience venture is named and no deployment or revenue figure beyond the company's own published descriptions is stated.

More from Blog
October 25, 2026

Data annotation in India: the hidden data operations layer of Indian AI

Read →
October 25, 2026

Synthetic data for enterprise AI: when it helps and when it lies

Read →
October 25, 2026

Why enterprise RAG fails in production, and how to fix it

Read →
← Back to all media