Why trust is the first design requirement
For an internal knowledge base, the question is not whether the answer is correct, but whether employees dare use it without checking it themselves. Once someone looks up the original document anyway, the time saving disappears and usage fades within weeks. Everything below serves that single purpose.
Requirement 1 — Every answer shows its source
Not "according to the handbook", but a reference to the document, version and preferably passage. That delivers three things: the reader can check in two seconds, an error can be traced to a document rather than "the AI", and outdated sources become visible when they appear in answers.
If the system gives no source, it is a conversation partner with an opinion rather than a knowledge base.
Requirement 2 — Source-system permissions still apply
This pitfall has the greatest consequences. An index ingesting everything and then serving everyone turns your permission model into a suggestion. An employee unable to open the salary overview can then ask questions about it.
The answer must be filtered according to the requester's permissions, with that check as close to the source system as possible. Filtering the result after a model has already seen the content is demonstrably weaker: the model has already read what it was not allowed to see.
Establish this explicitly for each source too. "Everyone may read everything in this folder" is a fine outcome, provided it is a decision rather than an assumption.
Requirement 3 — The date is included
Internal documentation ages quietly. An answer from a three-year-old procedure looks exactly like one from last month's version. Always show the source date, and consider a visible warning for documents older than an agreed age.
This brings a side benefit often worth more than the knowledge base itself: seeing which outdated documents are actually used, the only meaningful priority list for cleanup.
What you deliberately exclude from sources
- Personnel files and HR data — separate handling, usually outside the general knowledge base.
- Drafts and working versions — they produce answers that are not formally valid.
- Channels containing asides, such as informal chat. Technically searchable, but they produce answers someone once typed casually.
- Client data not contractually intended for internal reuse.
Fewer sources with a clear status produce better answers than indexing everything. That is this subject's most counterintuitive lesson.
When this is not the right solution
If knowledge lives in people rather than documents, a knowledge base adds nothing — documenting it is the project. If documentation contradicts itself, a search assistant only exposes that contradiction faster; useful, but not a time saving. And if the real problem is that people do not know something exists, better discoverability helps more than adding a conversational layer.
Keeping permissions intact when connecting multiple document systems is covered in connecting documents and knowledge.