Your AI assistant inherits the state of your business knowledge
A service business wants an internal assistant to answer sales and delivery questions. The useful material already exists, though it lives across proposal templates, CRM notes, a shared drive, the website and messages between experienced staff.
The first test exposes the operating problem. One proposal promises a two-week turnaround. The current delivery plan says four. An old FAQ includes a retired service. Pricing appears without an effective date. Nobody can say which version the assistant should trust or which staff should see a sensitive client record.
Uploading more files will make more conflicting material available. It won't decide which statement is approved.
An AI-ready knowledge base turns that scattered material into an operating corpus with known authority, ownership, access and lifecycle. When that work is missing, implementation slows down and reviewers spend their time checking facts the business should already control. Customer-facing use increases the consequence because a plausible answer can still be stale, unsupported or disclosed to the wrong person.
This guide starts after you've chosen a plausible use case. If the question is still what to automate, begin with the AI workflow selection guide and bound one workflow first.
What an AI-ready knowledge base actually is
An AI-ready knowledge base is a governed body of business knowledge that a system can find, interpret, permission, cite, test and maintain. It may draw from several source systems. It does not need to replace all of them.
The NIST definition of retrieval-augmented generation describes a generative AI model paired with a separate retrieval system or knowledge base. A user asks a question, the system finds relevant information and supplies it to the model as context for the response. This approach is usually shortened to RAG.
For an operator, the important part is the chain of control. Source systems contain working records. An approved corpus exposes the material suitable for the use case. Retrieval finds evidence the user is allowed to access. The model forms an answer from that evidence. A citation lets a person inspect the source. Human review or escalation catches cases the evidence cannot settle. Feedback then leads to a source correction, a better retrieval rule or a narrower system boundary.
Grounding gives the system better evidence. It does not guarantee an accurate answer. The business still needs to test what retrieval found, what the model said and what happens when evidence is missing.
Start with the questions the system must answer
Don't begin with every file the business owns. Begin with a bounded set of real questions from the people who will use the system.
For an internal sales assistant, those questions might cover service fit, inclusions, lead times, pricing authority and the point where a specialist must step in. For a delivery assistant, they may cover approved processes, role boundaries and current client commitments. Record the language people actually use, including ambiguous wording and common follow-up questions.
Map each question to the fact, policy or evidence needed for a safe answer. Mark questions the system must refuse or escalate. This creates a practical boundary for the corpus. It also reveals missing knowledge before a technology team spends time indexing documents.
The same question set becomes the pre-launch test set. Keep examples of routine, difficult and high-consequence cases. Include questions that should return no answer. Completeness now has a concrete meaning. The corpus is complete enough when it supports the agreed questions within the agreed boundary.
Build a source register before you build the corpus
A source register records what the business knows, where it came from and how it may be used. Start with the sources needed for the bounded question set. Add a row for each document, record collection or controlled content unit. Record the question each source answers beside the register so the table stays usable on a small screen.
| Source | Authority | Owner | Access | Lifecycle | Conflict rule |
|---|---|---|---|---|---|
| Service catalogue | Canonical | Service lead | Staff and public | From 15 Jul, quarterly review | Wins on scope |
| Pricing schedule | Canonical | Commercial lead | Sales, commercial | From 1 Aug, monthly review | Wins on price |
| CRM notes | Case record | Account lead | Account team, personal | Per record, review at close | Wins for that client |
| Website FAQ | Published view | Marketing lead | Public | From 20 Jul, quarterly review | Must match catalogue |
Authority describes the job a source performs. A signed agreement may govern one client. A current policy may govern the whole team. A transcript can reveal a useful question without becoming an approved answer. Proposal language may explain positioning while the pricing schedule remains authoritative for current figures.
The register should point back to the original source and preserve its origin. The NIST Generative AI Profile recommends documenting training data and generated data sources, origins and metadata. It also calls for documentation of techniques such as retrieval augmentation and other system modifications on pages 20 and 35. For a growing business, a source register and change record are a workable expression of that discipline.
Choose authority and resolve conflicts
The following example is constructed. It shows the decision record a business needs when three plausible sources disagree.
| Before | Status | Problem |
|---|---|---|
| “Brand workshop included in every website project” | Old proposal | Predates modular packages |
| “Strategy workshop available as an add-on” | Current service catalogue | Approved scope from 15 July |
| “We always include strategy” | Sales call transcript | Informal wording with no approval |
The service lead approves one canonical statement. “A strategy workshop is available as an optional add-on unless the signed proposal includes it.” The record names the service lead as owner, gives 15 July 2026 as the effective date and links the catalogue and decision note as provenance. The proposal template gets a sales-specific variant that preserves the same meaning. The old proposal remains in the client file, though it is excluded from general service retrieval.
The conflict rule matters as much as the final sentence. Current approved scope wins for general questions. A signed agreement wins for questions about that client. Unapproved call language can trigger a review, though it cannot silently change the service.
Once an internal fact is canonical, compare it with public claims. The business entity consistency audit covers that public representation work. Here, the knowledge-base job is to give website owners and profile owners one approved fact they can maintain.
Prepare knowledge for retrieval and maintenance
Retrieval works better when each content unit has a clear subject and enough context to stand on its own. Give it a descriptive title, a visible status, an owner, an effective date and a link to the originating record. Use stable names for services, roles and policies. Remove duplicate copies when they add no evidentiary value.
Keep important conditions beside the claim they qualify. A price without its currency, audience, tax treatment or effective date is easy to retrieve and easy to misuse. A process step separated from its exception rule can produce an incomplete answer. Tables can help with genuine comparisons, while headings and short sections help a person understand the same material.
Chunking, embeddings and index settings vary between retrieval systems. The operator's durable job is to make meaning, authority and lifecycle explicit before those technical choices are tuned.
Public pages benefit from a similar clarity discipline. The structured-content guide explains that work for search engines, AI agents and buyers. An internal corpus has extra concerns, especially authority, permissions and unpublished operational context.
Attach permissions, privacy and provenance to the knowledge
Access is part of knowledge design. Classify each source by audience and sensitivity before it enters the corpus. A public service description, an internal playbook, a commercially sensitive price list and a customer's record should not inherit the same retrieval permissions.
Microsoft documents document-level access control in Azure AI Search as a concrete implementation pattern. User or group permission metadata can be stored with documents and enforced when a query runs. Other platforms implement access differently, so treat retrieval-time enforcement as a design requirement and verify the chosen product's behaviour.
Use least privilege. Separate audience tiers and keep sensitive sources outside a use case that does not need them. A universal search store may be convenient for setup, though it creates an avoidable disclosure path when permissions or filters fail.
When personal information from CRM records, transcripts or customer documents is involved, the OAIC guidance on commercially available AI products asks organisations to consider purpose, access, provider due diligence, accuracy, human oversight and ongoing review. It also warns that inferred or generated information about an identifiable person may itself be personal information.
The Australian Cyber Security Centre's AI data security guidance recommends controls for data provenance, integrity, secure storage and access across the AI lifecycle. Together, these sources support a practical rule. Record why the system needs the data, who may retrieve it, where it came from, how changes are detected and when it leaves the system.
This is practical risk guidance, not legal advice. Privacy obligations and suitable controls depend on the organisation, data and use case. The broader AI governance checklist can hold the organisation-wide rules for permitted uses, approvals, incidents and review.
Assign owners and a freshness rhythm
Every canonical knowledge unit needs a business owner who can approve its meaning. Technical ownership is also useful, especially for ingestion, permissions and monitoring. The two roles should be visible when they belong to different people.
Record the effective date, next review date and events that force an earlier review. Pricing might change monthly. A safety procedure may require immediate review after an incident or regulatory change. Stable company history may only need an annual check.
Define expiry behaviour as well. The system can exclude expired material, label it as historical or route the question to a person. Quietly serving stale facts is the weakest option.
When an owner cannot resolve a conflict, name the escalation path. A knowledge base becomes maintainable when changes and disagreements have somewhere to go. That's more valuable than a migration that looks complete on launch day and begins ageing immediately.
Test retrieval with real questions before launch
Run the original question set against a representative version of the corpus. Microsoft's RAG evaluation guidance separates retrieval measures from response measures. Its retrieval evaluators examine whether retrieved context is relevant and whether it covers the ground-truth answer. Its response evaluators examine groundedness, relevance and completeness.
Apply that distinction in a human-readable test record.
- Check whether the correct source appears for the question.
- Confirm restricted sources stay unavailable to unauthorised users.
- Check whether each answer claim is supported by the retrieved evidence.
- Assess whether the answer addresses the question and includes necessary conditions.
- Open every citation and confirm it supports the nearby claim.
- Confirm missing or conflicting evidence produces the agreed escalation.
Add adversarial cases. Ask for an expired price, use an old service name, pose an ambiguous question, request another customer's information and combine two policies that conflict. Include a question outside the approved scope. Record the expected source, permission result, answer behaviour and escalation for each case.
Grounding can reduce unsupported answers by supplying relevant evidence. Reliability still depends on what was retrieved, how the answer used it, human review and source maintenance. That's our synthesis of the NIST risk-management guidance and Microsoft's evaluation model. Neither a knowledge base nor RAG eliminates errors.
For customer-facing answers, test the route to a person as carefully as the generated response. The safe human handoff guide covers missing evidence, customer frustration and high-consequence escalation in that interaction.
Use the readiness scorecard to choose the next move
Score the corpus for the bounded question set. Use evidence instead of confidence or platform capability.
| Dimension | Ready evidence | Repair signal |
|---|---|---|
| Authority | A winning source is named | Plausible sources disagree |
| Accuracy | Owners verify current facts | Material errors remain |
| Completeness | Test questions have evidence | Core questions lack support |
| Freshness | Effective and review dates exist | Stale status is invisible |
| Structure | Meaning and conditions travel together | Units are vague or duplicated |
| Permissions | Retrieval respects audience tiers | Sensitive content is broadly exposed |
| Provenance | Origins and decisions are traceable | Claims cannot be traced |
| Ownership | Approvers and escalation are named | Nobody can settle a change |
| Test coverage | Normal and adversarial cases pass | Important behaviours are untested |
A bounded pilot is ready when the high-consequence dimensions meet their agreed threshold and remaining gaps have an owner. Repair before connection when authority, access or accuracy failures could create material harm. Narrow the question set and source pool when the team can support a smaller useful job while broader conflicts are resolved.
Once a pilot is operating, move to workflow ROI and reliability measurement. Live outcome rates, review effort, exceptions and total cost answer a different question from pre-launch corpus readiness.
Make business knowledge easier to trust and reuse
An owned corpus can support more than one interface. Internal assistants can use approved operational facts. Customer experiences can retrieve public or customer-specific material within their permissions. Content teams can build source packs from reviewed evidence. Website owners can keep public descriptions aligned with canonical service facts.
That reuse stays valuable while authority, access, freshness and feedback remain visible. A knowledge-readiness audit or AI systems discovery workshop can help when ownership or architecture remains unresolved. Its useful outputs are an approved source register, a repair list and a defensible decision to pilot, repair or narrow the corpus.
Start with one bounded question set. Audit every source needed to answer it, then test whether the system finds the right evidence and knows when to stop.