How Accurate Does AI Actually Need to Be?

Not every task calls for the same level of precision from a tool. My GPS doesn’t need to know the exact location of every object on the road to be useful. If it tells me to turn right in 500 feet, I don’t expect the turn to land exactly 500 feet away. Close enough gets me where I’m going. 

But I wouldn’t trust that same level of precision to tell me exactly where my property line runs before I put in a fence. Off by a few feet there means tearing out a fence and moving it, or ending up with a gap between my yard and the neighbor’s that nobody wanted. Same underlying idea – knowing where something is – but a very different standard. 

The job sets the standard, and I’ve noticed that distinction tends to get lost as AI shows up in more parts of daily work. There’s an increasing tendency to ask whether an AI system is “accurate,” as though there’s one universal threshold where accurate becomes good enough. There isn’t. A 99% accurate system can be more than enough for one task and nowhere close to enough for another. 

Take air traffic control and financial trading, for example. If the FAA announced a new AI system running air traffic control at 99% accuracy, most people would stop getting on planes. I know I would. Now say a trading platform announced it picked winning trades 99% of the time instead. People would be lining up to hand over their savings. Same number, opposite reactions, because the cost of that missing 1% isn’t remotely the same. 

Most AI deployments don’t have anywhere close to that kind of clarity about their own number. A team runs a pilot, the output looks decent, there’s an arbitrary “good enough” judgement, and the system goes live. Good enough for what, though? Good enough when a human reviews every answer? Good enough when the answer goes straight to a customer? Good enough when it influences a financial decision? Those are very different bars that are worth considering carefully. 

The Principle: Good Enough Depends on the Job 

The standard you set should reflect what the AI is being asked to do, what happens when it gets something wrong, and what users already expect from comparable solutions. 

The first piece in this series argued that AI should continually earn trust through evidence: test the system against answers you already know, and keep testing it as the system changes. But tested against what benchmark? This one answers that: how good does the system actually need to be for the job you’re asking it to do? 

You 

You already make these judgments instinctively. If an AI gives you three ideas for what to make for dinner and one is terrible, who cares? You throw it out. If it summarizes a long article and misses a minor detail, you might never notice. If it summarizes a contract you’re about to sign and misses an important obligation, that’s a different problem. 

The underlying technology hasn’t changed, but the consequences of mistakes have. Before you go to AI with a task, think about what happens if it’s wrong. How costly is the mistake? Would you catch it if it happened? Can you fix it easily? Those questions determine how much you should trust the answer without checking it yourself. 

You don’t need a 99.9% accurate AI tool to brainstorm names for your fantasy football team. You probably want something much closer to perfect before relying on it to run the numbers on a mortgage refinance. Even that isn’t really about hitting some magic accuracy percentage. It’s about understanding the task, the cost of being wrong, and how much human judgment is still standing between the AI’s answer and the outcome. 

My rule of thumb: let the stakes set the scrutiny. Low stakes, take the answer and move on. Anything you’d have to defend later, check it yourself before it leaves your hands. The more consequential the outcome, the more deliberate that verification should be. 

Your Team 

The same principle gets more complicated once a team is involved, because people start making assumptions about who is checking what. 

Picture a healthcare team using AI to draft patient education materials. The AI produces a useful first draft, and a clinician reviews it before anything reaches the patient. That human review shapes what good enough needs to mean here. The AI’s job is producing a draft a qualified person can reliably review and correct, nothing more. 

Now take the human out of the loop. If the same system starts generating patient-facing answers automatically, the standard has to rise with it. A mistake that was easy to catch and fix during drafting can turn into a real problem the moment nobody is reviewing the answer before a patient sees it. 

That’s why teams need to agree on more than whether an AI tool is “accurate.” They need to decide what role it’s actually playing, which errors are tolerable, which aren’t, and where a person still has to be in the loop. 

A good gut check for any AI-assisted workflow your team runs: pick one output and ask what would happen if it went out today with nobody checking it. If the honest answer is “nothing meaningful,” the review step may not be worth the cost. If the answer is “that could cost someone money, time, or trust,” the review should have an owner: someone specifically responsible for verifying outputs, not just a general sense that someone will. 

Your Systems 

At the organizational level, the threshold should be well established and written down. 

Different use cases call for different standards within the same company. A chatbot answering questions about office hours doesn’t need the same bar as a system that helps decide whether an insurance claim gets paid. The threshold gets defined for each use case, before deployment. 

I’ve found it useful to think about that threshold in one of three ways. 

1. A performance gate means the system needs to hit a specific performance level before it can operate at a given level of independence. For example, an AI system might need to correctly classify at least 98% of a particular type of request before it can handle those requests without routine human review. 

2. A review gate means the AI can produce or recommend an output, but a qualified employee verifies it before the customer, patient, employee, or other end user sees it. In this case, the question isn’t simply whether the AI can perform well enough on its own. It’s whether the combination of AI plus human review produces a reliable enough result. 

3. A decision gate is reserved for the highest-stakes situations. The AI can surface information, identify patterns, or make a recommendation, but the decision itself stays with a person. The AI may be highly accurate, but accuracy alone doesn’t give it authority to make the call. 

The threshold shouldn’t be set in isolation, either. If AI is replacing an existing process, that process likely already has a track record, and that track record sets the floor. If your support team currently resolves 92% of tickets correctly on the first reply, and the new AI tool only hits 80%, that’s a regression, no matter how much faster or cheaper the AI version runs. New technology doesn’t get to lower the standard simply because it’s cheaper to operate. 

None of this requires a company-wide overhaul to start. Take the AI use cases already running today, sort each into a performance gate, a review gate, or a decision gate, and write down the specific number or workflow rule that gate implies. 

What This Means for Leaders 

Before approving an AI use case, or reviewing one that’s already live, ask: 

• What is AI being asked to do? Be specific about the task, not just the tool. 

• What happens when it gets something wrong? Consider the financial, operational, customer, legal, or safety consequences. 

• Who catches the mistake? Is there a person reviewing the output, and are they actually positioned to catch the kinds of errors that matter? 

• What standard already exists? Look at the existing process and comparable solutions. What level of performance have people already come to regard as acceptable? 

• What does good enough look like for this use case? Put a number on it when a number makes sense. If it doesn’t, define the workflow or review requirement instead. 

Try this with your leadership team this week: pick one AI use case your team already relies on. Sort it into a performance gate, a review gate, or a decision gate. Then write down the specific number or workflow rule that gate requires, and check whether everyone in the room would have written down the same one. If you wouldn’t have, have that conversation before the next AI use case goes live. 

The Takeaway 

AI doesn’t need to be perfect. 

It needs to be good enough for the job you’re asking it to do. 

The right standard depends on the consequences of being wrong, the human review around the system, and the performance users already expect. A 99% result can be more than enough for one job and nowhere close for another. 

Decide what good enough means before the system does it for you. 

About the Author

Matthew Hisscock is a Senior Consultant at Thrivence specializing in AI strategy, digital transformation, and enterprise technology. Prior to Thrivence, he served as a Vice President and AI Product Manager at Goldman Sachs, where he led enterprise AI initiatives, product strategy, and large-scale transformation programs. Today, he helps organizations turn emerging AI capabilities into practical, scalable solutions that drive measurable business value.