# Sign off on the decision to stop an AI pilot before it starts

> Many AI pilots get stuck because nobody agreed in advance what "working" means. A weak model is often not the problem.

Original: https://fdetimes.net/en/guides/ai-pilot-stop-criteria-scorecard/

It is week six of the pilot and you are in a meeting with the customer. The agent answers roughly three-quarters of questions correctly. The head of operations asks: "So is that good or not?" Nobody speaks, because nobody ever wrote down how much counts as "good".

This scene is more common than you might think. A survey by S&P Global Market Intelligence found that the average organisation abandons 46% of AI PoCs before they reach production. The share of companies abandoning most of their AI initiatives jumped from 17% to 42% in a single year.

So the question for an FDE is not how to make sure a pilot never fails. The right question is this: when results fall short, is the next step already decided, clear and signed by both sides? That skill is what separates people who run pilots well from people who are only good at demos.

## Pilots fail for lack of definition, not only for lack of quality

A practical guide from SoftwareSeni puts it bluntly: pilots often get stuck because, before they started, nobody agreed what "working" meant. Without a definition, each party reads a figure of 75% its own way. Engineering sees progress, finance sees risk, and the project sponsor sees fatigue.

Gartner predicted that at least 30% of GenAI projects would be abandoned after proof of concept by the end of 2025. It gave four reasons: poor data, inadequate risk controls, escalating costs and unclear business value.

The last of these is entirely in your hands. Value is "unclear" only when nobody has written down how to measure it.

Anthropic's official documentation on evaluating models sets out the basic principle: replace "good performance" with a specific, measurable metric, and fix it before you build the eval.

The same documentation warns that targets should not exceed what the model can currently do. Setting a 99% threshold for a task where benchmarks reach only 85% is like drafting the failure report in advance.

## What to fix on day one, and what to leave for later?

This is where people go wrong. Hamel Husain, an evals specialist who has worked at Airbnb and GitHub, warns that writing a rubric before looking at the data is a very common mistake. In his view, you must analyse logs to learn which errors actually occur, and only then create evals.

The two pieces of advice do not conflict. On day one you fix the business outcome metric, the thresholds and the response protocol. The detailed rubric for grading each type of error is written only after you have read real logs in the first few weeks.

The response protocol is the part most often forgotten. SoftwareSeni advises agreeing how to respond before the scorecard signals failure, and splits course corrections into two kinds.

Revive means fixing one solvable bottleneck while keeping the current approach. Restructure means redesigning the approach. The final decision at day 90 is deliberately designed to have only two possible answers: scale or stop.

## What does a day-one scorecard look like?

Picture a hypothetical pilot: an agent that answers invoice questions for the customer service team of a logistics company. Before writing a line of code, you and the customer service lead sign a one-page scorecard like this.

| Checkpoint | Question to answer | Agreed threshold and action |
|---|---|---|
| Day 30 | What do real errors look like? | Read at least 100 logs, classify the errors, write the rubric from them |
| Day 60 | Are we on track? | 85% correct or above: prepare to scale. 70–85% with errors concentrated in one fixable cause: revive. Below 70%, or errors scattered and caused by the workflow: restructure or stop |
| Day 90 | Scale or stop? | Only two options; the person who signs the decision was named on day one |

The 85% and 70% figures here are only illustrations. In practice you set them based on a small initial experiment and the current productivity of staff doing the work by hand, in keeping with the emphasis on "achievable" targets that Anthropic stresses.

Now it is day 60. On a set of 200 real questions, the agent answers 148 correctly, or 74%, which lands in the middle band. Nobody is allowed to jump to conclusions. You open the 52 wrong answers and label each one.

The result: 31 errors happened because the person asking did not give a waybill number, so the agent could not look up the right invoice. 14 errors came from the agent consulting an old price list that had not been updated. Only 7 were cases where the model reasoned wrongly despite having all the data it needed.

This is exactly the kind of failure Husain describes: the model never had a chance because the user's question was too vague and lacked enough context.

If adding a mandatory waybill-number field fixes those 31 errors, accuracy could rise to 179 out of 200, or 89.5%.

Switching to a stronger model, by contrast, could fix at most 7 errors.

Under the signed protocol, the decision is to revive: fix one specific bottleneck while keeping the current approach. As a result, the day-60 meeting lasts fifteen minutes, because nobody has to argue again about what "good" means.

**Key point:** The decision to stop a pilot should be signed before it starts, not after it fails.

## When to redesign rather than patch?

Suppose the labels told a different story: errors spread evenly, and customer service staff ignore the agent because it sits outside the tools they use every day. That is the signal to restructure. MIT NANDA's report "The GenAI Divide" argues that generic tools stumble in enterprises because they do not learn from or adapt to real workflows.

The report puts the failure rate for enterprise AI solutions at 95%, but its sample is fairly small, so treat that figure only as an indicator.

What is worth keeping is the diagnosis: the root cause lies in the gap in integrating with workflows, not in model quality. In this case, restructuring means putting the agent on the very screen staff already use to do their work.

The same report finds that solutions built in-house succeed only a third as often as those bought from specialist vendors or built through partnerships. So when you restructure, seriously consider buying rather than building, even if you are the one writing the code.

## Mistakes that ruin a good decision

The first mistake is scoring too early. Gartner's Rita Sallam notes that the impact of GenAI is often not visible straight away but emerges gradually over time. If your main metric is the whole team's handling time, do not measure it in week two, while staff are still learning to use the tool.

The second mistake is switching models by reflex. As the example shows, most errors may sit in an input form or a price list, and no model can fix stale data. Always count your error labels before opening a model comparison page.

The third mistake is letting the pilot run indefinitely. A pilot without a day-90 checkpoint easily becomes an endless series of "one more month" extensions. It slowly burns through cost, which S&P Global ranks among the top barriers alongside data privacy and security.

## Turn this skill into a career advantage

On your CV, don't just write "deployed an agent for a customer". Spell out how you set the scorecard, how many logs you read, and which numbers you used to choose between reviving and stopping.

A recruiter reading that will see that you know how to bring a pilot to a clear conclusion rather than stopping at the demo.

This week's exercise: pick a pilot you have worked on, even one that has ended, and rewrite the scorecard it should have had from day one. If you cannot write its day-60 threshold, you now understand why that meeting went silent.

**Try this week:**

- Take a live pilot and rewrite its scorecard on one page: main metric, three thresholds, three checkpoints, and who signs the decision
- Read 50 real logs, tag each error with one label (data, product, workflow or model), then count them
- Send the scorecard to the accountable person on the customer side and ask them to confirm the response protocol before the next checkpoint

## Sources

- [Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025](https://www.intelligentcio.com/eu/2024/08/05/gartner-predicts-30-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025/)

- [AI project failure rates are on the rise: report](https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/)

- [MIT report: 95% of generative AI pilots at companies are failing](https://finance.yahoo.com/news/mit-report-95-generative-ai-105412686.html)

- [Define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/define-success)

- [Automating Error Analysis](https://hamel.dev/notes/llm/ai-product-engineering/evals-error-analysis.html)

- [Hamel Husain explains why AI evals fail before the evaluation begins](https://arize.com/blog/rise-of-the-ai-engineer-why-ai-evals-fail-before-the-evaluation-begins/)

- [How to Define Production Readiness Before an AI Pilot Begins](https://www.softwareseni.com/how-to-define-production-readiness-before-an-ai-pilot-begins/)

- [When to Kill, Revive, or Restructure a Stalled AI Pilot](https://www.softwareseni.com/when-to-kill-revive-or-restructure-a-stalled-ai-pilot/)