An audit firm can now buy an AI tool that reads every contract in a revenue sample, or flags the journals that look least like the rest of the ledger, in the time it once took to agree the sample. The harder question arrives afterwards, usually from the Head of Audit Quality: when a reviewer or an inspector opens the file, what shows that the firm knew the tool worked for this use, on this engagement, at this version? The Financial Reporting Council (FRC) has now published three pieces of material that answer that question, and none of them is written as a rule.
This guide reads the FRC's AI-in-audit material as an evidence checklist for the person who has to certify a tool before an engagement team relies on it. It covers the June 2025 AI in audit guidance on documenting tools that use AI, the June 2025 thematic review of how the six largest firms certify automated tools and techniques, and the March 2026 Generative and Agentic AI Guidance. It is written for a mid-tier firm that is more likely to buy a tool than build one. It deliberately leaves three neighbouring frames to the posts that own them: the FRC Ethical Standard and what an auditor may build for its own client sits in our Big Four AI consulting alternative guide, the human in the loop definition and the reviewer gate sit in our governed practice operations desk guide, and the market picture of audit quality and firm numbers sits in our AI for accounting firms hub.
This guide is shipped by the team behind DATS, the five-stage AI consulting system from DILR.AI that runs from Discover and Diagnose to Scale and Run. Or see our AI operating model work, which covers governance, RACI and lifecycle for AI that has to stand up to review.
What does the FRC's AI in audit guidance actually cover?
The FRC's AI in audit material is three documents, not one. The June 2025 AI in audit guidance sets out what to document for tools that use AI. The June 2025 thematic review describes how the six largest firms certify automated tools and techniques. The March 2026 Generative and Agentic AI Guidance adds the risks and mitigations specific to large language models and agents, aimed at audit firms' central technical teams.
The first document arrived on 26 June 2025, when the FRC published its first guidance on AI in audit together with the thematic review. The guidance has two parts: an illustrative example of a firm building an AI tool that scores journal entries for unusualness, and a set of documentation principles for any tool that uses AI. The example is worth reading in full, because it shows the decisions a firm actually faces, such as whether the new model replaces the existing rules-based journal tests or runs alongside them. The firm in the example kept both, because a model that only finds items unusual relative to the population can miss journals that are consistently posted to odd accounts.
The thematic review is a different kind of document. It reports what the FRC saw across BDO, Deloitte, EY, Forvis Mazars, KPMG and PwC when it asked how they certify automated tools and techniques, the tools used to perform risk assessment procedures or obtain audit evidence. Its evidence is a snapshot: the information request went out in April 2024, the FRC met the firms in summer 2024, and the report was published in June 2025. Read it as a view of mature practice two years ago, not as a description of 2026.
The third document came on 30 March 2026. The FRC describes it as the first guidance on generative and agentic AI from any audit regulator globally, and as its second piece of AI-in-audit guidance. It works through two illustrative examples, summarising board minutes and reviewing contracts for revenue recognition testing, and it is the one most relevant to a firm deploying a large language model. For a broader view of where these tools fit in a firm's plan, our enterprise AI consulting guide sets out how a programme moves from pilot to production.
Is the FRC guidance mandatory for audit firms?
No, the FRC's AI-in-audit material is guidance, not new regulation. The FRC says the June 2025 guidance is not prescriptive and adds no new requirements, that the March 2026 guidance codifies good practice, and that the thematic review's observations are not an expected set of controls. The binding duties sit in existing standards: ISQM (UK) 1 for the firm's quality management and ISA (UK) 220 for the engagement partner.
That distinction matters when a quality team writes policy. The obligation that actually bites is in ISQM (UK) 1. The thematic review cites paragraph 32(f), which requires a firm to set quality objectives so that its technological resources are appropriately obtained or developed, implemented, maintained and used to enable engagements to be performed. An AI tool that an engagement team relies on is one of those resources. The FRC guidance is the most detailed public account of what the regulator would expect that quality objective to look like for AI, which is why a sensible firm treats it as the benchmark even though it is not a rulebook.
The March 2026 announcement is equally plain about accountability. It says regulatory accountability for deploying AI tools, and for the quality of audit outputs, remains unchanged, and it points firms to their quality management obligations under ISQM (UK) 1. The Generative and Agentic AI Guidance factsheet states that the firm and the engagement partner retain full responsibility for audit quality, in accordance with ISQM (UK) 1 and ISA (UK) 220 respectively. Mark Babington, the FRC's Executive Director of Regulatory Standards, put it in one sentence when the guidance launched:
"AI is a powerful tool, but the professional judgement and accountability of the auditor remains at the core of how we regulate."
Two practical consequences follow. First, a vendor's assurance never transfers the firm's responsibility, however good the assurance is. Second, the guidance tells a firm what good evidence looks like, but deciding how much evidence a given tool needs is left, repeatedly and explicitly, to professional judgement. Our comparison of AI governance consulting options explains how to keep the people who build an AI control apart from the people who assure it.
What should a firm document centrally for an AI tool?
The FRC's June 2025 AI in audit guidance lists seven topics to document centrally for a tool that uses AI: what the tool does, when it is appropriate to use, how it was developed, why the firm is confident it works as intended, what training and guidance teams receive, how the tool is appropriately explainable, and, where not covered elsewhere, how use follows the five government AI principles.
Those seven topics are the spine of a central certification file. The table below restates them as the questions a quality reviewer would ask, alongside what the FRC says changes when the tool is bought rather than built.
| Central topic | The question it answers | Where the tool comes from a third party |
|---|---|---|
| Description and function | What does the tool do, why are we using it, and what technology sits underneath? | Same expectation as a tool built in-house |
| When it is appropriate to use | What must the input data, transaction types or entity look like for use to be valid? | Same expectation |
| How it was developed | Why was it built, which data trained or tested it, which model and why, and which versions were approved and retired? | Full history may be unavailable; the firm still needs the standards case, lawful data use and supported versions |
| Why we are confident it works | What governance surrounds it, and which certification tests did it pass? | The firm may rely on independent assurance; a tool updated continuously without version numbers needs a stated way to stay appropriate |
| Training, guidance and support | How do teams know when to use it, how to use it and how to read its outputs, including how to resist automation bias? | Same expectation; material may come from the vendor or the firm |
| How it is appropriately explainable | Can users understand why the tool produced an output, to the level the use case needs? | The firm forms its own judgement on the information it can obtain |
| The five government AI principles | Where not covered above, how does use follow safety, transparency, fairness, accountability and contestability? | Independent assurance may inform the conclusion, including on cyber resilience |
The explainability row is the one most often misread. The guidance defines explainability as how far the behaviour or decisions of a tool can be understood, not how transparent its inner workings are, and it accepts approximate or post hoc explanations for neural networks. In the illustrative example, the firm judged that users needed to know which features of a journal made it look unusual, because that told the team what follow-up work to design. That is a use-case test, not a technical one, and it is the kind of judgement that belongs in the central file in writing.
The same evidence-first thinking shapes our AI execution office, embedded delivery in which the production placements belong to the client.
What belongs on the audit file when a team uses an AI tool?
For an automated tool or technique that uses AI, the FRC's June 2025 guidance suggests four topics for the audit file: a short description of the tool, including the tool and model version and any configuration, data or prompts the team supplied; why the team judged the tool appropriate, including input completeness and accuracy; evidence that the central function approved it; and how the team used its outputs.
The guidance adds a principle that saves a great deal of argument: the more widely a tool is used across engagements, the more the documentation should sit centrally, and the more bespoke the tool or use case, the more should sit on the audit file. A firm-wide journal scoring tool is mostly a central file with a thin engagement record. A one-off routine written for a single client is mostly an engagement record.
Version control is, in our view, the easiest point for an audit file to fail. The guidance suggests recording the version number of the tool and the model so it can be cross-referenced to a central list of versions approved at the time, and it allows a firm to document centrally instead when a control prevents teams reaching anything but the latest approved version. Either works. A file that records neither does not let a reviewer establish which tool produced the evidence.
For other tools that use AI, outside the formal category of automated tools and techniques, such as a chat assistant a team uses while drafting, the guidance says there may be no requirement to document use on the audit file if an experienced auditor would not need it to understand the basis for the report. A team may still record it to help a reviewer. The line between the two categories is worth defining in the firm's own policy. At the time of the thematic review, the FRC noted that generative AI use at the largest firms was limited to assistants such as chat bots, outside the formal category, and that will not stay true as tools move into evidence gathering.
The engagement-specific end of the spectrum is where the thematic review found the most variation. Bespoke routines were mainly data analytics built in platforms such as Alteryx or in languages such as SQL, R, Python or SAS, and most firms required a template on the audit file to evidence that each one was reliable. The FRC found some templates worded as though completing them were optional, and some that did not say when they applied. Both are cheap to fix and costly to discover at inspection. Our governance framework comparison across UK sector regulators shows how other regulators phrase the same expectation.
How should a firm certify a generative or agentic AI tool?
The FRC's March 2026 guidance treats certification of a generative or agentic AI tool as three activities: evaluating the system inputs, evaluating the system architecture and component logic, and testing the outputs. It sets the unit of certification as an AI tool in the context of a use case, so the same tool used for two different audit tasks may need two certifications.
The guidance states the principle directly: "This guidance presumes the unit of certification is an AI tool in the context of a use case." That sentence changes how a firm should keep its inventory. A register that lists a model or a product name once is not enough; the register needs a row per approved use, each with its own criteria for when it applies. A broad use-case definition means fewer certifications, but the FRC notes that each one may then need more work to reach the same level of assurance.
The guidance names three kinds of system input. LLM training data is usually out of the firm's reach, because model providers rarely share it, and the FRC says this does not by itself rule a model out but may shape how much testing is needed. Prompts come from a library, from the system or from the person using the tool, and the guidance notes that prompts a human writes at runtime cannot be evaluated during certification. Information sources the system reads at runtime can be evaluated for completeness, accuracy and relevance.
Output testing carries more weight for these tools than for traditional ones, the FRC says, precisely because inputs and internal logic are hard to inspect. Its guidance lists four kinds of case to test: default expected uses, edge cases, diverse cases, and cases aimed at known weaknesses such as overconfidence or bias. Tests will often be qualitative, so the guidance suggests structured criteria for judging outputs, to reduce inconsistency between reviewers. For a multi-component agent, testing each component as well as the whole tool helps locate the weak link and decide where a human review point belongs.
This is where engineering practice and audit methodology meet. A firm that already runs an evaluation set against a fixed answer key has most of what the FRC describes; our note on evaluation harness engineering covers how such a set is built and kept current. The same testing questions arise in any production agent, which is why evaluation and observability for production agents is one of the enterprise AI solutions DILR.AI lists.
The March 2026 guidance also describes limited deployment: releasing a tool to a small number of teams before full certification. Because training, guidance and prompt libraries may not yet be settled, the FRC notes that teams in that position often perform the alternative procedures in full alongside the AI-enabled one. A pilot run in parallel is slower, but in our view the side-by-side results are useful evidence when the tool comes up for full certification.
What changes when the AI tool comes from a third-party vendor?
When an audit AI tool comes from a vendor, the FRC expects broadly the same central documentation but accepts that some of it cannot be obtained. A firm may then rely on independent assurance about the tool, while still evidencing how use meets auditing and ethical standards, why any data use is lawful, which versions are supported and how the firm keeps a continuously updated tool appropriate.
This is the situation most firms below the largest six are in. The thematic review found that the largest firms generally prefer to build tools in-house or take them from their global network, and observed that outside the largest firms it is more likely that tools are sourced from third-party vendors. The documentation tables in the June 2025 guidance carry a separate column for exactly this case, setting out what the firm still needs when a tool is obtained from a third party.
Buying changes where the evidence comes from, not whether it is needed. Three gaps are typical. The vendor will rarely disclose training data or full development history, so the firm documents what it could obtain and leans harder on its own output testing, which the March 2026 guidance says a firm may perform even when it holds third-party assurance. The vendor may update the model without a version number, so the firm needs a written method for confirming the tool is still fit for its approved uses. And the vendor's assurance report covers the vendor's controls, not the firm's use case, so the use-case criteria and the test results remain the firm's own work.
Selection is part of certification. The thematic review found that all six firms considered a vendor's control environment, data security and confidentiality when selecting a tool, using supplier questionnaires or available assurance reports. Confidentiality is a real constraint for audit data, and one option is to keep model processing inside the firm's own perimeter; our guide to private and self-hosted LLMs for regulated institutions covers that option. Where client data is personal data, the firm also has to meet its own obligations under UK GDPR, which the ICO sets out separately from anything the FRC says about audit quality.
An ISO 42001 certificate on the vendor side can help with the governance questions, but it is not a substitute for use-case testing. Our ISO 42001 procurement guide explains what that standard does and does not evidence.
When does an AI audit tool need recertifying?
The FRC's March 2026 guidance gives five reasons a firm may recertify an AI tool: updates to components or inputs that materially change performance, use on a materially different use case, observed performance issues, relevant changes to auditing standards, guidance or internal policy, and the passing of a set amount of time. It pairs recertification with ongoing monitoring of output quality and failure patterns.
The thematic review shows why the triggers need writing down. Among the six largest firms, formal recertification usually happened only when a tool changed, and the FRC found that identifying those triggers generally appeared informal, relying on tool owners to notice. It encouraged firms to build a recertification question into change management. Two firms ran an annual confirmation in which UK tool owners confirmed whether anything significant had changed, and one firm set a backstop minimum recertification frequency of three years for every tool. Those are not rules, but they are the practices the FRC chose to highlight.
Monitoring is where the review found the least formal practice. The FRC reported no formal monitoring by the firms to quantify the audit quality impact of using their tools; most monitoring counted how many teams used a tool, largely for licensing. For a generative model whose behaviour can drift with a provider update, usage counts say nothing about whether outputs are still good. The March 2026 guidance describes monitoring the quality and consistency of outputs, patterns of failure and unexpected behaviour, and how these affect audit quality.
Two other findings are worth checking against a firm's own templates. Only two of the six firms explicitly recorded a tool's limitations or restrictions of use in the certification template, and three explicitly assessed the supporting control environment, including general IT controls. A limitation that lives only in a training deck is easy to lose. Our continuous audit evidence guide shows the same principle in a quality system outside audit: evidence that accumulates as work happens holds up better than evidence assembled for the visit. An AI operating model that names an owner per tool is what makes the triggers someone's job.
What is the best way for a mid-tier audit firm to prepare its AI evidence in 2026?
For most mid-tier audit firms in 2026, the best approach is a central register with one row per tool and use case, a certification file built around the FRC's seven documentation topics, output tests designed for that use, and written recertification triggers. Firms inside a global network with mature central certification may do better adopting the network's file and adding a UK-level review.
That concession is real. The thematic review found that most of the largest firms run globally defined certification, and two required globally certified tools to have a UK owner and pass UK-level certification. The FRC called a UK-level certification, relying where sensible on global work, an effective way to evidence UK-specific points such as data confidentiality and methodology. A firm with that support should use it rather than rebuild it. A smaller independent firm buying one tool from a vendor needs less machinery, but it still needs the use-case criteria and its own tests.
The other options all have a place. Building in-house gives the most control and the most complete development history, and the review found most of the largest firms preferred it where no existing tool met the need, but it needs engineering staff a mid-tier firm may not have. Relying on a vendor's assurance alone is quick but leaves the use-case evidence missing. Bringing in an outside adviser can help with design, though a firm should check the adviser's independence first. The separate question of what an auditor may build for its own audit client is covered in our Big Four alternative guide and are not repeated here.
The FRC's own offer is narrower than it looks. On 4 June 2026 it announced an Audit Tech and AI Sandbox, open to audit firms of all sizes. Its sandbox page says first-round applications closed in July 2026, that participation involves an estimated three engagement meetings over three to four months, and that it will not result in any approval, endorsement or compliance guarantee for a firm's chosen technology. It is a place to test how standards apply, not a certification route.
A practical sequence for the next quarter follows from all of this, and it is the same sequence the DATS five-stage system applies to any AI placement: decide which uses matter, place them deliberately, write the operating model, prove each one in a pilot and then run it. Start with an inventory of every AI tool already in use, including assistants. The review found legacy automated tools in use that had never been through the formal certification process, and the same gap opens quickly for AI. Classify each as an automated tool or technique or as an other tool. Write use-case criteria for the first category, run output tests, record limitations in the template itself, and name the triggers that send a tool back for recertification. For where else AI pays inside a practice, from onboarding to the records chase, see our AI for accounting firms hub.
Frequently asked questions
Does joining the FRC Audit Tech and AI Sandbox approve an AI tool?
No, joining the FRC Audit Tech and AI Sandbox does not approve an AI tool. The FRC's sandbox page says participation will not result in any approval, endorsement or compliance guarantee for a firm's chosen technology, and that the sandbox does not involve detailed technical review. It offers structured discussion of how auditing standards and FRC guidance apply, over an estimated three meetings.
Who is accountable if an AI tool produces a wrong output on an audit?
The audit firm and the engagement partner remain accountable if an AI tool produces a wrong output on an audit. The FRC says regulatory accountability for deploying AI tools and for audit quality is unchanged, and its factsheet places responsibility on the firm under ISQM (UK) 1 and on the engagement partner under ISA (UK) 220. A vendor's assurance does not move that responsibility.
Does the FRC's generative AI guidance cover cybersecurity and data protection?
No, the FRC's Generative and Agentic AI Guidance limits its scope to risks to audit quality. Its factsheet names three such risks, misuse of output, deficient output and non-compliant methodology, and states that other risks such as cybersecurity and data risks exist but fall outside the guidance. A firm still has to manage those risks under its own security policy and data protection law.
Want to see this applied to your own tools? Read how the DATS consulting system places AI, see our approach to governed delivery, browse more industry AI guides, or talk to the DATS team about a certification file for one tool.
Put the evidence on file before the tool goes live.
30-min scoping call · No deck · Confidential. We will tell you whether DATS fits, and which AI use to document first.
Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.