Only 13% of CIOs see AI value
walk-away rules

The night before a quarterly budget review, a CIO asked the team to line up the seven AI projects in flight and put one number next to each: what it produced this quarter that someone outside the team could check. Five of the seven had no number. Nobody proposed shutting those five down. Each had a progress report, and each report said integration was eighty percent complete. All seven rolled into the next budget year, where their cost moved from the project line to the operating line and became a monthly bill instead of a one-time purchase.

That outcome is not sloppy management. It is the default result of a structure in which starting requires a reason and quitting requires a decision, and reasons are easier to write than decisions. The scarce act is not approval. It is saying stop.

Gartner put a number on the gap in October. Its findings point away from which projects a company picks and toward whether it wrote down, in advance, the conditions under which it would walk away.

A sample that says the quiet part

Gartner surveyed 2,002 CIOs and technology executives between May and July 2026 and published the results on October 19. Only 13 percent of CIOs said their enterprise has realized significant or transformational value from AI. In the same survey, the odds that a single use case succeeds are about one in five.

The survey splits respondents into two groups. Vanguards deliver better business outcomes and also earn a high CEO assessment of AI value. The difference between vanguards and everyone else shows up in two places, and both are exit points. Organizations with guidelines for deciding that a pilot should not move to production are 2.3 times more likely to be vanguards. Those with guidelines for abandoning low-value initiatives already in production are 2.6 times more likely. Yet only 31 percent and 17 percent, respectively, have either practice in place.

The second pair of numbers explains more than the first. Roughly a third of organizations write a pilot-stage rule, and fewer than a fifth write a production-stage rule. Rules are easy to put on paper and hard to wire into a system. Killing a pilot costs a team a few months. Killing something in production means users are on it, dashboards hang off it, and another department has built a workflow on top of it.

Two more figures in the same release show where the pressure comes from. Fifty-eight percent of CIOs report rising pressure to deliver cost improvement from AI, and 51 percent expect AI to raise the total cost of ownership of technology. Both hold at once, which is the point: the savings target is being pushed down while the cost line moves up. Gartner attributes this to organizations still applying funding and governance models built for cloud and SaaS, while AI costs are probabilistic and settled at run time.

Label the evidence correctly. This is a self-report survey of CIOs, and the link between vanguard status and exit rules is correlation, not proof of cause. A company with strong discipline elsewhere may end up with both. Still, the correlation is strong and the direction fits the mechanism, which makes it a reasonable place to start an argument.

Why the exit rule decides more than the selection

Traditional technology costs are largely fixed at signature. Licences price by seat, cloud by specification, projects by person-day. You can compute the number before you commit, and the variance comes from scope changes, which usually has a ceiling.

AI costs are not fixed at signature. They are set by behaviour after deployment: how many model calls a task makes, how much history gets reread, how often a step retries, which tier the request routes to, whether a failure triggers a full rerun. The same feature, run by two teams, can produce monthly bills five times apart. The gap is rarely the model price. It is the call structure.

Uncertain cost plus project-based approval means risk is not controlled where the approval happens. Approval blocks the start and does nothing about the expansion. When a project cost can quietly double after deployment, the only control point that works is a threshold written before the start: at this number, we stop.

That also explains the 51 percent. CIOs expecting AI to raise total cost of ownership are not describing more expensive purchases. They are starting to see spending that never enters a purchase order: inference, tool calls, human review, rework.

An exit rule has a second effect that gets less attention. It improves the quality of the conversation at approval time. To write a walk-away threshold, someone has to answer what success looks like. If nobody can answer that, the value definition is still blank, and what goes live is not a pilot but an unbounded promise.

Write the rule so a machine can judge it

Most companies write exit conditions as a paragraph in a project charter, in the right tone and with a fuzzy test: discontinue if results fall short of expectations. That clause does not get executed, because judging it requires a meeting, and the people in the meeting approved the project.

An executable exit rule takes one of three shapes. All three share a property: a system can decide that the condition holds without convening anyone.

The first is a ceiling on cost per successful task. The denominator is tasks completed and accepted. The numerator is all spending in the period, including inference, tools, human review and rework. The threshold is an absolute number, and the trigger is the billing system, compared every settlement cycle.

The second is a floor on coverage increment. The denominator is the work that should have been processed in a period. The numerator is the share actually processed and accepted. When this number sits still, the agent is running without doing the work. The trigger is queue depth and closure counts in the business system.

The third is a ceiling on human intervention. What share of tasks needs a person to go back and fix them. Past some level, saved hours and added review hours cancel out, and the programme keeps running while moving cost from one line to another. The trigger is the rejection log in the ticketing system.

All three can be fed from systems a company already runs. That is the practical point: the hard part of adopting exit rules is not instrumenting them. It is finding someone willing to join the three numbers into one table and accept that the table may say stop.

Why organizations cannot write them

The first layer is asymmetric credit and blame. The person who ships a project gets recognized; the person who stops one has to explain why the earlier spending was wasted. In an organization that counts launches, stopping is a correct act with no bonus attached.

The second layer is budget ownership. The business unit sponsors the project and pays for it. Stopping means returning the budget, and next year the same envelope may not be granted again. The financially rational move is to keep a mediocre project alive to hold the line. Until that incentive changes, a written rule gets routed around.

The third layer is a missing ledger. Killing something in production requires a cost record from run time, and most companies have purchase invoices instead. The invoice shows subscription and cloud spend, not which feature spends, and not whether the money went to retries or to rereading history. Without that record, the abandon call rests on opinion, and in a meeting, opinion sits on the project side.

The fourth layer is sunk-cost language. Teams say so much has gone in that stopping wastes all of it. True in accounting, wrong in decision-making, and not fixable by explaining the fallacy. The workable fix is to make stopping a scheduled act rather than an incident. Every project gets a review date at approval, and on that date the choice is continue or stop, with no third state.

How our own queue runs it

We have run this mechanism internally long enough to have numbers that can be checked. The company task queue holds 3,186 tickets to date: 2,985 completed, 145 cancelled, 29 superseded by newer tickets, and 27 currently open.

The interesting figures are not the completion count but two ratios. Cancelled plus superseded comes to 174, or 5.5 percent. Roughly one in twenty tickets that gets opened ends with an explicit decision not to do it. And the open count is 27, so the queue does not accumulate.

The mechanism is one rule. Every ticket carries a deadline. Missing it triggers an escalation, and the escalation has exactly two exits: set a new deadline and say why the work is still worth doing, or close the ticket with a written reason for dropping it. There is no third state, and no ticket is allowed to sit in the queue unattended.

The effect is that queue depth stays bounded. The cost is that a person has to perform that two-way choice every week instead of letting escalation notices pile up in an inbox. We manage it because the act sits inside a fixed routine rather than depending on someone remembering.

State the limits of this sample. It comes from one organization of about twenty people, and it demonstrates that the mechanism works, not that any large enterprise will get the same result by copying it. At scale the two-way choice has to be delegated across many levels, and the quality of those judgments will thin out.

Where the rule does not belong

Treating exit rules as universal would create a new class of error, so the exceptions matter.

Exploratory research should not carry thresholds. The purpose is to learn whether something can be done, and the answer may be no. The output of that work is information, and measuring it with a delivery metric pushes people to fake results. Mandated compliance projects are similar: regulation does not offer the option of not doing the system, only of doing it well or badly.

Capability building does not suit a hard threshold either. Teams are learning to use the tooling, and high cost with low output for six months is normal. A fixed cost ceiling at that stage kills projects that are still climbing.

Accept the cost of stopping too early. Some projects deliver value late. Work that changes how people do their jobs often looks bad for two quarters and turns in the third. A threshold alone would kill those. A workable compromise separates the time dimension: for the first six months only the review date applies, and the threshold starts after that.

One more failure mode is a threshold with the wrong denominator. Counting calls rewards slicing tasks smaller. Counting sessions rewards splitting one task across several conversations. The denominator can only be an accepted unit of work. If a team cannot settle that, the whole table is decoration.

Our judgment

The difference in AI returns comes less from which model or which use case a company chooses and more from whether the organization can say stop at the moment the evidence arrives. That capability can be engineered: one threshold, one review date, one run-time ledger. With all three, stopping becomes arithmetic instead of courage.

The inverse also holds. A company whose AI portfolio only ever grows, with no project ever explicitly abandoned, should not be credited with progress because its adoption rate is high. Adoption measures starts. Only the abandon count measures judgment.

Three moves for this week

First, sort the AI projects in flight into two piles by whether a walk-away threshold exists. The second pile is probably the larger one, and that is your first fact.

Second, add one line to each project in that pile: what the unit of work is, what the absolute threshold is, and who performs the two-way choice on the review date. Projects where this cannot be written should not get more investment yet.

Third, put the act on a monthly routine instead of a quarterly review. Quarterly agendas fill up with new projects, and stopping needs its own time slot.

A question to take into the next meeting: if you had to shut three AI projects tomorrow, could you name the three and the reason for each within half an hour? If not, the missing ingredient is not judgment. It is a few thresholds nobody wrote down.

References

External figures come from the pages below. Internal figures come from the company task queue records.

Gartner, Gartner Survey Finds Only 13% of CIOs Say Their Enterprise Has Realized Significant or Transformational Value from AI (October 19, 2026; 2,002 CIOs surveyed May to July 2026; source for 13 percent, one in five, 2.3x and 2.6x, 31 percent and 17 percent, 58 percent, 51 percent)

Gartner, 2027 CIO and Technology Executive Agenda (survey method and the vanguard definition, cited by the release above)