FRC AI audit guidance: documenting AI tools, centrally and on the audit file

The FRC's AI audit guidance comes in two documents. The FRC says its June 2025 documentation guidance is not prescriptive and adds no new regulatory requirements, and that firms are assessed only against the ISQMs and ISAs (UK); it describes its March 2026 guidance on generative and agentic AI as codifying good practice, leaving the auditor's accountability unchanged. What the guidance gives any firm using AI in audit in the UK is a way to split the record of a tool in two. The firm documents once, centrally, what the tool is, how it was developed or obtained, why the firm is confident it works and how teams are trained to use it. Each audit file documents how the tool was used on that engagement. The more widely a tool is used across engagements, the more of the record sits centrally; the more bespoke the tool or the use, the more sits on the file.

This guide reads the FRC's two publications for documentation, works one invented tool through both columns, and covers what a firm that buys its tools can and cannot get from the vendor. For the rest of the standards set, see the guide to UK auditing standards.

What the FRC's AI audit guidance is, and is it mandatory?

No. The FRC says its 2025 material "is not prescriptive, and the requirements against which firms will be assessed remain only those in the ISQMs and ISAs (UK)", and that it "does not introduce new regulatory requirements". It explains what proportionate documentation of an AI tool looks like under standards that already apply.

The 2026 guidance has no statement in those terms. The FRC describes it as codifying good practice, "not a response to identified quality deficiencies", and says the human auditor is always accountable and "this guidance does not alter that position". Its text is framed largely as what a firm may do.

There are two documents:

• AI in audit: Illustrative example and documentation guidance, published on 26 June 2025. The FRC's first guidance on AI in audit, developed with its Technology Working Group and published alongside a thematic review of how the six largest firms certify automated tools and techniques. It has two parts: an illustrative example of an AI-enabled tool used to test journals, and guidance on documenting tools that use AI. Its scope "comprises both traditional machine learning techniques and deep learning models, including generative AI".
• Generative and Agentic AI Guidance, published on 30 March 2026, the FRC's second, on risks to audit quality and their mitigation (summarised below).

The 2025 guidance cites ISQM (UK) 1 paragraphs 32(f) and (g), the quality objectives for technological and intellectual resources, and 57(c), documentation evidencing the firm's responses; for the file, ISA (UK) 230 paragraph 8.

Responsibility does not move. The FRC's 2026 factsheet says: "The firm and engagement partner retain full responsibility for audit quality, in accordance with ISQM (UK) 1 and ISA (UK) 220 respectively."

Read the PDFs. The FRC's HTML versions of both documents carry its own warning that they were converted using an AI tool and that "No human verification has been conducted of the converted content".

Which tools the guidance covers: ATTs and other tools that use AI

Both kinds of tool are covered. An automated tool or technique (ATT) is "technology used to perform audit procedures". The guidance also covers "other tools that use AI that may be deployed on an engagement", and gives three examples: tools that create first drafts of workpapers, tools that review work to identify omissions or inconsistencies, and chatbots that answer the team's questions about the firm's methodology.

Built or bought, "The overarching principles in either case are the same", though a vendor may not supply everything a builder would hold; the FRC's central-documentation table has a column for that case. ATTs used on component audits can also need documentation on the file.

The label matters less than the facts. A tool that uses a large language model to research an aspect of the audited entity's environment, as part of risk assessment, is "arguably an ATT". But if every output is checked back to the cited sources, "it may well be appropriate to document less about the tool than this guidance would suggest, as the corroboration limits the relevance of the fact that an AI-enabled tool has been used." For the uses themselves, see how auditors use AI.

What the 2025 documentation guidance expects firms to record centrally

The 2025 documentation guidance lists seven topics the firm documents centrally, for ATTs and other tools alike, with a column for bought-in tools. The "black box" nature of many models, the FRC says, makes records of governance, development and explainability more important. The FRC heads its list "key material to be documented" (on PDF page 13, "where applicable"); the table paraphrases it (PDF pages 13 to 15).

Two definitions do much of the work. Explainability, in the FRC's words, is "a measure of the extent to which the behaviour or decisions of a tool can be understood, rather than the extent to which the inner mechanics and processing of the model are transparent and understandable to humans"; approximate or after-the-event explanations of how inputs influence outputs may be appropriate, particularly for tools that rely on neural networks. The five principles come from the government's 2023 white paper A pro-innovation approach to AI regulation, which said they would be issued on a non-statutory basis: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; contestability and redress. For common and good practice on description, certification and training, the guidance points to the FRC's thematic review.

What goes on the audit file

Under the 2025 documentation guidance, an ATT that uses AI needs documentation on the file under ISA (UK) 230, but not everything the firm holds about it. The test is paragraph 8: enough for "an experienced auditor, having no previous connection with the audit, to understand" what was done, what it found and the significant matters and judgements.

For an ATT that uses AI

The FRC lists what it "may be appropriate to document" on the file under four topics:

1. What was used, and for what. A brief description and objective; the tool and model version, cross-referenced to the central list of approved versions (or, where a control allows only the latest approved version, that control documented centrally instead); any configuration by the team; and the data or prompts put in.
2. Why its use was appropriate. The assessment against the central criteria, any consultation, and how the team made sure the input data was complete and accurate.
3. Approval. Evidence the central function approved the tool for the engagement, which can be held centrally for a tool approved for every engagement.
4. How the outputs were used. How they led to a judgement or further procedures; for several runs, the team judges whether to document each or the final one only.

The guiding principle, quoted in full: "the more widely used a tool is across engagements, the more we would expect to see the balance shift toward central documentation, and the more bespoke a tool or use case, the more we might expect to see on the audit file".

For other tools that use AI

For a drafting tool or a methodology chatbot, "There may be no requirement to document the use of these tools on the audit file, if it would not be required for an experienced auditor to understand the basis for the auditor's report, or significant matters arising during the audit." The team may still record it for a reviewer.

The FRC warns that "over-documentation can divert time and resource from areas where they can better enhance audit quality." The general rules of ISA 230 audit documentation still apply to everything else on the file.

Worked example: one journal-risk tool, documented centrally and on the file

This example is invented. Firm X is an imaginary small audit firm and Tool J an imaginary journal-risk tool it buys from a vendor; neither is a real firm or product. Tool J is modelled on the FRC's illustrative example: an AI model that flags journals unusual relative to the population, combined with rules-based routines in one tool, and locked in the audit software to the latest approved version; like the deep-learning option in the FRC's example, its model is frozen before deployment. Its use is mandated where the ledger data is good enough and the risk of material misstatement due to fraud has not already been reduced to an acceptably low level by other procedures. Unlike the FRC's firm, Firm X bought the tool, which the FRC's thematic review says is more likely outside the largest firms. The weights and the "high risk" threshold, which the FRC calls matters of significant professional judgement, sit in Firm X's central record, not in this table. The cells are Firm X's choices, made to illustrate the FRC's topics; they are not FRC requirements.

The file note matters most when the tool's output points the wrong way. In the FRC's example, journals were flagged because their values were unusual for their description and posting time. The values were correct, which suggested the unflagged journals with that description, posted at similar times, might be the riskier ones. The team examined them, found the descriptions recorded incorrectly but the transactions genuine, concluded that none of the high-risk journals, including the extra ones, was fraudulent, and documented why the description problem was contained. Firm X's note would record the same: what was flagged, why the team distrusted the pattern, the extra journals examined, and why the error went no further.

If you bought the tool: what a smaller firm can and cannot get from a vendor

The FRC accepts that a buyer may not be able to get the full development history, all the governance and certification information (including on testing), or all the design detail behind explainability. It still expects to see the four items in the development row of the table above. Where testing information is unavailable, the firm may choose to rely on independent assurance that the tool operates as intended, and for a tool updated continuously without version numbers, the firm documents how it makes sure the tool stays appropriate. The 2026 guidance adds, for tools built on large language models:

• Training data. It is "usually not possible for the audit firm to obtain, and therefore evaluate" an LLM's training data. "This does not inherently preclude the use of LLMs, but may have implications for the nature and extent of testing performed in the certification process."
• Component logic. A vendor's internal logic may be unavailable; if no assurance is either, that does not in itself rule the component out, but it can change the testing.
• The firm's own testing. Even where third-party assurance is obtained, "the firm may perform its own testing on the performance of the component or tool in the context of the relevant use case."

ICAEW staff have warned that such assurance may be hard to find. In ICAEW Insights in July 2025, Esther Mallowah, ICAEW's Head of Tech Policy, said getting it could be challenging in a relatively nascent sector: in her view, firms "would need to be sure that any assurance they obtain over an AI model covers the relevant risks", and many build on foundation models "for which access to information about their development and testing is limited, and independent assurance reports are not yet available". In May 2026 Ian Pay, ICAEW's Head of Data Analytics and Tech, said the 2026 guidance "talks a lot about firms having teams of technology and methodology specialists", which smaller firms will not have; in his view they "will also be leaning heavily on third-party technology and methodology providers. That's where the guidance doesn't go into enough detail."

Buying does not transfer responsibility. ISQM (UK) 1 paragraph 32(h) requires resources from service providers to be appropriate for use, and its application material gives "A commercial IT application used to perform audit engagements" as an example and says "the firm remains responsible for its system of quality management". So the evaluation is also a question about ISQM 1 service providers.

Questions for the vendor, drawn from that column: how use of the tool meets auditing and ethical standards; how any use of data to train or test it is permitted by law, regulation and professional standards, and whether an independent assurance opinion covers that; which versions are supported, and if, how and when the tool will be updated; what independent assurance exists that it operates as intended, or on the five principles (such as resilience to cyber attacks), and what that assurance covers; what training and guidance material it supplies; and what it can disclose about how the tool is designed to be explainable. Where the vendor cannot answer, the FRC's column points to independent assurance or, for explainability, the firm's own judgement on the information it can get; the 2026 guidance adds that the firm may do its own testing in its use case.

If you are considering AI on your audit files, partner with Innate: the platform takes the hours out of the legwork, your team reviews and judges, and your firm remains the auditor and signs.

Using AI in audit in the UK since March 2026: what the second FRC guidance adds

For firms using AI in audit in the UK, where the 2025 guidance covers how to document a tool that uses AI, the FRC guidance on generative and agentic AI (30 March 2026) covers the risks to audit quality and their mitigation. It is, the FRC says, the first such guidance from any audit regulator globally, and not a response to identified quality deficiencies. It was developed in the FRC's technology working group, which includes representatives from eight audit firms, for the central teams that build these tools and their methodology; engagement teams and technology providers are "not the primary audiences". It defines agentic AI as systems that "can orchestrate and execute multiple components and/or tasks toward a goal, with some degree of autonomy".

It sorts the risks into three categories:

• deficient output: the tool's output is deficient;
• misuse of output: an appropriate output is misused or misinterpreted;
• non-compliant methodology: the methodology permits an approach using the tool that fails to meet auditing standards, even where the output is appropriate and used as specified.

It groups mitigations into four categories: system design and development; certification; staff education and governance; and human in the loop review and oversight. The nature and extent of work in each is "a matter of professional judgement". The guidance presumes the unit of certification is "an AI tool in the context of a use case".

For documentation it builds on 2025. In both illustrative examples the hypothetical firm's auditor documents on the file: for a board-minutes summariser, that the tool was used and how its output informed further work and conclusions; for a contract review tool, the assessment against the criteria for use, the contracts selected, their risk indicators and the testing. In both, "The remaining documentation in relation to this tool is retained centrally, in line with the FRC AI in the Audit Guidance." Its points on certifying LLM-based tools are under bought-in tools, above.

What inspectors and reviewers will look for

ISQM (UK) 1 monitoring reaches technological resources. The thematic review the FRC published alongside AI in audit in June 2025, covering the six largest firms, shows where they were. Monitoring "was generally restricted to a sub-set of more widely used ATTs", mainly to count how many teams used them, "typically for licensing purposes". There was "no formal monitoring performed by the firms to quantify the audit quality impact of using ATTs", and generally no key performance indicators, though one firm reported usage against targets. The FRC's observations "do not represent an expected set of processes or controls", but it encouraged firms "to establish policies or metrics to support the continuous and consistent evaluation of how ATTs impact audit quality", and a smaller firm's evaluation can say, in proportion, how it knows a tool helps. That belongs in the ISQM 1 annual evaluation; the file notes above are what a cold file review would find on the file.

The FRC's Innovation and Improvement Hub launched on 15 September 2025, with AI and the future of audit an early priority. Its Audit Tech & AI Sandbox opened for applications on 4 June 2026, "Open to audit firms of all sizes across the UK market"; the FRC says its role "is not to develop or endorse specific products".

A proportionate checklist for a small firm or sole practitioner. It is our suggestion, built from the FRC's topics, not a list the FRC publishes:

• A short central record per AI tool covering the seven topics, with vendor gaps and the firm's judgement on each marked.
• Written criteria for when each tool may be used, which the file assessment refers back to.
• Version control documented once, centrally, where the software enforces it.
• Guidance for the team on reading outputs and on automation bias.
• For each ATT used, the four file topics as far as they apply: what was used, why it was appropriate, approval, and how the outputs were used.
• For drafting tools and chatbots, a file note only where the experienced-auditor test needs one.
• One line in the annual evaluation on how each tool's effect on audit quality was checked.