The Enterprise Capital Gate: Bringing venture discipline to the enterprise AI portfolio (Part 1)

In this two-part series, I introduce the Enterprise Capital Gate, the companion instrument to the AI GPS. The AI GPS provides the executive team with a dashboard that uses project telemetry to track the progress of the enterprise’s AI strategy. The Enterprise Capital Gate converts what the dashboard reports into a capital decision for a specific AI project. The Gate allocates capital to address specific risks rather than merely completing project components, sets its conditions based on the project’s innovation horizon and stage, and enforces criteria established by the corporate management team. Its mechanics come from the venture capital portfolio practice. Its constraints come from the corporate innovation practice. In this article, Part 1 of the series, I present the reasons the enterprise needs the Capital Gate and define the concepts it rests on. In Part 2, I will present the Enterprise Capital Gate in detail.

1. Introduction

Enterprise decision-makers lack the tools to assess the types of risk an AI project carries, how much of that risk each dollar can reduce or eliminate, and what action to take next.

The AI GPS is a dashboard that gives the executive team a macro-level view of the enterprise’s AI strategy through four interrelated curves. It tells the team whether the AI-driven transformation is working, and it distinguishes a healthy Productivity Dip from a failing project. However, diagnosis is not a decision. The dashboard cannot release the next tranche of funding, withhold it, or shut the project down. Those actions require a second instrument. I call it the Enterprise Capital Gate. I developed it using two insights from our firm’s venture capital investing and corporate innovation advisory efforts.

Insight 1: Conventional corporate capital process kills the wrong AI projects. The errors run in a predictable direction. The projects that touch the most ossified processes dip deepest, fail their first review, and get killed. The shallow automations look orderly on a quarterly review and survive. Two years of this yields a portfolio of thin automations, a large bill, and a board that has concluded AI does not work here. In Part 2 of this series, I will describe how to protect a deep Dip from a quarterly review.

Insight 2: Enterprise AI projects carry the risk profile of venture investments. They carry AI model, data, AI application adoption, unit-economics, governance, and vendor-dependency risk, frequently all at once. Like venture investments, a few can generate asymmetric returns. Others may not even return their cost. However, even the failures generate information that is valuable to every remaining and future project. For example, a pilot project that was cancelled because the proprietary data it relied on didn’t provide a meaningful advantage informs the enterprise about the data’s value.

The Enterprise Capital Gate is the mechanism. It allocates capital to address specific risks rather than merely completing project components, sets its conditions based on the project’s innovation horizon and stage, and enforces criteria established by the corporate management team. Its mechanics come from the venture capital portfolio practice. Its constraints come from the corporate innovation practice. In this article, Part 1 of the series, I present the reasons the enterprise needs the Capital Gate and define the concepts it rests on. In Part 2, I will present the Enterprise Capital Gate in detail.

2. Manage Corporate AI projects like startups in a Venture Portfolio

Corporations built capital allocation for normally distributed returns on well-understood processes, such as a plant expansion, a new distribution center, or an ERP system upgrade.  The process involves forecasting cash flows, approving the budget, executing, and comparing the outcome to the forecast. Management must correct every variance against the plan. This approach assumes that the mean outcome is the likely outcome and that the management already knows the forecast at approval time.

AI projects behave differently. The distribution of outcomes across an enterprise’s AI portfolio is closer to a venture portfolio’s than to a capital budget’s. Most projects will not return their cost. However, a small number will carry the portfolio.

Enterprises govern their AI project portfolios poorly because of a mismatch between expected returns and the tool that measures them. It is also why the solution must come from the venture practice rather than from the stage-gate or balanced scorecard practices. Those practices were built for a different problem.

A typical venture portfolio includes 10-15 startups per fund. Each of the large corporations our firm advises typically runs at least ten AI projects concurrently. In this and the next piece, I focus on such project portfolios. Smaller corporations work with smaller portfolios of AI projects. In such situations, the management mechanics change.

This is an argument I first made in 2014 and applied to Horizon 2 tranches in 2017. This is before AI made it urgent.

3. The Goals of Existing Frameworks

Corporations already use several frameworks (see Table 1 below) that touch this problem. While none of them is wrong, each addresses a problem that is different than the one presented here.

Corporate Frameworks

The enterprise is provided with measurement, classification, and scheduling frameworks. However, it lacks a framework that allocates capital under venture-like uncertainty and enforces its own conclusions.

4. Horizon, Stage, and Gate

Innovation portfolio discussions routinely conflate horizon and stage. Before specifying the Enterprise Capital Gate, we need to separate them. Every parameter of the Enterprise Capital Gate depends on one of the axes.

Horizon establishes a project’s intent. It answers what the project is trying to accomplish and whose economics its return lands on. It is fixed when the project is proposed. An AI project to rebuild quote-to-cash is a Horizon 1 project. A project to turn a technology company’s internal AI data center into a neocloud business is a Horizon 2 project.

Stage establishes a project’s maturity. Every project moves through the same three stages regardless of horizon: experimentation, pilot, and scale-out. A project that completes scale-out exits the AI portfolio and moves onto the operating budget. This is a transition most corporations never define, and one that costs them more than they realize. Stage advances. Horizon does not.

A gate is a checkpoint to release, withhold, or reclaim capital against a named risk the previous allocation was meant to retire. Gates occur within stages, not only between them. A project in experimentation may pass through several, each buying down a different uncertainty. The gate that closes a stage carries one additional decision: whether the project advances, stays where it is, or stops.

Figure 1: A project’s horizon is fixed and the stages advance left to right. Bars show gates when capital is released, withheld, or reclaimed.

The grid shown in Figure 1 above is the mechanism’s coordinate system. The horizon sets the tolerances, i.e., how many gates a stage contains, how much capital each releases, how long the project may remain in a stage, and what evidence advancement requires. A Horizon 1 experiment should be short, cheap, and aimed at a known target, and may need only one gate. A Horizon 3 experiment is open-ended by design and warrants more gates releasing smaller amounts. Learning velocity and cost-to-invalidate rather than unit economics score experiments. Stage sets which risks should already have been retired before allocating new capital, and how much capital is at stake.

The two axes of Figure 1 are frequently collapsed, usually by scoring Horizon 3 projects on learning and Horizon 1 projects on unit economics. That is wrong. A Horizon 1 project at the experimentation stage is still an experiment and should be scored on learning too. The risk categories are identical across all nine cells. Only the tolerances differ.

As a project passes through gates, data accumulates in the funding record. This is a per-project artifact stating the thesis, the risks retired and outstanding, the capital committed and reserved, the criteria for the next release, and the decision taken. Part 2 specifies it.

Horizon is indexed to a business, not to the corporation. Once a Horizon 3 effort scales and becomes established, e.g., Waymo, it operates as a business with a core to defend. Defending it generates Horizon 1 projects of its own. Therefore, the funding record must name the business whose economics the project serves. Without that field, naming a project’s horizon becomes ambiguous and useless.

That ambiguity is not academic, because horizon classification is consequential and can be manipulated. Sponsors could classify a project as Horizon 3 to escape unit-economics scrutiny, or as Horizon 1 to be funded from operating budget rather than compete for innovation capital. Use two rules to avoid this problem:

Rule 1: Someone other than the sponsor classifies the horizon.

Rule 2: Reclassification is never a routine activity. It requires re-underwriting the project against a new baseline. This stops statements such as “we’ve reclassified this as Horizon 3 project” from becoming the standard escape from a missed milestone.

5. The AI Risk Stack

At each gate, the Enterprise Capital Gate allocates capital to eliminate and/or reduce a subset of the risks associated with the AI project. At the beginning of each AI project, the entire risk set must be specified. Venture practice calls for maintaining a risk ledger. However, the risk categories must be specific to enterprise AI. I identified the following six risk categories:

1. Model and capability risk. The AI model, or models, must be as capable and reliable as the workflow requires. To eliminate this risk, use data that is representative of the production environment. This category has a property no other risk on the list shares. Someone else can create it or eliminate it. A frontier model release can de-risk a project overnight, and it can also make a category obsolete. The risk ledger records which of a project’s risks are exposed to external capability movement. That exposure changes the correct decision at the gate.
2. Data risk. This risk type flags whether the data for the project’s AI models is available, sufficient, and of the necessary quality. It also flags whether the enterprise is entitled to use the data for the intended purpose. Experiments with the data must establish its value to the AI project. Enterprises frequently skip this valuable test. To address this risk, document the enterprise’s data rights and measure the value of the enterprise’s proprietary data compared to an equivalent publicly available data baseline. Don’t automatically eliminate a project that shows no lift because of using the enterprise’s proprietary data. However, the corporation should recognize that it is a different project than the one it funded.
3. Workflow and adoption risk. An AI-centric workflow changes the work of the people using the workflow it will replace. As I stated in the AI Stakeholder Squeeze, employees may resist using the new workflow. To eliminate this risk, observe how production teams use the AI-centric workflow. Do not rely on volunteer cohorts because of their enthusiasm. This risk type feeds the Adoption S-Curve on the AI GPS dashboard. It is not uncommon to underestimate it.
4. Unit-economics risk. This risk type assesses the cost of the application or service resulting from the AI project when fully deployed. To address this risk, generate a cost-per-successful-outcome curve that relies on projected full-deployment volumes, rather than the pilot deployment volumes. Enterprise AI inverts an assumption we often encounter in non-AI systems. In conventional software systems, marginal cost per additional unit of usage approaches zero. In AI systems, it does not. More importantly, it can rise with usage because hard cases consume more inference.
5. Governance and legal risk. This risk type measures intellectual property exposure, data privacy, regulatory standing, auditability, and model accountability. When the Chief Legal Officer signs off, the project inside the enterprise’s audit perimeter addresses this risk.
6. Dependency and vendor risk. The risk type assesses whether the project’s efficacy relies on a single AI model provider, measures switching costs, and determines who holds the pricing power. Establishing a vendor switching path, or a negotiated price floor, addresses this risk. A project whose economics depend on a counterparty’s current pricing has not addressed this risk type. Instead, it has deferred it.

Across all six risk types, the enterprise must constantly ask whether each AI project is developing a durable asset or renting a capability that will be commoditized within a short period. Both answers can justify funding. However, they justify different amounts, on different terms, with different expectations of permanence. The distinction between investing to acquire capability and renting capability belongs on the business case record.

6. Summary

Four things follow from the preceding sections.

Manage the enterprise AI portfolio using venture capital practice, because its outcomes are distributed like a venture portfolio’s rather than like a normal corporate capital budget’s. Most projects will not return their cost, a few will carry the portfolio, and the failures produce information worth having. The corporate CapEx process, built for the opposite distribution, misallocates against it in a predictable direction.

Existing frameworks measure, classify, and schedule. None of them allocates capital under this kind of uncertainty, and none enforces its own conclusions.

Horizon and stage are independent axes. Horizon provides the project’s intent. Stage shows the project’s maturity. Gates fall within stages as well as between them.

Enterprise AI projects carry six categories of risk, each with a test that establishes whether capital has retired it.

That is the vocabulary. Part 2 puts it to work: how much capital a gate releases and against which risk, why write kill criteria separately from advancement criteria, what the enterprise must state about expected failure before it kills anything, and how to protect a deep Productivity Dip from a quarterly review that would end it.