What kinds of documents suit a knowledge base, and what to leave out

Good candidates are documents that are current, written for readers, and fine for everyone with access to the assistant to see. Everything else stays out until you've thought about it.

What tends to work well

Look for material that answers the same questions again and again.

• Staff handbooks and written procedures.
• Price lists, service descriptions and product sheets that you keep up to date.
• Frequently asked questions and the standard replies your team gives.
• Opening hours, delivery areas and booking rules.
• Plain-text or well-formatted manuals for the equipment you use.

These share a few traits. They're written as text. They have one owner who can say whether they're right. And they have a clear subject, which helps the search step, which the chunking page covers.

Check the file types your tool accepts before you gather files. Makers list what they support. As one example, Amazon says its Kendra service supports document formats such as HTML, Word, PowerPoint, PDF, Excel and text files.¹ Other products differ.

What to leave out

Old versions and drafts. If three price lists sit in the library, the assistant has to pick one. Wikipedia notes that when faced with conflicting information, RAG models may struggle to determine which source is accurate.² Keep one current copy of each document, or none.

Anything you can't vouch for. AWS lists "creating a response from non-authoritative sources" as a known problem with language models.¹ A forwarded rumor or an unchecked web page copied into the library becomes one more source the assistant may draw on.

Passwords, API keys and card numbers. Never store these in a knowledge base, and never paste them into an AI tool. A library is built to be searched, so keep secrets out of it entirely.

Customer records and personal details. Keep these out unless your business's own policy allows them in that tool. The Australian privacy regulator says sensitive information is a subset of personal information that is generally afforded a higher level of privacy protection.³ That guidance comes from Australia. Other countries have their own privacy rules, so check the official source where you operate rather than relying on this page.

Files meant for only a few people. Think about payroll, performance reviews, legal letters and board papers. Microsoft's documentation warns that opening private content to language models requires granular access control.⁴ Its example is finance data that should only be reachable by the finance team, even when an executive asks the chatbot.⁴

Ask who will be able to read it

The test for every file is simple: should everyone who can use this assistant be allowed to read this? Microsoft says users and agents must only retrieve authorized content.⁴ Some systems can filter answers based on what each user's permissions allow. AWS lists this as a feature of its Kendra service.¹

A simple tool may not do that. It may treat everything in the library as open to every user. The Australian regulator says businesses should conduct due diligence to ensure a product is suitable to its intended uses.³ Read your tool's documentation on access before you upload anything sensitive.

A short routine before each upload

• Is this the current version?
• Would I be happy for any staff member to read it aloud?
• Does it hold secrets or customer details?
• Does someone own it and keep it right?

If you can't answer yes to the first and fourth, and no to the third, wait and sort it out first. The page on upkeep covers what to do once the library is running.