How Much AI Error Can Your Business Afford?

By Victor Hoang · Updated Oct 11, 2026

Somewhere in your company, a pilot is stuck because someone asked, "What if it gets one wrong?" And somewhere else, a different team has quietly put AI in front of customers and nobody has asked at all. Both teams made the same mistake. Neither one decided how much error is acceptable.

The question for an executive isn't "is the AI accurate enough?" That has no answer until you say what the work is, what a mistake costs, and whether you can take it back. The better question is: how much error can this specific workflow absorb, and who agreed to that number?

Our view is that every AI workflow needs an explicit error budget, set by the cost and reversibility of a mistake rather than by the tool's reputation. Zero is the wrong target, and "we'll see" is not a target at all.

Key Facts

• Google's site reliability engineers say that 100% is probably never the right reliability target, and that an incremental improvement in reliability may cost 100x more than the previous one.
• In the same book, an availability target of 99.99% allows up to 52.56 minutes of downtime a year, or up to 250 errors on 2.5 million daily requests. The error budget is the failure you've agreed to tolerate, stated as a number.
• NIST's AI Risk Management Framework says attempting to eliminate negative risk entirely can be counterproductive because not all incidents and failures can be eliminated. It also says it does not prescribe a risk tolerance, so organizations should define their own.
• In February 2024, a British Columbia tribunal found Air Canada did not take reasonable care to ensure its chatbot was accurate and ordered it to pay $812.02 in total on a bereavement-fare dispute. The business owned its chatbot's error.

Two Ways to Get This Wrong

The first failure is perfectionism. A leader says AI output must be right every time before it touches a real process. It sounds responsible. In practice it's a veto, because no system, human or machine, meets that bar. The pilot never graduates, the manual process keeps its own unmeasured error rate, and everyone feels safe while the work stays slow.

The second failure is the opposite. Nobody sets a threshold, so nothing trips when quality slips. Error isn't a problem until it's a big one: a wrong quote sent to a major customer, a policy misstated in writing, a batch of records changed that can't be restored. By then the cost is large, and the decision about how much risk to accept was made by default, by whoever shipped it.

NIST describes the trap in the first case plainly. Unrealistic expectations about risk may lead organizations to allocate resources in a way that makes risk triage inefficient or impractical, when a healthy risk culture recognizes that not all AI risks are the same. Treating a mislabeled internal meeting summary like a wrongly denied loan wastes scarce attention on the first and under-protects the second.

What an Error Budget Is

Engineers at Google use the term for reliability. A service gets a target, say 99.99% of requests succeed. The gap between that target and perfection is the budget: the failures you've agreed in advance to live with. Product management defines the target based on what the business and its users need, not engineering alone, because each extra "nine" costs more than the last.

Two ideas transfer directly to AI at work.

The target is a business decision. The SRE book says engineers work with product owners to turn business goals into explicit objectives. For AI, the equivalent is that the workflow owner, not the vendor or the IT team, signs the acceptable error rate. They're the one who knows what a bad output costs.

The budget triggers action. Google's example error budget policy says that when a service exceeds its budget over a four-week window, the team halts changes and releases other than P0 issues and security fixes until it's back within its objective. It also says the policy isn't meant to punish missed targets. It gives the team permission to focus on reliability when the data says it should.

Borrow that logic. A budget with no consequence is a wish. A budget with a pre-agreed response (tighten review, cut scope, pause the automation) turns error from an argument into a routine.

The analogy has limits. Uptime is easy to measure, and AI correctness often isn't. You have to define what counts as an error for each workflow: wrong, harmful, off-policy, or merely unhelpful. That definition is most of the work.

Cost Times Reversibility

How big should the budget be? Two questions set it.

What does one uncaught error cost? Include the direct cost to fix it, the customer or employee impact, and any liability. The Air Canada case is a small number with a large lesson: the tribunal rejected the idea that the company wasn't responsible for what its chatbot said. Whatever your system tells a customer, you said.

Can you reverse it? An error caught before it leaves the building costs minutes. An error that sends a payment, deletes a record, or lands in a signed contract may not be fixable at any price. Reversibility often matters more than size. A hundred small reversible errors are cheaper than one irreversible one.

Combine the two and you get a rough map of how much error a workflow can carry.

Two points sit inside that table. First, "near zero" for a workflow doesn't mean "don't use AI." It means the AI's output can't be the last step. Second, reversibility is something you can engineer. A staging field, a hold period, a daily limit, or a rollback copy converts an irreversible workflow into a reversible one, and that moves it up a row.

A Worked Example (Illustrative)

These figures are invented to show the arithmetic, not to benchmark anyone.

A finance team processes 4,000 vendor invoices a month. An AI tool proposes the coding (which account and cost center each invoice belongs to). Today, clerks key these in by hand, with an error rate nobody has measured.

At the full 3% budget, that's 120 miscoded invoices a month. If 90% are caught at close ($12 each) and 10% slip through ($150 each), the monthly cost is 108 x $12 plus 12 x $150, or about $3,100. The team can now ask a sensible question: does the labor saved by not keying 4,000 invoices by hand exceed $3,100, plus the cost of the checks? If yes, the workflow clears the bar. If it's close, tightening the budget to 1%, or adding a rule that flags unusual invoices for review, becomes a purchase decision with a visible price rather than a feeling.

And here's the piece most teams skip. The same arithmetic applies to the manual baseline. If clerks miscode 2% today, a 3% AI budget isn't an alarming new risk. It's a one-point difference you can decide on. "AI must be perfect" quietly assumes the current process is.

How to Set a Budget, Step by Step

1. Name the workflow, not the tool. "AI in customer support" is too broad to budget. "AI-drafted replies to billing questions" is not.
2. Define an error. Write down what counts: factually wrong, off-policy, wrong tone, missing a required disclosure. Keep the list short enough that a reviewer can apply it.
3. Measure the human baseline. Sample 100 recent outputs from the current process. You need a comparison point, and most teams discover they've never had one.
4. Price one error and check its reversibility. Use the table above. If you can't reverse it, either add a control that makes it reversible or put a person on the final step.
5. Set the budget and the trigger. For example: "No more than 3% of sampled outputs may contain a defined error, measured weekly. Above that for two weeks, we move to full review until we're back under."
6. Name the owner. One person owns the number, not a committee. In our governance thinking, the gap usually opens when everyone is accountable for AI and nobody is accountable for a specific outcome.
7. Review the budget on a schedule. Models change, and so do volumes and customers. The budget you set at launch deserves a quarterly look, particularly when you switch models or vendors.

The Trap Inside Human Review

Leaders often assume "a human reviews it" settles the question. It doesn't, because review has its own error rate, and it gets worse when volume is high and the AI is usually right. A reviewer who sees 500 correct outputs in a row stops reading carefully. We cover that in the rubber-stamp problem.

Budgeting helps here. If you measure the budget on what reaches the customer, the review step becomes part of the system under test instead of an assumption. Seed a few known errors into the queue now and then and see whether they're caught. And remember that review time is a real cost, which is the subject of our piece on the verification tax. A budget that demands heavy review on everything just recreates the perfectionism problem at higher cost.

What to Do Next

For a CEO, COO, or functional head, here is a sequence that fits in a month.

1. List your live and planned AI workflows. Include the shadow ones. If you don't know what's running, start with the tools people actually use.
2. Sort each into the cost-and-reversibility table. Most will land in the top rows. Those should move fast with light controls.
3. Pick the two highest-stakes workflows and set a written budget. Use the seven steps above. Make the owner sign it.
4. Retire the zero-error requirement. Replace "must be accurate" in pilot charters with a number, a measurement method, and a response when it's exceeded.
5. Convert irreversible steps. For each bottom-row workflow, ask what it would take to add a staging step or hold period. It's often cheaper than the review it replaces.
6. Report error against budget alongside value. Pair it with the scorecard in measuring AI ROI beyond time saved, so the board sees the cost of error next to the benefit, not only one of them.

The point isn't to make AI risk disappear. It's to make the risk you've accepted a decision someone made on purpose.

Learn More

• The Verification Tax: Why AI Time Savings Shrink Once Someone Checks the Work
• Measuring AI ROI Beyond 'Time Saved'
• The Governance Gap: What Leaders Get Wrong About AI at Work
• AI Copilots vs. AI Agents: Understanding the Difference Matters