
An AI assistant flags a booking request that falls outside the policy. The message lands in a shared inbox, three people assume someone else is handling it, and the guest receives no answer. The system found the exception. Management still has to decide who owns it.
This fictional situation is a useful test for any manager introducing AI into customer service or administration. Before expanding the workflow, follow one difficult case from the first warning to the final decision. Every handover needs someone able to receive the work, judge it and act within an agreed boundary.
Give the exception a destination and a decision
“Escalate to a human” leaves several jobs unfinished. Which person is available? What evidence will they receive? Can they decide, or only forward the message? What happens while they are away?
The NIST AI Risk Management Framework Playbook, under GOVERN 2.1, calls for documented responsibilities and clear communication around AI risk. The practical method below is an original management application: give each recurring exception a named decision role, a backup and a safe waiting state. It is not a claim that NIST prescribes this exact template.
Start with the exceptions your team already understands: conflicting records, a request beyond published terms, missing evidence or an action the system cannot safely complete. An AI-generated confidence score should not be the sole trigger. A confident answer can still ask for something the organisation has not authorised.
Separate the reviewer from the person with authority
Consider a fictional guesthouse in Jamaica using AI to draft replies from its published booking terms. A guest asks to move a non-refundable reservation because a flight has been cancelled. The front-desk supervisor can check the booking and relevant terms. Only the manager can approve an exception to those terms.
Putting the supervisor’s name in a review box does not give that person the manager’s authority. The workflow should distinguish checking the facts from approving the exception. Otherwise, a hurried colleague may approve wording that makes a promise nobody agreed to fulfil.
A handover for this fictional case
- Trigger: The requested change falls outside the current published booking terms.
- First reviewer: The duty supervisor checks the request, the booking reference and the applicable terms.
- Decision owner: The duty manager decides whether an exception is permitted. A named authorised deputy covers absence.
- While waiting: Keep the proposed exception in draft. Staff may send only the approved acknowledgement; do not change the reservation or promise an outcome.
- Evidence: Retain the relevant policy version, a short factual summary, the decision and who authorised it in the approved system.
The response checkpoint must fit actual staffing and service commitments. Agree it with the people doing the work. If the manager cannot respond within that checkpoint, the supervisor should have a defined next contact or manual fallback. The AI must not interpret elapsed time as permission.
Ask the receiving person to confirm ownership
A notification proves little about whether work has been accepted. Build a visible acknowledgement into the handover: the receiving person confirms that they understand the question and can act within the checkpoint. Keep that separate from the later decision.
For a small team, this can be a field in an existing service log rather than a new platform. Record the owner, status and next update. When a shift changes, transfer unresolved items explicitly. If a role is covered by one person, decide who handles it during leave before the first live case arrives.
For Caribbean businesses supporting English- and Spanish-speaking customers, include the original request where policy permits and identify any translated summary. A colleague needs to see whether the guest requested a refund, a date change or simply an explanation. Translation should not silently turn one into another.
Make the stop instruction enforceable
Write the AI’s job narrowly: collect permitted facts, identify the relevant policy passage, prepare a neutral summary and draft a response. Reserve approval for the authorised person. Use approved systems and minimise personal information in the handover.
Where the AI has connected tools, reinforce that boundary through permissions and an approval step. A sentence in a prompt cannot replace controls on changing bookings, issuing refunds or sending messages. Test with fictional records before allowing live actions.
Try three failures: the decision owner is absent, two policy versions disagree, and the AI’s summary omits the guest’s main request. A safe result leaves the case visibly pending, routes it to the right person and preserves the unresolved question. If the system silently continues, narrow its access or return that part of the work to a manual process.
Use the four Ds across the whole handover
The AI Fluency Framework by Rick Dakan, Joseph Feller and Anthropic names Delegation, Description, Discernment and Diligence. Delegation divides work between people and AI. Description communicates the intended output, process and behaviour. Discernment evaluates the output and interaction. Diligence concerns responsible use, transparency and accountability.
Applied here, the four Ds reach beyond the prompt: choose what AI may prepare; describe the exception and its destination; check the evidence and proposed response; then preserve human authority and a usable record. This is an original example, not a reproduction of the course’s exercises.
Today, take one recurring exception and ask the receiving colleague to walk through it with you. Can they identify the decision, the evidence, their authority and the next checkpoint? Change the handover until they can. Automating the ordinary cases is useful only when the difficult ones still have somewhere reliable to go.
Sources & further reading
NIST AI RMF Playbook: GOVERN 2.1 — responsibilities and communication ↗Rick Dakan, Joseph Feller and Anthropic: AI Fluency terminology and four competencies ↗Sources checked 2026-10-20. Examples and recommendations are original editorial analysis.
