AI programmes need a credible way to stop

Once an AI system reaches production, it can become difficult to question the investment. The supplier is in place and people have spent months introducing it. A team facing weak results may ask for more time to increase adoption before considering whether the use case is worth continuing.

Gartner’s survey announcement on 19 October 2026 challenges that habit. Among 2,002 CIOs and technology executives surveyed from May to July 2026, only 13% reported significant or transformational enterprise AI value. Gartner also put the likelihood of use-case success at roughly one in five.

Gartner also examined criteria for abandoning work, both before and after deployment. That is worth attending to because a pilot normally has an end date, whereas a disappointing production system can remain in use without ever facing another clear decision.

What Gartner found about stopping rules

Gartner defines its higher-performing “vanguards” through better business outcomes and high CEO-perceived AI value. Organisations with guidelines for stopping pilots were 2.3 times more likely to fall within that group; those with guidelines for abandoning low-value production initiatives were 2.6 times more likely. Only 31% and 17% respectively reported those practices.

These are survey associations, not experimental estimates of the effect of stopping rules. More capable management could contribute both to clearer criteria and better outcomes. The public announcement does not provide enough detail to independently reconstruct the success measure or every comparison. It also does not establish an 87% AI failure rate: limited value and significant value are different categories.

The survey does not provide a formula a marketing team can copy. It does suggest a decision to make before deployment: which results would justify stopping? Agreeing that in advance gives the team something to refer to when sunk costs and pressure to demonstrate progress make withdrawal harder to discuss.

Count the review work the tool creates

A hypothetical AI reviewer for financial promotions promises to reduce review time. It processes copy quickly and produces plenty of recommendations, yet specialists spend longer dismissing unsupported objections and rewriting confusing explanations. The tool’s usage figures could look healthy while the work takes longer to finish.

An evaluation organised around tool usage could miss the problem. A more useful comparison would follow work through to an acceptable final communication, accounting for specialist time and the quality of the issues found. A shorter first pass is worth less if reviewers then have to reconstruct its reasoning or check every citation again.

Coordination and review can absorb marketing AI productivity gains even when the individual task accelerates. The relevant unit of value is the business activity, including what happens before and after the AI produces an answer.

A system may reduce copy-editing while creating work to maintain product knowledge or investigate errors. Those costs belong in the assessment even if another team pays for them. Otherwise, the reported saving depends partly on moving the work somewhere less visible.

Historical averages may be a weak baseline if the existing process is poorly measured or the cases vary considerably. Observing a defined set of work before deployment could give the team a more credible comparison than estimates recalled after the tool has arrived.

Separate a safety limit from a commercial target

An outdated document causing false positives may be straightforward to replace. Poor use of a feature could justify narrowing its task or improving its integration. The business can allow time for a specific repair without committing to an indefinite series of improvements.

A marketing team might tolerate slower-than-expected review during a pilot while refusing to allow unsupervised publication of unsupported claims. Missing a commercial target and crossing that safety boundary should lead to different responses. Combining both into a single score would obscure the decision.

A team finding a material missed issue might restrict the system’s role while investigating the cause. A persistent increase in review work could instead prompt a time-limited repair, followed by a decision to retire the tool if the expected benefit still failed to appear. These are possible responses to different problems; the evidence does not establish universal thresholds.

An override rate is especially easy to misread. Frequent overrides might expose poor AI performance or show that specialists are correcting it effectively. A low rate could mean excellent recommendations or uncritical acceptance. Reviewing some of the decisions behind the figure would help the business decide what, if anything, it should change.

Application-level AI assurance establishes a basis for that decision. Knowing the tasks and conditions in which performance is adequate helps the business identify deterioration and choose an appropriate response.

Production is a continuing decision

Production can expose an application to work unlike the cases used in the pilot. Costs may change, product information can become stale and staff may start using the system for tasks it was not assessed to perform. The original business case needs to be revisited against those conditions.

Someone needs responsibility for that review and authority to restrict the system’s use. Reporting a missed threshold to a committee is unlikely to help if nobody can decide whether to repair the problem, reduce the scope or end the deployment.

The ability to stop also depends on practical alternatives. If an AI tool becomes the only accessible route through a process, withdrawing it may be too disruptive even when confidence weakens. Maintaining a workable fallback can make the stopping rule credible. The fallback needs enough capacity and knowledge to operate when called upon.

Suppliers should be part of the arrangement where relevant. A team needs to understand what information it can obtain about changes, how incidents are investigated and what happens to records if the service is restricted or retired. Those details affect whether the business can actually act on its assessment.

Clear stopping rules can also make a pilot easier to approve. The business is agreeing to a bounded experiment with a decision at the end, rather than accepting an obligation to scale whatever it deploys. Ending one unsuccessful use case then becomes a result the team planned for, leaving its attention and budget available for work with a stronger case.