Implementation and ownership
Your AI needs a source of truth and someone to maintain it
Build a knowledge inventory with owners, approval dates, conflict rules, and a way to withdraw incorrect information.
Published · Collection dates are retrospective editorial dates.
An assistant can retrieve an answer perfectly and still give the customer the wrong information. The source may be obsolete, incomplete, or contradicted by another document. Retrieval quality cannot repair a knowledge base that your business does not govern.
Start with a source of truth and a named owner. “Use our website” is rarely enough. Your website may contain marketing descriptions, archived policies, location-specific information, and forms that imply different rules.
The operating goal is straightforward: for every answer the system is allowed to give, someone should be able to identify the approved source, explain its scope, and withdraw it when it becomes wrong.
Build an inventory before importing documents
Do not begin by uploading every file the team can find. More material can create more opportunities for conflict. Inventory the topics customers actually ask about and identify the best approved source for each.
| Topic | Approved source | Owner | Scope | Review trigger |
|---|---|---|---|---|
| Opening hours | Location schedule | Location manager | Specific site and dates | Holiday or staffing change |
| Service eligibility | Current service policy | Operations owner | Named services and areas | New offering or boundary change |
| Booking rules | Appointment procedure | Scheduling lead | Appointment types and locations | Calendar or staffing rule change |
| Refund information | Approved policy | Finance or policy owner | Relevant products and terms | Policy revision |
| Escalation destinations | Contact and coverage roster | Team manager | Channel and coverage period | Role or coverage change |
These are illustrative categories, not a universal ownership chart. Your organization should name actual roles and people with authority to approve the information.
Include a last-approved date and version. A last-edited date tells you that a file changed; it does not tell you who approved the new content or whether it should govern customer answers.
Make conflicts visible
Suppose a hypothetical location page says weekend appointments are available, while the scheduling procedure says they have been suspended. The system needs a rule for handling the conflict. It should not choose whichever passage is easier to retrieve.
Ideally, correct or withdraw the outdated source. During the correction, restrict the affected answer or send it to a person. A temporary operating limit is preferable to a confident guess between two official-looking documents.
Distinguish global policy from local exceptions. If a location has a different opening time, encode the scope explicitly. Do not rely on a model to infer which location a paragraph applies to from a nearby heading that may not appear in the retrieved excerpt.
NIST's generative AI profile includes information integrity among its risk categories. The inventory here is an original operating tool for controlling the business information you choose to supply.
Give every answer a usable source boundary
A short, precise source is often easier to maintain than a long document containing several policies and historical explanations. Separate the rule, its applicable conditions, the permitted customer wording, and the escalation condition where useful.
Do not strip away qualifications in pursuit of brevity. “Appointments available” is not equivalent to “appointments may be requested, subject to confirmation by the scheduling team.” The qualification may be the most important part of the answer.
Avoid placing secrets or unnecessary personal information in a general knowledge collection. Access should follow the workflow's needs. A public-policy answer does not require unrestricted access to customer records.
Define how updates reach the live system
Someone changes a policy. What happens next? Write the steps: approval, source publication, system ingestion or refresh, test, and confirmation that the old answer is no longer served.
Ask the supplier how long updates take and how your team can verify them. A successful file upload does not prove the customer system is using the new version. Test a question that distinguishes the old rule from the new one.
Keep a small regression set for each important topic. Include ordinary wording, a known exception, and a question whose correct answer is to ask for more information. Run it after changes to sources or retrieval settings.
Review by change and by consequence
A calendar reminder can prompt routine checks, but review should also follow events: a new service, a moved location, a pricing change, or a changed escalation team. Information becomes wrong when the business changes, not only when a scheduled review arrives.
Prioritize consequential topics. An outdated descriptive phrase and an incorrect booking rule deserve different urgency. Keep a correction log that records what was wrong, which interactions may have been affected, and whether customer recovery is necessary.
Give frontline staff a simple reporting route. They should be able to point to a bad answer, identify the expected source if they know it, and see who owns the fix. Do not make them diagnose retrieval internals before accepting the report.
The knowledge owner does not have to perform every update personally. They do need authority to approve sources, resolve conflicts, and require retesting. Without that responsibility, “the knowledge base” becomes a shared folder everyone assumes somebody else maintains.
A dependable assistant needs dependable information. Keeping that information current is continuing operational work, and it belongs in the budget and ownership plan from the start.
Sources
For help defining this workflow, explore our customer messaging work.
Keep reading
