Applied AI · · 6 min read · By the Cirlume studio
Answers staff can trust: an assistant built on approved documents
How to build a document assistant that cites its sources, respects permissions and says when it does not know.
Most organisations have the answers their staff need. They sit in policies, procedures, contracts, product guides and old email threads. The problem is finding the right one quickly, and knowing it is still current. People ask a colleague instead, and the colleague answers from memory.
An assistant that answers questions from your own documents can help, but only if people trust it. A tool that gives a confident wrong answer about a refund policy or a safety procedure does more harm than no tool at all. Trust comes from a few design decisions made early: which documents it can use, how it shows where an answer came from, who can see what, and what it does when the documents do not cover the question.
Choose the sources before the model
The first decision is not which model to use. It is which documents the assistant is allowed to answer from.
Start with a small, deliberate set. A single policy library or one team’s procedures is enough for a first version. Each source should have an owner who can say whether it is current, and a clear status: approved, draft or superseded. If you cannot say which version of a document is the right one, the assistant cannot either.
Leave out material that looks useful but is not authoritative. Chat logs, meeting notes and personal folders often contain outdated or informal answers. Including them makes the assistant sound more knowledgeable and makes it less reliable.
How retrieval works, and where it fails
Most document assistants use retrieval: when someone asks a question, the system searches the approved documents for the most relevant passages and gives only those to the language model, with instructions to answer from them. The model writes the answer. The search decides what it has to work with.
That means most quality problems are search problems. Common causes:
- Poor splitting. Documents are cut into passages before they are indexed. Cut a policy mid-table or separate a rule from its exceptions and the model sees half the answer.
- Wording gaps. Staff ask about “holiday” while the policy says “annual leave”. Combining keyword search with meaning-based search, and adding a glossary of internal terms, helps.
- Messy inputs. Scanned PDFs, tables and slide decks often extract badly. Check the extracted text of your most important documents by hand.
- Too much context. Passing twenty loosely related passages can produce a muddled answer that blends several policies. Fewer, better passages usually work better.
When an answer is wrong, look at what was retrieved before changing the prompt. Often the right passage was never found.
Show the passage behind every answer
Every answer should show the passage it was based on, with the document title, section and a link to the source. This does two things. Staff can check an answer in seconds without searching themselves, and reviewers can see whether an error came from the search or from the model.
Make the citation specific. A link to a forty-page handbook is not a citation. Point to the section, and show the quoted text so the reader can compare it with the answer.
Ask the model to answer only from the passages it was given, and check that it did. A simple automated check is whether each claim in the answer can be matched to the cited text. Where it cannot, treat the answer as unsupported.
Respect permissions from the start
An assistant must never show someone a passage they could not open themselves. HR case notes, board papers and client contracts often sit next to general policies in the same systems.
- Filter at retrieval. Apply the user’s access rights when searching, so restricted passages are never passed to the model. Filtering the answer afterwards is too late.
- Mirror the source permissions. Read access rules from the document system rather than keeping a separate list that drifts out of date.
- Treat documents as untrusted input. A document can contain text that tries to instruct the model, which OWASP lists as indirect prompt injection. The assistant should treat document content as material to quote, never as instructions.
- Decide what is logged. Questions can reveal personal matters. Agree what is stored, who can read it and for how long.
If the documents contain personal data, the ICO’s guidance on AI and data protection is a sensible starting point, and your data protection lead should be involved before the build, not after.
Make “I don’t know” a normal answer
The most important behaviour to design is the refusal. If the approved documents do not answer the question, the assistant should say so, name the documents it searched and point to a person or team who can help.
This needs deliberate work. Language models tend to produce an answer whatever they are given, so the instructions, the retrieval threshold and the evaluation set all need to reward a clear “I couldn’t find this in the approved documents” over a plausible guess.
Similar care applies when documents disagree. If two policies give different answers, the assistant should show both and say they conflict. That is useful information for the document owners as well as the person asking.
Keep the documents current
An assistant is only as current as its index. Plan how updates flow through:
- re-index documents when they change, and remove superseded versions rather than keeping them alongside the new ones;
- show the document’s last-reviewed date next to each answer;
- report to owners which documents are cited most, and which questions found nothing, so gaps get filled;
- give staff a quick way to flag a wrong or outdated answer, and route that flag to the document owner.
Over time, the unanswered questions are often the most valuable output. They show where the documentation itself is missing.
Build an evaluation set from real questions
Before launch, collect real questions staff have asked: from email, help desk tickets or by asking teams directly. For each, record the correct answer and the passage it should come from. Include questions the documents do not cover, where the right response is a refusal, and questions a given user should not be able to answer because of permissions.
Score each run on a few separate things:
- did retrieval find the right passage;
- is the answer supported by the cited text;
- did it refuse when it should have;
- did it leak anything the user should not see.
Run the full set every time you change the prompt, the model, the splitting or the documents. Keep it separate from the examples you tune on, and add every reported mistake to it. Without this, changes are judged on a handful of questions that happened to look good in a demonstration.
The trade-offs
A document assistant is not a substitute for well-kept documents. If policies are contradictory or out of date, the assistant will surface that quickly, which is useful, but it will not fix it.
Strict refusals and narrow sources make the assistant less impressive at first. Staff will hit “I don’t know” more often than they would with a general chatbot. That is the right trade for anything where a wrong answer has consequences. You can widen the sources once the evaluation results support it.
There are also running costs: model usage per question, indexing, and someone’s time to review flagged answers and maintain the evaluation set. If nobody owns that work, quality will slip without anyone noticing.
When to bring in help
If you have a pilot that answers well in demonstrations but staff do not rely on it, the cause is usually in retrieval, permissions or evaluation rather than the model. We can help choose the first set of sources, design citations and refusals, set up permission-aware search and build an evaluation set from your own questions, so you can see whether the assistant is ready for daily use.