Part 1 argued that enterprise AI projects share the characteristics of venture investments but are funded like plant expansions. This mismatch creates the Pilot Purgatory condition and frequently leads to the elimination or underfunding of the wrong projects, while others continue indefinitely. In this article, we describe the Enterprise Capital Gate (ECG) in detail.
1. Introduction
The AI strategy identifies the transformations the corporation must undertake to achieve certain business goals. For example, transform the Quote-to-Cash process to reduce Days Sales Outstanding (DSO). The AI Transformation Office owns the strategy’s implementation. It merges business, technology, legal, and HR expertise, allocates capital, and can reclaim it. In this respect, it differs from AI Committees or Centers of Excellence, neither of which can make an enterprise AI-first.
Teams submit proposals to the AI Transformation Office for new projects that use AI to implement the identified transformations. Each proposal asks for a capital allocation. A funded project becomes an Ambidextrous Pod. A P&L owner leads the Pod, which consists of a team that combines business and technology expertise. The Pod builds a solution implementing the transformation. It starts as an experiment and may become a new business unit, or replace an existing department. The Pod manages the capital the Office provides.
2. The Enterprise Capital Gate
The Enterprise Capital Gate is the decision mechanism the AI Transformation Office uses to make capital-allocation decisions about the corporation’s AI projects. The ECG specifies what data the Office examines, when, against which criteria, and what the Office must record after each decision. However, it does not specify the decision itself. The ECG employs the review process. The funding record captures the data generated during the review process. The ECG enables the corporation to run AI projects at every stage under one capital allocator.
The Office applies the ECG to two different decisions. The first involves selecting and funding a proposal, thus introducing a new Pod into the portfolio. The Office weighs the proposal against the AI strategy and the other proposals. The second involves deciding whether an existing project receives more capital. In this case, the Office uses all data provided by the Pod, data from previous reviews stored in the funding record, and data from the AI GPS.
The Office reaches its decisions through three review types. The selection review selects new projects into the portfolio. The allocation review decides whether an existing project receives more capital. The progress review validates that each funded project is on the trajectory its Pod claimed. Capital is allocated as a result of the first two. The third review type ensures the first two ask the right questions.
3. The Three Reviews
The selection review
The Office holds selection reviews to identify the next set of AI experiments. These reviews happen on a fixed calendar, for example, twice a year. The calendar matters because proposals compete against one another and a comparison requires them to arrive together.
The Office organizes the submitted proposals into the Use Case Matrix. Each Use Case Matrix entry includes a description of the proposed project’s use case, the business process to be transformed, the transformation’s goal, the solution that will be developed, the expected results, the applications the process already relies on, the data it requires, the data it generates, and the transformation’s priority as assigned in the AI strategy. The Office assigns the risk types and associated levels to the proposed solution and the project’s Horizon.
The Office assigns the risk types because a team proposing a transformation has no incentive to characterize its own solution as risky. It also assigns the Horizon because it is uniquely positioned to determine every tolerance the project will operate under. A team that could set its own project horizon would set the one that attracts the least scrutiny.
The selection review produces one of two outcomes. The Office funds the proposal. In that case, the project enters the portfolio in the experimentation stage, a Pod forms, and the project receives its first funding allocation. Alternatively, the Office declines to fund the proposal. Either outcome creates a funding record. A declined proposal’s funding record explains the reasons for the rejection. Teams whose proposals were declined often re-emerge with new proposals. The Office’s past conclusions become extremely helpful in evaluating new efforts.
The capital allocated to each experimentation stage project is small. It addresses solution and/or data risk. The capital is used to determine whether the team’s technical approach can be implemented, or whether the corporation’s proprietary data offers a measurable competitive advantage over a publicly available baseline. Corporations are advised to run many such experiments simultaneously, but to expect that only a few will move to the pilot stage.
The allocation review
The Office holds allocation reviews to decide whether an existing project receives additional capital. An allocation review is asynchronous, convened per project, because a project that is ready to advance should not wait for a calendar date. Most allocation reviews occur within a stage.
The allocation review is convened because a) a Pod requests it, b) the Office demands to understand why the project has diverged from its committed trajectory, or c) the project has reached the end of a stage. The review addresses three questions.
- Did the last allocation address the risk it was meant to address? The Office assesses whether the named risk is smaller now, by how much, and at what cost. A project that delivered every committed milestone without addressing its named risk consumed capital and bought nothing. The Office does not examine how the Pod spent the money, since the Pod manages its own capital, but it examines the spending’s outcome.
- Which risk to address next? One of the six risk categories usually dominates. As the project matures, the dominant risk shifts. Early-stage risk is about whether the solution would work. The solution’s cost and its deployment speed are late-stage risks. Solution and data risk dominate experimentation. Workflow adoption and unit economics dominate the pilot. Vendor dependencies and regulatory risk dominate scale-out. The Office, together with the AI project’s team, must identify the appropriate risk to address next.
- What will addressing that risk cost? The answer sets the size of the funding allocation. The allocation size relates to the costs of addressing the risk, rather than the stage budget, the annual plan, or the amount the Pod requested. Sizing capital to evidence rather than to ambition is the largest single departure from conventional corporate practice, because the Office can reclaim only what a Pod has not spent. Therefore, the allocation’s size shows how much the corporation can lose between two reviews.
The allocation review that closes the pilot stage carries the largest allocation in a project’s life, because scale-out is where the Pod begins dismantling the existing workflow and replacing it with the AI-first one, or introducing a new AI-first process to the entire corporation. It is also where the Productivity Dip begins. Experimentation doesn’t break any production systems. A pilot-stage project could only disrupt operations within its testing cohort.
In the allocation review, the Office and the Pod must commit to the expected depth and duration of the Dip, the threshold at which the project counts as recovered, and the guardrail thresholds the project will be held to. The agreement makes a deep Dip defensible later, when declining throughput and unhappy employees look identical to a failing project. It is also never amended to accommodate a project that has exceeded it. A moving target agreement measures nothing.
Stage-closing allocation reviews
An allocation review that closes a stage answers two further questions. First, does the project advance to the next stage, stay where it is, or stop? Advancement is not the default outcome of a successful review. A project can meet every criterion and remain in its stage, because the next stage costs considerably more and the corporation is not ready to commit to it.
Second, is this the right team for the next stage? Enterprises avoid this question because it appears to impugn people who have just succeeded. A venture firm asks it as a matter of course at every round, because the skills that establish a startup and the skills that scale it are different. The corporation has stronger remedies than a venture firm. It can reassign a Pod member, add someone from another function, or remove a member and hire externally, all without a board vote or a signal to the market. It is also far less likely to use them in time.
A review closing the scale-out stage answers the advancement question differently, because no further stage exists. Either the project exits the AI portfolio and moves onto the operating budget, with its guardrail thresholds becoming standing service commitments, or it does not yet qualify to exit and continues in scale-out under a further allocation.
The progress review
The Office holds progress reviews quarterly, across the whole portfolio. The review’s purpose is to confirm that each project is progressing along the lines its Pod has claimed and remains on target to achieve the transformation it set out to achieve.
The monthly diagnostic the AI GPS prescribes, and the quarterly progress review serve different purposes. At the monthly diagnostic, the Office reads the four curves and sees the transformation’s aggregate shape. During the quarterly progress review, the Office scrutinizes the Pod’s data.
A progress review determines whether the Pod’s data, the AI GPS data, and what the Office recorded in the project’s funding record are consistent. When the Office finds a project off track, it records the divergence along with a set of actions for the Pod to take before the next review. At the next review, the Office can then determine whether the Pod acted on the recommendations and assess their impact. Whether the proposed solution is harder to develop than originally expected or the Pod is not performing to the expected level, the Office uses the deviations and the recorded data to determine when to terminate a project. A progress review does not result in capital-related decisions. The Office convenes an allocation review to act on that determination. It cannot terminate a project in the meeting where it first noticed the problem.
The corporation should expect high mortality among experimentation-stage projects. This shows that the Office is using the stage as intended. An experiment that fails quickly and cheaply has done its job. Mortality falls as projects mature. Pruning a project that is in the scale-out stage implies that an earlier review’s evidence bar was set too low.
4. The funding record
The funding record holds a project’s accumulated data and the Office’s decisions about that project. The record is created at the selection review, regardless of whether the proposal is funded, and it persists after the project exits the portfolio or is terminated.
The funding record borrows elements from VC best practices. Venture firms maintain “data rooms” for their portfolio companies. These “rooms” store data the company provides, such as board of directors meeting materials, and information and commentary generated by the venture firm’s investment professionals, such as market analysis and investment memos. Venture firms also store data from each company they evaluated but did not invest in.
The analyses and associated commentaries developed by the firm’s investment professionals are especially important because they contain information a portfolio company’s reporting does not. Such analyses are used to support the portfolio company’s position and trajectory, e.g., approving a new financing round, but also to have difficult conversations that require drastic actions, e.g., changing members of the senior management team.
The Office must adopt the practice of developing such analyses and commentary instead of only relying on the data provided by the Pod.
The funding record produces a decision. Its attributes, shown in Table 1, are organized into three groups: a) set once at the selection review, b) accumulated continuously, and c) written at each review.
The Funding Record Attributes
| Attribute | Set | Content |
| Thesis | At selection | The transformation the project will accomplish if successful, and the part of the AI strategy it serves |
| Indexed business | At selection | The business whose economics the successful project will affect |
| Horizon | At selection | Horizon 1, 2, or 3, assigned by the Office rather than the proposing team |
| Use case | At selection | The Use Case Matrix entry the project implements |
| Selection decision | At selection | Funded or declined, with the rationale |
| Team | Continuously | The Pod's composition, and the P&L owner leading it |
| Capital position | Continuously | Committed to date, current allocation, and what remains unspent |
| Sponsorship | Continuously | The executive whose budget funds the project, and the date of the last review they personally attended |
| Stage | At each stage-closing review | Experimentation, pilot, or scale-out |
| Risk ledger | At each allocation review | The six risk categories, each marked addressed, reduced, or unchanged, with the evidence and the capital spent reaching it |
| Allocation thesis | At each allocation review | The risk the approved capital is meant to address, and the evidence that will establish that it did |
| Advancement criteria | At each allocation review | What must be true at the next review for the project to receive more capital |
| Kill criteria | At each allocation review | The conditions under which the project stops, written separately from the advancement criteria |
| Alerts | At each allocation review | The conditions that will cause the Office to convene an allocation review ahead of a Pod's request |
| Dip covenant | At the pilot-closing review | The committed depth and duration of the Productivity Dip, and the recovery threshold |
| Guardrail thresholds | At the pilot-closing review | Limits on customer satisfaction, error severity, and attrition among the employees whose work is being redesigned |
| Wind-down disposition | At each allocation review | Where the people, data, model artifacts, and commitments go if the project stops |
| Allocation decision | At each allocation review | Fully fund, stage the funding, or prune |
| Current mark | At each progress review | The Office’s revised view of the project’s expected value, and the direction of the last two revisions |
| Trajectory findings | At each progress review | Divergences the Office identified, the actions it recommended, whether the Pod executed them, and the resulting changes |
Table 1: The funding record’s attributes
Advancement and kill criteria
The Office writes these two criteria types separately because they are not complements. A project that fails its advancement criteria has not received additional capital. It should not necessarily be terminated. It may warrant an additional allocation. Conversely, a project that satisfies every advancement criterion may still have to stop. For example, a regulatory determination may prohibit its market viability, a competitor’s solution may make its economics impossible to match, or a guardrail threshold may have been breached.
Corporations that collapse the two make a predictable error. The projects that dip deepest fail their advancement criteria first. If failing those criteria defines termination, those projects are terminated first. These are the projects attacking the most ossified processes, which is where the transformation value sits.
Kill criteria written in advance are also what the corporation can honestly state about expected failure. It cannot state a failure rate. No venture firm tells its limited partners what fraction of a portfolio it expects to lose, because the rate is an outcome rather than a plan, and its variance across funds measures the firm’s judgment. What the corporation can state, project by project and before any evidence arrives, are the conditions under which it will stop.
5. Between reviews
A project’s life happens between reviews. During those periods, the Office watches, interprets what it sees, and decides whether the next review should arrive on schedule or earlier.
The clocks
The Enterprise Capital Gate runs on several clocks at once, and the asymmetry between them is deliberate. Selection reviews follow a fixed calendar because proposals compete against each other and a comparison requires them to arrive together. Progress reviews are quarterly and cover the whole portfolio. Allocation reviews are asynchronous and per project, because a project ready to advance should not wait for a calendar date.
The Pod’s reporting runs on a cadence the Office sets for each project. Projects generate data periodically, such as monthly cost figures, and when specific events occur, such as releasing a new version to its users. A Horizon 3 project in experimentation reports more often than the same project at scale-out, for the same reason a seed-stage startup’s board meets more frequently than a growth-stage company’s board: the uncertainty is larger, and the cost of learning late is higher. Granularity moves in the opposite direction. Early-stage data is sparse and imprecise because much remains unknown, while scale-out data is precise and voluminous. The Office therefore receives frequent, coarse reporting early in a project’s life and less frequent, but precise reporting late.
The AI GPS runs on its own dual-track cadence. The CIO, CTO, and business unit leaders review the weekly project telemetry. The monthly diagnostic gives the Office the transformation’s aggregate shape across the entire AI project portfolio. The quarterly progress review examines each project against its commitments. The AI GPS serves the Office’s macro view regardless of whether the corporation uses the Enterprise Capital Gate. This is why it is an input to the decision mechanism rather than a part of it. The Office provides progress reports to the CEO to update the board of directors and shareholders.
From data to consequences
The project’s stage determines what the Office can draw on. During experimentation, the Pod is the only data source. The project touches no production system, so there is no adoption to measure, no throughput to track, and no cost per successful outcome to compute. When the project moves to the pilot stage, the Office uses the AI GPS to establish the baseline for later measuring the Dip. Only projects at the scale-out stage, when production teams begin using AI-first or AI-enabled processes, does the AI GPS report the project’s observed state, i.e., adoption across the workforce, throughput, error and rework rates, and the fully burdened cost per successful outcome
Note that the stages with the highest mortality rate and the largest number of allocation reviews are the stages where the Office’s data comes from the Pod that is using the allocated capital and will ask for new allocations in the future.
Neither source interprets what it reports. A dashboard showing flat adoption and rising cost cannot distinguish an improperly redesigned workflow from an underperforming model or an unrepresentative test cohort. It cannot decide what any of those warrants.
That interpretation is the Office’s work. Assume the AI GPS shows declining use among the test cohort of a Horizon 3 pilot-stage project. The Office may conclude that the test users were inadequately trained. It may simultaneously revise its cost assumptions for rolling the solution out across the corporation. Two consequences, one observation, neither of them visible in the data.
Venture investors do the same thing from a board seat. A partner who sees a portfolio company’s sales cycle lengthening infers what it implies for the monthly burn and then decides whether to mention it to the partnership, raise it at the next scheduled board meeting, or call one immediately. No instrument makes that inference. The Office becomes accountable for interpreting the measurement using the Enterprise Capital Gate as a decision mechanism. It must record its interpretation and act on it.
Alerts
An alert is a condition that causes the Office to convene an allocation review. Each such review describes a specific way a project can diverge from the trajectory its Pod claimed:
- The Productivity Dip exceeds its committed depth or duration.
- Cost rises while adoption stays flat.
- The project has been in its current stage longer than its Horizon allows.
- Compute and storage consumption rises without a corresponding gain in the solution’s performance.
- The project’s mark has declined at two consecutive progress reviews.
- A guardrail threshold has been breached.
Several of these correspond to diagnostic patterns the AI GPS identifies. The distinction is worth keeping. The AI GPS shows that a pattern is present. The Office determines what the pattern means for this project, at this stage, on this Horizon, and what to do about it.
Alerts translated into potential consequences may result in one or more informal interactions between the Office and the Pod’s team or a review. Flat performance within a stage deserves additional attention because it leads the enterprise to Pilot Purgatory.
Recording what the Office concludes
The Office records alerts and its conclusions in the funding record when it reaches them, dated and attributed, rather than at the next review. When a venture partner infers that a lengthening sales cycle will raise the monthly burn, that inference goes into the portfolio company’s data room as a memo. It exists so the file later shows what was noticed, when, and by whom.
The requirement is mechanical, and it is what makes the Office auditable. The Enterprise Capital Gate cannot determine whether a Productivity Dip running deeper than committed means a project is dying or finding its footing. That judgment depends on the people in the Office. The ECG requires a timely decision ahead of the outcome. The decision is available to the review that follows. An Office whose conclusions appear in the record only after events have proven them is not exercising judgment. It is narrating.
6. Conclusion
Using AI to transform a legacy corporation and overcome the AI Stakeholder Squeeze requires a disciplined investment approach paired with the right people, processes, and technologies. The Ambidextrous Pods undertake the transformations. They redesign existing workflows and invent new ones. They carry them from experimentation through scale-out. The AI Transformation Office, staffed appropriately and equipped with the Enterprise Capital Gate, decides which transformations the enterprise funds, the funding level, and the risks the funding must address. Over time, the mechanism also improves the strategy that set it in motion, because the Office learns from running it which transformations the enterprise can achieve and at what cost. The result is an enterprise that allocates its AI capital deliberately, retires the risks its projects carry before committing to them at scale, and can defend both to its shareholders.