What an AI readiness audit actually measures

“Should we be doing something with AI?” is the wrong question. It has no answer, because it isn’t about anything specific. The question that has an answer is narrower and much less exciting: which of our processes have a clear input and a predictable output, and how many hours a month do they consume?

That reframing is the entire content of an AI readiness audit. Everything else — model choice, tooling, build-versus-buy — comes after, and is much easier once you know what you are pointing at.

Three filters, applied to real processes

In a mid-size logistics company, we ran this across the operational, product, and technical side of the business: back office, support, reporting, ticket classification, and data extraction from documents. Each process went through three filters.

Is it repeatable? Not “does it happen often” — does it happen the same way each time. A process that branches differently depending on who is handling it isn’t one process, it’s several, and each branch needs its own answer.

Is it based on text or rules? Language models are good at text in, text out, and at decisions that follow stated rules. They are not a substitute for a decision nobody has written down. If the rule lives only in someone’s head, the automation project is actually a documentation project first.

Is the data good enough? This is where most candidates die. A process can be perfectly repeatable and perfectly rule-based, and still be a bad target because the data feeding it is inconsistent, incomplete, or scattered across systems that disagree with each other.

The number that came out

In that company, roughly 20–30% of processes qualified for partial AI automation — which worked out to about 40–80 hours per month that could realistically be recovered.

Two things about that number matter more than the number itself.

First, it’s a range, not a point. Anyone giving you a single figure before looking at your data quality is guessing. The spread between 20% and 30% is exactly the uncertainty that an audit is supposed to expose rather than hide.

Second, “partial” is doing real work in that sentence. Almost none of those processes were candidates for full automation. The realistic shape is a human staying in the loop on the judgement calls while the repetitive scaffolding around them gets handled — classification, extraction, drafting, summarising.

Where the qualifying processes clustered

The candidates were not evenly spread. They concentrated in three places:

• Back office — repetitive administrative steps with clear inputs and stable outputs.
• Support — classifying and routing incoming requests, drafting first responses.
• Reporting — assembling the same shapes of information on a schedule.

That clustering is worth knowing before you start, because it tells you where to look first. It also tells you where not to look: the parts of the business where every case is genuinely different are the parts where an audit will keep coming back negative, and that is a correct result rather than a failed one.

Why data quality caps the answer

The single most common way these projects disappoint is that someone automates a process whose inputs are messier than anyone admitted. The automation then produces confident output from bad input, which is worse than no automation, because now the errors look official.

This is why a serious audit adjusts its estimate downward when data quality is poor, instead of quietly assuming it will be cleaned up later. If the data underneath a process is chaotic and hard to reach, the honest answer is that the process is not ready — and the useful next step is a data problem, not an AI problem.

What you should get out of an audit

A readiness audit is a counting exercise with a written conclusion. Done properly it hands you:

• the specific processes worth automating, named, not categories;
• an estimated range of hours per month recoverable, with the reasoning shown;
• what is blocking the rest — usually data quality or process variability;
• the ones that don’t qualify yet, and what would have to change for them to qualify.

That last item is the one people skip and the one that ages best. A “no, and here’s why” is a result you can act on next quarter. A vague “yes, there’s potential” is not.

The part that generalises

The lesson from that engagement was not the percentage. It was the framing:

An AI readiness audit is not the question “should we adopt AI.” It’s the arithmetic of which specific processes have a clear input and a predictable result.

In a typical mid-size company that tends to land at roughly a quarter of processes and a few dozen hours a month, concentrated in back office, support, and reporting. Your numbers will differ — that is what the method finds, not a promise about your company. But the method is the same, and it is boring on purpose. Counting beats speculating.

If you want the counting done on your processes, the audit is where that starts. If you’d rather get a rough read first without talking to anyone, the AI Leverage Scorecard asks ten questions and sends back an estimate built the same way.