The FRC's Generative and Agentic AI Guidance: Risks, Mitigations and What It Doesn't Say

The FRC published 60 pages of guidance on generative and agentic AI in audit in March 2026, and the most useful thing to understand about it is how little of it is a requirement. The word "requires" appears five times in the whole document, and never once as an FRC requirement on firms. It identifies risks, sets out mitigations, illustrates two worked examples, and leaves nature and extent to professional judgement throughout.

That matters because the guidance is frequently summarised as though it imposed obligations. It does not. The requirements against which firms are assessed remain only those in the ISQMs and ISAs (UK) — the FRC says so itself.

Who it is actually for

Not engagement teams. The guidance names its audience as "the central technical teams within audit firms who are responsible for the development of generative and/or agentic AI tools and supporting methodology". The companion factsheet goes further and states that audit engagement teams, audit committees and third-party technology providers are not the primary audiences.

If you are an engagement partner looking for a checklist, this is the wrong document. It is a design-and-certification document for the people building the tools.

It was developed through the FRC's technology working group, which includes representatives from eight audit firms — worth knowing when you weigh how closely it reflects current firm practice.

How it is structured

Four sections: Introduction, including definitions; Risks; Mitigations; and Illustrative examples. Risks and Mitigations subdivide along the same categories, so the two halves map onto each other.

The risk taxonomy decomposes as a tree. The risk of deficient output splits into system performance risk — further divided into generative AI component performance risk, other component performance risk, and combination risk — and runtime system input risk, divided into human in the loop input risk and information quality risk.

That combination risk category is the one most often missed in firms' own risk registers: the possibility that individually sound components produce a deficient result when chained together.

The four mitigation categories

These lead, in the FRC's own diagram, to "appropriate confidence in quality of output":

• System design and development
• Certification
• Staff education and governance
• Human in the loop review and oversight

Use those labels exactly. The guidance does not call this a "framework" — that word comes from the FRC's announcement, not the document.

The caption beneath the diagram carries the whole philosophy: "Nature and extent of activities in each category is a matter of professional judgement."

Two principles make the categories interlock rather than stack. First, they trade off against each other: if a tool consistently produces high quality outputs in testing, and staff are trained to use it appropriately, it may be appropriate for review activities to be less extensive. Second, performing some mitigating activities from each category may be appropriate for all tools and use cases — so none of the four is optional in principle, even where its weight is light.

The passage on risk appetite

One sentence deserves more attention than it has had. The guidance says that where an AI procedure may reduce audit risk by a significantly greater amount than the alternatives, it may be appropriate to tolerate a higher risk of deficient outputs from the AI tool.

That is a genuine statement of risk appetite, and it cuts against the instinct to demand near-perfection from AI tools. It is also consistent with the certification section's acknowledgement, in the first worked example, that "perfect accuracy in these tests is not required for the tool to be certified."

Agentic AI, treated as different in kind

Agentic systems are defined as those that "orchestrate and execute multiple components and/or tasks toward a goal, with some degree of autonomy", with the distinguishing feature being that "the system has the agency to pursue a goal independently across multiple steps" without step-by-step human instruction.

Rather than a separate chapter, agentic material is woven in and flagged where it applies. The agentic-only content is worth knowing:

• The orchestrator role. The guidance identifies six roles a language model can play — researcher, reasoner, writer, summariser, critic and orchestrator — with the orchestrator role found only in agentic systems. Its responsibilities are goal interpretation, work programme design, integrating outputs, and managing iteration and feedback logic, each mapped to an indicative deficiency and system risk.
• The autonomy trade-off, stated plainly: increased autonomy for the orchestrator often results in greater flexibility for the system, but may carry greater risk.
• The workflow engine as an especially important component, because it coordinates everything else.
• Control point decisions, which the guidance says are only relevant for agentic systems.
• Oversight as distinct from review — covering intermediary outputs, authorising continuation, and choosing next actions, rather than evaluating a finished product.

That last distinction is the practical heart of it. Reviewing a generative output is a retrospective act. Overseeing an agentic process means intervening while it runs.

The two worked examples

There are exactly two, both framed as a hypothetical firm's considerations which "may not be the best or only approach".

Summarising board minutes

Used to enhance rather than replace risk assessment. Three risks: the tool omits information, distorts it, or hallucinates. The mitigations are specific enough to be instructive — minutes segmented and indexed with stable identifiers so the tool can cite sources; summarisation split into three separately prompted steps, per meeting then whole period then synthesis, to distribute cognitive load; a model chosen for domain expertise, reliability and context window; and prompts instructing the model to err on the side of inclusion where relevance is uncertain, to include something only if it summarises something in the minutes, and to cite via the identifiers.

On review, the hypothetical firm's methodology requires the auditor to read the board minutes themselves and corroborate completeness and accuracy, with more detailed review where output conflicts with prior understanding or affects risk assessment. Note the framing: that is one firm's choice, illustrated, not an FRC rule. The named misuse risk is auditors treating the output as a complete summary of the period.

Contract review for revenue recognition

The tool selects a risk-based sample; it does not test it. Contracts are chunked and indexed, a language model extracts specified content, unambiguous indicators such as bonuses, contingent payments, refunds or contract length are recorded directly, and judgemental indicators — whether performance obligations are distinct, whether control transfers over time, whether variable consideration is constrained — are evaluated with a bespoke prompt each. A computation component scores the risk and contracts above a threshold form the sample.

Four risks are numbered: the extraction prompt specification is not fit for purpose; the model fails to extract all and only the specified content; it misevaluates what it extracted; or the weighting and threshold are inappropriate.

Review here is deliberately lighter than in the first example, and the contrast is the point. The firm's methodology does not require contract-by-contract review of the risk classification, only review of whether the output is consistent with the auditor's understanding of the entity. Oversight is dynamic instead: the model is prompted to escalate when it lacks appropriate certainty.

What the guidance does not contain

No documentation section

This surprises people. The March 2026 guidance has no documentation chapter. It defers twice to the FRC's earlier document, noting that remaining documentation is retained centrally "in line with the FRC AI in the Audit Guidance" — that is the AI in audit: illustrative example and documentation guidance of June 2025, which is not superseded. Both sit live on the same FRC page, and the division of labour is clear: 2025 covers documentation expectations plus a machine-learning example; 2026 covers risks, mitigations and confidence for generative and agentic systems specifically.

The 2025 document splits documentation into two tables. Centrally: a description of the tool and its function, when it is appropriate to use, how it was developed, why you are confident it works as intended, what training and support is available, how it is appropriately explainable, and alignment with the five government AI principles — safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. On the audit file: the description and function including version number and any configuration, data or prompts the team input; why the team considered use appropriate, including how they ensured input data was complete and accurate; evidence of approval from the relevant central function; and consideration of the outputs.

The guiding principle is a sliding scale: the more widely a tool is used across engagements, the more documentation shifts centrally; the more bespoke the tool or use case, the more sits on the audit file. And the FRC explicitly warns the other way too — there may be no requirement to document some tools on the audit file at all if it would not be needed for an experienced auditor to understand the basis for the auditor's report, because over-documentation can divert time and resource from areas where it would do more good.

Almost no standards references

The 60-page document cites exactly one provision in a footnote: ISQM (UK) 1 paragraph 14(a), in the certification section. No ISA (UK) is cited anywhere in it. The factsheet names ISQM (UK) 1 and ISA (UK) 220 without paragraph numbers. If you want a requirements map by number, it comes from the 2025 document, which cites ISQM (UK) 1 paragraphs 32(f), 32(g) and 57(c), and ISA (UK) 230.8.

On audit evidence and persuasiveness

Two passages matter for anyone arguing about whether AI output counts as evidence.

The first: where the output is to be relied upon as audit evidence, the auditor's evaluation of their confidence in its quality consists of their evaluation of the quantity and quality of evidence obtained, not just its reliability. The guidance sets no threshold at which output becomes evidence.

The second is more consequential. AI procedures may produce outputs relating to entire populations rather than samples, but the insights about each individual item may be less conclusive — and it may be impossible to compare persuasiveness quantitatively. The FRC's conclusion: it is not necessary that an AI-enabled procedure's outputs exactly match the persuasiveness of the procedure it replaces, so long as the methodology does not overstate them and the overall approach meets auditing standards.

That is a meaningful licence to change method, and it sits alongside the IAASB's current consultation on the definition of audit evidence, which closes on 15 December 2026.

Review, testing and automation bias

Reviews need appropriate reviewers — competent to identify deficiencies, sometimes with specialist expertise — and appropriate activities: evaluating whether outputs are appropriate for the intended use, complete, accurate, internally consistent, and consistent with the reviewer's understanding of the entity, applying professional scepticism and awareness of automation bias. Review may involve forming an independent view to compare against some or all of the output.

Automation bias appears on the risk side too: control point decisions may be poor where the auditor does not understand the scope or purpose of the task, lacks relevant technical knowledge, or exhibits automation bias.

Testing should cover default expected use cases, edge cases, diverse cases and cases that test known potential issues, and will often be qualitative. Firms may also release to limited teams before certification, with teams often performing alternative procedures in full, in parallel.

The sandbox, and what it is not

The FRC's Audit Tech and AI Sandbox gives registered UK audit firms access to FRC expert teams through roughly three engagement meetings over three to four months. Eligibility requires a registered UK audit firm with an identified technology application, consideration of integration, compliance and relevant standards, readiness for critical evaluation or limited deployment, and a commitment of staff time. Firms of any size or specialism are welcomed.

Two limits are stated plainly. Participation "will not result in any approval, endorsement or compliance guarantees", and it will not involve detailed technical review of the technology. Applications for the first round opened on 4 June 2026 and closed in July 2026, with no future round date published.

How to read it, in one line each

• It identifies three risk categories, sets out four mitigation categories, illustrates two approaches, and leaves nature and extent to professional judgement.
• Anything phrased as "the firm methodology requires" is a hypothetical firm's choice, not an FRC rule.
• Documentation expectations live in the June 2025 document, which is still current.
• The guidance addresses your own use of AI, not how to audit a client that uses it — and nobody has published guidance on the latter.
• Deficient-output risk cannot be eliminated, because language models have inherent limitations. The factsheet says so.

For firms building competence rather than tools, the transferable skill is the same one the audit committee oversight literature keeps landing on: documented judgement about a system's limitations, rather than confidence in its outputs. The scepticism requirement does not soften because the output looks polished, and internal audit is reaching the same conclusion from a different direction.