An AI document workflow should be allowed to say that it cannot answer from the available evidence. If every request must produce a confident response, the system encourages a polished guess precisely when the user needs a clear boundary.
Design the unanswered state as part of the feature. It should explain what is missing, preserve the user's work and offer a next step that a person or a better source can complete.
Define an acceptable answer
Start with the job the answer supports. Summarising a public handbook is different from deciding whether a particular customer qualifies for an exception. The latter may depend on account records, policy versions and a person authorised to make the decision.
Write examples of answers that are useful, unsupported and incomplete. Include a question whose answer does not exist in the document set. If the evaluation only contains answerable questions, the team will not learn whether the system can stop appropriately.
For a hypothetical support assistant, a useful response might cite the current returns policy and identify the relevant section. If the customer's purchase falls outside the cases described, the system should route that uncertainty to the support team instead of inventing an exception.
Preserve evidence with the draft
Keep the source passages and document identifiers alongside the generated answer. A reviewer should be able to inspect the evidence without performing the search again. Include the document version or update date when it affects meaning.
Do not assume that a citation proves support. The cited passage must actually justify the claim. An answer can include a real link while attributing something to the document that it never says.
Review the relationship between the question, retrieved material and final text. Each can fail independently: the search may miss a relevant page, the source may be obsolete or the generated response may overstate what the source establishes.
Give abstention an operational route
Use explicit states such as “needs a source”, “conflicting information” or “requires a decision”. Keep the labels understandable to the team that receives them. A generic low-confidence score rarely tells an operator what to do next.
Preserve the original question and the evidence already found. Let the reviewer add a source, correct the interpretation or make the decision within their authority. That work can also reveal gaps in the organisation's documentation.
Avoid treating a model's own confidence statement as a complete safety mechanism. The workflow needs observable checks, suitable evaluation examples and the right permission boundaries around any resulting action.
Measure the cost of wrong answers
Track answer quality and review burden together. A system that abstains on every question may be safe from one kind of mistake but provide little value. A system that rarely abstains may create expensive corrections.
Use a representative evaluation set and review failures by cause. Improve retrieval when evidence is missed, improve the source when it is ambiguous and narrow the permitted task when the workflow asks for decisions it should not make.
Our AI automation work focuses on useful tasks with clear review and recovery paths. An honest unanswered state is part of making that automation dependable, not an admission that the feature has failed.