An AI assistant for internal documents can help people find procedures, manuals and decisions scattered across systems. I would start with one task: helping someone resolve a work question with an answer they can verify. If the existing search tool already does that well, adding generated text may not justify the work.
The difficulty appears when a convincing answer omits a condition, combines two versions or cites a document that does not support its claim. This is one of the issues to address when taking AI from a demo to production. A pilot should expose those failures before expanding access.
Define the job before choosing a model
I would choose one team, one process and a document collection with a named owner. For example, looking up support procedures without changing accounts, sending messages or approving exceptions. Answering a question and taking an action are different scopes. The first proposal should state which it includes.
The system needs versioned ingestion, server-enforced identity and permissions, retrieval of authorized passages and traceable answers. The RAG pilot acceptance guide covers expiry, deletion and access revocation tests. Here I focus on evaluating the answer a person receives.
How to evaluate answers and citations
I would prepare anonymized real questions with the process owner before tuning the assistant. For each question, record the test identity, valid source and version, expected passage, conditions the answer must preserve and acceptable output. Keep some questions for a later check: testing only the examples used during development conceals errors.
| Check | Evidence I would request | Reason to reject |
|---|---|---|
| Retrieval | The required passage appears in the authorized context. | The document exists, but the relevant condition was not retrieved. |
| Support | Every decision-relevant claim points to a passage that supports it. | The citation mentions the topic but does not justify the conclusion. |
| Completeness | Limits, exceptions and necessary steps survive the summary. | The answer drops an exception that changes the decision. |
| Uncertainty | It asks for missing information or explains what it cannot confirm. | It fills a gap with an invented rule. |
| Usefulness | The person identifies the correct next step and can open the source. | They must reconstruct the answer or reach the wrong action. |
A confidence score declared by the model does not replace these checks. Nor would I accept an answer based on citation count: someone must inspect what the passages support. An automated evaluator can help prioritize reviews, but the process owner should check critical cases and resolve disagreements.
The research paper Evaluation and Continual Improvement for an Enterprise AI Assistant treats evaluation as a problem involving multiple components and ongoing improvement. The sheet above is a proposed working method, not a finding from that study or an accuracy guarantee.
Example: an answer that leaves out an exception
Suppose a fictional manual allows temporary access requests and requires a manager's approval for one particular system. An employee asks how to get that access. The assistant links the manual and says to open a request, but leaves out approval. Retrieval succeeded; the answer remains incomplete.
I would record the missing condition and inspect where it was lost: document extraction, passage selection or answer generation. Then I would repeat the question and equivalent cases. If the employee has not named the system, asking for clarification may be the expected output. This example is not a client implementation or a reported result.
What to require before accepting the pilot
- Complete question: a supported answer, necessary conditions and a reference to the right passage.
- Ambiguous question: requests the missing detail that changes the answer instead of choosing an interpretation silently.
- Partial evidence: separates confirmed information from gaps without presenting the partial answer as complete.
- No documented answer: acknowledges the absence and offers the agreed review route.
- Conflicting sources: exposes the conflict to an authorized reviewer instead of resolving it through an arbitrary preference.
- Request to act: preserves the lookup boundary and does not treat an explanation as permission to execute.
I would agree criteria by category and severity before testing. Measure supported answers, omissions, correct refusals and unnecessary refusals separately against their relevant cases. An assistant that refuses everything is not useful. A favorable average also cannot offset a data disclosure: that failure blocks expansion until it is fixed and the tests are repeated.
Measure the work your team still has to do
Compare equivalent questions against the current process, including search, source reading, correction and escalation time. Add document maintenance, incidents and system usage costs. Less time generating text does not necessarily mean less total work or automatic cash savings.
The pilot may justify continuing, narrowing scope or returning to search. It may also be inconclusive if representative cases are missing. Technical planning before development helps record those decisions and their owners.
Traces and maintenance after handover
I would retain the query identifier, test identity, source versions, retrieved passages, answer, citations, configuration version and review outcome. Access and retention limits apply to those traces too: copying sensitive documents into an open log creates another problem.
Adslyfy documents executions, failures and screenshots for ad monitoring. It is a reference for operational visibility, not a document-assistant case study or evidence of AI accuracy.
Assign who corrects a source, who handles a technical incident and who reviews answers after a model, instruction or document change. Repeat the evaluation set after those changes and record regressions instead of treating the initial result as permanent.
What to prepare before commissioning development
Request a proposal covering included sources and formats, identity integration, evaluation set, interface, traces, handover and maintenance. Separate implementation from recurring costs and the work your team will retain. Use the guide to comparing software quotes to make deliverables and exclusions explicit.
If you need to turn a demo into a system you can evaluate, I can review the scope through my automation and applied AI services. When the blocker spans decisions across teams, technical leadership support may also fit.
To discuss the first pilot, prepare document types, intended users and two representative questions with expected answers. Start with anonymized examples rather than sending confidential documents in the initial enquiry.