Kognita
All posts
Product2026-09-15·8 min read

How to audit your company's knowledge before you automate it

Pointing an AI at a messy knowledge base automates the mess. A knowledge audit — before you build — tells you what you have, what's stale, what's missing, and what's safe to expose. Here's a practical template.

The most common way an AI knowledge base project fails is that the team skips straight to building. They connect the AI to the wiki, the drive, and the ticket history, flip it on, and discover the hard way that half the content is outdated, some of it contradicts the rest, sensitive documents are now answerable by anyone, and the questions people actually ask aren't covered at all. An AI doesn't fix a messy knowledge base — it automates the mess, and does so confidently. A knowledge audit before you build is how you avoid that. Here's a template.

how to audit your knowledge before you automate it

Why audit first

Automating retrieval over your content amplifies whatever's already there. Good content becomes more findable; bad content becomes more authoritatively wrong. An AI will retrieve a stale policy and state it with total confidence, quote a contradicted fact without noticing the contradiction, or surface a document that should have been access-controlled. The audit's job is to surface these before they become answers. Think of it as due diligence on the raw material before you build the machine that broadcasts it.

Step 1: Inventory your sources

Start by mapping where knowledge lives. Almost always it's more places than anyone expects:

  • Wikis (Confluence, Notion)
  • Shared drives and document stores (Google Drive, SharePoint)
  • Ticketing and support history (past resolutions are gold)
  • Communication tools (Slack threads where real answers happen)
  • Code repositories, runbooks, and internal tools
  • People's heads and local files (the knowledge that isn't systematized yet)

For each source, note roughly: how much content, how it's structured, who owns it, and how it's accessed. You can't decide what to ingest until you know what exists.

Step 2: Assess freshness and accuracy

For each source, ask how current and correct is this? Categorize content as:

  • Fresh and trusted — actively maintained, safe to expose.
  • Stale — outdated, needs review or exclusion. Remember: stale content in an AI system is worse than missing content, because it produces confident wrong answers.
  • Contradictory — multiple sources disagree (three docs, three different refund windows). The AI will retrieve whichever it ranks highest, so contradictions must be resolved or the system will answer inconsistently.
  • Unowned — no maintainer, so no reliability guarantee. Flag for ownership assignment.

This is often the audit's most sobering step: teams discover a large fraction of their "knowledge base" is stale or contradictory. Better to learn it now than from a customer.

Step 3: Identify sensitivity and access requirements

Before anything gets ingested, classify content by who should be able to see it:

  • Public/general — safe for anyone in the audience.
  • Restricted — HR records, financials, legal, security details, customer PII — content that must not be answerable by unauthorized users.

This drives your permission model. If restricted content goes into a knowledge base that answers everyone equally, you've built a data-leak engine. Decide now what gets excluded entirely versus what gets ingested with permission controls that filter retrieval by the querying user. Getting this wrong is a security incident, not a quality issue.

Step 4: Map the demand side — what do people actually ask?

An audit of supply (what content you have) is only half the picture. You also need demand: what questions people actually ask. Pull from:

  • Support ticket themes
  • Repeated questions in Slack/help channels
  • Search logs from your existing (probably keyword) search, especially the queries that returned nothing
  • A survey of the teams the KB will serve

Then compare demand to supply. The gaps — frequent questions with no good source content — are your coverage holes. These matter enormously: they tell you where the AI will fail no matter how good retrieval is, because the answer simply isn't in the corpus. Coverage holes are content problems to fix before or alongside building, not retrieval problems to tune away.

Step 5: Produce the audit output

The deliverable is a clear picture that drives build decisions:

  • Ingest list — fresh, trusted, appropriately-scoped sources, ready to go.
  • Fix-first list — content that's valuable but stale, contradictory, or unowned; remediate before or during ingestion.
  • Exclude/restrict list — sensitive content to keep out or gate behind permissions.
  • Coverage gaps — high-demand topics with no good source; a content-creation backlog.
  • Ownership assignments — every ingested source gets a maintainer, so freshness has an owner from day one.

The payoff

The audit turns "point AI at everything and hope" into a deliberate rollout. You ingest content you trust, you've resolved contradictions so answers are consistent, sensitive material is handled, and you know in advance where coverage is thin so you're not blindsided by confident failures. It also front-loads the governance — ownership and review — that keeps the knowledge base from going stale later.

None of this is glamorous, and it's tempting to skip because building is more fun than inventorying. But the teams whose AI knowledge bases succeed almost universally did this first. The audit is cheap; automating a mess and discovering it in production is expensive. Know what you have before you teach a machine to speak for it.