A business assistant is asked a clear question. It retrieves a document, produces a fluent answer and adds a citation. The document, however, does not contain the fact needed to answer that question.
The leadership question is what the assistant should do at that point. Guessing may create a false commitment. Refusing every difficult question may make the service unusable. A useful design gives the system a defined way to stop, explain the gap and move the work to the right next step.
AI abstention means withholding an answer or action when the conditions for a justified response are not met. For a business leader, the practical task is to decide which conditions matter and who handles the case when they are missing.
Define the boundary in business terms
“Answer only when confident” leaves too much unresolved. Confidence expressed in natural language is not a substitute for evidence that the response meets the organisation’s requirements. A convincing explanation can still be wrong.
The NIST Generative AI Profile describes confabulation as the generation of erroneous or false content, potentially presented confidently. It also notes that supporting logic and citations can themselves be fabricated. A link beside an answer therefore needs checking for relevance and support, not merely for existence.
For a specific workflow, translate the answer boundary into observable conditions. Examples include an approved source covering the question, a current policy version, the required case information and permission to disclose the result. These checks depend on the task. A creative brainstorming assistant needs a different boundary from an assistant explaining a contractual entitlement.
This builds on the emphasis in my AI for Business workshop material on giving an assistant a clear task, relevant context, reference material and a defined output. The next design question is what happens when that context or reference material is insufficient.
Separate four reasons to stop
“I cannot answer” is more useful when the reason determines the next action. Consider four distinct situations:
- Missing information: the user has not supplied a fact needed to select the applicable rule. Ask for that fact through an approved channel.
- Insufficient evidence: the available sources do not establish the answer. Say what cannot be verified and refer the case to the responsible source owner.
- Conflicting evidence: two applicable sources disagree, or the current version cannot be established. Identify the conflict without choosing a convenient answer.
- Outside scope or authority: the requested decision is beyond what the assistant is permitted to determine or disclose. Route it to an authorised person without revealing restricted information.
An access restriction should never be treated as an invitation to search for the same private information somewhere else. Similarly, an escalation should not imply that a human will approve the request; it means the right person must assess it.
Make the stopping response useful
Consider a hypothetical internal service assistant asked whether a particular customer qualifies for a contract exception. The knowledge base contains the standard policy but no approved record of that exception.
A weak response invents an entitlement from similar cases. A safer response might be:
“The standard policy covers the normal terms, but I cannot verify this customer’s exception from the approved records available to me. Please refer the case to the contract owner before confirming an entitlement.”
That response separates what is known from what is missing and identifies a next step. It should not say that a referral has been created unless the workflow actually created one. Where the assistant can open an authorised referral, it should confirm the reference and handoff; otherwise it should explain how the user can proceed.
Partial answers can still be valuable. The assistant may explain the general policy while clearly withholding the case-specific conclusion. The boundary must be visible enough that a reader does not mistake background information for a decision about their case.
Test whether the assistant stops for the right reasons
A prompt telling a model not to guess is an instruction, not proof that the system will behave reliably. Test the complete workflow, including retrieval, source selection, access checks, the response and the handoff.
Prepare paired examples: one question with sufficient approved evidence, and the same question with an essential fact removed or a conflicting document added. Also include questions that look similar to the supported task but require a decision outside its scope. Use fictional or appropriately protected cases.
Review three outcomes separately:
- Unsupported answers: cases where the system should have stopped but supplied a conclusion.
- Unnecessary stops: cases where the evidence was sufficient but the system withheld a useful answer.
- Completed handoffs: cases where the stop led to a clear, usable next step rather than leaving the person stranded.
Do not optimise for an abstention percentage on its own. A rising rate could mean the assistant is respecting its boundary, the source collection is deteriorating, or the service is receiving new questions. Examine the reasons, the consequences and the workload created for people. My article on evaluating AI accuracy beyond a headline score explains why different errors need separate attention.
Give unresolved cases an owner
Before release, agree who receives each category of unresolved case, what information they need, and what happens if nobody is available. Set response expectations that the team can actually support. A general inbox without an owner is a weak fallback for a service people depend on.
Keep a proportionate record of the reason for stopping, the source or policy version involved and the eventual resolution. Avoid copying full conversations or sensitive records into a new log without a legitimate need and appropriate controls. Review recurring gaps with the knowledge owner: some require better source material, while others should remain outside the assistant’s remit.
Change the boundary deliberately. If the assistant begins handling a new type of decision, use an AI change-control review rather than quietly relaxing the instruction because users want more answers.
A practical question for the next demonstration
Ask the team: “Show me a question this assistant must not answer, then show me where the work goes.”
The demonstration should reveal a justified stop, an understandable explanation and an accountable next step. That is a more useful test than checking whether the assistant can produce a reassuring sentence about uncertainty.
The NIST AI RMF 1.0 Core, particularly MAP 2.2 and MEASURE 2.6, addresses documenting knowledge limits and evaluating safe behaviour beyond those limits. The operating approach above is a practical synthesis, not a claim that NIST prescribes these exact categories or responses.
If your team is defining the answer boundaries for a business assistant, schedule a consultation to connect those boundaries to the work, evidence and responsibilities involved.