An AI pilot must be allowed to fail

A pilot that cannot return no cannot support an investment decision

An enterprise AI pilot must be designed so that failure is a valid, contractually usable result. If the vendor can redefine success after seeing the results, the buyer has funded a demonstration rather than tested an investment.

The distinction matters because more than 80 percent of AI projects fail, according to a synthesis of interviews with data scientists and engineers. That figure covers several causes, but it makes one procurement error especially hard to defend: approving a pilot that has no defined way to fail. ¹

A properly scoped pilot freezes six things before delivery begins: the decision, the baseline, representative hard cases, operating exposure, the cost boundary, and the no-go criteria. Each item belongs in the statement of work or pilot authorization. None should wait for the final presentation.

Six gates turn a vendor demonstration into a decision procedure

The procedure works by removing discretion at the point where discretion is most biased. The buyer and vendor agree what evidence will settle the decision before either has results, sunk costs, or reputational pressure to protect.

This is a stage gate, not a vendor scorecard. Government investment guidance uses the same governing logic: before proceeding, a project must still be required, affordable, and achievable within the proposed time, with clear ownership of the go or no-go decision. ²

Demonstrations and discovery buy speed by answering narrower questions

A demonstration can show that a vendor understands the desired workflow. It cannot establish performance on the buyer’s difficult cases because the vendor controls the inputs, conditions, and recovery path.

A technical benchmark can compare candidate approaches under controlled conditions, but it pays for that control with lost operating context: it does not expose approval delays, user workarounds, escalation load, or failures at system boundaries.

Paid discovery can reduce uncertainty about requirements and data access. It does not produce deployment evidence unless the contract says that it must. Buyers deciding whether the supplier is capable should use How should you test an AI vendor before hiring?. Buyers deciding whether a proposed system deserves production funding need the six-gate pilot.

A limited production release provides stronger operating evidence, but it creates obligations that a pilot may be intended to avoid. Users require support, affected processes need fallback arrangements, and stopping becomes harder. Evidence that the vendor has operated comparable systems belongs in diligence before this exposure begins. Make AI vendors prove they can run production systems explains what that evidence should contain.

First, freeze the decision the pilot is funded to settle

Write one sentence that states the decision, the decision owner, and the permitted outcomes. A good statement reads: “The accountable executive will approve, reject, or narrow production procurement based on the agreed acceptance record.”

The contract should also identify what remains outside the decision. A pilot that tests whether claims adjusters can review AI-generated case summaries does not settle whether the same system can approve or deny a claim on its own.

A bad answer sounds like: “The pilot will explore value and inform the AI roadmap.” It conceals that no commitment follows from success and no rejection follows from failure. The vendor can present selected achievements while the buyer leaves with the same decision it had before paying.

Freeze the decision itself, not the organization’s priorities. If the business need changes later, close the pilot as superseded and record that it did not answer the original question, rather than rewriting the question around whatever result came back.

Second, measure against the current operation

Capture how the work performs now using the same unit of analysis the pilot will use. The baseline might cover decision quality, completion time, rework, escalation, or cost. Choose only measures that can change the funding decision.

The baseline protocol belongs in the contract. It should name the source records, sampling rule, exclusions, measurement owner, and treatment of incomplete cases. The vendor must provide enough evidence for the buyer to reproduce the comparison.

NIST advises organizations to compare AI system risk and performance with human performance, simpler approaches, and other manual benchmarks rather than judging the system in isolation. ³

A bad answer sounds like: “Users preferred the new experience.” That may be useful evidence, but without a defined comparison it can conceal slower work, transferred effort, or additional review. A polished output is not an improvement unless it beats the accepted current state on the funded decision.

Third, make the vendor face representative hard cases

Approve the evaluation set before the vendor runs the final test. Include routine work, uncommon valid inputs, ambiguous cases, missing information, adversarial behavior where relevant, and cases that require refusal or escalation. For a contract-review pilot, that means testing against a genuinely ambiguous indemnification clause pulled from a real, messy contract, rather than the clean template the vendor demoed with.

Representation concerns the intended use, not statistical decoration. The EU AI Act requires data for high-risk systems to be relevant and sufficiently representative for the intended purpose. ⁴

Require a case register containing the reason each class is included, the expected handling, the result, and every exclusion. Give the buyer control over a held-back portion of the evaluation material. The vendor should encounter those cases only during the agreed test.

A bad answer sounds like: “We tested a representative sample from the available data.” It conceals who defined representative, which failures were removed, and whether availability excluded the work that creates operational risk.

Fourth, expose the system to the operation it would enter

Specify the conditions the pilot must face: actual user roles, realistic input quality, permission boundaries, review queues, escalation routes, downstream handoffs, and an agreed fallback when the system cannot proceed.

Real-world testing is a distinct activity with its own plan, rather than an informal extension of laboratory evaluation. The EU AI Act makes that distinction explicit for covered high-risk systems. ⁴

The acceptance record should include failures and recoveries, not only completed outputs. Require timestamps, user interventions, overrides, escalations, unresolved cases, and changes made during the test. If another supplier or internal team may inherit the system, use Can another team operate what your AI vendor built? to add the necessary handover evidence.

A bad answer sounds like: “The pilot used production-like data in a secure environment.” It conceals whether the system survived the people, interruptions, dependencies, and controls that define production work.

Fifth, put an edge around cost before usage creates the bill

Set a total pilot spending cap and state what it includes: vendor fees, third-party charges, buyer labor, integration work, evaluation, security review, support, and decommissioning. State who authorizes exceptions and whether an overrun is itself a no-go event.

Require an operating cost schedule tied to the expected unit of work. It should expose assumptions about volume, retries, human review, exception handling, monitoring, and support. A low cost for a successful automated transaction says little if difficult transactions repeatedly require manual recovery.

Investment-gate guidance requires a comprehensive financial management process, including allowances for risk-informed contingencies, before a project proceeds. ²

A bad answer sounds like: “Costs will be optimized at scale.” It conceals the price of the proposed operating pattern and asks the buyer to approve expansion before affordability has been shown.

Sixth, precommit the conditions that stop the project

Write no-go criteria as observable conditions. Each criterion needs an evidence source, an evaluator, a decision owner, and the consequence of failure. Include unsafe behavior, unacceptable outcome quality, unaffordable operation, excessive human intervention, failed controls, and inability to reproduce the vendor’s result where those conditions affect the decision.

Route the acceptance record to someone outside the delivery team. NIST recommends independent risk reporting because it can counter groupthink and sunk-cost bias. ⁵

Define the stop process as carefully as the success path. State who withdraws access, preserves evidence, closes integrations, returns or deletes data, communicates with users, and signs the closure record. NIST treats safe decommissioning and phase-out as a process that should already exist. ⁵

A bad answer sounds like: “The steering committee will consider all findings in context.” Context matters, but this wording conceals unlimited discretion to excuse any miss.

Precommitted gates do not rescue a badly governed pilot

This procedure cannot repair an irrelevant business case, unavailable data, unlawful use, weak executive sponsorship, or a supplier that lacks access needed to perform the test. Those are entry conditions. If they remain unresolved, do not start the pilot.

It also cannot prevent leadership from abandoning useful work for unrelated reasons. RAND found that shifting priorities can end projects before they demonstrate results, while other teams are moved on prematurely and deliver only a fraction of the system’s potential. ¹

That failure should not be mislabeled as a technical no-go. Record it as a cancelled or superseded decision, preserve the evidence gathered, and close the pilot under the agreed exit process. A valid no-go means the system failed a criterion fixed in advance. Cancellation means the organization stopped asking the question.