The fastest way to make an internal KB unusable is to let it become the place where anything written goes. Four things belong in it, three things constantly try to get in, and knowing which is which is most of keeping it navigable.
What belongs: the recurring internal question
How do I get access to X. What do we tell a customer who asks Y. Who owns Z. Where does the thing live. These are questions asked repeatedly by different people, and an article is worth writing exactly when the same question has been answered twice in a chat.
What does not: the process document
A process document says how work moves through the company, step by step, with handoffs. It has a different reader, a different review cycle and usually a different owner. It belongs with the process documentation, not in the KB.
What does not: the policy
A policy is a rule people have to acknowledge, and the record that they did is the point of it. A KB article is a reference nobody signs. Putting policies in the KB loses the acknowledgement, which is the only reason the policy exists.
What does not: the training course
Onboarding material is sequenced and assessed: you go through it in an order and somebody checks you did. A KB is random access and unassessed. New starters need both and merging them produces a base that reads like a course and a course nobody can search, which serves neither audience.
Where the boundary genuinely moves
The reference page that sits inside a process: the table of approval limits, the list of codes, the contact for a system. It is legitimately either, and the useful test is who would be asked whether it is still true. If that is the process owner rather than a KB owner, it belongs with the process.
Questions people ask about internal kb
Should internal and customer bases be one system?
Two bases, whatever the system. Shared systems are fine; a shared base ends with an internal note being published, and that mistake is much more expensive than the second base.
How do we stop it becoming a dumping ground?
Ownership, again. If every article needs a named owner before it can be published, the volume self-limits, because nobody volunteers to own a page they did not want to write.
What about search-only bases with no structure?
They work up to a point and fail on discovery: search finds what you knew to look for, categories tell you what exists. New starters need the second one.
How should an internal KB handle secrets and credentials?
It should not hold them. A KB article can say where the credential lives and who grants access; the credential itself belongs in the password manager or the vault with its own access control. An article that carries a password is the one that turns up in a search result two years after the person who pasted it left.
What about the article that is half reference, half process?
Split it at the boundary. The reference half, the table or the list or the contact, becomes a KB article with an owner; the process half stays with the process documentation and links to it. Two short pages with clear owners outlast one long page that belongs to both and is reviewed by neither.