By Donal Kerr, CEO, Run Audit

In Part 1 of this series, I walked through the Financial Reporting Council’s landmark guidance on generative and agentic AI in audit — the first document of its kind from any audit regulator globally. The core message was straightforward: AI can enhance audit quality significantly, but the accountability stays with people. The technology changes. The regulatory framework does not.

Now I want to be concrete about what that means in practice. Because the FRC’s guidance isn’t abstract — it’s a framework of specific risks and specific mitigations. And if you’re building an AI tool for use on audit engagements, every design decision you make either aligns with that framework or it doesn’t.

Here’s how Run Audit was built, and why every major design principle maps directly to what the FRC requires.

The Problem We Set Out to Solve

IT auditors and GRC practitioners — the people we built Run Audit for — are losing a staggering proportion of their week to work that doesn’t require their expertise. The evidence ingestion. The manual cross-referencing of policy documents against control frameworks. The gap analysis spread across multiple spreadsheets, duplicated for each regulatory framework in scope. We’ve seen practitioners spending forty to sixty percent of an engagement on tasks that require no professional judgement whatsoever.

That’s not where their expertise lives. It’s just where their time goes.

The insight driving Run Audit is straightforward: automating the repetitive parts of audit is not the same as automating the audit itself. Automating the former is entirely legitimate — it’s what releases the practitioner to do the work that actually requires them. Automating the latter isn’t just irresponsible; it’s precisely the failure mode the FRC has been at pains to describe. The auditor who lets an LLM generate their conclusions hasn’t automated their workflow. They’ve abolished their professional judgement.

Automate the grind. Preserve the judgement. That’s not a marketing line. It’s a system design principle. And as it happens, the FRC’s guidance is a precise description of what it requires technically.

How Run Audit Addresses the FRC’s Three Risk Categories

The FRC identifies three categories of risk from AI in audit: deficient output, misuse of output, and non-compliant methodology. Here’s how each one maps to specific design decisions in Run Audit.

Deficient output. The FRC catalogues five failure modes for LLMs: hallucinations, omissions, distortions, faulty reasoning, and inconsistencies. For a tool ingesting policy documents and mapping evidence to controls, these aren’t theoretical risks — a hallucinated control mapping that doesn’t correspond to any actual evidence, or an omitted gap that should have triggered a remediation requirement, is an audit quality failure.

Run Audit addresses this through what the FRC would recognise as a combination of system design and information quality controls. The platform doesn’t generate conclusions from thin air. It maps evidence to controls with full traceability — every mapping is linked to the source document, every gap is derived from a structured comparison between what the evidence demonstrates and what the framework requires. The auditor can see, and interrogate, every step of that reasoning. We built evidence-first because that’s the only foundation that holds. Analysis divorced from traceable evidence isn’t analysis — it’s a document that looks like analysis.

Misuse of output. The FRC describes this as the risk of misinterpretation or misunderstanding of methodology — where the output itself is sound but the human draws inappropriate conclusions from it, missing the limits of what the AI has actually done. The FRC’s recommended mitigation is explicit: build systems where outputs explain themselves, showing the chain of thought that led to the output, including references to the information considered.

That’s exactly how Run Audit reports work. The output isn’t a verdict. It’s a structured presentation of what was found and where, grounded in evidence the auditor can verify. The auditor’s role isn’t to countersign a report that was generated before they arrived. It’s to review the working, challenge the mappings, and draw their own conclusions — with the full reasoning visible beneath them. The AI has done the search and the mapping. The professional judgement is entirely theirs.

Non-compliant methodology. The FRC notes that AI-enabled procedures may produce outputs relating to entire populations rather than samples, making direct comparison with traditional audit procedures difficult. This is directly relevant to Run Audit’s multi-framework capability, where a single evidence base is mapped across DORA, ISO 27001, NIS2, and SOC 2 simultaneously. The question of what conclusions can be appropriately drawn from those outputs — and how that methodology meets auditing standards — is one we’ve built into the platform structurally. The tool presents findings. The professional draws conclusions. Those are not the same thing, and the boundary between them is enforced by design, not just recommended in a manual.

The Human in the Loop Is the Point, Not a Feature

The FRC’s guidance defines a human in the loop as someone who “directs, authorises or reviews the system’s actions or outputs at runtime.” That definition is doing a lot of work. It means the human isn’t just present — they’re active. They’re not signing off on a black box. They’re reviewing outputs, interrogating reasoning, and bringing their professional judgement to bear on what the system has produced.

This is the principle that distinguishes legitimate AI-enabled audit tooling from what one recent industry scandal illustrated so vividly: the generation of hundreds of near-identical reports across different clients, with different logos, before anyone had actually looked at the organisations in question. What the FRC calls misuse of output — and what I’d call the industrialisation of compliance theatre — is the predictable result of removing the human in the loop from anything but the most nominal role.

Every design decision in Run Audit is built around keeping that role substantive. A practitioner uploads the organisation’s policy documents, system architecture diagrams, and prior audit reports. Run Audit maps the real evidence to the relevant controls across every applicable framework — automatically, accurately, and with full traceability. What used to take four to six weeks of manual document review happens in a fraction of that time. The auditor then does what only a qualified auditor can do: review, interpret, challenge, and conclude.

The output is faster. The margins are better. The professional judgement is entirely intact.

Validation Before Marketing

One of the things the FRC’s guidance emphasises is the certification process — ensuring that AI tools are working as intended before they’re deployed on engagements, through evaluation of system inputs, architecture, and outputs. We applied a version of this principle to ourselves before we made any public claims about what Run Audit could do.

We validated our approach with the CISO at FEXCO — one of Ireland’s largest financial services firms — before we wrote a line of marketing copy. Not as a pilot deployment. As a reality check. The claim that Run Audit significantly compresses evidence review and control mapping while maintaining full traceability and keeping the auditor’s judgement central — that claim had to be real before we could make it.

In a market where the plausibility of “AI-generated compliance” has been severely tested, the value of making claims you can actually substantiate has never been higher. The FRC’s guidance is, among other things, a framework for holding AI vendors in the audit space to that standard. We welcome that. The bar it sets is one Run Audit was designed to clear.

What This Looks Like in Practice

A mid-market financial services firm in scope for DORA, ISO 27001, and NIS2 simultaneously doesn’t have three separate compliance problems. It has one underlying reality — the state of its security controls — that three frameworks are asking it to evidence and report in three different ways. The way the industry has typically responded to that — separate workstreams, separate evidence gathering, separate consultants — is one of the most expensive and avoidable inefficiencies in corporate compliance.

Run Audit ingests the evidence once. It maps it to the relevant controls across every applicable framework. It surfaces the gaps. The auditor focuses on interpretation, remediation, and the client conversation about what the findings actually mean for their risk posture. The engagement runs faster, the output is more consistent, and the practitioner has done the work that actually requires their expertise.

That’s what the FRC’s guidance is pointing toward. Not AI that replaces the auditor. AI that gives the auditor their time back — and in doing so, makes the profession more sustainable, more attractive to the next generation of practitioners, and more capable of meeting the growing demand for rigorous, independent audit work.

The rulebook has been written. We built Run Audit to operate within it.

If you’re evaluating AI tools for your practice or your firm’s GRC workflow — or if you want to map Run Audit’s design against the FRC’s risk framework in more detail — I’d be glad to walk through it with you.