Drafting with a language model
It is good at turning a mess into a structure and bad at knowing how your organisation does anything. The second failure is quiet, which is what makes it dangerous.
Where a language model helps in drafting a procedure, where it fails quietly, and what must never be given to one.
What it is genuinely good at
Turning a mess into a structure. Somebody who has captured a task as twenty unordered lines in a note has done the expensive part; converting that into numbered steps with a purpose line and a consistent voice is exactly the kind of tidying a language model does well and quickly.
Producing a first draft that is easier to criticise than a blank page. People are much better at saying "no, step four comes before step three" than at writing step four unprompted, and a draft turns writing into reviewing.
Making a set of documents read consistently. Ten procedures written by ten people in ten registers is a real problem, and normalising them is a mechanical task with no judgement in it.
Asking what is missing. A model reading a draft will reliably point out that nothing says who owns the task or what to do when it fails — the two omissions that turn up in most first drafts anyway.
What it cannot do, and the failure is quiet
It does not know how your organisation does the task. Asked to write a procedure for something it has not been told about, it will produce a plausible generic version — correct-sounding, well-formatted, and describing a company that is not yours.
That is the specific danger, and it is worse than an obvious error. A wrong procedure that looks wrong gets fixed. A wrong procedure that looks professional gets filed, approved and followed until the day it fails.
It also cannot tell you which steps matter. A model has no way of knowing that step six is the one where a mistake is expensive and step two is cosmetic, so it gives them the same weight — and weighting is a large part of what makes a procedure usable.
Never ask it to write a procedure from the title
"Write an SOP for onboarding a new employee" produces a document about onboarding in general. It will name systems you do not use, steps you do not perform and roles you do not have, and every one of those will read as a suggestion that you are doing it wrong.
The correct input is your own capture. The steps as somebody actually performed them, in whatever order they came out, with the real names of the real things. Then ask for structure, not content.
The test to apply to any draft: could this have been written without knowing anything about us? If yes, it contains nothing and it should be deleted rather than edited. Getting the real steps out of the person who does the work remains the part that cannot be skipped.
Three things that must not go in
Anything confidential. Customer data, personal data, financial detail, credentials, anything under an agreement. Where the text goes and how it is retained depends on the service and the settings, and it is your organisation's call rather than a detail to work out afterwards.
Anything with legal effect. Language that creates or limits an obligation is not a drafting exercise. This site does not carry adoptable legal language for the same reason, and a model producing something that reads like a clause is producing something that reads like a clause.
Any claim about a standard. Ask a model whether a procedure meets a named standard and it will answer, fluently, and the answer is worth nothing. Conformance is determined by an assessment, not by a document's own opinion of itself.
The review that has to happen anyway
Every draft, however it was produced, gets the same test: somebody who has not done the task follows it, without help, and everything that breaks gets fixed. That step was always the one that mattered, and nothing about how the draft was written changes it.
What does change is the temptation to skip it. A hand-written draft looks provisional, so people test it. A generated draft looks finished, so people approve it. That inversion is the main risk this whole approach introduces.
Two further checks are worth adding. Read every step and ask whether it names something real in your organisation. And check the numbers, dates and thresholds specifically — they are the details most likely to have been supplied plausibly rather than accurately.
Who the document belongs to
The named owner in the control block is a person, and it stays a person. A procedure with no accountable human is one that nobody revises when the process changes, which is the ordinary way documents die.
It is also worth recording in your own notes how a document was drafted, if only so that a reviewer knows how much scepticism to bring to it. That is a matter of your own document control rather than something to publish. Document control basics covers what the block carries.
Everything on this site is a blank and worked template, free and without an account. The SOP template is the structure worth pasting a draft into, because it already has the fields a generated draft tends to leave out.
No service is named anywhere on this page and none is recommended. What is available, what it does with your text and what it costs all change faster than a page can, and this site takes nothing from anyone.
Editor's notes
Written by Free Biz Docs about the document above — not reader submissions.
No service is named and none is recommended
This site names no product, vendor, brand or platform, takes no affiliate arrangements and carries no comparison tables — that is a standing rule, and it applies here even though it makes the post less immediately useful. What is available, what it does with your text and what it costs all change faster than a page can.
The quiet failure is the whole reason the post exists
A generated draft that is wrong does not look wrong. It is well-formatted, consistently voiced and plausible, and it passes the review a hand-written draft would not have passed — because a rough draft invites testing and a finished-looking one invites approval. That inversion is the risk this approach introduces, and it is not obvious in advance.
The post makes no claim about how good any model is
Nothing here says a model writes well or badly, and nothing depends on the capability of any particular one. The two things claimed are structural: a model does not know your organisation unless you tell it, and a document's own opinion of its conformance is worth nothing. Both stay true whatever the tools do next.
These documents are starting structures for you to build on, not professional or legal advice. Anything that will have legal or contractual effect, or that varies by jurisdiction, should be reviewed by someone qualified in the relevant place.
Common questions
- Can I use AI to write an SOP?
- For structure, yes — turning a captured mess into numbered steps in a consistent voice is mechanical work it does well. For content, no. It does not know how your organisation does anything, and asked to write from a title it will produce a plausible document about a company that is not yours.
- What is the risk of a generated procedure?
- That the failure is quiet. A wrong procedure that looks wrong gets fixed; one that is well-formatted and professional-sounding gets filed, approved and followed until the day it fails. A hand-written draft looks provisional so people test it — a generated one looks finished, so they approve it.
- How should I prompt it?
- Give it your own capture — the steps as somebody actually performed them, with the real names of the real things — and ask for structure rather than content. The test for any draft: could this have been written without knowing anything about us? If yes, delete it rather than edit it.
- What should never go into a language model?
- Anything confidential — customer or personal data, financial detail, credentials, anything under an agreement. Anything with legal effect, which is not a drafting exercise. And never ask whether a procedure meets a named standard: it will answer fluently and the answer is worth nothing.
- Who owns a procedure that was drafted this way?
- A person, named in the control block, exactly as before. A procedure with no accountable human is one nobody revises when the process changes, which is the ordinary way documents die — and how a draft was produced does not change that.