AI Answer Library
Short answer
The minimum is three properties: findable, extractable, and attributable. Findable means the documents live in one known place with a way to search them. Extractable means they are not scanned images or locked files and can be reliably converted to text. Attributable means every document carries a version, an effective date and a visibility scope. Without these three, no model will answer correctly. But you do not need a data platform first — cleaning up the corpus for your first scenario is enough to start.
The table breaks down the data types common in an enterprise, with a definition of "usable" and an owner for each. The criteria are written concretely so they can serve as a pre-kickoff checklist: for every row, sample twenty items at random and count how many pass. The ownership column matters just as much — most of this work sits with the business side, not the technical team, which has neither the authority nor the judgement to decide which version of a policy is currently in force. If that is not settled at kickoff, the project stalls mid-build.
| Data type | Typical problems | What counts as usable | Who owns it |
|---|---|---|---|
| Policies, processes and regulations | Multiple live versions, no effective dates, superseded copies still circulating | One current version each, with an effective date and a superseded flag; archived versions excluded from retrieval | The owning department — the technical team cannot judge which version is in force |
| Product material and technical manuals | Scanned and image-only PDFs, complex tables, specifications trapped in figures | Reliably extractable as text, table structure preserved, key parameters searchable | Technical side runs OCR and parsing; business side spot-checks correctness |
| Historical tickets and support transcripts | Full of personal information, uneven answer quality, and mishandled cases recorded as-is | Redacted, and filtered down to cases a human confirmed were handled correctly | Business side curates correct samples; legal signs off on the redaction standard |
| Structured data in business systems | No callable API, field semantics nobody can explain, and stale data | A stable API or view, documented field semantics, and a defined freshness guarantee | The system owner exposes the interface; the business side documents field semantics |
| Internal terminology and abbreviations | Same thing named differently, same name meaning different things, department-specific abbreviations | A glossary with synonym mappings and disambiguation rules for overloaded terms | Business side leads, extending it continuously from usage feedback |
| Permissions and visibility | No visibility labels, and a company-wide share drive containing everything | Every document labelled with visible departments or roles, aligned with retrieval-layer filters | Business side defines the boundary; technical side enforces it in retrieval |
Walk this list at the kickoff review; any item you cannot answer is a risk signal. One: which documents does the first scenario touch — can you produce an explicit list rather than "whatever is on the share drive"? Two: sample twenty at random — how many yield clean text? Below fifteen, schedule OCR and format remediation first. Three: does the set contain multiple versions of the same subject, and if so, who has the authority to declare which is current? Four: does it contain personal or sensitive data, and who signs off on the redaction standard? Five: can the business team write 50–100 questions they have actually asked, with reference answers? If not, the scenario is usually not yet thought through. Six: can every one of those answers be found in the documents from item one? Whatever cannot must either get a new document or move out of phase one. Seven: who is allowed to see each document? Eight: how often does this data change, and how does the system learn that it changed? Complete those eight and most of the technical uncertainty disappears.
First, "we must build a data platform first" is an expensive misconception. A data platform solves company-wide data supply — long timeline, heavy investment — while one AI scenario typically needs only a small slice of it. The right order is to make one scenario work, let real usage expose the data gaps, then extend governance on demand. Done the other way round, the platform can absorb two years while not a single AI scenario ships. Second, "more data is better" does not hold either. Dumping every historical file into the knowledge base buries retrieval under drafts, superseded versions and irrelevant material, and accuracy falls. Prefer less over more: load only confirmed, currently effective documents and add as needed. Both points come under pressure early in a project, because "build the foundation first" always sounds safer than "make one small scenario work" — yet in practice the former fails more often.
Where this applies
People also ask
How accurate can an enterprise RAG knowledge base actually be?
Should an enterprise knowledge base use RAG or a fine-tuned LLM?
Why do so many enterprise AI projects fail?