What error rate should you accept from an AI system?
The rate your own process already produces. Measure that before the system arrives, write it into the contract as a tolerance for each class of error, and read it monthly. A system that is wrong less often than the team it supports is working, whatever the demo looked like.
Contracts are being signed across Alberta this quarter with no number in them anywhere. Accuracy turns up as a word. Then the first wrong invoice lands, and two parties who never defined wrong start negotiating what it meant.
Why almost nobody knows their current error rate?
Every process in your company already produces errors, and almost none of them are counted.
Accounts payable miscodes a supplier. A quote goes out against last year’s price list. An intake form is rekeyed with two digits swapped, and five weeks later someone in billing finds it, fixes it, says nothing and moves on. The work absorbs the mistake. The mistake never reaches a report.
Then a system goes in, and every output it produces is logged, timestamped and attributable. The error rate did not rise. The visibility did.
| What you measure about your team | What you measure about the system |
|---|---|
| Hours worked, volume cleared | Every output, stored |
| Errors, informally, when a client complains | Errors, counted, attributed and dated |
| Performance, at a review once a year | Drift, weekly, if anyone is reading it |
Most AI deployments are judged against a standard the people doing the work were never held to.
How wrong are the systems built for accuracy?
Stanford RegLab ran a preregistered evaluation of the AI legal research tools sold by LexisNexis and Thomson Reuters and found they hallucinate between 17 and 33 percent of the time. The study was published in the Journal of Empirical Legal Studies in 2025.
Hold that against what those products cost. They are sold into a profession where a single fabricated citation ends a career. They are built on retrieval over a curated legal corpus, the architecture every consultant recommends for exactly this problem. Seventeen to thirty-three percent is what a serious, well-resourced, measured attempt looks like.
Every system will be wrong sometimes. What decides whether that matters is the class of error, how fast someone sees it, and who carries it when it reaches a client.
What goes into an error budget?
Six parts. None of them are technical, which is why the technical team cannot write it for you.
- The unit. One invoice, one claim, one quote. Errors per hundred units. A vendor accuracy score measured on a public benchmark says nothing about your workflow.
- A baseline from your own records. Pull a hundred completed items from last quarter and count the mistakes by hand. One afternoon, and it produces the only figure in the exercise nobody can argue with.
- A tolerance for each class of error. The classes carry different consequences, so they cannot share a number.
- A detection rule. Who sees the error, in which report, how long after it happened.
- An owner, named. Plus the escalation path for the day the system is wrong at volume rather than wrong once.
- A review date. Error rates drift as your data, your suppliers and the underlying model change underneath you.
| Class of error | Example | Where the tolerance sits |
|---|---|---|
| Omission | A line item the system never extracted | At or below your human baseline |
| Wrong value | The right field carrying the wrong number | Tighter than the baseline, because it passes review unnoticed |
| Fabrication | A clause, reference or supplier that does not exist | Zero at release, caught by a check the system cannot skip |
| Unsafe action | A payment released, a message sent to a client | Zero, and the system should not hold that permission yet |
An error you catch costs money. An error you never see becomes a liability.
Put the tolerance in the contract
The error budget belongs in acceptance testing, while the price can still move. A vendor who cannot state the measured error rate of their last three deployments is selling a demo, and a buyer who does not ask has agreed to find out in production.
Baseline first, through a readiness assessment, then the budget, then the build. Carry the review effort into the unit economics as well, because a human check on every output moves the cost per decision further than the model choice does. Those two ORKA AI briefings cover the steps either side of this one.
Write the number down before the system touches the workflow. A tolerance agreed in month one is a specification. The same number raised in month seven is a dispute.
Sources
- Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning and Daniel E. Ho, Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools, Journal of Empirical Legal Studies, 2025. Study page at Stanford RegLab.
Software is only the surface. Infrastructure is the rest.
