SRA’s AI Warning Notice: Operationalising AI Assurance

The SRA’s AI Warning Notice: What are the Asks & How to Build the Proof

A practitioner paper from Acora on operationalising AI assurance in the legal sector and other regulated, high-risk verticals. Published in response to the Solicitors Regulation Authority warning notice Misuse of AI, 17 August 2026.

What Changed on August 17th?

The Solicitors Regulation Authority has published a warning notice on the misuse of artificial intelligence. It applies to all regulated firms and individuals, and it carries teeth: the SRA states plainly that failing to have proper regard to it puts you at risk of disciplinary action.

The notice raises two areas of concern. The first is court and other documents containing false or incorrect information, including fabricated case citations, as a result of AI misuse. The second is that firms are not fully considering or mitigating risks to client confidentiality and that both free and paid AI tools may lack the contractual and technical safeguards required to protect it.

The notice draws on recent judgments. In the Ayinde litigation, false AI-generated citations were placed before the court; the judgment observes that a referral to the regulator is likely to be appropriate in such cases, and that reliance on an AI output is no defence. In a 2026 Upper Tribunal decision, the Tribunal observed that putting client correspondence into an open-source AI tool amounts to placing that information in the public domain with the consequence that privilege may be permanently waived and unrecoverable. Trade press reporting alongside the notice indicates the SRA received 42 reports of potential AI misuse between July 2025 and July 2026, with investigations ongoing.

One structural point matters more than any individual case. The SRA regulates for outcomes. It sets the standard and leaves firms free to decide how to meet it. That freedom is real, and it transfers the burden of proof onto the firm.

Two Concerns, One Failure

Read as separate risks, hallucination and confidentiality look like they need separate remedies: better verification habits for one, better tool policy for the other. Read properly, they are two symptoms of a single failure.

A hallucination is what happens when a system is asked a question it cannot answer from the material it was given, and generates something plausible instead. That is not a malfunction. It is the design. The failure occurred upstream, when the right material did not reach the model.

A confidentiality breach is what happens when material reaches a place the firm cannot control. Same axis, opposite direction.

Both are questions about context: what reached the model, where it came from, whose authority it travelled under, and what happened to it afterwards. Firms that treat this as a prompt-writing problem will keep having both failures. Firms that treat it as a retrieval and boundary problem will fix both at once.

The Risk the Notice Implies but does not Name

The SRA acknowledges that many firms are now building in-house AI systems, and reminds them that confidentiality must be maintained in any system used. In a firm-built system the confidentiality risk moves inside the walls. A retrieval system indexing the document management system, which does not inherit matter-level entitlements and information barriers, can surface material from one matter to a fee earner acting on the other side. No external tool is involved. No data leaves the tenant. It is still a breach, and a harder one to detect, because there is no obvious event to detect.

The Burden is Evidential

Trace the obligations the notice invokes and a pattern emerges. Solicitors must provide a competent service and effectively supervise work done for clients. Firms must maintain effective governance structures, systems and controls, and an effective system for supervising client matters. The COLP must take all reasonable steps to ensure compliance. And under paragraph 7.2, you must be able to justify your decisions and actions in order to demonstrate compliance.

Demonstrate. Not assert.

A policy states an intention. Evidence states what happened. If a regulator, a client, or a court asks whether a particular AI-assisted output was properly supervised, the answer has to be reconstructable: for that matter, on that date, by that named individual, drawing on those sources, using that version of that model.

That is a telemetry requirement dressed as a governance requirement. The profession has been here before. Anti-money laundering began as a policy obligation and became a records obligation. Cyber security began as a policy obligation and became a logging obligation. AI assurance is following the same path, and the notice of 17 August is the point at which it started.

Four Control Layers

What follows is the structure Acora uses with clients, and the structure we run internally against our own AI adoption. It is deliberately ordered: each layer depends on the one before it.

Layer 1: Governed Adoption – Who is Allowed to do What

Not every AI user carries the same risk. The fee earner using a drafting assistant, the business services analyst automating a workflow, and the innovation team building an application are three different risk profiles requiring three different sets of controls and three different competence standards. Treating them as one population produces controls that are simultaneously too heavy for the first and far too light for the third.

• A tiered user model — defined categories of AI use, each with its own terms of use, approval route and required training.
• A stage-gated route to production — for anything the firm builds or configures itself, defined gates between pilot, controlled use and production, each with a named approver.
• Supervision mapping — for each approved use, who supervises it, whether they are competent to do so, and how that competence is evidenced. Note the authorisation requirement for regulated work to be supervised by someone with at least three years’ practice.
• A register of approved uses — uses, owners, approvers, supervisors, dates. This is the single most requested artefact arising from the notice, and most firms do not have one.

Layer 2: Supplier Assurance – What your Tools Actually do with your Data

The notice is unambiguous that both free and paid tools may lack the necessary contractual and technical safeguards. That makes this a procurement and contract question before it is a technology question, and it applies to tools nobody procured, which in most firms is the larger population.

For every AI tool in use, a firm should be able to answer:

• Is our input used to train or improve the model, and is that excluded contractually rather than by setting?
• How long is data retained, where, under which jurisdiction, and can we compel deletion?
• Who at the supplier can access it, under what circumstances, and is that logged?
• Is the tenancy isolated or shared, and what separates our data from another firm’s?
• Which sub-processors are involved, and are we notified when they change?
• Does the supplier change the underlying model beneath us, and are we told when they do?

That last question is rarely asked and matters disproportionately. Verification performed against one model version does not carry forward to the next. A supplier who silently upgrades has silently invalidated your assurance work.

The structural answer to supplier risk is to reduce dependence on it to keep the firm’s institutional knowledge inside a boundary the firm controls, and to treat external models as compute rather than as custodians.

Layer 3: Data Safeguards – Knowing what you Hold and Where it can Go

You cannot protect what you have not found. Before any control can be applied, a firm needs to know where client-confidential material actually lives, which of it is privileged, which is subject to an information barrier, and how much of it sits outside the document management system in mailboxes, shared drives and collaboration tools.

• Discovery and classification — automated identification and sensitivity labelling of confidential, privileged and personal data across the estate, using Microsoft Purview and data security posture management (DSPM) tooling to surface what nobody remembered was there.
• Labels that travel — sensitivity labels applied at the document level so an item behaves consistently whether it is in the DMS, attached to an email, or pasted into a prompt.
• Egress control at the point of use — endpoint and browser controls that technically prevent client material being entered into unmanaged AI tools. This is the highest-yield single control against the notice’s second concern, because it converts a prohibition into a prevention.
• Entitlement-aware retrieval — the control most firms miss. The retrieval layer must enforce the same matter-level entitlements and ethical walls as the source system, per user, at query time — as a constraint applied before retrieval, not a filter applied after it.
• Purpose and persona scoping — a knowledge assistant for a paralegal, a research tool for an associate and a client-facing service are three systems with three risk profiles, even where they share a model. They should not share a configuration.

Layer 4: Continuous Assurance – Accuracy is not a Launch Event

A system verified at go-live does not stay verified. AI systems do not fail loudly; they degrade quietly, and the degradation is invisible in the metrics most firms watch.

• The supplier changes the model, or its version, on their schedule.
• The corpus changes: new matters open, old ones archive, permissions are amended.
• Retrieval quality drifts as the index grows and document mix shifts.
• User behaviour drifts as people discover new uses nobody designed for.

The supervision duty in paragraph 4.4 is continuous. It does not have office hours. If a retrieval index breaks at two in the morning, the firm remains accountable for what it returns the next morning. What should be instrumented:

• Citation verification — automated validation that every asserted authority in an output resolves to a real, retrievable source before that output can leave the system. This is a control a court would recognise, and it addresses the notice’s first concern directly.
• Groundedness and retrieval quality — continuous measurement against a maintained evaluation set, so a fall in answer quality is detected rather than discovered.
• Refusal and confidence behaviour — a sudden fall in the rate at which a system declines to answer is an alarm, not an improvement. Systems that stop saying “I don’t know” have usually stopped knowing when they don’t.
• Access and usage anomaly detection — the same behavioural analytics discipline a security operations centre applies to user activity, applied to AI usage and retrieval patterns.
• A complete audit trail — prompt, retrieved sources, output, user, matter, timestamp and model version, retained and searchable. This is what makes paragraph 7.2 answerable.

What Good Looks Like

Acora has worked in the legal sector for over two decades, and our Data & AI practice works with firms across The Lawyer Top 200 locally and internationally. The clearest illustration of the model described above is our work with Herbert Smith Freehills Kramer on their Sovereign System of Intelligence.

Reported by Legal IT Insider in June 2026, the platform grounds AI in the firm’s own institutional knowledge rather than in a general-purpose tool. It is built on Microsoft Azure and Microsoft Foundry, governed through Microsoft Purview, and uses an applied ontology to make unstructured content in documents, spreadsheets and email interrogable. The firm’s global CTO has described the result as a defensive moat around its internal knowledge; the programme began as an exercise in aligning process, culture and operating model before it became a platform.

Law firms don’t need more end-user AI tools.” They need to harness their own institutional knowledge to drive AI-enabled services that improve client outcomes.

Darshna Shah, Chief AI Officer, Acora — speaking to Legal IT Insider, June 2026

The significant point is not the technology. It is that governance was designed in rather than bolted on. Purview and DSPM tooling sit at the centre of the architecture, not at the edge of it. That is what makes the resulting system evidenceable, and it is why a firm in that position reads the SRA notice as confirmation rather than as a problem.

Questions a Legal Compliance Officer Should be Able to Answer this Quarter

These are the questions we would ask in an assurance review. They map directly to the obligations the warning notice invokes.

1. Which AI tools are in use across the firm, including the ones nobody procured?
2. For each, does the contract exclude your data from model training, and can you produce the clause?
3. Where does client data go, how long is it retained, and in which jurisdiction?
4. Can you produce a register of approved AI uses with a named supervisor against each?
5. Are those supervisors competent for AI-assisted work, and how is that competence evidenced?
6. Does your retrieval layer enforce matter-level entitlements and ethical walls at query time?
7. Is client-confidential material technically prevented from reaching unmanaged tools, or only prohibited by policy?
8. Is every case citation in an AI-assisted output automatically verified against a real source before it leaves the firm?
9. If a client asked how a specific AI-assisted output was produced last month, could you reconstruct its sources, user, and model version?
10. Who is accountable if accuracy degrades overnight, and by what mechanism would you know?

If the honest answer to more than three of these is “we would have to find out”, that is the finding. It is also, in our experience, the normal starting position, including at firms with well-drafted AI policies.

The Same Pattern Outside Legal

The SRA has arrived at this first and most explicitly, but the structure is not specific to legal practice. Every regulated sector deploying AI against sensitive data is converging on the same three demands: know what your systems do, supervise them continuously, and be able to prove both.

Financial Services: Consumer Duty outcomes testing and senior manager accountability require evidence that automated decisioning is monitored and explicable, not merely governed by policy.

Healthcare & Life Sciences: Patient confidentiality and clinical safety obligations require the same entitlement-aware retrieval and audit trail, with higher consequences for silent degradation.

Insurance: Fairness and bias monitoring obligations turn model drift into a conduct risk, not just a technical one.

Any EU-Facing Operation: The EU AI Act imposes logging, human oversight, accuracy and robustness requirements and post-market monitoring on high-risk systems, with continuous assurance as a statutory duty.

The common thread is that all of these are operational obligations expressed in regulatory language. They are discharged by running something, not by writing something.

Where to Start

We offer a fixed-scope AI Assurance Review: a short engagement that discovers the AI tools actually in use, tests the data controls around them, and produces a written evidence pack against the ten questions above with a prioritised remediation plan and an indicative cost for each item.

It is deliberately small. It is designed to be commissioned by a COLP, a Director of Technology or a Head of Risk without a business case, and to produce a document that can be taken to a board or a client without further work.