What Actually Drives Up the Cost of an AI Knowledge Base

Most internal knowledge bases are a mix of current, outdated, and flatly contradictory documents that have accumulated for years without anyone pruning them. An agent built on top of that mess will confidently answer questions using outdated information, because it has no way to know a document is stale unless someone tells it. The unglamorous work of archiving outdated content and resolving contradictions before indexing anything is where most of the real budget goes, and it's the step most project plans underestimate.

This is also the step vendor demos never show, because a vendor's demo environment is always built on curated, clean sample documents. Your actual document set almost certainly isn't, and the gap between the demo and your real rollout is exactly where the budget overrun happens.

Once you start auditing documents for accuracy, you'll find content nobody currently owns, written by someone who left the company, covering a process that has since changed twice. Someone has to be assigned to either update or retire each of those documents, and that assignment work is manual, slow, and doesn't parallelize well no matter how much budget you throw at it.

A reasonable rule: any document without a clear owner after the audit gets archived rather than indexed, even if it looks mostly accurate. An agent confidently citing an orphaned document is a worse outcome than the agent saying it doesn't know, because nobody catches the error until a decision has already been made on bad information.

Check each document against these tests before indexing it:

• It is current, meaning it still describes how the process works today rather than how it worked before the last change.
• It has a named owner who can update it or retire it when the process changes.
• It does not contradict another document covering the same topic, since the agent cannot tell which one is right.
• If it has no clear owner after the audit, archive it instead of indexing it, even when it looks mostly accurate.

Median R&D spend runs about 34% of revenue at B2B SaaS companies¹, and for a company building genuine internal search infrastructure rather than wiring up an off-the-shelf tool, a knowledge base project competes directly with that same engineering budget. That's a real tradeoff worth naming explicitly in the planning conversation, not discovering after the fact when the project stalls behind higher-priority product work.

Say a fifty-person company has around eight hundred internal documents accumulated over four years. If even a quarter of them are outdated or contradictory, that's two hundred documents needing review, at maybe fifteen minutes each for someone with the context to judge accuracy. That's fifty hours of unglamorous review work before the agent side of the project even starts, and most budgets never line-item that time explicitly.

That fifty-hour estimate assumes the reviewer already has the context to judge each document quickly. For documents covering a process that's changed hands twice, the reviewer often has to track down someone else to confirm accuracy first, which stretches the real timeline well past what the simple math suggests going in.

Rather than indexing the entire knowledge base at once, pick one well-maintained category, like IT setup or a single product area, and prove the agent works well there before expanding. This also forces the hygiene question early: if even your best-maintained category has contradictions and gaps, that's useful information about what the full rollout will actually cost before you've committed to it.

Use the pilot to build a real per-category cost estimate, hours spent on cleanup divided by documents in that category, and apply that ratio to the rest of the knowledge base before committing a full budget. It won't be exact, but it's a far better estimate than the one most projects start with, which is usually just a guess.

A common mistake is judging a pilot by how impressive the answers sound. A better test is to collect real questions staff ask every week, run them against the pilot category, and have the document owner check each answer against its source. For example, an IT setup category might be tested with questions about laptop provisioning, password resets, and software requests. Any wrong answer should be traced back to a specific document, which is then fixed or archived before the next round. Repeat until the owner is comfortable, and only then expand to the next category. This gives you both a quality signal and the cleanup estimate you need for the full budget.