Takeaway
When an AI workflow produces a consequential error, pause the affected work, keep customers moving through a named manual queue, and account for every uncertain item before restarting. A corrected prompt alone does not establish that yesterday’s drafts, today’s queue and messages already sent are consistent.
Who this guide is for
Owners and operations leads in small businesses using AI for administrative drafts. Our example is a small hotel: AI prepares enquiry replies from approved hotel information; a receptionist checks and sends them. The workflow cannot create bookings, change reservations or take payments. Those activities remain in the hotel’s existing human-controlled process.
This is Nadali’s proposed operating procedure, with illustrative choices to adapt. NIST’s AI RMF Playbook discusses non-AI alternatives, incident recovery, deactivation responsibilities and criteria for redeployment in MANAGE 2.1, 2.3 and 2.4. It does not prescribe this hotel checklist or its example thresholds. NIST AI RMF Playbook: Manage.
1. Decide what warrants a stop
Write stop triggers before the next busy shift. For this hotel, one invented price, false availability claim, wrong guest’s details or suggestion that a booking is confirmed is enough to pause the affected drafting route. Also stop when staff cannot establish which hotel information was used, the review queue is missing items, or a draft appears outside its intended enquiry.
A spelling mistake can be corrected locally. An unsupported commercial promise requires investigation. Any receptionist may request the pause; the shift lead owns the response. Name a deputy so absence does not leave the decision waiting.
2. Stop new work and check the pause
Pause new AI drafting jobs and automatic retries. Tell colleagues which route is paused and where new enquiries now belong. Keep the inbox available for manual service. Do not delete the workflow or clear its history to make the warning disappear.
Check jobs already running, queued drafts and any connected delivery step. A stopped trigger may leave existing jobs running. Mark their outputs as held until reviewed. Verify the pause with a fictional enquiry in an isolated test route or an administrative status check; do not send a test message to a real guest.
3. Establish the last-known-good boundary
Record the incident time with its timezone, the earliest suspicious draft, the last positively verified item, and the relevant prompt and information versions. These may define different boundaries. A correct draft at 09:10 does not prove every earlier draft was correct.
For example, if a hotel-policy update at 08:40 may explain the error, include drafts produced since that update in the review window. If the cause is unclear, widen the window to the earliest plausible point. Separate verified records from assumptions. Record unresolved uncertainty explicitly rather than inventing a clean cutoff.
4. Preserve enough evidence, with limited access
Keep the original faulty output and the minimum input needed to understand it, plus job identifiers, timestamps, source versions and relevant status records. Store originals where authorised incident reviewers can access them. Use redacted copies for discussion, preserving links to controlled originals when necessary.
Avoid exporting the entire guest inbox or pasting passports, payment details or unrelated conversations into another AI tool for diagnosis. Assign someone to manage access and retention under the business’s existing policy. If exposure of personal data is suspected, involve the appropriate privacy or security specialist promptly; this guide does not determine notification duties.
5. Give the manual queue an owner
Use the existing shared inbox or an approved tracker. For each enquiry, record a stable reference, assigned person, next action, deadline and status: awaiting review, being handled, awaiting information or completed. Keep personal details in the original system where possible.
The shift lead assigns items and checks that someone accepts each handover. Staff consult current hotel records and approved wording directly. They make no availability or price promise without the normal verification. If capacity is limited, prioritise time-sensitive enquiries and give realistic response expectations. A busy queue is a reason to adjust service, not to restart uncertain automation.
6. Reconcile outcomes before retrying
Compare the inbox, draft store, job records and sent-message history using each enquiry’s stable reference. Identify drafts never created, drafts held, replies actually sent, duplicates and items whose outcome remains unknown. Give every unknown item a named investigator and keep it out of automatic replay.
A timeout does not prove a job failed. A missing success message does not prove a reply was unsent. Check the receiving system’s record before retrying. If records conflict, resolve the uncertainty through the normal support process; do not repeatedly generate or send another reply just to see what happens.
If a guest received incorrect information, the responsible employee reviews the actual message and prepares a clear correction through the hotel’s approved customer-contact process. Track that correction separately. Repairing the workflow cannot retract a promise already communicated.
7. Set acceptance criteria for a limited restart
The owner records the fault addressed, remaining uncertainty, changed components and rollback method. If the affected scope cannot be bounded or an effective control cannot be demonstrated, keep the manual route.
Before restart, require all of the following:
- The affected review window is accounted for, with unresolved items isolated and assigned
- The corrected route uses identifiable, approved hotel information and retains draft-only permissions
- Fictional test enquiries cover the observed failure, ordinary requests, missing information and an interrupted job
- Staff can stop the route and distinguish held, completed and unknown items
- A named reviewer has capacity to inspect every draft during a limited pilot
For an illustrative pilot, review the next ten drafts individually against their sources. This number is an editorial starting point, not a statistical guarantee. Stop again on any defined trigger. The owner decides whether evidence supports continuing, extending observation or returning to manual work.
8. Rehearse the handover on paper
Try a fictional tabletop exercise: an outdated breakfast policy appears in a draft; another job times out; three enquiries arrive during the pause. Ask the team to show who stops drafting, who owns each enquiry, how it checks whether the timed-out job created a draft, and what evidence would permit restart.
Do not claim success merely because everyone agrees with the plan. Record unanswered questions and update the procedure. This is a proposed exercise, not a test Nadali has run.
Limits and a useful final record
Keep a short incident record: what happened, affected scope, customer corrections, changes, restart decision and owner. Review it at the next operational handover. This procedure cannot guarantee error-free AI or replace product-specific recovery instructions, cybersecurity response or professional advice. It is not designed for clinical decisions or other high-consequence automated actions.
Source checked: 16 October 2026. Prepared with AI; the workflow recommendations and hotel example are original editorial proposals.
