An AI assistant for your internal knowledge base

An AI knowledge assistant helps employees answer questions using approved company sources. It is useful where ordinary search returns documents, but somebody still has to assemble the relevant answer from several passages. Typical tasks include understanding a procedure, locating a product rule or finding an entry point into an internal policy.

Before starting a project, collect recurring questions from actual work. “What can AI know about our business?” is too broad. “Which documents does a business customer need for the replacement procedure in the handbook for their country?” can be assessed against a defined source by a domain reviewer. If no authoritative rule exists, improve the knowledge first.

The assistant also needs an explicit boundary. It can explain an approved rule but cannot invent an approval. It can combine supporting passages but cannot turn a contradiction into a company decision. With personnel, legal and customer information, a well-directed clarification is often more useful than a complete-sounding answer.

An internal knowledge base is the maintained collection of procedures, explanations and records that staff are allowed to use. An AI knowledge assistant adds a way to ask questions of that collection. Improving the source material and improving the interface are separate tasks; some teams need the first before the second becomes useful.

For a team using SharePoint, test the current knowledge-base structure and available Microsoft capabilities before building a separate index. For a team using several systems, compare the same question set across the existing tools and a proposed RAG design. Include a question with no approved answer: a visible gap can be more useful than a fluent guess.

The AI knowledge-base implementation guide supplies a source-to-answer test matrix. The SharePoint permissions guide explains the boundary between native knowledge management and a separate retrieval system. Whichever route you choose, assign responsibility for updates and access changes before rollout.

Retrieval-Augmented Generation, or RAG, combines search with the generation of an answer. Relevant sources are supplied for the question, and the model uses them to compose a response. Microsoft's RAG documentation explains this pattern and the role of an index. It is a technical approach rather than a correctness guarantee.

For project planning, distinguish two routes. The content route ingests sources, interprets their structure and keeps versions and permissions current. The question route identifies the user, retrieves permitted evidence and produces a checkable response. Both routes need a consistent understanding of documents and validity. A new chat interface cannot by itself resolve obsolete files or incorrect sharing settings.

A vector database is one possible search component. It is neither the complete knowledge base nor an access-control system on its own. Whether keyword search, semantic search or a combination is appropriate depends on the questions and sources. Product codes, abbreviations and complete natural-language descriptions create different retrieval needs. The architecture guide explains the components and their responsibilities.

Begin with a bounded source collection whose owners are available. For every source, identify its title, responsible person, version or validity date and permitted user groups. Mark drafts and archives explicitly. Two similarly named PDFs with different instructions cannot reliably be reconciled merely by choosing a more powerful model.

Start with document types encountered in daily work: a structured manual, a table, a scan and a short policy. This exposes information lost during preparation. A large import can create an impression of completeness while tables or handwritten amendments remain unusable.

The AI knowledge-base guide helps organise this inventory. Keep the original source authoritative. Domain corrections belong there and should then move through a controlled update into the search index. Otherwise, the chatbot can become a second, inconsistent version of company policy.

Agree how to handle conflicting sources before ingestion. A newer filename is not necessarily a formally approved policy, and a copied paragraph may omit an exception. Record the actual precedence rule and the person who can resolve uncertainty. The assistant should expose unresolved conflicts rather than choose whichever passage appears more confident.

First assess search and assistant capabilities already available in your workspace. If they cover the required sources, access and answers reliably, the project may primarily involve cleanup and training. Additional development should close a named gap, such as an unsupported source system, a review process or a particular user interface.

Microsoft documents how Microsoft 365 Copilot uses existing permissions in its data, privacy and security guidance. This creates an important selection question: are those existing permissions correct? An accidentally broad sharing permission does not become appropriate simply because an assistant respects it.

A custom implementation gives you more design choices, with responsibility for connectors, retrieval, operations and troubleshooting. Compare both options using the same questions. Record whether the right passage appeared, whether the answer followed from it and whether the user could open the evidence. An impressive demonstration using one simple question cannot replace that comparison. The Copilot versus RAG guide develops the decision criteria.

Include maintenance in the comparison. A connector that supports today's document format may require changes later. Ask who will investigate missing sources, inspect permission synchronisation and repeat acceptance after an upgrade. Flexibility has value only when somebody can maintain it.

The retrieval route must take the user's identity into account. Content a person may not read should not first reach the answer model and then be concealed by hiding its citation. Include conversation history and reused answers in the access design.

The Azure AI Search document-access guidance, checked on 26 September 2026, distinguishes security filters from several native approaches labelled preview. Verify the actual mechanism and its limitations. A blanket statement that SharePoint permissions are inherited is insufficient without a supported data route and tests.

Use at least two user roles and a permission change during acceptance. One role can read a policy and the other cannot. Then revoke access. Test direct questions, follow-ups in an existing conversation and the original source link. An authorised technical operator should also understand what appears in logs and who can read those logs.

The following is a synthetic test design. An imaginary company permits equipment issue after team-lead approval. Its policy contains a separate exception for loan equipment and an effective date. An older edition requires approval by a different function. The question is: “Who approves a laptop for our new colleague?”

A useful answer identifies the current responsible role, cites the relevant passage and asks whether the request concerns loan equipment if that affects the result. It must not silently combine old and new rules. The reviewer sees the source version and passage as well as the answer text. Success means that the accessible evidence supports the specific claim.

Now change the current policy. Record when the source was saved, when the index incorporated the change and when the new answer appeared. If the document is removed, the assistant must handle the question without that source. This compact scenario joins freshness, retrieval, exceptions and access into one complete test.

Finally, ask the question using a synonym and with the employee's name omitted. That checks whether the system understands the underlying information need without depending on a rehearsed sentence. Add a question that the policy cannot answer, such as whether a particular purchase has already been approved. The correct outcome should reveal that evidential gap.

Prepare questions and expected answers before tuning retrieval. An initial set can include straightforward lookups, questions requiring several sources, ambiguous wording, unanswerable questions and prohibited access. Its size depends on scope; there is no universal quality threshold. Reserve additional questions for final evaluation rather than using every case during tuning.

Separate at least four failures: the source is absent; search does not find it; the supplied passage omits an important exception; or generation misrepresents the evidence. This identifies whether to improve the source, ingestion, retrieval or response construction. A different model does not automatically repair all four problems.

Score correct refusals separately. When the knowledge collection cannot answer a question, a clear limitation and responsible contact can be the intended result. A single accuracy percentage can conceal these differences. The RAG acceptance guide provides starting cases to adapt to your sources and roles.

Retain enough evidence to investigate failures without unnecessarily collecting sensitive content. Record the question category, configuration and relevant source identifiers, subject to the agreed data policy. A reviewer should be able to reproduce an issue without relying on someone's memory of a chat.

Plan for source cleanup, connectors, indexing, model output, search infrastructure and domain maintenance. Cheap generation can still produce an expensive overall service if employees must research every second answer again. Measure the complete handling time, including reading, checking sources and asking follow-up questions.

In an invented example, 30 employees ask ten questions each per working week. Four weeks produce 1,200 monthly questions. At an assumed five minutes today, this represents 100 hours. An improvement to three minutes including evidence checking would leave 60 hours. Six additional hours of content and technical maintenance would reduce the theoretical capacity gain to 34 hours. These are assumptions, not observed product performance.

The decision then needs software and introduction costs, plus a credible explanation of how the team will use the capacity. The RAG cost guide helps compare those categories. Appoint a source owner, technical operator and quality-feedback contact for ongoing use. A knowledge assistant stays useful only when business changes reach it as reliably as software updates.

An English-language knowledge assistant may need to search source documents in several languages. Retrieval, translation and authority are separate questions: finding a German or French passage does not prove that its rule applies to an employee in Ireland, Sweden or the UK. Store the source’s country, owner, validity date and intended audience alongside its text.

Start with a bounded cross-office question set. Ask the same operational question as users with different locations and permissions. Include one answer that should be shared, one that must differ by country, and one that should be refused because no current source exists. Expected answers come from the responsible domain owner, not from the assistant being evaluated.

Test source links as ordinary users. An answer that cites a document only administrators can open is not a useful handover. If translated wording is shown, preserve a route to the original passage and make any uncertainty clear. An employee should be able to tell whether the assistant found a current policy, summarised older material or needs a person to resolve a conflict.

The commissioning decision is whether this arrangement improves useful enterprise search over existing tools. Include time spent verifying citations and asking follow-up questions in the evaluation. Do not measure only fluent answers or the proportion of questions answered. The source and permission tests provide a practical framework, while each office’s actual rules and access groups remain part of project acceptance.