The First Legal AI Platform Built for the SRA Code of Conduct

A barrister stands up in the High Court and cites five authorities. The other side cannot find them. Neither can the judge. It turns out none of the five cases exist. They were generated by an AI tool, dropped into a skeleton argument, and filed without anyone re-checking whether the law was real.

That is not a hypothetical. It is a pattern now large enough to have its own public database, and it holds more than 1,600 court decisions where AI-fabricated citations were caught. The tool did what these tools do. It produced fluent, confident, well-formatted text. What was missing was the one step that would have stopped it: an independent check, before the work left the building, that every authority was real and said what it was quoted as saying.

That is the whole thesis behind what we built. The tool is not the failure. The missing check is.

I want to explain why LegalAI Space is put together the other way round from almost every other legal AI product, and what that changes for a firm that has to answer to the SRA. This is a legal AI platform built for the SRA Code of Conduct first, and a productivity tool second. Not the reverse.

Most legal AI is a general tool pointed at law firms

Here is the honest story of how most legal AI came to exist. A general-purpose model was built for everyone: marketers, developers, students, salespeople. It was good at writing. Someone noticed lawyers write for a living, wrapped a legal-looking interface around it, wrote an acceptable-use policy, and sold it into firms. The governance is a document. The product underneath it does not know or care what the SRA Code says.

I built LegalAI Space because I think that order is backwards for regulated work. When a solicitor is personally accountable under the Code, and the firm's COLP has to demonstrate compliance to an inspector, a policy sitting beside the tool is not enough. The rules have to run inside the work.

So we started from the Code, not from the chat box. The governance layer was designed first. The agents that do the drafting, research and review were built to run inside it. Every output passes through the governance layer before a human ever sees it. That single design decision is the difference between a tool you have to police and a tool that polices itself and shows its working.

	Governance bolted on	Governance built in
Where the rules live	A PDF in a shared drive	Code that runs on every task
When compliance is checked	After the fact, if at all	Before, during and after the output
Who does the checking	Each fee earner, every time	The platform, then the fee earner
Evidence for the SRA	Assembled the night before	Produced as the work happens

I have written before about why an AI policy is not the same thing as AI governance. If that distinction is new to you, start there. This piece is about what governance-first actually looks like when you build the platform around it.

Governance that runs before, during and after the output

Most compliance features in legal AI are a review step: the work is done, then something skims it. Review after the fact catches some errors and misses others, and it never catches the error that matters most, which is work that looked fine and went out anyway.

Our governance layer runs at three points on every task. There are 19 named protocols and gates in total. You do not configure them. They run whether the fee earner remembers to think about them or not.

Before the work starts. Four pre-run protocols set the boundaries before the model does anything. A planning step structures the task. A jurisdiction gatekeeper blocks cross-border contamination, so Scottish authority does not creep into an England and Wales matter. A redaction step strips client personal data out of the prompt before it leaves your tenancy. A conflict check screens against SRA Rule 6.1 and 6.2 before a single word is drafted. If the task should not run, it does not run.

During generation. Six deterministic gates are enforced in code, not by another model asking politely. Code does not have a bad day. These gates hold the line on the things you cannot afford to get wrong: a citation must belong to a verified match set, a quotation must be verbatim, confidence cannot fall below a floor, provenance must be labelled, privileged material must be dropped, and a URL cannot point outside the closed world of checked sources. A gate either passes or it stops the output. There is no persuading it.

After the work is generated. The post-run protocols check the finished output against the SRA Code, the FCA, the ICO and the EU AI Act. They review for privilege and confidentiality leaks. They flag authorities that have been overruled, repealed or superseded. They re-fetch and re-verify every citation. And they write the audit record. There is also an on-demand verifier that checks citations against BAILII, legislation.gov.uk and EUR-Lex when you want a second pass on the law itself.

The trade-off is honest: this is slower than a raw chatbot that answers instantly and checks nothing. A pre-run conflict screen and a post-run citation re-fetch cost seconds. For regulated legal work, I will take those seconds every time. The alternative cost is a fabricated case in a filed document, and that bill arrives in a very different currency.

The COLP dashboard already has the answers written down

Ask most firms to prove how their AI-assisted work was governed and you will watch a scramble: emails, memories, a spreadsheet someone updated in March. The evidence gets reconstructed after the request arrives, which is the worst possible time to be assembling it.

The COLP dashboard is built so the evidence is already there. Every AI-assisted matter appears in one place, with its verification status, its compliance score and anything that was flagged. When an inspection comes, the report is not a project. It has been writing itself as the work happened. Three things sit underneath it.

Every citation is re-fetched, not recalled. This matters more than it sounds. When a general model gives you a case, it is reciting a pattern from its training, and it can invent a citation that looks perfect. Our authorities are not recalled from a model's memory. They are fetched live, and each one arrives with its primary-source URL, a content hash and a treatment signal, so you can see it is good law and prove where it came from. A case that cannot be fetched is flagged, not quietly dropped. If you want the deeper mechanics, I wrote a full explainer on verifying AI legal citations.

The audit trail is signed and reproducible. Every run leaves a record of what was asked, which sources were touched, what each check found, who reviewed it and what they changed. Re-run it and you get the same evidence, carrying an integrity hash. It exports as the artefacts different readers actually ask for: a COLP evidence bundle for an inspection, a PI insurer evidence pack for renewal, an EU AI Act human-oversight attestation for a client with EU exposure. It is written as the work happens, not assembled the night before an audit.

The risk register is live, not annual. SRA Rule 2.5 asks firms to identify, monitor and manage all material risks. A register that has not moved since it was created reads as unmonitored. Because entries update as governed work runs, the register stays current on its own rather than depending on someone remembering to open a file. I go deeper on that in building an AI risk register your firm can hand to the SRA.

A specialist agent for every kind of legal work, not one general assistant

A single general assistant is a reasonable answer to "help me write something." It is a poor answer to "run due diligence on this data room" or "tell me if this clause survives the governing-law change." Different legal work needs different reasoning, different sources and different checks. So instead of one chat box, the platform ships 15 specialist agents, grouped by how UK firms actually organise the work.

Research and Intelligence. The Research Agent for verified case and statute research, Know-How for internal precedent, Horizon Scanning for regulatory change, and Radar for keeping watch on a defined area.

Transactions. The Contract Agent for clause-level review, the Due Diligence Agent for data rooms, the Drafting Agent for first drafts in house style, and an IP and Technology agent for that practice area.

Risk and Compliance. Compliance and Regulatory, AI Governance and Audit, Client Intake, and Privacy and Data Protection.

Disputes and Practice. Matter Management, Litigation and Disputes, and Employment.

Every one of them runs inside the same governance layer. The Contract Agent and the Research Agent do very different jobs, but they clear conflicts before they start and verify their sources after they finish in exactly the same way. The governance does not get weaker because the task changed.

And it is not a fixed toolkit. Beyond the 15, a firm can build custom agents around its own practice: a bespoke drafting agent for a particular type of client letter, for example, governed the same way as everything else. The custom agent capability means the platform extends to how your firm works rather than forcing your firm to work around it.

Document Review: one question across every document at once

There is a specific kind of work that breaks people. You have forty documents and the same three questions to ask of each one. The manual approach is to open them one at a time, read, summarise, and hope you were consistent by document thirty as you were on document one. You will not be. Attention does not hold that long.

Document Review turns that into a single grid. You ask your questions once, point it at the set, and get a cited answer for each document, side by side, in a table you can read across. Every answer is grounded in a verbatim quote and verified against the source, so a "yes" in the grid is a "yes" you can click into and check, not a summary you have to trust. It is the difference between reviewing a bundle and interrogating it.

Built for UK firms, and for the EU work they cannot avoid

Two more things matter if you are a UK firm, especially one acting for clients with European exposure.

Self-hosting and your own model keys. For firms with the strictest data-residency requirements, the platform is designed to run inside your own tenant, pointed at your own Azure OpenAI resource or enterprise model agreement, with the same governance unchanged. I want to be straight about status: the self-hosted deployment is in active development rather than a finished shipping product today, so if data sovereignty is a hard requirement for you, talk to us about timing before you plan around it.

EU AI Act mapping. UK-only governance is half an answer for a firm with EU clients. Under the EU AI Act, AI assisting the administration of justice is classified high-risk under Annex III, point 8. Those obligations apply from 2 December 2027, having been moved from 2 August 2026 by the Digital Omnibus adopted by the European Parliament and Council in June 2026. Article 12 requires high-risk systems to keep automatic logs across their lifetime, and the signed, reproducible run record we already produce is built to export as exactly that evidence. One record answers the UK and the EU question at once. The detail is in our EU AI Act guidance for UK firms.

Which part matters most for you

Productivity and governance usually sit in different tools, which is how the gap between what an AI produces and what the SRA expects gets so wide. Putting them in one place is the point. Here is where I would start depending on who you are.

If you are a COLP or MLRO, look at the dashboard and the audit trail first. Your problem is evidence you can produce on demand, and that is the part built for you.

If you are a managing partner, the question is whether AI use across the firm is governed by design or by hope. The 19 checks running on every task, without anyone opting in, is the answer to that.

If you are a fee earner, the honest pitch is that the governance gets out of your way. You do the work; the checks run underneath it; the output comes back with its sources already verified.

If you act for EU clients, the record that satisfies the SRA is built to satisfy Article 12 as well, so you are not maintaining two compliance stories.

---

LegalAI Space builds specialist AI agents for UK and EU legal teams, wrapped in a governance layer that makes every output verifiable, compliant and audit-ready. Try the platform or book a pilot call with founder Daman Kaur.

---

FAQ

Is LegalAI Space SRA-approved or SRA-certified? No, and be wary of any legal AI tool that claims to be. The SRA does not approve, certify or endorse software. What it does is hold firms to the Code of Conduct. The platform is built to map to that Code and to produce the evidence a firm needs to demonstrate compliance, which is a different and more useful thing than a certificate the regulator does not issue.

What does "governance runs before the output" actually mean? It means the compliance checks are not a review step after the work is finished. Before a task runs, pre-run protocols clear conflicts and strip client personal data. During generation, deterministic gates enforce citation, quote and privilege rules in code. After the output is produced, post-run protocols check it against the SRA Code and re-verify every source. A fee earner sees the result only once it has passed through all three.

How is this different from a general AI tool with an AI policy? A policy describes what should happen and relies on each person to follow it. This platform enforces the rules on every task and records that it did. The general tool cannot show an inspector what happened on a given matter; the platform's audit trail can. I set out the full distinction in why an AI policy is not AI governance.

How does the platform stop AI hallucinations? It does not ask the model to check its own work, because a model that invented a citation will happily confirm it. Instead, citations are re-fetched from primary sources rather than recalled from memory, quotations are matched verbatim against the source text, and a citation that cannot be verified is flagged rather than passed through. The check is independent of the model that produced the draft.

Do I still need a qualified lawyer to review the output? Yes. The platform is built to make every output a verified, well-evidenced draft, not a final answer that bypasses professional judgement. A named, qualified person still reviews and signs off, and the audit trail records who did and what they changed. The governance narrows what they have to catch; it does not remove them from the loop.

Can the platform run inside our own environment? That is the intended model for firms with strict data-residency needs: self-hosted, pointed at your own model keys, with the same governance layer. It is in active development rather than generally available today, so confirm current status and timing with us before you depend on it.

---

Sources

• Damien Charlotin, AI Hallucination Cases Database. A publicly maintained database of legal decisions where courts or tribunals identified AI-generated hallucinated content. The figures cited here (1,668 total cases, 59 UK, 653 involving lawyers) reflect the database as of 2 July 2026; the counts change daily, so verify against the live source before relying on them. See also our own analysis in 1,600+ AI Hallucination Cases: What Every Law Firm Should Learn.

• R (Ayinde) v London Borough of Haringey; Al-Haroun v Qatar National Bank QPSC [2025] EWHC 1383 (Admin). The Divisional Court addressed fictitious, AI-generated case citations filed in the High Court, with referrals to the relevant regulators. See Law Gazette reporting and BIICL analysis.

• SRA Code of Conduct for Firms, SRA Standards and Regulations. Rule 6.1 and 6.2 govern conflicts of interest; Rule 2.5 requires firms to "identify, monitor and manage all material risks"; Rule 2.2 requires records to demonstrate compliance. The SRA regulates AI use through these existing obligations rather than a standalone AI rulebook, and it does not certify or approve software.

• EU AI Act, Regulation (EU) 2024/1689. AI intended to assist a judicial authority in administering justice is high-risk under Annex III, point 8. Article 12 requires high-risk systems to keep automatic logs across their lifetime. The high-risk obligations were moved to 2 December 2027 by the Digital Omnibus adopted by the European Parliament and Council in June 2026; these dates are time-sensitive, so verify against the Official Journal before relying on them.