There is a difference between pointing at a policy on a shared drive and handing over a report that records exactly what your AI did, who checked it, and when. The first says what the firm meant to do. The second proves what the firm actually did. When the SRA asks you to show your work, only the second one answers the question.
Most firms have the first. They have an AI policy, sometimes a good one, and they assume it is the thing an inspection wants. It is not. A policy is a statement of intent, and Rule 2.2 of the SRA Code of Conduct for Firms does not ask for intent. It asks for records that demonstrate compliance. The instrument that carries those records is an audit report, and the single most important thing about it is when it was written.
This is a companion to two pieces we have already published, and it deliberately does not repeat them. The COLP's AI governance checklist covers what to do for each rule. The complete SRA AI compliance guide maps every obligation to a control. This piece is about the output those produce: what the report itself has to prove, rule by rule, and what it needs to look like.
A report is not a policy, and the difference is timing
Start with the distinction that everything else hangs on. A policy is written once, in advance, describing how things should go. A report is written continuously, as things happen, recording how they actually went. One is a promise. The other is evidence.
Rule 2.2 requires you to "keep and maintain records to demonstrate compliance." The operative word is demonstrate. You cannot demonstrate with a description. You demonstrate with a record that shows the specific action, the specific person, and the specific date. A report that says "AI-assisted advice is reviewed before it reaches the client" demonstrates nothing. A report that shows this advice, drafted by this tool, reviewed by this named solicitor, on this date, against this source, demonstrates exactly what the rule asks for.
That is why the report has to be contemporaneous. A record created at the moment of the work carries weight a reconstruction never can, and the SRA knows the difference between a log that was running and a document that was assembled the week the letter arrived.
Field note: The question I use to separate a policy firm from a report firm is simple. "Pick a matter from three months ago where AI was used. Can you show me what the AI produced, what it was checked against, and who signed it off, without anyone reconstructing it from memory?" A policy firm goes quiet. A report firm opens the record.
What the report must prove, rule by rule
The rules that govern AI use are not AI rules. They are the ordinary obligations you already hold, applied to a new kind of work. Here is the evidence line each one requires the report to carry. Not what to do about it, the checklist covers that, but what the report has to prove happened.
Rule 2.1, effective governance. The report must prove a governance structure operated, not just that one exists on paper. That means a named owner for AI governance, a reporting line that actually reported, and dated decisions the structure took: a tool approved, a use restricted, a risk escalated. A governance section that lists roles but shows no activity proves the org chart, not the governance.
Rule 2.2, records demonstrating compliance. The report is itself the proof for this rule. What it must show is that the records exist, cover the period, and can be produced on demand rather than assembled from scratch. The test is not "do you have records" but "can you export them now."
Rule 2.5, identifying and managing material risks. The report must prove that AI risks were identified, assessed, assigned an owner, mitigated, and reviewed, with dates on each. The instrument for this is a risk register with a live history, not a one-off assessment, which is why we treat it as its own artifact in building an AI risk register. The report has to show the register was maintained, not merely created.
Rule 3.3, responding promptly to the SRA. This is the rule the checklist does not dwell on, and it is the one the report exists to satisfy. Rule 3.3 requires you to respond promptly and provide "full and accurate explanations, information and documentation" in response to any request, and to ensure that relevant information, including information held by third parties acting on your behalf, is available for inspection. A report that can be produced on day one, that is complete and accurate, and that reaches into your AI vendors' records too, is what turns a production notice from a crisis into a task. The report is your Rule 3.3 readiness made concrete.
Rule 4.2, competent service. The report must prove that AI-assisted work met the competence standard before it reached the client. Per output, that means evidence of the review: what was checked, against what source, by whom, when. A single verification record per AI-assisted deliverable is what proves the work was competent, not just produced.
Rule 4.3, staff competence. The report must prove that the people using AI were competent to, and stayed current. That is a training log with dates, attendees, and content, showing competence was built and refreshed, not asserted once at induction.
Rules 6.3 and 6.5, confidentiality. The report must prove client confidentiality held through the AI layer: that only approved tools touched client data, that data flows were controlled, that one client's information did not surface in another's matter, and that processor agreements bound the vendors. This is where AI-specific evidence meets the firm's oldest duty.
The anatomy of an SRA-ready AI audit report
Put those evidence lines together and the report has a natural structure. Each section answers a rule, and the report is the join that makes the whole thing inspectable in one place.
| Report section | What it contains | The rule it proves |
|---|---|---|
| Scope and period | Which systems, which teams, which dates the report covers | Frames the whole |
| AI systems register | Every AI tool in use, what it does, what data it touches | 2.1, 6.3 |
| Governance and accountability | Named owner, reporting line, dated governance decisions | 2.1 |
| Risk register extract | AI risks identified, assessed, owned, mitigated, reviewed, dated | 2.5 |
| Per-output evidence | What the AI produced, its source, the reviewer, the date | 4.2, 2.2 |
| Competence and training log | Who was trained, on what, when | 4.3 |
| Incidents and remediation | What went wrong, how it was caught, what was done | 2.5, 2.2 |
| Confidentiality and data controls | Approved tools, data flows, processor agreements | 6.3, 6.5 |
Notice what this is not. It is not a narrative essay about the firm's approach to AI. It is a set of records, organised so that an inspector, or your COLP, or your insurer, can go straight from a rule to the evidence for it. The report's job is to make the evidence findable, complete, and dated.
Contemporaneous beats reconstructed, every time
The reason timing decides everything is that a reconstructed report is weaker in two ways, and sometimes impossible in a third.
It is weaker on accuracy, because memory fills gaps the record would have caught, and an inspector reading a document assembled after the request will probe exactly the parts that were filled in. It is weaker on completeness, because you can only reconstruct what someone happened to remember or save, and the gaps become the story. And it is sometimes impossible, because the evidence a rule needs, who reviewed this output on this date, simply was not captured at the time and cannot be recreated honestly now.
A firm that reconstructs is also, at that exact moment, failing Rule 3.3's "promptly." The days spent building the report are days the SRA is waiting, and a slow, patched-together response is itself a finding. The whole value of a contemporaneous report is that it collapses the response time to the length of an export.
What generates the report
The report firms want is one they do not have to write, because it writes itself as the work happens. That is the point of putting governance in the layer where the AI runs rather than in a document beside it.
When every AI action is logged as it occurs, what the tool did, the source it traced to, the named person who reviewed it, the time it happened, the report is a by-product. The risk register updates as risks are logged. The per-output evidence accrues matter by matter. The training log fills as sessions happen. When the request comes, you are exporting a report that already exists, not composing one under a deadline.
That is what the AI Governance and Audit Agent is built to produce, and it is why we frame governance as a record that generates itself rather than a policy that describes good intentions, the theme of why an AI policy is not AI governance. If you want to test whether your firm could produce this report today, the interactive SRA AI audit readiness check scores you against the records a production notice would demand, and what happens if your firm fails an SRA AI audit walks through where the absence of that report actually leads.
LegalAI Space builds AI agents for legal teams with a governance layer that makes every output verifiable, compliant, and audit-ready, generating the evidence your COLP, your insurer, and the SRA need. Sign up for early access or book a pilot call with Founder Daman Kaur.
FAQ
What is an SRA AI audit report? It is a record that demonstrates how your firm governs its use of AI, organised so that each SRA obligation can be evidenced. There is no formal, named "SRA AI audit report" required by a standalone rule; the term describes the body of records the SRA Code, especially Rule 2.2, requires you to keep and be able to produce when asked. Its purpose is to prove what the firm did, not describe what it intended.
Which SRA rules apply to AI use? There is no separate AI rulebook. AI is governed by the existing SRA Code of Conduct for Firms: effective governance (2.1), records demonstrating compliance (2.2), managing material risks (2.5), responding promptly to the SRA (3.3), competent service (4.2), staff competence (4.3), and confidentiality (6.3 and 6.5). The report exists to evidence each of these.
What is the difference between an AI policy and an AI audit report? A policy states what the firm intends and is written in advance. An audit report records what actually happened and is written continuously, as the work is done. Rule 2.2 requires records that demonstrate compliance, which a policy cannot do on its own. The report is the evidence; the policy is the intent behind it.
What does Rule 2.2 require you to prove? That you keep and maintain records demonstrating compliance with your obligations. In practice, that means being able to produce, for the relevant period, records showing which AI tools were used, what they produced, who reviewed the output and when, what risks were managed, and what training was delivered, exported on demand rather than assembled after a request.
Can we produce the report after the SRA asks for it? You can try, but a reconstructed report is weaker on accuracy and completeness, and some evidence, such as who reviewed a specific output on a specific date, cannot be recreated honestly if it was not captured at the time. Producing it late also cuts against Rule 3.3's requirement to respond promptly. A contemporaneous report avoids both problems.
Does the SRA have a required format for the report? No. The SRA does not prescribe a template. What matters is that the records demonstrate compliance and can be produced promptly and in full. Organising the report so each SRA rule maps to its evidence is a practical way to meet that standard, not a mandated structure.
Sources
-
SRA Code of Conduct for Firms, SRA Standards and Regulations. Rule 2.1 (effective governance structures, arrangements, systems and controls), Rule 2.2 (keep and maintain records to demonstrate compliance), Rule 2.5 (identify, monitor and manage all material risks), Rule 3.3 (respond promptly to the SRA and provide full and accurate explanations, information and documentation, and ensure relevant information, including that held by third parties on your behalf, is available for inspection), Rule 4.2 (competent and timely service), Rule 4.3 (competence of managers and employees, kept up to date), Rules 6.3 and 6.5 (confidentiality of current and former clients, and not acting where a client's adverse interest conflicts with confidential information you hold). Rule wording quoted from the current SRA Code of Conduct for Firms.
-
SRA, Standards and Regulations. The SRA does not operate a standalone AI rulebook or a prescribed audit-report template; AI use is assessed through these existing obligations.
-
For the "what to do" for each rule, see our COLP's AI governance checklist; for the full mapping of obligations to controls, our SRA AI compliance guide. This report-focused piece is designed to sit alongside them without duplicating their content.