Treadstone Associates
Article · Staffing, training & knowledge

AI for standard operating procedures

Writing the first version was never the bottleneck. Keeping forty procedures true after the work changes is — and that is the part a model is genuinely good at.

Treadstone Associates · Updated 2026

Key takeaways

  • • Most SOP libraries fail on upkeep, not on authorship.
  • • A model reads the whole library at once, which no partner ever does — use it to find contradictions and stale references.
  • • Any answer drawn from the library must show which document it came from and when that document was last reviewed.
  • • Some documents in the library are statutory policies with their own deadlines, not procedures you can freely rewrite.

The short answer

You can create standard operating procedures with AI, and most firms start there. The return, though, is almost entirely on the other side of the job: maintenance. A twenty-person consultancy can write forty procedures in a fortnight and be wrong about half of them within a year, because the work moved and nobody went back.

The useful mental model is a library rather than a document. Authorship is a one-off; the library is a standing asset with an owner, a shelf life and a failure mode.

One procedure, one outcome

Before any tool touches it, fix the shape. Every procedure in the library carries the same six fields, and a model will enforce that consistency across sixty documents far more patiently than a person will:

  • Outcome — the one thing that is true when this procedure has been followed.
  • Trigger — what causes somebody to open it.
  • Owner — a named person, not a team.
  • Steps — in order, each with the system it happens in.
  • Exceptions — the awkward cases, and who decides them.
  • Last reviewed — a date, shown at the top rather than buried in file properties.

If a procedure needs two outcomes, it is two procedures. That single rule removes most of the sprawl that makes libraries unreadable.

What a model does across a library that a person will not

  • • Normalise sixty inherited documents into one format without losing content.
  • • Find contradictions — two procedures that give different answers to the same question, which is the single most common defect in an inherited library.
  • • Draft a change list when a rule, a system or a client requirement moves: which documents mention it, and what each would need to say.
  • • Answer a staff member’s question about what the procedure is for a given task, and cite the document it drew from.
  • • Report which procedures are past their review date, which is a query nobody runs manually twice.

Note what is missing from that list: deciding what the procedure should say. That remains the owner’s call, and the draft change list is an input to it.

The retrieval trap

The moment staff can ask a chatbot instead of opening the document, two things happen. They stop reading the source, and the model’s answer inherits every error in the library without inheriting the caveats around it. A stale procedure that used to be quietly ignored becomes a confident answer.

Two controls fix most of it. Every answer names the document and its last-reviewed date, so the reader can judge it. And anything past its review date answers with that fact first. The Privacy Commissioner’s generative AI principles make the same point about accountability from a different angle: where a system forms part of a decision-making process, keep records adequate to explain how the decision was reached.

Not everything in the library is a procedure

Some documents are policies with statutory content and statutory deadlines, and they are not yours to reword freely. In Ontario, an employer with 25 or more employees on 1 January of any year must have a written policy on electronic monitoring of employees in place before 1 March of that year. The policy has to state whether the employer monitors employees electronically and, if it does, how and in what circumstances, and the purposes for which the information may be used. Those requirements were added to the Employment Standards Act, 2000 on 11 April 2022, and the same guidance is clear that they do not create a right not to be monitored — they require transparency about it.

Draft with a tool if you like, but have the result reviewed. Treadstone Law’s notes on the electronic monitoring policy requirement and the disconnecting-from-work policy set out what those documents actually have to contain, and the ministry’s guide to the Employment Standards Act is the source to check against.

Retention has its own clock, separate from content, and the same ministry record-keeping guide sets it out document by document. The electronic monitoring and disconnecting-from-work policies must each be kept for three years after the policy is no longer in effect, even once you have replaced it with a newer version. Employee records carry different periods again: name, address and start date for three years after the person stops working for you, the hours-and-pay record for a day or week for three years after that day or week, and vacation time and vacation pay records for five years after the record was made. Treadstone Law’s summary of ESA retention periods lays out the rest by record type. None of this is what the procedure says to do; it is how long the evidence that you did it has to survive, and a library audit should check the two separately.

Organization size also changes which documents you owe at all. Ontario’s accessibility regulation requires a documented, publicly posted multi-year accessibility plan, reviewed at least once every five years — but only from a “large organization”, defined as 50 or more employees in Ontario. A firm under that line still owes the general accessibility policies and the training behind them; it does not owe the multi-year plan document or the posting requirement. Even below that line, s.3(1) of the same regulation still requires every obligated organization — small or not — to develop, implement and maintain the underlying accessibility policies. Size only removes the duty to write them up as a public-facing document; it never removes the duty to have them. Before a model flags a missing accessibility plan as a gap in your library, check headcount against the regulation, not just the calendar.

A worked example

A 22-person consultancy has roughly sixty documents scattered across a shared drive, of which about half are current. The sequence that works:

  • • Inventory first — every document, its last modified date, and a one-line statement of what outcome it produces.
  • • Collapse duplicates. Three versions of the same onboarding checklist become one, and the two losers are archived rather than deleted.
  • • Normalise into the six-field template, in batches, with a human reading each batch before it is committed.
  • • Run the contradiction pass and resolve every hit by decision, not by averaging the two documents.
  • • Assign owners and review dates, staggered across the year so no month carries the whole library.

The measure of whether it worked is not the number of documents. It is how often somebody asks a question in the team channel that the library already answers. That number is easy to count and painful to look at in month one.

Questions we get asked

How many procedures should we have?
Fewer than you think. One per outcome that repeats often enough to matter and goes wrong often enough to hurt. Everything else is a note, not a procedure.

Should the tool apply changes automatically?
No. Let it draft the change and show the diff; the named owner approves. Automatic edits to a library nobody re-reads is how a firm ends up following instructions no person ever agreed to.

Can we put client-specific procedures in the same library?
Keep them separate and keep confidential client material out of any general-purpose tool. The OPC’s guidance on limiting collection, use and disclosure is the standard to design against, not an afterthought.

See where AI pays off first in your firm.

A 30-minute call is enough to tell you whether AI pays for itself here.