Build an AI knowledge base with owners and current sources

An AI knowledge base combines a maintained collection of information with a way for an assistant to retrieve relevant material. A RAG knowledge base uses retrieved passages to support a generated answer. The source collection remains the authority; the model's wording does not replace its owner, version or permission rules.

Keep three layers distinct: the original knowledge source, the searchable representation and the answer shown to a user. Updating the source must lead to an observable update or removal in the search layer. A citation should take an authorised reader to the material that supports the claim. Merely displaying a link does not establish that the answer is correct.

An internal knowledge base also differs from a public chatbot knowledge base. Staff procedures, customer records and public opening hours have different audiences. Select the intended audience before choosing sources or adding a conversational interface. The internal knowledge-assistant guide covers that service decision, while the chatbot maintenance guide deals with customer-facing sources.

Collect frequent questions from service teams, onboarding and internal collaboration. Preserve users' original wording initially. “Where is the returns form?” differs from “May I approve a return after the deadline?” The second requires rules and decision authority.

Map each question to the source currently used. Mark a knowledge gap when no source exists and a conflict when two sources disagree. Both require business ownership before an AI system can turn them into reliable guidance.

The first collection need not cover every company process. Choose an area where information mostly exists and owners are available. This lets you test maintenance before several departments contribute interdependent material.

The register identifies knowledge objects and accountability. A spreadsheet can be enough initially. In that role, it is an organizational tool rather than automatically becoming the eventual technical knowledge base.

A source register entry can contain the following fields, shown here with a proposed example:

These values are synthetic. Use your actual roles and rules. Unknown ownership should remain visible rather than being assigned to whoever happened to upload the file.

A formal process may need a short, accessible explanation. Those documents serve different purposes. Identify which version is authoritative and which explains it. If a summary omits an exception, it must not become the sole basis for a decision.

Define precedence only where the business has agreed it. An approved policy may take priority over an informal team note, for example. The responsible function must confirm that rule; an assistant should not infer authority from filenames or document length.

For multiple offices, scope matters more than language. A German-language page may apply to Austria, Germany or Switzerland. An English translation can retain the same scope without creating additional international authorization.

Find identical files, copied sections and competing pages about the same process. Decide which source will be maintained. Other locations can link to it or remain clearly marked as historical versions.

Do not delete every older version indiscriminately. It may be needed to establish which rule applied to a past decision. Active retrieval must distinguish a question about today's workflow from a historical question.

Renaming a file is not necessarily a new business version. Changing an exception may be material even when the filename stays the same. Stable identities and change notes preserve these distinctions for retrieval and evaluation.

Page structure. A useful knowledge page addresses a defined task. It explains prerequisites, steps, exceptions and the contact for unresolved cases. Headings should describe their content rather than merely saying “General” or “Miscellaneous.”

Terminology. Explain internal abbreviations and keep common synonyms in a glossary. Preserve product numbers and exact system names. Rewriting everything into informal language can make precise lookup worse.

Tables and scans. Tables need clear headings and units. A number without currency, period or reference is ambiguous for people and models alike. For scanned documents, inspect the extracted text before assuming the assistant can understand the structure visible on the PDF page.

Document types. Do not force every source into the same page format. A short contact directory and a detailed operating procedure have different information needs. Consistency should help readers identify authority and scope, while allowing each document type to express its content clearly.

Choose initially for editing, approval and access control. An existing wiki or document platform may be sufficient if it reliably represents ownership, versions and permissions. A new product is justified when a concrete required capability is missing.

The following table compares tool categories for maintaining a knowledge collection and what to check first for each.

Atlassian, for example, documents content ownership and collection-cleanup functions in specific Confluence plans. Availability and plan requirements belong in the product check. A feature's existence does not establish that a team uses it consistently. Atlassian: content management.

A simple workflow can use draft, subject review, approval and later reassessment. The important question is who may change the state. An ingestion pipeline should not turn a draft into authoritative knowledge merely because it can read the file.

Decide which changes require renewed subject review. Correcting a typo differs from changing a deadline or permission. Urgent corrections need a fast route to block a wrong active source and replace it with a reviewed version.

When the responsible person leaves the role, transfer ownership. A calendar reminder without an accountable recipient does not prevent obsolete content. Atlassian documents ownership transfer as a product capability; organizational handover remains the company's responsibility.

Assign an allowed audience to each source. Public product information, internal procedures and confidential employee records should not enter one answer collection without distinction. Whether to separate storage or enforce consistent filters is an architecture decision.

Review accidentally broad access as well. An assistant that correctly preserves existing permissions can make overshared information easier to discover. Microsoft's Microsoft 365 Copilot guidance describes use of existing user permissions; that does not clean up the source collection for you. Microsoft: data and security.

The eventual RAG application needs the caller's access rights or an equivalent validated authorization mechanism. A single broadly privileged ingestion account does not automatically provide an appropriate basis for answering every employee.

A fictional service team has three returns instructions: an old PDF, a current wiki page and an email containing a special exception. Employees find different answers depending on the search terms they use. An AI assistant would initially inherit that inconsistency.

The business owner designates the wiki page as the current authoritative source. The exception is reviewed and incorporated there, the PDF is marked historical, and the email is excluded as a separate general rule. Register entries record scope and approval.

The team then evaluates three questions: the normal current case, the exception and a historical return. Only after resolving the sources does it assess answer generation. This illustrates why cleanup belongs before, rather than after, technical deployment.

Import a representative sample containing different document types and access restrictions. Compare the source with its imported representation. Are tables, links and sections preserved? Do version and ownership survive? Will the system recognize a later deletion?

Evaluate with people who know the process and people learning it. Specialists can identify incorrect claims; new users reveal unclear terminology and missing intermediate steps. Both perspectives are necessary.

A pilot is useful when it supports concrete decisions: which sources may enter the collection, which documents need revision and which capabilities are genuinely missing. The number of imported files does not answer those questions.

Suppose a fictional service team has an approved installation checklist, an obsolete draft and a restricted purchasing document. The intended assistant helps staff find the current checklist. The following are proposed tests, not results from a deployed system.

Record the source identifier, version, test identity, update time, question and observed answer. Set a maximum acceptable refresh delay and a way to withdraw misleading material immediately. The right delay depends on the consequence of stale information; it is not a universal AI setting.

For SharePoint sources, continue with the native knowledge-base and RAG permissions decision. For a broader quality review, use the knowledge-assistant acceptance tests.

A knowledge collection should remain understandable if the retrieval technology or provider changes. Test a small export: are text, tables, attachments, internal links and version information still usable? Can ownership and scope travel with the content, or do they exist only in one product's interface?

Exporting every file is insufficient when the relationships between files disappear. A procedure whose exception links to an inaccessible subpage is substantively incomplete. Export one connected process with its supporting material and rerun its important questions afterward.

Also decide what should deliberately stay out of an export, such as confidential comments or editorial notes. Portability is not authorization to transfer every piece of information to a new service. The approved collection, its permissions and permitted recipients still govern the migration. This test creates concrete evidence for a later platform decision rather than relying on a general promise that data can be downloaded.

Track unanswered questions, conflicting sources, overdue reviews and frequently reported errors. Page count alone is not a quality metric. A smaller maintained collection may be more useful than a large set without clear authority.

Connect product and process changes to knowledge maintenance. Introducing a new form should trigger review of its associated instructions. Scheduled reviews still help, but they are insufficient for time-sensitive changes.

Only on this foundation should you choose the search or RAG implementation. The knowledge-assistant acceptance plan evaluates answers and access, while the freshness guide explains how business changes propagate into the technical collection.

Set a realistic operating commitment before expansion. Identify who handles a reported error, how quickly an unsafe instruction is withdrawn and how a departing owner is replaced. If no team can maintain a small approved collection, adding thousands of sources is unlikely to improve reliability. Expanding after these routines work makes the next decision observable and manageable.

These modernagents guides cover related decisions about AI knowledge assistants:

• AI knowledge assistants: sources, access and answers
• Preserve SharePoint permissions in RAG answers
• Use Confluence and Notion as controlled RAG sources
• Keep RAG knowledge current through updates and deletion

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.