How to Build a Team SOP From a Personal AI Workflow

Document purpose, roles, inputs, steps, checks, exceptions, and version ownership, then test the SOP with someone who did not design it.

A team SOP needs more than a list of steps. It must explain when the method applies, who is responsible, where the input comes from, how the result is accepted, when an exception should stop the process, and who maintains the current version. It works only when another person can use it without the author filling every gap verbally.

You may know your own AI workflow so well that many decisions feel automatic. You recognize which material needs cleaning, which claims need human judgment, and which output must not be delivered. A colleague who receives only “upload the file to AI and check the result” cannot see any of that. They have to keep coming back to you.

An SOP makes hidden judgment observable. The NIST AI Risk Management Framework also emphasizes documented roles, responsibilities, processes, training, and human oversight. NIST: AI RMF Core

Here is the source boundary. NIST supports documenting roles, processes, training, and oversight. The seven fields and unfamiliar-operator test below are my minimum SOP method for a small team. They are not an official NIST SOP template.

A minimum SOP answers seven questions

  1. Purpose: What problem does the SOP handle, and what is outside its scope?
  2. Roles: Who prepares the data, operates the workflow, and approves the result?
  3. Inputs: Where are the materials, what formats are allowed, and what data boundaries apply?
  4. Steps: What happens in order, and what does each step produce?
  5. Checks: How does the operator know that the result is acceptable?
  6. Exceptions: What happens when data is missing, a tool fails, or the content is high risk?
  7. Version: Which version is current, who maintains it, and when was it updated?

These fields turn an informal habit into something another person can inspect and test.

Replace “use your judgment” with observable conditions

Avoid writing:

If the content has a problem, ask a person to check it.

Write a condition, action, and owner instead:

If the output contains a number, quotation, or person’s name that cannot be
found in the source material, mark it for review and do not deliver it. The
content owner must verify it against the original source.

The operator can now see what triggers the rule, what to do, and who makes the final judgment. They do not have to guess what the author meant by “a problem.”

Test the SOP with an unfamiliar operator

Ask a colleague who did not design the workflow to complete a representative case using synthetic material. The author should not coach them during the first attempt. Instead, note:

This is not a test of the colleague. It is a test of how much of the process still lives only in the author’s head.

Practice: draft a team SOP

SOP name and purpose:
Out-of-scope situations:
Roles and responsibilities:
Allowed inputs:
Steps and output from each step:
Acceptance checks:
Stop and escalation conditions:
Version, maintainer, and update date:
Unfamiliar-operator test results:

Your saved result is a team SOP draft. It is complete enough for this lesson when another person can independently finish a representative case and knows when they must not continue.

The next lesson goes beyond whether the instructions can be followed. You will test whether the Skill, Plugin, or workflow behaves reliably across normal, boundary, and failure cases.

References