Nadia Khoury leads a 15-person creative operations team at a digital agency. Over a single busy quarter, AI quietly worked its way into half of what her team did. One designer used it to generate first-draft ad copy. Two project coordinators used it to summarize client calls. Someone built a prompt that turned messy briefs into structured task lists. None of it was written down anywhere. Then a long-time client asked, plainly, "How was our campaign copy produced, and who reviewed it?" Nadia realized she could not give a confident answer for her own team. The work was good. But the process behind it lived entirely in people's heads. That week she set out to do something different from documenting any single deliverable: she set out to bake AI-use documentation into the team's standard way of working, so the next time anyone asked, the answer was already written down.

What This Lesson Covers

This lesson is about your team's processes, not about one finished artifact. The goal is to embed lightweight records into the standard operating procedures (SOPs) and workflows your team already uses, so that "how AI fits into this process" is documented once and stays visible to everyone who touches the work. When documentation lives inside the workflow, a new hire can read it, a client can be answered, and an auditor can be satisfied, all without anyone scrambling to reconstruct the truth.

You will learn the three levels of process documentation, how to build a documentation system that people actually use, a maintenance routine that keeps it from going stale, and how to handle special cases like client and regulated work. The recurring principle: keep it the minimum that serves a real purpose. The goal is clarity, not bureaucracy.

Why Process Documentation Matters

The failure mode Nadia hit is common. AI gets adopted process by process, informally, and nobody writes down where it lives. Then the gaps appear all at once. You cannot tell a client how a deliverable was made. An auditor asks a question and you have no answer. Someone uses AI in a way you would not have approved, and there is no trail to catch it. A new joiner has no idea which steps in a workflow involve AI. And you want to improve a process but cannot remember how it actually runs.

Documenting AI inside your processes addresses five needs at once: compliance (in regulated work, records may be required), accountability (you can answer for what your team produces), risk management (if something goes wrong, the record helps the investigation), onboarding (new people learn the real workflow fast), and learning (you can only improve a process you can see). The aim is the smallest documentation that delivers those benefits, not a binder nobody opens.

If you would want to explain it to a regulatory auditor or to a new team member, document it. If you would not, leave it alone.

The Three Levels of Documentation

Nadia found it useful to think in three layers, because each answers a different question and lives in a different place.

Level 1, process documentation, answers "how does this workflow work, and where does AI sit inside it?" It is a one-page summary per process, kept in a shared wiki.

Level 2, output documentation, answers "for this thing we produced, was AI involved and was it reviewed?" It is a short annotation attached to the output itself, inside the tool where the work happens.

Level 3, decision documentation, answers "why did we choose to use AI this way, or this tool?" It is a brief entry in a decision log, kept over time for retrospectives.

The trick is to put each layer where the people who need it actually look. Process docs in the wiki. Output notes in the workflow tool. Decisions in the log. Mixing them up is why most documentation goes unread.

Level 1: Documenting a Process

For each process that uses AI, a one-page record answers six questions: what is the process and who runs it; where AI is used (which step); what tool is used; why AI is used (what value it adds); how output is verified before use; and what the known limitations are. Here is the record Nadia wrote for her team's caption-drafting workflow, the one the client had asked about.

Process: Social caption drafting
Purpose: Produce first-draft captions for client social posts
Owner: Dev Okafor (senior copywriter)

Steps:
1. Pull approved campaign brief → human
2. Draft 3 caption options → AI (ChatGPT, brand-voice prompt)
3. Review and select → human (Dev, against brand guidelines)
4. Client approval → human (required before scheduling)

Why AI: caption drafting drops from about 25 minutes to about 6 minutes per post; brand voice held through a saved prompt.

Verification: every caption read by Dev for tone and accuracy; product claims checked against the live fact sheet; no client account data entered into the tool.

Limitations: AI sometimes invents product specifics, so claims are always checked; AI can miss cultural nuance, which the human review catches; the three options are suggestions only, never auto-scheduled.

That one page is what Nadia can now hand a client, a new hire, or an auditor. It took fifteen minutes to write and it closes the exact gap that embarrassed her.

Level 2: Annotating an Output

The second layer is a sentence or two attached to the output itself, inside the tool where work lives, so the next person sees it without hunting. It answers what the output is, whether AI was used, what verification happened, and whether it is draft or final. The point is that it travels with the work. For a caption set ready to schedule, the annotation in the project tool reads: "Captions drafted with AI, reviewed by Dev for tone and accuracy, checked against the current product fact sheet. Final, ready to schedule." For a coordinator's call summary it might read: "Summarized from the call recording with AI; action items verified against my own notes; draft, pending the account lead's review." Short, specific, and exactly where the next person will look.

Level 3: Logging a Decision

The third layer captures the choices behind the process, so future-you remembers why things are the way they are. Each decision-log entry notes what was decided, the reasoning, what alternatives were weighed, and who decided. When Nadia's team chose a captioning tool, the log entry read: decision, standardize on the team ChatGPT workspace for caption drafting; reasoning, it met the security review (data not used for training) and fit the existing budget; considered, a cheaper consumer tool (rejected over data-handling concerns) and a pricier specialist tool (rejected on cost for the volume); decided by, Nadia plus Dev as process owner. Six months later, when someone asks "why aren't we using the cheaper tool?", the answer is already on file.

Building a Documentation System

Three layers only help if they live somewhere usable and get maintained. Nadia built her system in four steps.

Step 1: Audit what needs documenting. She listed every team process and marked which used AI. Then she filtered hard: only processes touching client deliverables, compliance-sensitive work, or significant time investment got documented. A handful of trivial internal uses were left undocumented on purpose. Her test was the auditor-or-new-hire rule above.

Step 2: Create quick templates. She built three reusable templates matching the three levels: a one-page process summary, a two-field output note ("AI used: yes/no; status: draft/final" plus the verification line), and a decision-log row. Quick templates are what keep documentation from feeling like a project.

Step 3: Choose where it lives. Process docs went in the team Notion wiki (searchable, version-controlled). Output notes went into the project-management tool where the work already happened, because documentation people have to leave their workflow to find goes unread. The decision log was a simple Notion database. The best practice is a combination: a wiki for processes, in-workflow annotations for outputs, a log for decisions.

Step 4: Make it a habit. Documentation is only useful if it stays current, so Nadia tied updates to events: draft the process doc at the same time the process is designed; update it the moment the process changes, noting what changed and why; have every new hire read the relevant docs and flag anything unclear (if they do not understand it, it needs fixing); and review all docs quarterly for accuracy, archiving anything obsolete.

Handling Special Cases

Client work. When a deliverable was made with AI, be transparent in proportion to the client's needs: note AI use in the deliverable, explain your quality-assurance process, and disclose in the agreement if the contract calls for it. This is exactly what would have spared Nadia the awkward question. Some clients simply want assurance that a human reviews the output, and the process doc answers that on the spot.

Regulated work. For healthcare, finance, or legal contexts, check the actual regulations first, then document more thoroughly: what data was input, who reviewed and approved each output (the chain of verification), and how the output was confirmed to meet the relevant standard. A healthcare example annotation: "Patient summary organized with AI assistance; all clinical details reviewed against original records by the attending clinician; diagnoses are clinician-verified, not AI-generated."

Low-risk internal processes. For minor internal work, document lightly: process name, tool, owner, and that is often enough. A two-line note for an internal sales-summary process is proportionate; a full SOP would be over-engineering.

Evolving processes. Mark the maturity so readers know how much to trust it: "pilot, owner testing only," then "established, used team-wide and verified," and eventually "being replaced, no longer recommended." This stops people following a process you have already moved on from.

Documentation as a Learning Tool

Beyond compliance and clarity, the records become a way to improve. Three months into the caption workflow, Nadia reread the process doc and compared it to reality. The team had quietly added a step (running brand-voice spot checks) that was not written down, and had dropped the A/B testing of options because it was not adding value. The doc had drifted from the truth. Updating it surfaced both changes, let the team confirm the spot-check step was worth keeping, and created a record of how the process had evolved. A process you can see is a process you can improve; one that lives only in habit quietly mutates without anyone deciding it should.

Common Mistakes and Anti-Patterns

Over-documenting. Fifty-page docs for every process go stale and unread. One page, with links to detail if needed, is the target.

Under-documenting. "People just know how it works" means knowledge is fragile, and when someone leaves, the process breaks. Document enough that a new hire can follow it with minimal hand-holding.

Documenting once and never updating. Stale docs are worse than none, because people either follow the wrong process or learn to ignore the docs entirely. Build updates into your routine.

Treating it as a compliance checkbox. Documentation written only to satisfy auditors is dry and unused, so it is not maintained. Make it serve the team first; compliance is then a free byproduct.

Keeping it separate from the work. If the docs are in a wiki but the work happens in Slack and the project tool, people will not consult them. Put documentation where the work lives, or link to it from there.

No owner for updates. "Everyone's job" means nobody's job. Assign a named owner per process, exactly as Nadia named Dev for captions, and pair updates to a recurring review.

Key Takeaways

• Document the process, not just the artifact. This skill embeds AI-use records into your team's standing workflows and SOPs, so the answer to "how do we do this?" is written down and visible to everyone.
• Work in three layers. A one-page process doc in the wiki, a short output annotation in the workflow tool, and a decision-log entry over time; each answers a different question and lives where its readers look.
• Keep it light and practical. One page per process beats a fifty-page manual; quick templates are what make documentation sustainable rather than a project.
• Put it where the work happens. A separate wiki is a useful supplement, but output notes belong inside the tools your team already uses, or they go unread.
• Make maintenance a habit. Draft docs when you design a process, update them the moment it changes, have new hires pressure-test clarity, and review everything quarterly.
• Assign one owner per process. A named owner keeps documentation current; "everyone's responsibility" reliably becomes no one's.
• Match depth to risk. Document client and regulated work thoroughly with verification chains; document low-risk internal processes in a couple of lines.
• Use it to learn. Periodically compare the doc to reality, capture how the process has drifted or improved, and update; documentation you maintain becomes a record of evolution you can act on.