AI knowledge management for business: the control layer

An employee asks which policy applies. The assistant finds a document, summarizes it clearly and supplies a citation. The answer can still be wrong if that document is a draft, applies to another department or was replaced yesterday.

AI knowledge management for business is the work of making organizational knowledge usable for AI-assisted tasks while preserving its authority, access rules and history. Search is part of it. So are deciding which source wins, maintaining current versions and correcting answers when the evidence changes.

Before buying or building a new system, choose a real employee question and inspect the evidence needed to answer it. If nobody can identify the current source or its owner, an AI interface will not resolve that missing decision.

Our Business Brain case study shows interfaces for knowledge access and controlled updates. For a new implementation, require a demonstration with your roles and sources; a published interface is not proof that every connector, permission rule or retention requirement already works for your company.

Choose between finding knowledge and creating it

If an approved answer already exists but employees cannot find it, start by improving the source structure or testing search in the tools they use. A separate knowledge platform may be unnecessary. Microsoft’s connector documentation, for example, describes bringing external content into Copilot and Search with source permissions. Check the particular connector and access model rather than assuming a supported product name means the whole workflow fits.

The problem changes when the answer exists only in conversations or scattered decisions. A meeting transcript can supply evidence for a proposed decision record, but the transcript is not automatically an approved policy. Capture what was decided, who owns it and where it applies, then use the review required for that type of change.

Do not ingest every conversation merely because it is available. Define eligible channels, personal-data exclusions and retention before capture. The reliable agent-context guide explains the separate choices around indexing content, querying live records and processing returned data.

Keep the source’s role attached to its content

The policy repository should remain authoritative for policy. The CRM should own its account records. A prepared summary should preserve the original identifier, location, source date and owner instead of silently becoming a replacement source.

Record whether an item is approved, supporting, draft, superseded or historical; its effective and review dates; and the department, client or jurisdiction it covers. Semantic similarity can find related passages, but it does not establish which document the organization has authorized for this decision.

Consider a fictional expense-policy example. An approved policy takes effect on 1 September. A July draft has similar wording, and a meeting note records one exception for a particular trip. The assistant should use the effective policy for a general question, explain the dated exception only when relevant and permitted, and avoid promoting the draft because it matches the question closely. This is a design example, not a customer result.

If two approved sources conflict, show the unresolved conflict to an authorized reviewer. Do not let the assistant silently choose a policy because one source sounds more confident.

Test permission changes, not only initial access

Identity and access rules must constrain which evidence reaches the model. A prompt asking it to ignore private passages is too late if those passages have already entered its context.

Microsoft Graph’s externalItem schema makes this concrete: an indexed item requires access-control entries for users or groups, and supplied content is full-text indexed. A production design must also explain how those entries change when someone moves teams, loses access or leaves the company.

Test revocation through search results, cached answers and a continued conversation. Define how quickly a source permission change must take effect, and what the system does while that update is uncertain. Blocking a new retrieval does not erase information previously disclosed to a user. Conversation retention and deletion are separate controls.

Avoid combining an authoritative company answer with an unrestricted web or model-memory answer without making the distinction visible. For a company-policy question, missing approved evidence should produce an unresolved answer and an appropriate next step.

Use an acceptance set the knowledge owner can judge

Microsoft’s RAG evaluation guidance separates groundedness, completeness and correctness. That distinction matters: faithfully repeating an obsolete policy is not a correct answer about today’s rules. A citation also needs to support the particular claim, not merely point to a related document.

The following is a proposed acceptance set, not a report of completed tests. Adapt the sources, roles and expected results with the responsible business owner.

Keep a result for every attempted case, including failures, abstentions and escalations. Report source eligibility, retrieval success, supported-answer quality and unresolved questions separately. One average “accuracy” score can hide a permission failure or a topic the system cannot answer.

Test questions should come from the roles that will use the system, not only from the person configuring it. Repeat important cases across relevant source and model changes. A successful demonstration on a small set establishes only what that set tested.

Give corrections an owner and a return path

When an employee flags an answer, capture the question, cited source version and what appears wrong, without exposing restricted material in a broadly shared ticket. Assign the issue to someone who can change the source or the retrieval rule. A thumbs-down count without that route is not knowledge maintenance.

Treat proposed knowledge changes according to an explicit policy. An official-policy change may require an authorized person, while a narrowly defined low-risk update may be eligible for automated acceptance. Record which rule and actor accepted the change, preserve recoverable history where permitted, then rerun the affected questions. Do not confuse “reviewed” with “reviewed by a person” unless a person actually made the decision.

Name the source owner, platform operator and access administrator. Agree who handles stale sources, failed refreshes, permission incidents and unresolved answers. NIST’s AI RMF Core describes govern, map, measure and manage as continuous functions, not a fixed sequence or a certification checklist. The published 1.0 framework is being revised; use it as a risk-management reference, not proof of compliance.

Make the purchase decision from a bounded pilot

Choose one knowledge area, its users and a set of questions with approved answers or explicit gaps. First test whether source cleanup and existing search solve the problem. If a new AI layer is still needed, agree on unacceptable errors, maintenance ownership and the evidence required to expand it.

Measure the work completed, review effort and time to resolve unanswered questions as well as answer quality. Faster answers are not useful if employees must spend the saved time checking unreliable claims. The Business Brain offer and AI automation services describe implementation options; the pilot should determine which controls and integrations your operation actually needs.