Testing a knowledge assistant before staff use it

Define the task and its owner

Start with a bounded internal task and a review plan. The exercise below uses a fictional staff handbook assistant. It is an example for planning, not a report of an Agenticures deployment or a claim that passing a checklist establishes security. Write down what the assistant is meant to help with. For the example, that could be locating approved internal procedures and pointing staff to the relevant passage. Identify what it must not do, such as changing a record or deciding an individual employment case. Assign someone who can judge whether an answer is supported by the approved material. Technical access to a document does not make a developer the owner of its policy. You need a route for resolving unclear or outdated source content before evaluating the assistant's answer against it. NIST's AI Risk Management Framework organises work around governance, understanding context, measurement and management. A practical pilot can use those ideas to connect tests to responsibilities and decisions. The example here is not a NIST certification process or a complete compliance assessment.

Build a reference set with expected behaviour

Collect representative questions from the intended task, using approved or synthetic examples. For each question, record which source supports the answer and what an acceptable response must include. Also record when the appropriate behaviour is to say that the material does not answer the question. For the fictional handbook, a normal question might ask where to find the equipment-request procedure. A missing-information question might ask for an exception that no approved document describes. Do not score both cases by how confidently the assistant produces an answer. In the second case, an invented procedure is a failure.

Test more than the easy questions

Group cases by the behaviour you want to examine: a direct question with a clear approved source; a question using different wording from the document; a request whose answer is absent from the approved collection; a question affected by an outdated or conflicting document; a request for information outside the user's permitted access; a document passage containing instructions unrelated to its informational purpose; and an unavailable search or retrieval dependency. Use a safe test environment and authorised accounts for access checks. Do not copy sensitive staff records into a demonstration to make the test look realistic. Synthetic material can reveal whether the intended boundary is enforced without exposing a real person's information.

Check the answer and the supporting passage

A source link is useful only if the referenced passage supports the answer. Record whether the assistant found the relevant document, interpreted it accurately and kept the answer within what it says. Separate an incorrect source selection from an unsupported claim added after the right source was found. For example, a procedure describing how to request equipment does not necessarily establish that a particular employee qualifies for approval. The assistant should not turn a process description into a decision about that person. Record that distinction in the expected response before testing.

Record failures in a form someone can fix

Keep the question, source version, relevant configuration, observed answer and review decision together. Protect the record according to the information it contains. Avoid collecting unnecessary personal data merely because a log can store it. Classify the issue precisely. Missing source content calls for a different correction from an access-control failure. A confusing answer may need clearer instructions; a stale procedure may require the content owner to replace the source. Repeating the same query until it produces an attractive answer does not resolve the underlying problem.

Make the release decision explicit

Before the pilot, agree which failures prevent staff access and which can be managed through a narrower task. An unauthorised disclosure should not disappear inside an average answer-quality score. Record unresolved issues individually and assign an owner and next step. Keep a set of cases aside for checking changes. Once you have adjusted the assistant to familiar examples, rerun those tests and examine fresh examples too. Passing previously seen questions is useful evidence, but it does not show how the system handles every request staff may make.

Plan the first period of use

Decide who can use the pilot, where people report problems and how the assistant can be paused. Give staff a clear description of its scope and the route to a person when the answer is uncertain. Keep any ability to take actions subject to its own controls and evaluation rather than assuming answer testing covers it. Review the sources and test cases when policies, access rules or the underlying system change. Preserve the earlier results so the team can see whether an edit improved one behaviour while weakening another. Set the review timing around the consequences and rate of change in the actual task.

What a useful pilot report contains

A concise report states the task tested, the source set, the cases examined, the important failures and the decision. Distinguish verified observations from expectations. Do not translate a short demonstration into a claim about company-wide savings or reliability. To discuss a pilot, bring a bounded task and a sample of approved source material to an Agenticures conversation. The knowledge-assistants service page explains the scope and the questions to settle before implementation.