PCAOB Auditing Standard No. 1215 was last meaningfully revised in 2004. The most advanced audit technology in most engagements at that time was a shared spreadsheet on a network drive. The standard's language reflects that context, but its underlying obligations do not become optional because the entity generating a workpaper is software rather than a staff auditor.
Audit teams using AI-assisted tools to analyze evidence, map controls, or draft workpaper sections frequently ask where these tools fit within the documentation requirements. The answer is both simpler and more demanding than it might appear: the standard does not prescribe how procedures must be performed, but it does prescribe what the resulting documentation must enable. Any tool that produces documentation falling short of that threshold creates compliance exposure regardless of how efficient the tool is.
This is not a fringe concern. We have looked at how several AI-assisted documentation tools produce output, and the gap between what the software writes and what AS 1215 requires is not always obvious from the interface. Understanding the mechanics of the standard is the only way to evaluate whether a tool's output is adequate.
The Core Requirement: The Experienced-Auditor Test
AS 1215 requires that audit documentation be sufficient to enable an experienced auditor with no previous connection to the engagement to understand several things: the nature, timing, and extent of audit procedures performed; the results obtained and evidence received; and the conclusions reached on significant matters, including significant findings and any information that contradicts or is inconsistent with the auditor's final conclusions.
The phrase "no previous connection to the engagement" is doing a lot of work there. It doesn't mean a colleague who reviewed the workpaper last week. It means someone picking up the file cold, without the context that existed in the performing auditor's head during fieldwork. That mental context is not part of the documentation unless it was explicitly recorded.
This is the aspect of the standard that most frequently produces inspection findings. An auditor who performed a procedure correctly but documented only their conclusion, without recording the procedure, the population, and the basis for the sample selection, has created a workpaper that would be unintelligible to anyone who wasn't in the room. The work may have been fine. The documentation fails.
What the Standard Requires the Workpaper to Capture
Working through AS 1215 in practice, the documentation that a workpaper must contain to satisfy the experienced-auditor test includes several components that are often absent or underspecified.
First, the procedure performed: not what category of procedure it was, but specifically what the auditor did. "Tested access controls" is not a procedure description. "Selected a sample of 25 user provisioning transactions from the Q3 access review log, traced each transaction to an approved HR request, and confirmed the provisioning date preceded the access grant date" is a procedure description.
Second, the population and how completeness was established. A test over a partial population that wasn't documented as partial looks like a full test to the reader. Population completeness is an independent step that has to be recorded, not inferred from the workpaper's existence.
Third, the evidence reviewed and the link between that evidence and the control being tested. The workpaper needs to make the connection explicit: this evidence supports this specific control objective within the control matrix, which maps to this financial statement assertion.
Fourth, the conclusion, including the auditor's professional judgment about any exceptions found. "No exceptions" is a valid conclusion. "Two provisioning entries lacked documented approval; both were reviewed and determined immaterial based on..." is a documented conclusion. The second one survives inspection. The first one might not, because it doesn't show that the auditor actually looked at exceptions and exercised judgment.
Where AI-Generated Workpapers Create a Documentation Gap
AI tools that analyze evidence and generate workpaper content typically produce outputs that look like conclusions. An evidence file maps to a given control objective. A transaction matches or doesn't match a defined exception pattern. An ITGC review produces a pass or fail for each tested attribute. These outputs are useful, but they have the same documentation problem that any undocumented human conclusion has: the reasoning that produced the output isn't automatically visible in the record.
Consider a scenario where an AI tool processes a population of 200 user access provisioning records, compares each record against an authorization matrix, and flags six records as exceptions. The auditor reviews the flagged items, investigates, and concludes that four are immaterial and two require remediation tracking. The conclusion is documented. What is often not documented: how the AI determined what constituted an exception, which authorization matrix version it applied, whether the 200-record population represents the complete period or a subset, and what the auditor looked at when reviewing each flagged item.
That missing context is precisely what the experienced-auditor test requires. A reviewer reading the workpaper six months later, or a PCAOB inspector two years later, cannot determine whether the procedure was adequate from the output alone. The tool performed the analysis correctly. The documentation is insufficient.
This is not a critique of AI tools specifically. A manually prepared workpaper with the same documentation gaps would fail equally. The difference is that AI tools can process larger populations faster, which means the documentation gaps can accumulate faster too if the workflow doesn't account for them.
What Adequate Documentation Looks Like for AI-Assisted Procedures
The requirements for AI-assisted work are not different from the requirements for manually performed work. They need to be applied deliberately, because AI tools don't generate compliant documentation by default unless they were designed to.
A workpaper for an AI-assisted procedure should record: the source population (where the data came from, the date range, how completeness was confirmed), the procedure the AI applied including the specific exception criteria, which control objective was being tested and its connection to the relevant assertion, the results with enough detail to understand the scope of what was reviewed, any exceptions found and the disposition of each, and the human auditor's review of the AI output with a basis for accepting or overriding it.
The review documentation is particularly important. AS 1215 does not transfer professional responsibility to software. The auditor signing the workpaper is responsible for the conclusion regardless of how it was generated. A workpaper that records "AI analysis performed, no exceptions identified" without any evidence that the auditor reviewed and evaluated the AI's output doesn't satisfy the documentation requirements, because it doesn't show that professional judgment was applied.
Even a brief review note, one that records what the auditor looked at and why the AI's output was accepted, is what separates a defensible workpaper from one that a PCAOB inspection might challenge.
Retention, Final Assembly, and Chain of Custody
PCAOB work requires retention of audit documentation for seven years from the report release date. This applies to AI-generated outputs in the same way it applies to any other workpaper document. If AI-generated analysis exists only in an external software system, the audit file must contain either the preserved output or a reliable reference to an archived version retrievable for the full retention period. An external SaaS platform that could be discontinued or that doesn't offer export functionality creates a retention gap that the auditor is responsible for closing.
Final assembly requirements also apply. Once the file is assembled, the standard restricts modifications. If an AI tool generates a revised analysis after the file has been assembled, that modification needs documentation: who made it, when, and why. This is a workflow question that should be resolved before the engagement, not discovered during file review.
A Note on What This Discussion Is Not Saying
None of this is an argument against using AI tools in PCAOB-governed engagements. The experienced-auditor test and the procedure documentation requirements apply equally to manual work. Plenty of manually prepared workpapers fail them. Inspection findings on documentation deficiencies long predate AI tools, and most of the documentation gaps described here are the same gaps that appear in manual workpapers year after year.
What this discussion is saying: evaluating an AI-assisted audit tool for PCAOB compliance requires looking at what the tool produces, not just what it can do. A tool that processes evidence efficiently but produces output that doesn't capture the procedure, the population, or the review rationale creates more work for the auditor, not less, because the documentation gap has to be filled manually after the fact.
The tools that fit well in PCAOB contexts are the ones that surface their reasoning alongside their conclusions. When the AI maps a piece of evidence to a control objective, the workpaper shows which attributes of the evidence triggered the mapping and which control definition was applied. The auditor can review that reasoning, accept or override it, and sign the workpaper knowing that a reviewer reading it cold will be able to follow the logic. That's not a compliance premium. That's what makes the tool useful rather than just fast.