In the fifth of a series on safely adopting AI, Ed Molyneux offers a short and occasionally awkward checklist that separates an AI tool a firm can genuinely govern from a confident brochure.
The SRA’s warning notice tells firms, before using AI with client data, to confirm that the data stays in a secure environment, is not accessed by unauthorised third parties, is not used to train models except where authorised, and is not kept longer than necessary. Those are precisely the things a supplier should be able to tell you. Yet almost every AI vendor selling into the legal market reaches instead for the same three words: secure, compliant, trusted. None is a fact a firm can check.
So here is a shorter list of questions that are. Put them to any AI supplier, in-house build or governance add-on before relying on it.
One. Does your audit log identify the individual user, or only an account or token? This catches the most. A common shortcut is for the tool to reach the firm’s systems through one shared service account, so every entry reads as that account rather than the person who asked. A log that cannot name the human cannot answer the only question anyone asks after an incident.
Two. Does the log record which data was released, or only that a request happened? A user ran a query at 14:32 is not evidence. A user requested these fields of this matter and received them is. That is the whole difference between being able to account for your firm’s AI use and not.
Three. Can access be scoped per user and per matter, and is it deny by default? The model to hold is not that the AI has access to our systems, but that it sees precisely what this fee-earner may see and no more, conflict walls included. If the tool can reach data the user could not open themselves, then buying it quietly widened everyone’s access.
Four. Can we export the log into our own records, on a schedule, in a documented format? The accountability obligation is the firm’s, so the evidence has to live in the firm’s registers rather than a vendor dashboard you can only screenshot. A trail that cannot flow into your own record of processing is decorative.
Five. Who are your sub-processors, where is data processed, and under what transfer mechanism? An AI tool is rarely one company. It is usually a chain, often including a large model provider in another jurisdiction. You are entitled to the whole chain, the processing locations, and the lawful transfer mechanism for anything leaving the UK. We use a leading AI provider is not an answer.
Six. Do you train on our data, and is that a contract term or a changeable setting? There is a real difference between a contractual commitment never to train on your data and a toggle that is currently switched off. Get the commitment in writing rather than in marketing. This is one of the confirmations the SRA expects a firm to obtain.
Seven. What is your retention for prompts, responses and logs, and can we set it? Every copy of client data a vendor keeps is retention the firm now owns and has to account for. A tool that quietly retains prompts is building a second, unmanaged copy of your case files.
Eight. What external assurance do you hold, as distinct from what standard you say you are aligned to? Aligned to, built around and in line with all mean the vendor has read the standard. That is not the same as being independently assessed against it. Both can be legitimate, and a young company may hold little formal assurance yet, but you are entitled to know which you are being offered, and not to have the weaker dressed as the stronger.
Two failure modes are worth watching for. The first is the confident blank: smooth reassurance with no specifics. Enterprise-grade security. Fully compliant. Trusted by leading firms. These are not answers, they are the absence of answers, styled to sound like their presence.
The second is a reason for confidence rather than concern: the supplier who tells you plainly what they do not yet have. Our log names the account and per-user identity is on the roadmap. Training is a setting rather than a contract term today. That candour is worth more than a wall of green ticks, because it is how a vendor behaves who will also tell you the truth when something goes wrong.
Apply the list to everyone: cloud tools, on-premise builds, the governance add-on somebody wants to bolt on, and the AI features your existing case management supplier is quietly switching on. A firm that puts these eight to every AI it adopts ends up with a defensible position almost by accident. A firm that takes secure, compliant and trusted at face value ends up with a drawer full of assurances and no idea what any of its tools actually did.
There is a ninth question people keep expecting: whether the AI is any good. It belongs, but it is a different kind of question with a different kind of answer. Governing where data goes is not the same as trusting what a model says about it, and conflating the two is its own mistake. That is where this series ends, and it is the subject of the final article.
About the author
Ed Molyneux is co-founder and CTO of Moverly and the original author of the Property Data Trust Framework (PDTF), the open standard for machine-readable property data now being adopted across the industry. Ed writes about AI, property data infrastructure, and the future of conveyancing.
The views expressed in this article are those of the author and not necessarily those of Today’s Conveyancer. This article is general information, not legal advice.
