What Must an Internal AI Assistant Prove Before Staff Rely on It?

Before staff rely on an internal AI assistant, test whether it finds the applicable source, supports its claims, and handles questions it can't answer. Test the same questions under different permissions, then change or withdraw the source and repeat them. Accept the whole path to a correct, permitted answer or an appropriate handoff.

Define the questions and decisions in scope

Start with the work staff need to complete. A warehouse manager finding a dispatch procedure and an analyst asking about a live account balance need different evidence. Name the first user group, source collection, and supported questions. State which decisions still need the responsible person to review the answer.

Separate finding information from taking action. An assistant that explains the dispatch procedure doesn't automatically have permission to change an order. Keep the first release's answer boundary explicit, with a route back to the operating system or accountable owner.

Collect real questions from staff and their current search process. Include the wording people use when they don't know the document's title. Record the correct source, relevant section, applicable date, and any conditions that a complete answer must preserve.

Our RAG, fine-tuning, and database-query guide explains the architecture choices. This acceptance process applies whichever design you choose. A direct search result can meet a document-finding need, while a changing numerical fact may require a live lookup rather than a document summary.

Agree what successful use looks like. Staff must reach the right answer, inspect its evidence, or receive an actionable handoff when the answer is unavailable. A fluent response that leaves them unsure which procedure applies hasn't completed the task.

Exclude consequential uses whose review and ownership you haven't defined. A pilot covering general operating procedures shouldn't expand into individual employee cases simply because the assistant can search another folder.

Prove the assistant finds the applicable evidence

Build a source register before judging answer quality. For each collection, name the owner, authority, intended audience, and update route. Keep a stable document identifier and enough version information to distinguish a current procedure from an archived copy.

A Reddit discussion about an internal knowledge assistant describes missing answers despite apparently reasonable retrieval measures. The author later explains that their measure checks whether the right document appears. That question illustrates why you should inspect the actual evidence returned, rather than treating a document match as proof of a complete answer.

Test for the passage that contains the decision and its conditions. A search result from the right policy can still omit the exception in a footnote or an amendment elsewhere. Record whether the assistant retrieves enough evidence to answer the question fully.

Use an illustrative multi-site business to make this concrete. Its dispatch procedure has a general rule and a later amendment for a particular site. A manager asks which cutoff applies there. The expected result includes the amendment's scope and effective date, with the applicable rule. Retrieving the older general paragraph alone fails that case.

Test exact references alongside paraphrases. Product codes, local abbreviations, and similar policy titles can expose different retrieval failures. Include documents with tables and attachments if staff depend on them. Inspect whether ingestion preserves the relationship between a heading, its rows, and any qualifying note.

Distinguish missing source content from failed retrieval. If the approved procedure doesn't answer the question, the content owner must resolve that gap. If the answer exists but retrieval misses it, the technical team needs the question and expected passage to reproduce the failure.

Keep historical questions separate from current-policy questions. An archived document can be the right source for explaining a past decision. The application needs the requested date and an explicit historical scope before using it that way.

Check the claim behind each citation

A working link proves that a document exists. To accept the answer, check whether the linked passage supports the material statement beside it, including its limits. The reviewer should be able to find that passage without searching the entire repository again.

Ask a content owner to review the answer claim by claim. Mark unsupported additions, missing qualifications, and conclusions that the evidence doesn't establish. If several sources support different parts of an answer, show those relationships instead of placing a generic reference at the bottom.

Microsoft's guidance on Copilot grounding says that users should still check sources and critical details before acting, and warns that pointing at older material can produce outdated answers. A citation helps someone inspect the evidence; your acceptance cases still need to establish support and currency.

In the dispatch example, the assistant fails if it cites the current amendment but gives the general procedure's cutoff. It also fails if it gives the amended cutoff without explaining that it applies to the specified site. Check applicability alongside the cited words.

Test the source link while signed in as the intended user. Check that it opens the relevant version or clearly identifies the version used. A citation to an inaccessible file leaves the user unable to verify the answer, even if an administrator can open it.

Decide how the interface handles a source that changes after an answer. Preserve enough version context to explain the earlier response, but don't present that response as a fresh check of today's policy. Make the answer's source date and current verification path clear.

Test clarification, refusal, and escalation

Give the assistant questions with no answer in the approved collection. The expected behaviour should identify the relevant gap and offer the agreed next step. It mustn't turn general model knowledge into an asserted company policy.

Microsoft's grounding guidance also notes that Copilot may give a more general answer when it can't find relevant accessible sources. For a company-policy workflow, test and configure the behaviour you actually require. An employee needs to distinguish approved internal guidance from a general explanation.

Include ambiguous questions that need clarification. If the dispatch cutoff depends on the site and requested date, ask for the missing detail. Avoid returning every possible procedure when a short question can identify which applies.

Test conflicting sources. If two current-looking procedures disagree and the authority rules don't resolve them, route the issue to the content owner. The model shouldn't blend them into a new rule that nobody approved.

Make escalation practical. Name the queue or role that owns the unanswered question and carry forward the information already supplied. Give staff a way to continue their work through the approved manual route when the assistant is unavailable or unable to answer.

Measure unnecessary refusals too. An assistant that declines an authorised question despite complete evidence creates extra work. Separate an appropriate refusal from a missed answer so a cautious response doesn't automatically count as success.

Test access with real role boundaries

Build paired tests using the same question and different authorised identities. A local manager may read their site's procedure while another role can read the central source collection. Include a user who has no access to the relevant material.

Microsoft's semantic-index documentation describes grounding within the current user's access boundary and says indexing doesn't change the underlying content permissions. That also means existing oversharing needs its own review. A tool respecting a broadly shared folder doesn't establish that the folder's sharing policy is appropriate.

Apply authorisation before restricted content enters the model's context. Test snippets, suggested questions, citations, summaries, and downloads as well as the main answer. A refusal that reveals a restricted document's title or facts may still disclose information.

Exercise group membership changes and removal of access. Record when the source permission changes and when the assistant enforces that change. Test the supported behaviour during the propagation interval, including the route to suspend a collection or user if the normal update path is insufficient.

Repeat the question in a new session and an existing conversation. Cached responses, stored context, and shared answer links need the same access review. Where the assistant reuses prior context for a new answer, it mustn't reintroduce material the user can no longer access.

Revocation can't erase information a person already saw. Have the responsible owners define transcript access and retention separately from permission to retrieve or generate a new answer. Test both arrangements and describe their limits accurately.

Add a document containing instructions to reveal another collection or ignore access rules. Treat that text as untrusted source material. The application's identity and permission controls must decide what can enter the answer; a retrieved passage can't grant access.

Change, revoke, and withdraw sources

Run a change sequence in an approved test collection. Ask a question, publish an updated source, and ask again after the agreed update process completes. Record the source-change time, ingestion outcome, and answer. Define the permitted freshness window for the task with its owner.

Test a replacement and an amendment separately. A replacement should displace the superseded current source. An amendment may need both documents to explain the rule. The expected evidence should state which interpretation applies rather than assuming every newer file replaces every older one.

Amazon Bedrock's data-source guidance describes incremental synchronisation after additions, changes, and removals. It separately documents whether converted source data is deleted or retained when a data-source or knowledge-base resource is removed. Those are distinct operations, so inspect the actual configuration and completion evidence in your chosen system.

Withdraw a test document and confirm that a new query stops retrieving or citing its contents through the active serving path. Check derived passages, answer caches, and other copies the application uses. A successful deletion in the source repository doesn't prove the assistant has stopped using an indexed copy.

Define the response when the removed document was the only support for an answer. The assistant should return the agreed gap or handoff, rather than reproduce the former answer from a cache as if its evidence were still current.

Keep operational withdrawal separate from complete physical erasure. Backups, audit records, and provider-held copies need their own retention and deletion arrangements with the responsible advisers and service owners. Record what the test proves and what those separate processes cover.

Test a failed update job. Show its owner which collection is affected and how staff learn that its freshness is uncertain. Where the consequence warrants it, pause answers from that collection until the owner restores and verifies the feed.

Build an acceptance set that can block release

For each case, record the question, user role, source versions, expected evidence, required answer conditions, and permitted fallback. Have the source owner review those expectations. Judge meaning and support rather than requiring the model to repeat a single exact sentence.

Include cases the implementation team hasn't used to adjust the prompts or retrieval settings. Keep the same source snapshot when comparing configurations, then run separate change tests. Otherwise a source update can look like a model improvement.

Separate retrieval, answer, citation, and access results so a failure points to the right owner. Report them by question type and user group. A strong average doesn't establish acceptable behaviour on restricted material or an important procedure.

Agree release blockers before running the evaluation. For example, an observed access leak or a wrong answer on a designated critical procedure should stop the affected release until its owner resolves and retests it. Set the actual gates from the consequences of the task; don't borrow a universal accuracy percentage.

Keep failed cases in the regression set, with a reviewed expected result. The evaluation-set guide explains the broader process for collecting cases and keeping a meaningful comparison.

Measure completed work and assign operating owners

Compare the assistant with the existing path to an accepted answer. Include searching, opening sources, checking applicability, and asking colleagues. Then count the same activities during the pilot, including correction and escalation effort.

Measure the time to a correct supported answer or an appropriate handoff. Track the share of questions staff complete through each path, with the reasons for failure. Short response time alone doesn't show that a manager finishes the underlying task sooner.

Assign a content owner for source authority and a technical owner for ingestion, access enforcement, and service recovery. Name the operating owner who accepts the supported question set and receives recurring failure reports. Keep specialist reviews within the relevant person's remit.

Give staff a way to flag an answer with its source references and task context. Limit what the feedback record contains and who can view it. Turn verified gaps into a content correction or an implementation change, then test the affected cases before release.

Re-run acceptance checks when you change the model, source connector, retrieval configuration, or access design. A newly added department needs its own role and source tests. A PE portfolio should validate local content authority before treating another company's assistant as a reusable solution.

The knowledge assistants service guide sets out the delivery scope and handover. A first release needs an approved source collection, reviewed questions, demonstrated change handling, and people who can maintain those decisions. Expand when the next user group has the same operating evidence.