A company knowledge base needs an editor, not just AI

A shared AI assistant can answer a question quickly and still make company knowledge harder to manage. It may retrieve an outdated instruction, combine material intended for different audiences or save a useful correction without recording who approved it. The solution begins with editorial responsibility. A company knowledge base needs owners who can explain what belongs there, who may read it and how it changes.

AI Engineer’s 3 September session with Tanmai Gopal of PromptQL addresses this problem. The publisher describes a company-wide collection of linked documents, file-level permissions and changes proposed by an agent but accepted by a person. These are a vendor’s design choices, not independent proof that the system eliminates leaks. They provide a useful starting point for a small business deciding how to manage its own internal knowledge.

Separate a useful answer from a new company fact

Suppose an employee asks how to handle a late delivery. The assistant combines a support note and an old sales promise into a clear response. The wording may look helpful, but the company still needs to decide which policy applies. An answer generated for one situation should not silently become the permanent instruction for every future situation. Otherwise a one-off exception can spread without anyone noticing that the policy changed.

A simple editorial process distinguishes between suggestions and accepted knowledge. The assistant can propose a correction, identify the affected document and explain the source. A named owner then reviews it. The owner should be able to reject the proposal, narrow it or request evidence. This is an operational recommendation, rather than a claim about a particular product feature. Its value is that somebody remains accountable for what the organisation treats as true.

NIST’s AI Risk Management Framework core treats governance and ongoing measurement as continuing responsibilities. For a small company, that can begin with one named owner and a visible review record.

Organise knowledge around its readers

A folder called “company information” may contain material for everyone alongside private commercial discussions. Connecting the entire folder to an assistant does not resolve those differences. Before a pilot, identify a small set of documents with a clear audience. General product instructions might be suitable. Negotiation notes, personnel discussions and unannounced business changes require a different analysis. The aim is a defensible boundary around a useful task.

The practical test is not whether the assistant can find a sentence. It is whether the person asking would be allowed to see that sentence in its original context. The same question may therefore need different answers for different users. Teams exploring technology and AI resources should ask vendors to demonstrate that distinction using harmless sample material. A persuasive general explanation is weaker evidence than a test with accounts that have different access rights.

Also test what happens when access changes. A person may move to another role, leave a project or stop working with the business. Previously generated summaries can remain in conversation history or exported files. A sound pilot therefore considers more than the original document store. It maps where answers and copies appear, and identifies which of those locations the company can actually control. This prevents a narrow permission check from becoming an overbroad assurance.

Make corrections easier than workarounds

Employees will find mistakes. The useful question is what happens next. If correction requires a long form or a meeting, people may create their own private notes instead. The shared knowledge base then becomes less reliable while everyone quietly develops an alternative. Offer a short correction route: identify the answer, link the better source and name the issue. Keep responsibility for approval separate from responsibility for reporting a problem.

A growing number of corrections can mean several things. Perhaps adoption is increasing. Perhaps the information is changing quickly. Perhaps the system is making more mistakes. Do not declare any one interpretation correct from the count alone. Look at examples, review effort and whether the same errors recur. A correction that prevents repeated confusion is different from a stream of duplicated complaints that nobody resolves.

This belongs in the ordinary management work discussed in leadership and business growth channels. The owner needs time to maintain the material, not merely a title in a project plan. If the company has no capacity to review changes, it should reduce the pilot’s scope. A smaller collection that somebody maintains can be more useful than an impressive archive that everybody assumes somebody else is updating.

Test questions that should remain unanswered

A demonstration usually shows what the assistant knows. A useful evaluation also asks what it should refuse to infer. Give it a question with no approved answer, an ambiguous request and a request outside the test user’s access. The correct behaviour may be to ask for clarification or direct the user to a person. Confidence is not a quality measure when the source is absent.

Keep a small collection of representative questions and rerun it after significant changes to the source material or system. Include the expected source and acceptable limits of the answer. Avoid treating a single successful demonstration as a permanent guarantee. The business process, documents and model may all change. Evaluation should reflect the task the company actually relies on, rather than a generic benchmark chosen because it looks favourable.

For entrepreneurs following startup and entrepreneurship discussions, the first useful deployment may be unglamorous: a maintained set of product answers for an internal support team. Success means people find accurate information, know when to escalate and can repair mistakes. It does not require presenting the assistant as an all-knowing company brain.

Questions before the pilot

Who should own the knowledge? Choose someone responsible for the underlying business process. The person managing the software may support them but should not automatically become the authority on every policy.

Should the assistant update documents itself? Start with proposed changes and explicit review. Expand autonomy only where the business can define and verify acceptable changes.

What is the first success measure? Check whether employees reach a correct, usable answer with less total effort, including verification and correction. Answer speed alone is insufficient.

▶

Source session: AI Engineer, Tanmai Gopal, 3 September 2026. References are based on the publisher’s detailed description, not a review of the full recording.