How to Implement Agentic AI in Audit

There's a number that gets quoted constantly: the Big Four have deployed tens of thousands of AI agents.

Look at where those agents actually sit. EY's 150 agents serving 80,000 professionals — that's tax. PwC's 25,000 agents — client operations. Deloitte's Zora — finance, HR, supply chain, procurement. These are real deployments doing real work. None of them are audit.

What's actually running in assurance is much narrower. KPMG has built agents into Clara supporting substantive procedures — expense vouching, searches for unrecorded liabilities and accrued expenses. The next tier, orchestration agents that direct other agents and select which one fits a task, was announced as a pilot for as soon as this summer, applied to asset valuations and revenue process testing. EY began embedding a multi-agent framework into Canvas in April.

Task-level agents in production. Orchestration in pilot. That's where audit is.

Audit is the slowest function in these firms to adopt agentic AI, and I'd argue that's not a lag. It's the correct response to the problem.

Which puts us somewhere unusual. The PCAOB is drafting its 2026–2030 framework right now — comments close September 4. Firms are drafting their implementations right now. Both are still in pencil.

That almost never happens. Usually the technology lands, the damage surfaces, and the regulator responds. This time we can design against the standard while the standard is still being written. This is a note on how to use that window.

Why audit is different

Every other function that adopted agents optimizes for throughput. Process more invoices, resolve more tickets, draft more returns. Errors are costly but recoverable, and success is measurable in volume.

Audit doesn't produce volume. It produces an opinion — one sentence, backed by evidence, signed by a person who is personally accountable for it.

That changes the engineering problem completely. Three consequences follow, and they drive everything below.

An agent's output is a procedure, not evidence. If an agent extracts terms from 400 lease contracts, the contracts are the evidence. The extraction is a procedure whose reliability has to be established independently, the way you'd establish the reliability of any instrument you rely on. Most implementation plans skip this and treat agent output as a work product to be reviewed. It isn't. It's a measurement to be validated.

Re-performance is the load-bearing wall. Deterministic tooling gives the same answer twice. That's how a manager checks a senior, how an EQR checks a partner, how an inspector checks a firm. Agents choose their own path and may reach a defensible but different conclusion on a second run. Nothing in the standards contemplates that.

Model error is correlated, not random. More on this below, but it's the one that should change how you scope.

How to implement: four tiers, with gates

The single most common implementation mistake is starting with the impressive use case. Start instead where failure is cheap and build the governance muscle before you need it.

Tier 0 — Non-evidentiary work

Engagement administration. Prior-year workpaper comparison. Standards research with citation retrieval. Disclosure checklist completion against a filing. Draft memo assembly from conclusions a human already reached.

Nothing here produces evidence. Failures are visible and cheap. This is where you learn what your people do with fluent output — which is the real thing you're testing.

Gate to advance: you have an agent inventory, a named owner for each agent, and documented evidence that reviewers are actually catching planted errors rather than waving output through.

Tier 1 — Evidence gathering under human-defined populations

Journal entry extraction and risk scoring. Contract and lease term abstraction. Confirmation orchestration and exception tracking. ITGC evidence collection.

The agent gathers and structures. A human defines the population, sets the procedure, and concludes. This is where KPMG's deployed Clara agents sit, and it's the right place to spend the next two years.

Gate to advance: stratified validation against human-adjudicated ground truth, with precision and recall reported separately, and a documented trace that an experienced auditor with no prior connection could follow.

Tier 2 — Multi-step procedures with orchestration

The agent runs a sequence: identify what requires testing, ingest source documentation, extract, generate the workpaper, execute the test. This is what KPMG is piloting this summer.

The autonomy jump here is bigger than it looks. When an agent selects which agent handles a step, the procedure design is partly the agent's. That crosses a line AS 2301 cares about.

Gate to advance: demonstrated bounded variance across repeated runs, escalation triggers that fire reliably, and a trace that survives an EQR who is actively trying to break it.

Tier 3 — Judgment

Sufficiency. Materiality. Scope. Fraud risk conclusions. Going concern. Estimate reasonableness.

There is no gate. The standards reserve these to the auditor. Agents can inform them; they cannot conclude on them. Build the escalation architecture that makes this boundary enforceable rather than aspirational — because under time pressure, aspirational boundaries move.

Six design rules that apply at every tier

1. Build the quality control layer before the first engagement use.

This is the instruction I'd most want firms to act on, and it comes straight from where the regulator is heading.

Jeffrey Johanns of UT Austin recently published a reading of the new PCAOB Board's first four months, arguing that its three requests for comment — March, June, July — triangulate rather than stand alone. He identifies Goal 2, modernizing inspections, as the most disruptive of the six. The Board has said it intends to inspect firms' quality control systems, supplemented by individual engagement reviews. That inverts the historical emphasis.

For agentic AI that changes the question entirely. Engagement-focused inspection asks: did this team use the tool appropriately here? The answer lives in a workpaper. Quality-control-focused inspection asks: how does the firm decide an agent is fit for audit use, who approves it, how is it monitored across engagements, what happens when the model version changes underneath you, where's the inventory?

Those answers live in a control system or they don't exist. And QC 1000, which would house them, has just been reopened for narrow revisions.

Agent governance is a QC 1000 problem before it is an engagement problem. Build there first.

2. Design for reproducibility from day one.

Retrofitting traceability is brutal and usually incomplete. Decide up front between two honest postures: pin everything — model version, temperature, tool sequence, retrieval index — and define re-performance as replaying the trace. Or accept path variation, run procedures repeatedly during validation, document observed variance in conclusions, and set a tolerance.

Capture model version, inputs, tool calls, sources retrieved, intermediate steps, and every human intervention. AS 1215 asks whether an experienced auditor with no previous connection can understand the work, the evidence, and the conclusions. A prompt and an output do not meet that bar.

3. Define populations deterministically. Always.

Retrieval systems have recall limits. An agent asked to find all contracts with variable consideration may analyze what it retrieved beautifully while silently missing 3% of the population — a sampling error you never designed, can't quantify, and won't see.

Extract from the system of record. Reconcile counts and control totals. Then let the agent work inside boundaries a human established and tied out. Population definition is never a semantic operation.

4. Validate as an instrument, not a benchmark.

Vendor accuracy figures are close to useless here, because model error is correlated and semantic. An agent that misreads a particular clause construction misreads it the same way across the entire population. That's systematic misstatement risk wearing the costume of comprehensive coverage.

Which produces something counterintuitive, and I'd welcome disagreement on it: testing 100% of a population with a biased instrument is not obviously safer than testing a sample with an unbiased one.

Full-population analytics have been sold for a decade on coverage-equals-assurance. KPMG's pilot results reportedly had teams analyzing 100% of revenue and expense line items against a typical 5–10% sample, and surfaced duplicate-invoice schemes missed in prior cycles. That's a genuine win. But the assurance from full coverage depends entirely on whether the instrument's error structure has been characterized — and a sample tested by an unbiased method has properties that permit extrapolation, which a biased full-population scan does not.

So: validate stratified. By transaction type, contract form, jurisdiction, entity, edge case. That's where correlated error hides. Report precision and recall separately, because in audit the missed item is usually the more dangerous error and a blended number buries it. Set thresholds before testing, not after.

5. Architect skepticism against the model's grain.

Language models are optimized to be helpful and agreeable. Ask one whether the evidence supports management's position and the gradient runs toward yes.

The default disposition of the tool is the inverse of the disposition AS 1015 requires of the auditor. That's an architecture problem, not a training problem.

Withhold management's conclusion and ask what the evidence supports on its own. Require the agent to build the strongest case against the assertion before evaluating it. Run challenge agents with no visibility into the first agent's reasoning. AS 1105 defines evidence to include information that contradicts management's assertions — make that an explicit logged step rather than something you hope emerges. And require the agent to report what it couldn't determine. An agent that never says "insufficient information" isn't being careful. It's being fluent.

6. Instrument the human, not just the agent.

The failure mode most likely to actually cause an audit failure isn't technical. It's that reviewers reviewing fluent, well-formatted output review less carefully.

Plant errors. Measure catch rates. Track them over time. If your reviewers' catch rate is falling as agent adoption rises, you have a problem no amount of model validation will fix.

Three things to settle before any agent touches an engagement

Who is accountable by name if this agent produces a material error?

What is this agent categorically not permitted to decide?

If an inspector asked us to re-perform this procedure, what exactly would we hand them?

If those don't have crisp answers, the implementation isn't ready regardless of how well the pilot went.

What we should be asking the Board

Comments on the draft strategic plan (PCAOB Release No. 2026-006) are accepted through September 4, 2026. Data and Technology survived the new Board's clearing of the prior agenda and appears across all three RFCs — Johanns calls it probably the most requested and most needed project on the list. These are the questions it should answer:

1. Does re-performance require determinism? If an agent reaches a defensible conclusion by more than one path, what does re-performance mean and what variance is acceptable?

2. What does AS 1215 require of an agent trace — full reasoning capture, or a summary of the procedure and its basis? The cost difference between those answers is enormous.

3. Is an agent a tool, or a specialist under AS 1210? That choice determines the whole evaluation architecture. I'd argue specialist is the better fit and it isn't currently sanctioned.

4. What validation supports full-population coverage using model-based extraction, given correlated rather than random error?

5. Where in QC 1000 does agent governance live — and does the reopening for narrow revisions let us say so explicitly?

6. Should "agentic" be a defined term, distinguishing systems that choose their own procedure path from those that execute a designed one?

7. What's the auditor's responsibility when the client's agents are embedded in transaction processing or generating estimates? Johanns frames the two technology problems well: the company's use of technology, and the auditor's use of technology to audit the company's use of technology. The first may be moving faster than the second.

The window

We are early in audit. Not behind — early. The pilots are running now, the standards are being drafted now, and both are still changeable.

The firms that use this window to build the quality control layer, the validation discipline, and the trace architecture will be able to answer an inspector. The firms that wait until the technology is proven and then bolt governance onto it afterward will be doing remediation.

Underneath all of it is a question that doesn't change. The standards have always required that the auditor obtain sufficient appropriate evidence and reach a conclusion. Nothing about an agent changes who signs. It only changes how far the signer is standing from the work — and whether that distance was engineered, validated, and documented, or quietly assumed.

That distance is the whole subject.

Working in assurance, methodology, or teaching audit? The correlated-error argument in Part Two is the one I would most like challenged — it complicates a decade of full-population marketing, and I would rather be wrong in correspondence than wrong in a workpaper.

Standards references should be verified against current PCAOB text. With thanks to Jeffrey Johanns, whose piece on the three RFCs prompted this.