An AI-drafted standard operating procedure can be clear, orderly and impossible to follow. The missing step may be an approval nobody named, a system permission the reader does not have, or an exception that experienced staff handle from memory.
My recommendation is simple: before approving an AI-generated SOP, ask someone with the right baseline training to walk through the work using the document. Review what they can actually do, not just how well the procedure reads.
Start with the work that exists
Give AI current, approved process information: the trigger, responsible roles, required inputs, systems used, decision points and evidence of completion. Ask the people who perform the work where the written process differs from reality. Keep confidential or personal information out of tools not approved for that data.
Do not let the model quietly resolve gaps. If the approval owner or exception rule is unknown, the draft should say “needs confirmation,” not invent a plausible answer. A detailed-looking procedure can otherwise turn a guess into an instruction.
Also separate documenting a process from improving it. If the existing workflow is wasteful, writing it more neatly will not fix it. Find the process bottleneck first, and have the owner approve any proposed change before it becomes the operating procedure.
Use a walk-through, not another proofreading pass
The reviewer should understand the role but should not need the writer beside them explaining every step. Use a safe test environment, dummy records or a tabletop walk-through when live actions could affect customers, money or production. Never create real transactions merely to test a document.
Ask the reviewer to identify five things as they move through the procedure:
- Start: What event starts this task, and are the required inputs available?
- Action: Can this role perform the stated step with its actual access and tools?
- Decision: Is there enough information to choose the next step without guessing?
- Exception: What happens when information is missing, a system is unavailable or approval is refused?
- Finish: What record demonstrates that the work is complete, and who receives the handover?
Record every point where the reviewer pauses to ask a question. Some pauses reveal a training need. Others reveal a missing instruction, conflicting policy or unavailable resource. The fix depends on the cause; adding more text is not always the answer.
An illustrative example: a delayed delivery
Imagine an AI draft for handling a delayed customer delivery. One step says: “Confirm the revised delivery date and notify the customer.” It sounds reasonable. A walk-through exposes the unanswered questions.
- Which system contains the confirmed date, rather than an estimate?
- Who may approve a commitment when the carrier has not confirmed?
- What should the employee say if no reliable date is available?
- Where is the customer update recorded so the next colleague can see it?
A workable revision might require the employee to check the approved tracking source, distinguish confirmed dates from estimates, use an approved holding message when confirmation is unavailable, and route unresolved cases to the named operations role. The process owner must supply those rules. AI can help express them clearly; it cannot authorize them.
This is an illustrative scenario, not a claim about a client engagement. Its lesson is broader: the exception often reveals whether a procedure supports judgment or simply describes the easiest case.
Keep a small acceptance record
For a routine, low-risk procedure, the review record can be brief: procedure version, process owner, reviewer, scenarios checked, gaps found, corrections made and approval date. Note any remaining limits, including steps simulated rather than performed. Higher-risk or regulated activities may require additional specialist validation and controls.
Test the ordinary path and relevant exceptions selected by the people who know the work. Recheck a corrected step and anything it affects. An unresolved question about authority, safety or a customer commitment is a reason to withhold approval, not a footnote for the reader to solve.
This approach is consistent with the US EPA’s 2007 guidance on preparing SOPs, which recommends knowledgeable authors and review by experienced people, and describes testing by someone other than the original writer as helpful. I use that as a useful documentation principle, not as a claim that this historical guidance imposes a current requirement on every organization.
Approve a maintained procedure, not a finished file
Publish the approved version in the team’s normal working location, remove ambiguity about superseded copies, and name who maintains it. A changed system, role or approval rule should trigger a review of the affected steps. Change control matters after the first approval, too.
When briefing AI, define what “done” means: a draft ready for operational validation, not a document authorized for use.
The acceptance question is not “Does this sound professional?” It is “Can the intended person follow it, recognize when to stop, and leave the right evidence behind?”
If your team is using AI to document operational work, schedule a consultation to discuss where human validation belongs in the workflow.