In this two-part series, I introduce the Enterprise Capital Gate (ECG). The AI GPS gives the AI Transformation Office a dashboard that uses project telemetry to track progress on the enterprise’s AI strategy. The ECG converts the evidence a project team produces, together with what the GPS shows once the project begins transforming a live process, into a capital decision for that project. The Office uses the ECG to allocate capital to address project-associated risks, sets its conditions based on the project’s innovation horizon and stage, and enforces criteria. Its mechanics come from the venture capital portfolio practice. Its constraints come from the corporate innovation practice. Part 1 explains why the enterprise needs the Enterprise Capital Gate and defines the concepts it rests on.
1. Introduction
Enterprise decision-makers lack the tools to assess the types of risk an AI project carries, how much risk each dollar can reduce or eliminate, and what action to take next.
The AI GPS dashboard gives the AI Transformation Office a macro-level view of the enterprise’s AI strategy through four interrelated curves. It tells the Office 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 shows the Office what is happening. It does not tell the Office how much capital to release, withhold, or reclaim, or when to shut a project down. Those decisions 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 follow a predictable pattern. The projects that touch the most ossified processes dip deepest, fail their first review, and get killed. Shallow automations look orderly on a quarterly business 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.
Insight 2: Enterprise AI projects carry the risk profile of venture investments. They carry solution, data, workflow-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.
Both insights point to the same conclusion: the enterprise needs an instrument built for venture-like uncertainty, and it needs one that operates on a single project at a time.
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 expected returns don’t match the tool used to measure 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.
I first made this argument in 2014 and applied it to Horizon 2 tranches in 2017. This was 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
| Framework | What it's built to do | What it can't do for an AI portfolio |
| DCF / NPV | Value a capital project by forecasting its cash flows and discounting them | Requires multi-year returns stated before technical feasibility is known, so funding becomes binary — the full budget or nothing |
| Stage-Gate | Stage product development work and gate the funding between stages | Releases capital against deliverables completed, not risks retired. A pilot that ran on curated data with a volunteer cohort passes |
| Discovery-Driven Planning | Plan ventures whose assumptions exceed their knowledge, via reverse income statement and assumption checkpoints | Supplies no capital-side architecture: no reserve for follow-on, no expected failure rate, no separation of advocate from allocator |
| Balanced Scorecard | Track a running business against strategy across four perspectives | Reports; it does not release cash, reclaim it, or terminate anything. Experimentation-stage projects have no P&L to balance |
| Agile/OKR | Manage delivery against technical and objective milestones | Operates in a financial vacuum. A model can meet every objective and still cost more per outcome than the process it replaced |
| Innovation Ambition Matrix | Determine how much investment goes to innovation portfolio's core, adjacent, & transformation work | Classifies and allocates in aggregate. It does not govern the individual project. The Enterprise Capital Gate assumes it rather than replacing it |
Table 1: Relevant existing management frameworks used by enterprises.
The enterprise has measurement, classification, and scheduling frameworks. However, it lacks a framework to allocate capital under venture-like uncertainty and enforce its own conclusions.
4. Horizon, Stage, and Capital Review
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. Most corporations never define this transition. This costs them more than they realize. Stage advances. Horizon does not.
A capital review is the occasion on which the enterprise releases, withholds, or reclaims capital against a named risk the previous allocation was meant to address. The Stage-Gate framework places its gates between stages. Capital reviews recur within them. A project in the experimentation stage may pass through several capital reviews. Each review addresses a different uncertainty. A stage’s final review, the stage-closing review, determines whether the AI 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 capital reviews, 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 capital reviews 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 review. A Horizon 3 experiment is open-ended by design and warrants more reviews, 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 capital reviews, 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 a Horizon 3 project” from becoming the standard escape from a missed milestone.
5. The AI Risk Stack
As venture investors, we underwrite four risks: technology, market, team, and business model. Those four do not transfer intact to enterprise AI projects. Watching where they break is what produces the right categories (see Table 2).
Venture risk to AI project risk
| Venture risk | What it asks of a startup | What it becomes for an enterprise AI project |
| Technology | Can this be built, and what will it take? | 1. Solution risk (is the technical approach appropriate? What does implementing it require?) 2. Data risk (does the enterprise hold data it is entitled to use that provides a measurable advantage?) |
| Market | Does/Will a market exist, and how large can it get? | Converts to Workflow and adoption risk. The market is guaranteed; it is the people already doing the work. The question is whether they adopt the new way of working. |
| Business model | Can a viable model be discovered? | Narrows to unit-economics risk. The business model is inherited. What is unknown is the cost per successful outcome at production volume. |
| Team | Can the team execute or does it require changes? | Transfers, but with lower severity. A VC is underwriting a founding team and helping it becomes costly: coach, add someone alongside, or replace a founder or other member of the executive team through a board process that signals distress. The enterprise has the same three remedies and can exercise them faster (reassign an AI project member, add an employee who was not previously part of the project team, or remove the ineffective team member and hire externally. The enterprise underestimates the remaining risk. The option to fix it exists on paper and is rarely used in time. |
Table 2: How venture risks transfer to enterprise AI projects
Note that two of the six categories have no venture risk equivalent. Regulatory exposure and vendor dependency emerge from the corporate setting rather than translating into it. Team risk, the category a venture investor, and particularly a seed investor, weights most heavily, is the one the enterprise is best equipped to remedy and least likely to act on. A venture firm’s answer to team risk is a board seat and the willingness to use it. The enterprise’s equivalent is a deciding body with people outside the project on it, which Part 2 specifies.
At each capital review, 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:
- Solution risk. A venture investor examining an opportunity asks three questions in order: is this an important problem to solve, is the proposed technical approach the right one, and what will it take to implement that approach? The third question carries the bulk of the risk. A startup’s proposed solution may require a fundamental technical breakthrough before becoming a reality. For an enterprise AI project, the hard part is not selecting which AI model to utilize. A project may need an off-the-shelf model. However, the solution’s key element may be a knowledge graph search algorithm that has unique characteristics, e.g., a low-latency SLA.
A management team that begins with model selection has already skipped the two questions that matter more. Does the model perform at the reliability the workflow requires, measured on data representative of the production environment? Is the system around the model buildable, and what will building it take? Interestingly, someone outside the enterprise can address this risk, or create it. A specific frontier model can de-risk a project overnight, and can also lead it to obsolescence. This is a property no other risk on the list shares.
The risk ledger should record which of a project’s risks are exposed to external capability movement, because that exposure changes the correct decision at a capital review. Note that the exposure applies to the model test, not the system test. Progress at the frontier does nothing for a project whose difficulty sits in the orchestration around the model. Solution risk is also where the enterprise determines whether a project acquires a durable capability or rents one. A project requiring novel search over a hybrid knowledge graph is acquiring. A project wrapping a vendor API is renting. Both can justify funding, on different terms and with different expectations of permanence. - 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.
- 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. Once the project reaches scale-out and production teams begin using the workflow, this risk type feeds the Adoption S-Curve on the AI GPS dashboard. Before then, the only evidence available is what the project team produces. Enterprises commonly underestimate this risk.
- 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, start by generating 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.
- Regulatory and compliance risk. This risk type measures intellectual property exposure, data privacy, regulatory standing, auditability, and model accountability. A project team addresses this risk when the enterprise can audit the project and the Chief Legal Officer has signed off.
- 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.
Which of the six risk types dominates depends on the project’s stage. Early-stage risk concerns existence: will this work at all? Late-stage risk concerns magnitude: how much, how fast, at what cost? Solution and data risk dominate experimentation. The experiment’s failure ends the project. Workflow-adoption and unit-economics risk dominate the pilot phase. The pilot’s failure leads to resizing it. Dependency and regulatory risk dominate the scale-out phase. This is also the stage at which the Pod replaces the existing workflow, and where the Productivity Dip begins. Failure at scale-out makes the project more expensive than it promised to be and extends the Dip beyond the depth and duration the enterprise committed to.
What matters concerns the risk categories present within a project given its stage, and the evidence that the allocated capital has addressed it, either by eliminating it or at least reducing it. “Data risk addressed” at experimentation means documented rights and adequate quality. At scale-out, it means the pipeline holds under production load, and the measured advantage persists. A seed investor and a growth investor may belong to different firms. The enterprise has to be both, in the same portfolio, under the same allocator.
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 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. Capital reviews fall within stages and between them.
Enterprise AI projects carry six risk categories. Each category has a test. The test establishes whether capital has addressed the risk. The six derive from the four venture risk types. However, two risk types have no venture equivalent. Moreover, team risk, which venture investors weight most heavily, doesn’t quite transfer. Which risk is important depends on the AI project’s stage.
That is the vocabulary. Part 2 puts it to work: how much capital a capital review releases and against which risk, why write kill criteria separately from advancement criteria, what the enterprise must state about the conditions for failure before it kills anything, and how to protect a deep Productivity Dip from a quarterly business review that would end it.