How to Test an Enterprise AI Assistant Against Facts and Procedures

Short answer: Start with a question someone needs the assistant to answer, identify the approved record that governs it, and write down what a correct answer must preserve. Then capture the assistant's full response and compare it with that record. Keep the conditions and exceptions in view. Record any discrepancy, decide what needs changing, and test the changed answer rather than assuming the fix worked.

The method applies to an assistant answering customers and to a copilot helping staff. A staff member looking up a procedure needs an accurate answer just as a customer looking up a deadline does. The audience changes what you test, not the need for a reliable reference.

Our internal AI validation explainer covers the underlying control. This guide is about preparing and carrying out a focused test. It is not a complete assessment of a deployment's safety, security or legal compliance.

Choose the answers that matter to the work

A useful test begins with a task, not a random collection of prompts. What does the assistant help someone decide or do?

For a customer assistant, that might be identifying a service channel or explaining a document requirement. For a staff tool, it might be finding the procedure that applies to a particular case. Start where a wrong answer could change the next step. The system owner and people doing the work can help identify those questions.

Write down the scope before testing: the assistant, the task, the users and the version or configuration you can identify. Include the language and market where they matter. A check of one workflow does not cover every task the assistant performs.

Use only a system you are authorised to test. Invent case details where possible. Do not put real customer records or confidential documents into a tool simply to make the test more realistic. Use the organisation's approved handling process when sensitive evidence is necessary.

Set the reference before asking the question

Find the approved document or procedure that answers the question. Record its version and effective date, not just when you downloaded it. A new document may not yet be in force. An older one may still govern a historical case.

Resolve conflicting references before calling an answer wrong. If a policy and a help page describe different conditions, ask the responsible owner which applies. An unresolved source conflict is a reference problem, not evidence against the assistant.

Next, write a short expected-answer note. It should list what the response needs to say, including the qualification that changes the outcome. It need not prescribe identical wording.

Illustrative example, not a client record or a real product rule: an approved procedure says, "We aim to respond within ten working days after receiving all required documents."

An expected-answer note would preserve both the target and its starting point. "Within ten days" loses the working-day condition. "Within ten working days of your first message" changes when the clock starts. A paraphrase can be clear and still be wrong.

Ask realistic questions and keep the full response

Begin with a plain question someone would actually ask. In the example above: "I sent my request yesterday. When should I expect a response?" A useful answer would make clear that the target runs from receipt of the required documents, rather than silently assuming they are complete.

Then vary the detail that could change the answer. What if a document is missing? What if the user asks whether the timeframe is guaranteed? Test those cases without putting the expected wording into the question.

Record the exact prompt and complete response, including any qualifications, citations and follow-up questions. For a conversation, retain the relevant preceding turns. An isolated sentence may look wrong when the qualification appears immediately below it.

Note when the answer was produced and the configuration you actually know. If a vendor does not expose a model version, record that limitation instead of guessing. A screenshot can help show presentation, but it should not be the only record of a long answer.

Separate a material error from an awkward answer

Compare the claim with the clause it depends on. Do not let an automated flag, or the presence of a citation, decide the result.

Use a small set of understandable outcomes:

• Wrong: the answer contradicts the applicable reference.
• Material omission: it leaves out a condition needed to answer the question correctly.
• Needs clarification: the prompt or reference is ambiguous, so a reliable conclusion cannot yet be drawn.
• Matches the reference: the answer preserves the relevant meaning, even if the wording differs.

A qualified estimate is not automatically a false promise. Nor is a short answer automatically incomplete. Ask whether the missing detail changes the answer to the actual question. Record correct handling too; an error-only record can distort what was tested.

Have a reviewer who understands the procedure check consequential findings. For specialist or non-English wording, involve someone able to assess that meaning. The comparison is stronger when the reviewer can explain why the discrepancy matters, not merely mark it red.

Use an assistant test card

Keep these fields together for each test. They are the text version of the worksheet accompanying this guide:

1. Question and context: the prompt, relevant conversation and user task.
2. Approved reference: the governing clause, version and effective date.
3. Expected answer: the facts and conditions that must survive.
4. Actual answer: the complete response and capture date.
5. Review outcome: the classification and a specific reason.
6. Action and owner: what needs investigating or changing, and who owns it.
7. Re-test: the new response, date and review outcome after the change.

This is a suggested working record, not a NIST form. NIST's voluntary AI Risk Management Framework supports context-relevant evaluation and documenting test methods and limitations. The worksheet is our practical way to organise a narrower answer-level check.

How Lawnise helps check assistant answers

The test card describes the work. Lawnise can automate part of that work once an organisation has set up its references and configured the checks.

In the authorised answer-submission workflow, a person supplies the question and the assistant's reply. Lawnise runs the configured checks against the project's factual and procedural references, and keeps the resulting evidence available for review. Collecting the reply may still be manual; comparing it with the configured references is the automated step.

For a factual finding, a reviewer can inspect the answer and supporting evidence, then record whether the finding stands or should be dismissed, with a reason. People still need to keep references current, choose useful questions and act on the result. A check with no issue detected is not a guarantee that the assistant is correct in every situation.

Platform example: this existing manual-intake record from an internal-assistant test shows an answer that gives a 30-day FMOS deadline alongside the configured reference stating six months from receipt of the Member's final decision. The reviewed decision is retained with the comparison. This is an example of the workflow, not a measure of the assistant's overall accuracy. [3]

View the submitted answer at full size

View the reference and review at full size

Re-test the fix and keep the result in scope

A changed source, instruction or configuration is a proposed fix. Run the affected question again and include nearby cases that might have been disrupted. Keep the original result alongside the new one so the change can be examined.

An assistant may produce different wording on another attempt. Where that matters, repeat the test and record what you observed. Do not turn a handful of successful checks into a claim that the assistant is accurate across its whole workload.

Agree what should trigger another review, such as a changed procedure or a complaint exposing a new misunderstanding. That is a testing plan; it is not the same as continuous monitoring.

The result should let a colleague answer a simple question: what did we check, against which record, and what did we do about it? If the record cannot show that, a green status on its own is not much help.

For support defining a factual and procedural review of selected assistant answers, talk to Lawnise.