How to Build an Internal Knowledge System Employees Can Trust

What makes staff trust an internal knowledge system?

Trust is not built by clever answers. It is built by predictable behaviour. A service engineer asks what the warranty covers on an industrial unit sold in Kerala last year, and gets a short answer, the clause it came from, the date that document was last reviewed and the name of the person who owns it. She can check in ten seconds. She stops checking after a few weeks, because every time she checked, it held.

Trust is lost in one incident. An assistant states a discount policy that expired in March, someone repeats it to a customer, and the whole team goes back to asking a colleague on chat. That is the real competition for an internal knowledge system: not a search box, but the two people everybody messages because they always know.

• Grounded: every answer comes from a document your business approved, not from the model’s general knowledge.
• Permissioned: nobody sees through the assistant what they could not open directly.
• Current: each source has an owner, a review date and one live version.
• Honest: when the evidence is missing or contradictory, it says so and points to a person.

Why must every answer come from an approved source?

A language model knows a great deal about the world and nothing about your credit terms. The useful pattern is narrow: take the question, find the passages that might answer it in your own approved material, answer from those passages only, and show which ones were used. Where nothing relevant is found, the honest output is a gap, not a fluent paragraph assembled from general knowledge.

This matters because the failure looks like a success. NIST’s profile for generative AI describes confabulation as the production of confidently stated but erroneous content. The same document sets out what high-integrity information looks like: it distinguishes fact from opinion, acknowledges uncertainties, and can be linked to the original source with appropriate evidence. That is a fair specification for an internal answer, and it is why the citation is not decoration.

How should access follow the permissions you already have?

The rule is simple to state and easy to break: a person should never learn through the assistant anything they could not open for themselves. Break it once with a salary band or a partner contract, and the system becomes a liability rather than a service.

• Check permissions when the question is asked, against the asker’s own identity and current rights.
• Do not rely on filtering at the end. If a restricted passage reaches the answer, it has already been read.
• Test with a real restricted document and a real restricted account before launch, then again after every change.
• Record who asked what and which sources were used, and agree who reviews those records.
• Remember that a summary can leak what the file did not: figures, names and terms all travel.

Our Enterprise Knowledge work treats access rules as part of the design rather than a setting: permissions are verified during retrieval, and restricted material is tested to confirm it stays restricted. For the wider question of what any AI system should be allowed to reach, how to introduce AI without giving it uncontrolled access is the companion piece.

Who owns each source, and how does it stay current?

A knowledge system inherits the quality of the catalogue behind it. Before indexing anything, list the sources you are prepared to stand behind and give each one an owner, a review rhythm and a status. Everything else stays out. A folder called “Old_Final_v3” is not a source; it is a trap you have chosen to publish.

Then remove the duplicates. If three versions of the leave policy sit in three folders, the system will cite one of them, and it may not be the one that is in force. One live version, dated, with older copies clearly archived, does more for answer quality than any change to the software. The India AI Governance Guidelines published by MeitY put “People First” and “Understandable by Design” among their seven guiding principles, asking for human oversight and for disclosures the intended user can understand. In an internal system that means a person owns each source, and the answer shows enough for the reader to judge it.

What should it do when the answer is not there?

Saying “I could not find this in our approved sources” is the most valuable sentence an internal system can produce. It protects the reader, and it produces something useful: a list of what your documentation is missing, ranked by how often people ask. Route each gap to the owner of the nearest source, with the original question attached, and review the queue on a fixed day.

Contradictions deserve the same treatment. When two approved documents disagree, the useful behaviour is to show both and flag the conflict, not to pick a winner quietly. Somebody then has to decide which is right, which is exactly the work that keeps a knowledge base alive.

How do you measure whether the answers are good?

Build an evaluation set from real questions your team has actually asked, with answers agreed by the people who know the work. Include awkward cases: questions with no approved answer, questions where two documents conflict, and questions the asker is not allowed to have answered. A set of fifty to a hundred questions is enough to see whether a change helped or hurt.

• Source-supported rate: answers that cite a source the reviewer accepts as relevant.
• Correctness on the evaluation set, graded by a person who knows the subject.
• Refusal quality: whether it declined the questions it should have declined.
• Time to a usable answer, compared with the old habit of asking a colleague.
• Gap closure: how long a reported gap waits before its owner fixes the source.
• Repeat use: whether the same people come back next week without being told to.

NIST’s AI Risk Management Framework asks that performance criteria be measured and demonstrated for conditions similar to the deployment setting, that the measures be documented, and that people who were not front-line developers of the system take part in regular assessment. In a small company that can be one experienced colleague reviewing twenty answers a month. The habit matters more than the scale.

Where should people still ask a colleague?

A knowledge system is good at what has been written down and agreed. It is poor at everything a document cannot hold: why a client was given an exception two years ago, how a regulator responded last time, whether this customer will accept a delay. Name those areas openly, so people do not learn the boundary by being let down.

• Judgement calls: pricing exceptions, credit decisions, whether to accept a return.
• Anything with a legal, safety or clinical consequence.
• History and relationships: what was promised, and by whom.
• Situations where the document is silent, ambiguous or out of date.
• New situations nobody has faced yet, which is where your next SOP comes from.

The system should hand these over rather than attempt them, naming the person or role to ask. That is also the bridge to the next piece of work: turning what those colleagues know into documents worth citing. AI for SOPs, policies and institutional knowledge covers how to capture and maintain the sources this system depends on.