When I audit a company's knowledge before any AI work, I am not looking at its tech stack. I am looking for five specific kinds of mess: where knowledge really lives, whether the same thing has different names in different systems, whether anything marks what is current, where people re-key data by hand, and what a wrong answer would cost in each workflow. Those five decide whether AI will work, far more than the choice of model or platform. A good audit turns them into a ranked list of where AI will pay first and what has to be fixed before it can. Here is what I look at, and what you should expect to get.
Why audit knowledge before building anything
Most AI projects that disappoint do so for reasons that were visible before the first line of code: the data was scattered, inconsistent or out of date, and the AI was connected to the tidy half of it. The model did its best with what it was given. What it was given was the problem, as I describe in what to do when your AI pilot fails and argue in your AI does not need a bigger model, it needs to know your business.
Leaders know this in hindsight. In a survey of 200 UK mid-market organisations published in September 2026 by TXP, an IT services firm that sells this kind of work, 77% said they wished they had spent more on discovery.
When we built the agentic system that resolved 67% of customer service cases at a European insurance brokerage, the data layer came first, before any models. A knowledge audit is the disciplined version of that first step.
One: where your knowledge actually lives
I start by mapping where the knowledge a process depends on really lives, which is rarely where the process documentation says.
The official answer is the CRM, the finance system and the document repository. The real answer usually includes a handful of spreadsheets maintained by one person, a shared drive with seven years of versions, and inboxes. Especially inboxes: the commitments, exceptions and approvals that never made it into a system. Nobody lists these in the kick-off meeting, and they are often where the most important knowledge sits. I explain why in email is your most underrated data source.
The question I ask is simple: if this person left tomorrow, where would we look for what they know? The honest answers to that question are the real map.
Two: whether the same thing has different names
Next I pull a sample of records for the entities that matter, usually customers, suppliers, products and contracts, and see whether the systems agree on who and what they are.
They rarely do. The same customer is "Northgate Logistics" in the CRM and "NGL Ltd" in finance. A supplier was acquired and renamed, and its history is split in two. Product codes changed in a migration and the old ones live on in older documents. People reconcile all of this from memory without noticing they are doing it.
An AI cannot, so this is where cross-system questions quietly fail. The audit measures how bad it is: how many duplicates, how many systems, and how much of the matching could be done with strong identifiers versus judgement. That tells you how much work an entity registry would take, and it is often less than people fear.
Three: whether anything marks what is current
Then I look at documents: policies, price lists, contracts, procedures, templates. The question is not whether they are good. It is whether anything tells a reader, human or machine, which version is the one that applies today.
In most organisations the answer is filenames and folklore. "FINAL_v3_revised" sits beside "FINAL_v4", the policy that was replaced in the spring is still in the same folder as its replacement, and the only way to know which contract terms apply is to ask the account manager.
This is one of the most common reasons AI assistants give confidently out-of-date answers, as I describe in why your RAG system keeps missing what is in your documents. The audit identifies the document sets where currency matters and whether it can be recorded cheaply, through a status, an effective date or a "supersedes" link.
Four: where people re-key data by hand
I look for the places where someone copies information from one system into another: from an email into the CRM, from a spreadsheet into the finance system, from a PDF into a quoting tool.
Re-keying is a signal in two ways. It marks the seams between systems, where knowledge is most likely to be lost, duplicated or changed in transit. And it is often the best early candidate for automation, because the work is repetitive, the rules are known and the value is easy to measure.
It also shows where your vendors cannot help. Most major software vendors now ship an agent that works well inside their own product, as I describe in your AI does not need a bigger model. The re-keying happens between products, which is exactly where no single vendor's agent reaches. That gap is where a knowledge layer earns its keep.
Five: what a wrong answer would cost
The last look is the one that decides where to start. For each process, I ask what it would cost if an AI gave a wrong answer or took a wrong action.
Some wrong answers are cheap: an internal question about the holiday policy, answered slightly wrongly, costs a follow-up message. Others are expensive: a missed contract obligation, a wrongly approved claim, an incorrect quote, a compliance breach. The cost of a wrong answer matters more than the volume of work when deciding where AI should go first.
Combine wrong-answer cost with how tidy the knowledge is and a simple map appears. Where wrong answers are cheap and knowledge is tidy, automate now. Where wrong answers are cheap and knowledge is messy, off-the-shelf search will do while you tidy. Where wrong answers are expensive and knowledge is messy, fix the knowledge first. Where wrong answers are expensive and knowledge is tidy, you have found your best first project, with a human reviewing the exceptions, and it is where grounded agents pay for themselves.
What you should get at the end
A knowledge audit should not end with a long report that sits on a shelf. It should end with decisions.
For each process reviewed, you should get the value AI could add, how ready the underlying knowledge is, what has to be fixed before AI can be trusted with it, a sensible first step and a rough sense of effort. Above all, you should get a recommendation: one process to start with, the success metric that will prove it worked, and what to measure against.
If the right answer is that your knowledge is in good shape and an off-the-shelf product will do the job, a good audit says so. If the right answer is to fix the data before spending anything on AI, it says that too. Both are cheaper than finding out after the build.
How to buy one
Three things separate a useful audit from an expensive one.
It should be fixed fee and fixed scope, with the deliverable named in advance. Weeks, not months, for one business unit or a handful of processes. An open-ended discovery phase is usually the start of a sales process wearing a lab coat.
It should come from someone with nothing else to sell you: no software licence, no platform, no agency bench waiting for the build. A vendor auditing your data has every incentive to find problems its product solves, a conflict I describe in the hidden conflict of interest in hiring a fractional CTO.
And it should be done by someone who has made AI work in production, not only someone who has assessed it. Knowing what breaks is what makes the audit worth paying for.
A self-check you can do today
You can get a feel for your own position in an hour. For one process that matters, ask five questions.
Where does the knowledge this process depends on actually live, including inboxes and personal spreadsheets? Do our systems agree on who our key customers and suppliers are? Could a newcomer tell which version of each important document applies today? Where does someone copy data from one system to another by hand? And what would it cost us if an AI got this process wrong?
If you answered all five confidently, you are in a strong position. If not, the question worth sitting with is which of the five would trip you up first. That is where your AI project would have stalled, and it is where to start.
If you would like an independent view of how ready your knowledge is for AI, before you commit to a build, I would be glad to help. This is exactly what my fixed-fee Knowledge Audit does, in two to three weeks, or you can simply get in touch.
Related: Your AI does not need a bigger model. It needs to know your business · What is an entity registry, and why does your AI need one? · What to do when your AI pilot fails
