Stop measuring AI projects by accuracy

The first question in most AI steering committees is "what accuracy are we getting?" It is the wrong question, or at least a badly incomplete one, and it produces predictable dysfunction: teams optimise a number that does not correspond to whether the system is doing anything useful.

Consider two document pipelines. The first reports 99.1% field accuracy and routes 40% of documents to human review. The second reports 96.4% and routes 12%. The first is more accurate and roughly three times more expensive to run. Accuracy alone cannot distinguish them, and accuracy alone is what most projects report.

Why accuracy misleads

Accuracy is a model metric. It answers: when the system produced an output, how often was it right? It says nothing about how often the system produced an output at all, what that cost, how long it took, or how the errors compare to what was happening before.

It is also trivially gameable in the direction of uselessness. Raise confidence thresholds and accuracy rises while automation collapses. Every AI system has this dial, and reporting only accuracy creates an incentive to turn it the wrong way.

And it hides distribution. A 96% average across document types can be 99% on the two types that are 80% of volume and 71% on the one that carries the most financial risk. The aggregate looks healthy; the exposure is not.

The four numbers that matter

1. Automation rate

What proportion of work completes end to end with no human involvement? Called straight-through processing in document workflows, containment in support, and autonomous resolution rate for agents — the same question in each case. This is the number that determines how much work was actually removed, and it should always be reported alongside accuracy so the trade-off between them is visible.

2. Cost per completed unit of work

All-in: inference, infrastructure, and the human review tail at your actual automation rate. Compared against the fully loaded manual cost of the same unit. This is the number a CFO can act on, and it is the one most projects cannot produce because they never instrumented cost attribution.

3. Cycle time

Time from work arriving to work completed, measured end to end including queues and waits — not the system’s processing time. A pipeline that processes in four seconds but sits in a review queue for two days has a two-day cycle time, and customers experience the two days. Cycle time is frequently where the business value actually is: intake falling from three days to four hours changes what the organisation can promise.

4. Detected error rate versus the manual baseline

Not the model’s error rate — the errors that reach the business, compared against how many reached it before. Every parallel run we have conducted has found a manual baseline error rate between roughly 1% and 4%, and in almost every case it had never been measured. Without it, an AI system’s errors are judged against an imagined standard of perfection rather than against reality.

Metrics for conversational and agent systems

The same four translate, with different names and one addition each.

For assistants and chatbots, automation rate becomes resolution rate — measured by whether the customer came back within seven days, not by whether the session ended. Deflection that produces a phone call two hours later is not deflection. The addition is correct-refusal rate: how often the assistant declines when the answer genuinely is not in its knowledge base. A falling refusal rate alongside a rising answer rate is the earliest available signal that it has started guessing.

For agents, automation rate becomes autonomous resolution rate, and the addition is escalation precision — when it escalated, was escalation the right call? An agent that escalates everything is safe and worthless; the useful measure is how well its self-assessment tracks reality, and it is the metric that most determines how much autonomy it should be granted.

For AI features inside products, automation rate becomes suggestion acceptance rate, paired with edit distance on accepted output. High acceptance with heavy editing means the output is a useful starting point rather than a finished one — a different product problem than outright rejection, and one that raw usage counts will never reveal.

Instrument before launch

The single most common reason organisations cannot answer whether their AI system worked is that they did not measure the before. Baselines cannot be reconstructed after the fact, and estimates produced six months later are advocacy rather than measurement.

Before launch, capture the current automation rate (usually zero), the current fully loaded cost per unit, the current cycle time from system timestamps rather than from opinion, and the current error rate through a sample audited by an expert. That last one is uncomfortable to run and is the one that makes every subsequent comparison defensible.

Then instrument the new system to report the same four continuously, tagged by work type so distribution is visible rather than averaged away. Cost attribution in particular must be built in from the start — reconstructing per-unit cost from a provider invoice three months later is close to impossible.

Where accuracy still belongs

None of this means accuracy is worthless. It means it is an engineering control rather than a business metric, and it does that job better than anything else available.

Inside the evaluation suite, accuracy against a golden set is what makes change safe. A prompt is tuned, a model is upgraded, a retrieval parameter is adjusted — and the score tells you within minutes whether quality moved. Without it, every change is an act of faith and every regression is discovered by a customer. Teams that ship AI improvements weekly rather than quarterly are almost always the teams with this in CI.

It also belongs in the launch decision, as a threshold rather than a report. "Ship when field-level accuracy exceeds 97% on the golden set with low-confidence cases routed to review" is a decision the business can make in advance. What it should not be is the number reported to the steering committee every month, because the committee cannot act on it.

The distinction is between metrics that guide engineering and metrics that guide investment. Confusing the two produces teams optimising a number nobody outside the team can interpret, and executives approving budgets against a number that does not tell them whether the last one worked.

The metrics that actively mislead

Some numbers are worse than useless because they look like progress. Four appear repeatedly in AI steering packs and none of them should.

Model benchmark scores. A vendor’s performance on a public benchmark tells you nothing about performance on your documents, your questions or your call recordings. We have run evaluations where the model that ranked first on published benchmarks placed third on the client’s actual data, which is exactly the kind of finding that only appears when you insist on your own test set.

Volume of AI interactions. Counting queries, messages or generations measures activity rather than value, and it rises when a system is performing badly — users retry, rephrase and regenerate. A dashboard whose headline number goes up when quality goes down is worse than no dashboard.

Time saved as reported by users. Self-reported savings are systematically inflated, not through dishonesty but because people estimate against how long a task feels rather than how long it took. Where the estimate has been checked against system timestamps in our engagements, self-reported figures have run high by a wide margin in both directions of variance. Use observable durations.

Number of use cases live. This one is popular in board reporting and it actively rewards the wrong behaviour: it counts breadth of deployment while saying nothing about whether any of it works. An organisation with two systems moving real numbers is ahead of one with eleven that are technically live.

Making the four numbers a routine rather than a project

Metrics that require someone to assemble them monthly stop being assembled by about month four. The four numbers need to be a property of the system rather than a reporting exercise.

Automation rate and cycle time come free if the workflow is orchestrated: every run already records its steps, its human interventions and its timestamps, so both numbers are queries against data the system produces anyway. This is one of the underrated arguments for orchestration over hand-rolled pipelines.

Cost per unit requires cost attribution to be built in from the start — tagging every model call with the tenant, feature and work item it belongs to. Reconstructing this from a provider invoice three months later is close to impossible, which is why we instrument it in week one even for clients who do not yet care about the number.

Error rate against baseline needs a periodic audited sample rather than continuous measurement: a few dozen completed items reviewed by an expert each month, scored against the same rubric used for the pre-launch baseline. It is the only one of the four that requires human effort, and an hour a month is a reasonable price for the one number that tells you whether quality is drifting.

Put all four on the same dashboard as the operational metrics the owning team already watches. A metric on a separate AI dashboard is a metric nobody looks at, and the fastest way to make a system invisible is to report on it separately from the business it serves.

Report four numbers, not forty

The failure mode at the other extreme is a dashboard with sixty metrics that nobody reads and that cannot support a decision. Four numbers, reported consistently, with the distribution behind each available on request, is more useful than any dashboard we have seen.

Accuracy still belongs in the engineering evaluation suite, where it does its real job: catching regressions when a prompt, model or retrieval configuration changes. That is a control, and it is essential. It is simply not the number that tells the business whether the system is working.