Risks, Mitigations and Illustrative Examples: The FRC's Guidance on Generative and Agentic AI, March 2026

Guidance dated March 2026 from the UK's Financial Reporting Council, the FRC, takes up generative and agentic AI in audit. The FRC, it says, supports innovation and the appropriate use of artificial intelligence "to promote high audit quality, growth in the UK economy and the public interest." But these technologies, it says, "pose risks to audit quality too." The guidance is aimed at the central technical teams within audit firms "who are responsible for the development of generative and/or agentic AI tools and supporting methodology."

Agentic AI systems, in its definition, "can orchestrate and execute multiple components and/or tasks toward a goal, with some degree of autonomy." A human in the loop is "a human who directs, authorises or reviews the system's actions or outputs at runtime."

Parts of the guidance follow, not the whole.

Risks to Audit Quality

The guidance limits its attention "to risks to audit quality on engagements where it is deployed." Those risks, it says, fall into three categories: that the output of the AI tool is deficient; that the output "is misused, despite the output itself being appropriate"; and that the firm's methodology permits approaches, which include the use of the AI tool, that "fail to meet auditing standards, even where the output of the tool is appropriate and is used as specified in the methodology."

It sorts the deficiencies in the output of large language models, LLMs, into five categories: hallucinations, "information that has been fabricated by the LLM"; omissions; distortions; faulty reasoning; and inconsistencies. These, it says, "ultimately arise due to four fundamental limitations of LLMs, as well as the finite compute they can access."

In an agentic system, an LLM may act as the orchestrator, whose responsibilities may include interpreting the system's goal, designing a work program to achieve it and integrating the outputs of other components. How much autonomy to grant it, the guidance says, "is a complex strategic decision for the system designers," and more autonomy "often results in greater flexibility for the system, but may carry greater risk." In integrating outputs, the LLM "may invent conclusions and attribute them to component outputs."

An output can also be sound and still be misused. One example the guidance gives is an auditor who "may not understand that the output of an AI-enabled risk assessment tool was intended to inform their judgement rather than being itself a conclusion."

Mitigations

The ways the guidance sets out to mitigate the risk of deficient output include designing the system for its intended use, "a robust certification process," educating staff and governing their use of the tool, and human review and oversight. How much confidence in the quality of output it is appropriate to obtain is, it says, "a matter of professional judgement for each use case."

Where an AI-enabled procedure, presuming no deficiencies in its output, may reduce audit risk by significantly more than the alternatives, the guidance says it may be appropriate to tolerate a higher risk of deficient outputs from the AI tool, "if the expected audit risk as a result is nevertheless lower than if alternative procedures were performed."

That trade rests on the word "expected". A tool accepted for a lower expected audit risk can still be wrong on the engagement in hand.

To be effective at mitigating risk, it says, reviews "should be performed by appropriate staff and comprise appropriate activities." The reviewer "should apply professional scepticism," along with knowledge of the main risks of output deficiency for the tool and use case, "and be aware of the risk of automation bias." On training, it says that if the tool is known "to sound confident even when it is wrong," it is important that staff know it and "apply appropriate professional scepticism."

Testing the outputs may carry greater weight in certifying these tools than in some other tool certification processes, the guidance says, "due to the potential limitations around evaluating the inputs to LLMs, and their internal logic." An LLM's training data is usually not available to the audit firm, because LLMs are usually obtained from third-party providers, "who may not share this information." This, it says, does not inherently preclude the use of LLMs, but may have implications for the testing performed.

The Illustrative Examples

The examples, the guidance says, "portray the considerations of a hypothetical firm," and show one way these tools may be designed and implemented, "which may not be the best or only approach."

In the first, a tool summarizes an entity's board minutes for the auditor's risk assessment. It does not replace that risk assessment, the example says. Its prompts tell the LLM to "Include something in the summary only if it is a summary of something in the board minutes," and to cite the material each part of the summary is based on. The methodology requires the auditor "to review the output of the tool and corroborate its completeness and accuracy by reading the board minutes themselves." A more complex system might in theory have allowed a scaled-back review, the example says, but it was determined that there was "significant uncertainty over whether this consistency of quality could be achieved with current models."

In the second, a tool selects for testing a sample of what the example calls higher risk contracts, those with a greater risk of revenue being misstated due to revenue recognition issues. The tool "exhibits some agentic behaviour," the example says, but "the agency is bounded within an entirely human-designed workflow." The audit team reviews whether the output is consistent with its understanding of the entity, and the tool may escalate issues to a human, but by default "there is no contract-by-contract review of the output by a human." Auditors "must remain alert" when substantively testing the higher-risk contracts for signs that there may be greater than expected risk in contracts "not identified as higher risk."

The contracts the tool leaves out of the sample are where a mistake can pass unseen.

Of its examples, the guidance says that they "do not include every relevant risk and mitigation that a firm may or should consider or implement in a real deployment."