AI & Automation · 7 min read
Making Company Knowledge Usable for AI: From PDFs to Answers
When a company wants an AI assistant that answers questions from its own knowledge, an uncomfortable question comes first: where is that knowledge, actually? The answer is almost always the same. It sits scattered across PDF folders, SharePoint sites, a half-maintained wiki, thousands of resolved support tickets and, to a remarkable degree, in the heads of three experienced employees. The path from that state to an AI that answers reliably is less an AI project than a data project. That is what this post is about.
The inventory: knowledge rarely sits where you look first
The first step is soberingly practical: walking through together where knowledge actually lives. The obvious places are manuals, process descriptions and the wiki. The richer ones are often inconspicuous: old quotes, which record the actual services and prices. The ticket history, where thousands of customer problems are documented together with the solution that worked. Email threads in which the edge case got settled that no manual mentions. This is not a quirk of badly run companies: according to an IDC survey of more than 400 IT and business decision-makers (2023), around 90 percent of all company data is unstructured, and only about half of it ever gets analyzed.
This inventory regularly exposes a gap: the most valuable knowledge is not written down at all. How to handle the difficult supplier, why machine three gets configured differently, none of it is anywhere. An AI can only use what exists. Sometimes the most important side effect of such a project is that this head knowledge gets documented for the first time, even if only as a recorded and transcribed conversation with the people who carry it. How much stays unused was measured by the German industry association Bitkom in 2024, across 603 companies: only 6 percent said they fully use the potential of their data.
Source: Bitkom survey of 603 companies, 2024
Do not dump everything in: selection beats volume
The obvious reflex is to index the entire file share, on the theory that more knowledge means better answers. In practice the opposite holds. A knowledge base where the 2019 travel expense policy sits next to the 2024 one will serve up one or the other depending on the question, source reference included, with full conviction. Contradictory and outdated documents are the biggest quality risk of the whole undertaking, well ahead of any technical question.
Preparation therefore starts with sorting out: duplicates and old versions removed, one valid document per topic, a recognizable effective date. Where contradictions surface, the responsible department has to decide what applies. This is tedious and cannot be automated away, but it is the same cleanup that would have benefited the company without any AI. The AI merely forces it, because unlike a person it does not know that everyone ignores the folder named “Old_final_2019”.
What “preparation” means technically
Once the sources are selected, the technical preparation follows, and it is less trivial than it sounds. PDFs are a display format, not a data format: a two-column layout, a table running across two pages or a scanned document first has to be converted cleanly into text, otherwise fragments end up in the knowledge base later. Tables need particular care, because a price table without its header row becomes meaningless.
After that, the content is split into sections and indexed, so that a search can find the passages that fit a question. How to split depends on the document type: a manual gets cut at chapter boundaries, a ticket stays in one piece with its solution. Metadata comes on top, such as date, validity and audience, because “What does product X cost?” needs the current price list, not the most similar-sounding passage from some arbitrary year.
Permissions: the AI must not know more than the person asking
One point that never appears in demos and has to be decided early in real projects: not everyone in the company may see everything. Salary bands, cost calculations and personnel files often sit in the same shares as harmless process knowledge. A knowledge base that answers everything to everyone is a data breach with a search box.
The solution is to carry the existing access rights into the knowledge base: whoever cannot open a document in the file share does not receive answers drawn from it either. That sounds self-evident, but it has consequences for the architecture, which is why it belongs at the start of the project, not in the patch phase.
Without upkeep, the knowledge base ages like any file share
The state at go-live is a snapshot. Prices change, processes get restructured, new products arrive. A knowledge base without a maintenance process is, after a year, as outdated as the folder it came from, except that it delivers its outdated answers more convincingly.
In practice, upkeep means three things. New and changed documents flow in automatically, for example by re-indexing defined locations on a schedule. There is a named owner for what belongs in the knowledge base. And the questions the system could not answer get reviewed regularly, because that list is the most honest overview of which knowledge is missing in the company or filed somewhere unfindable.
Realistic effort, realistic start
How much work all of this is depends almost entirely on the state of your document storage, and hardly anyone overestimates that state while almost everyone underestimates the work. Our recommendation is therefore the same as with workflows: start small. One knowledge area with clear value, say the service manual or the ticket history of one product, gets prepared and tested with real questions from the team. That reveals how good your documentation actually is, before you plan the preparation of the full inventory.
What you do not need for this: huge data volumes or an in-house AI team. A few hundred well-maintained documents make a usable knowledge base for a defined area. What matters is not the quantity, but whether what is in there is true.