Choose approved knowledge for an AI assistant

Choose the sources deliberately

Use information that is current, approved and relevant to the intended question. Record the owner, version, date and access restrictions. A large folder of documents is not automatically a reliable knowledge base.

Define what the assistant may answer

State which source supports each type of answer. Identify material that should be restricted to certain users. When sources are conflicting or insufficient, the answer should flag the gap and refer to the responsible owner rather than guessing.

Fictional example

A sample handbook says expense claims need a receipt and manager approval. It does not state payment timing or travel-allowance amounts. A grounded demonstration can answer the receipt question, cite the sample section and decline to invent an allowance.

Keep updates and review owned

Assign an owner to refresh sources and test stale, conflicting and unsupported questions. Actual client documents require agreed handling and access controls. Use fictional or anonymised material in public demos; do not treat the public Hub as a private document repository.

Build a small source register

For each proposed source record the title, owner, version, approval date, intended audience and update schedule. Add whether the assistant may quote it, summarise it or only use it for a particular task. Begin with a manageable set whose reliability you can assess. Uploading every file from a shared drive can introduce outdated, duplicated or contradictory instructions.

Design access around the user

A source that is approved does not automatically belong in every person’s answers. Company, client and role boundaries matter. Specify who may ask which questions and what underlying information they may see. Test those boundaries on the server, not only by hiding a button. The public JustDigital Hub is a fictional demonstration and does not offer a private repository for company records.

Define source-grounded answer behaviour

A useful knowledge response should distinguish what the source says from an interpretation or missing detail. Ask for a reference to the relevant document or section where supported. If the information is insufficient, the assistant should say so and identify an escalation route. A citation-looking label does not prove grounding; the reviewer needs to confirm the referenced material actually supports the answer.

Test conflicting and stale information

Include a test where two versions disagree, a question outside the source scope and a question about a retired rule. Decide whether the system should prefer a current approved version, flag the conflict or ask the owner. The answer should not blend incompatible rules into one confident response. Updating a document also requires checking that the assistant uses the new version and does not keep relying on stale material.

Prepare an owner-friendly maintenance process

Make source review a routine responsibility. Record which document changed, who approved it and which test questions should be rerun. Give users a way to flag unsupported or outdated answers without sending unrelated personal data. Track the corrections that matter to the business, not just the number of conversations. A knowledge tool can become less reliable over time if maintenance has no owner.

Keep the first pilot bounded

Choose a narrow question set such as approved service scope or a sample internal procedure. Use fictional or anonymised material while testing the experience. Actual private documents need agreed handling, access controls and delivery scope before upload. A grounded assistant is valuable when the source boundary and escalation path are clear; a larger collection is not automatically a better product.

Before you use the result

• Separate approved facts from assumptions.
• Identify missing information and the person who owns it.
• Check prices, promises and consequential fields.
• Review the work in the format the audience will actually see.

Questions to ask next