How to Run an AI Audit That Actually Leads Somewhere

Two consultancies had already quoted a client of ours for an "AI audit" before they called us. Both proposals were the same shape: a discovery phase, a sixty-page slide deck, a maturity-model diagram with their logo on it, and a number with a lot of zeroes. Neither one ended with anything the company could do on Monday morning.

That is the problem with most AI audits. They produce a document, not a decision. A real audit is not a report, it is a prioritised queue of work: a short, ranked list of the processes worth pointing an agent at first, and the honest reason each one is ranked where it is. This post is the mid-market version, the one that takes a week and costs a fraction of the platform pitch.

What Is an AI Audit, Really?

An AI audit answers one question: given everything this business does, where should AI go first, second, and third? Everything else is supporting evidence. It is the diagnostic that turns "we should be doing something with AI" into "we are automating invoice reconciliation next month, and here is why that one and not the others."

Notice what it is not. It is not a technology assessment of which model to buy. It is not a maturity score out of five. It is not a transformation roadmap stretching to 2028. Those artefacts feel substantial and change nothing. The audit that works is smaller and sharper, and its whole value is that it makes the next three decisions obvious.

The reason this matters at mid-market scale specifically: you do not have the budget to be wrong twice. A 200-person company can afford a stalled pilot as a learning experience. When you have thirty staff and one operations lead, a wrong first bet costs you the internal credibility you need for every bet after it. The audit exists to make the first bet a safe one.

Who Do You Talk To, and What Do You Ask?

Talk to the people doing the work, not just the people describing it. This is the single most common failure we see. The leadership team knows the strategy, but they have not personally reconciled an invoice or chased a quote approval in years, so they genuinely cannot see where the hours go. The highest-return use case in a business is usually invisible from the top of the org chart.

So the interview list runs top to bottom. From the leadership team you want the strategic picture: where is the business trying to grow, what is the constraint, what would you never risk automating. From the operators, the estimators, the admin staff, the account managers, you want something more specific and more valuable: walk me through your Tuesday. What do you open first? What do you dread? Where do you copy and paste the same thing between two systems? What takes an hour that feels like it should take five minutes?

The surveys the enterprise version leans on are optional at your scale, and often worse than a conversation. A ten-minute chat where you watch someone's screen tells you more than a fifty-response form. You are hunting for the boring, repetitive, high-volume work that everyone has stopped complaining about because they assume it is just the job.

Mapping the Processes That Matter

You do not need to map the whole company. Pick the five to eight processes that came up most in the interviews and map only those, end to end, marking two things at every step: where a human makes a judgement call, and where work crosses from one system to another.

Those two markers tell you almost everything about readiness. A process full of clean judgement calls (an agreed rule everyone follows) and messy handoffs (copy-paste between the CRM and the accounting system) automates beautifully, because the copy-paste is exactly what an agent removes. A process with clean handoffs but vague judgement (three people applying three different markup rules) is not ready, because automating it just produces inconsistent output faster. If you cannot write the rule down, the process is not ready for an agent, and the audit should say so plainly.

This is also where you find the decision points that need fixing before any automation. Half the value of an audit is discovering that your quoting process is not slow because it lacks a tool, it is slow because nobody agreed what "approved" means. That finding is worth more than the automation.

Turning the Audit Into a Sequenced Plan

Now rank. Every candidate process gets scored on three axes, and all three earn their place.

• Value. Hours consumed multiplied by the cost of getting it wrong. A ten-hour task that is fine at ninety percent accuracy scores lower than a two-hour task where an error reaches a client.
• Readiness. Is the data reachable read-only, are the decision points defined, does someone own the process. This is what the mapping told you.
• Cultural support. Will the team using it want it to work, or quietly route around it. This axis gets left off most audits and it is the one that sinks the most projects.

Plot value against readiness and the strategy writes itself. High value and high readiness is where you start. High value and low readiness is your prize pile, funded by the early wins, once you have fixed the permissions and the decision points. Low value and high readiness is practice work you can hand to keen staff. Low value and low readiness you ignore until next quarter, where most of it dies of natural causes. Then let cultural support break the ties.

What Does a Good Readout Look Like?

One page, or close to it. A good readout is a ranked list of five to ten candidates, each with a one-line reason for its position, a named owner, and a clear first pick with the boring-win properties: back-office, attributable return, low pushback. It reads like a queue, because it is one. We wrote the standalone guide to choosing that first item in how to choose your first AI project.

If the readout you are handed is longer than a few pages, be suspicious. Length is usually a substitute for a decision, not evidence of rigour. The test is simple: could the operations lead read it in ten minutes and know exactly what happens next? If not, it is a document, not an audit.

How Long Should This Take?

A week of calendar time, a few days of actual work. Two days of interviews, a day of process mapping, a day to score and sequence, a morning to write the one-pager. You are not building the company brain during the audit, you are deciding what to build first, and that decision does not require a quarter of discovery. The retrieval layer and the data cleanup come later, once you know which use cases actually need them; that is its own piece, building the company brain.

The enterprise version stretches to months because it is trying to be comprehensive. Yours should be trying to be decisive. Those are different goals, and at your scale decisive wins.

Where to Start This Week

Block two afternoons and sit with the five people who run your operations. Watch their screens, note every copy-paste and every hour that feels wasted, and leave with a list. Map the top handful, score them on value, readiness, and cultural support, and write the one-page queue. That is an AI audit, and it is the difference between a year of pilots and a first win inside a month.

If you would rather have an outside pair of eyes run it, our Deep Dive does exactly this: we interview your team, map your processes, score your use cases, and hand you the ranked plan. No sixty-page deck, no platform rebuild, just the queue and the reasoning behind it.