In the third of a series on safely adopting AI, Ed Molyneux turns a firm’s obligations into an actual design, a single controlled route to client data, and explains why a bolt-on guardrail can never be the safeguard it claims to be.
The duties this series has set out amount to a short specification: a record of what AI use touched, controlled and visible data flows, a lawful basis applied consistently, enforcement that data reaches only approved vendors, and AI kept as support with a human in the loop. The useful thing about them is that they converge. A firm does not need five separate mechanisms, because almost everything falls out of one idea.
The idea is this: there should be exactly one path from an AI tool to client data, and that path should check and record every transit.
State it that way and the central failure mode names itself. Copy-paste into a chatbot is not a second, worse path. It is the absence of a path, data leaving the firm’s control through a gap where a controlled route should be. Every requirement above is impossible to meet through that gap and straightforward through a controlled route. So the whole design reduces to building the route and closing the gap.
The route is a single interface the AI has to go through to reach matter data. Whether a firm calls it a connector, a gateway or an integration matters less than what it does on every request, which is four things in order.
Authenticate: establish which human is asking. Every other control depends on this. The tempting shortcut is one shared account used by everyone. It is faster to build, and it destroys two requirements at a stroke: access can no longer follow the individual’s permissions, and the record can only ever say that the shared account did it, never who actually asked, which is the one fact anyone will want.
Authorise: deny by default, and scope to the individual. The right mental model is not that the AI has access to the case management system. It is that the AI sees exactly what this fee-earner may see, the same matters, the same conflict walls. Anything looser is a privilege escalation route with a friendly chat interface on it.
Minimise: return the fields the task needs, not the whole file. A summarising task needs the events in a chronology, not the client’s bank details three pages further down. Field-level responses turn data minimisation from a sentence in a policy into a property of the system.
Record: log what was released. Not merely that a request happened, but which matter, which fields, to which tool, for which user. The point is that this is automatic. The record is a by-product of use rather than a register somebody maintains by hand, and hand-kept registers rot between audits.
Four jobs, one door. Meet them and the duties are satisfied structurally rather than by exhortation, which is the only way they stay satisfied when a fee-earner is up against a deadline at six in the evening.
Those four jobs are also a fair test to put to any supplier, including whoever already provides the case management system. A good deal of what is sold as AI governance is, underneath, an instruction attached to a chatbot: a prompt, a skill, a policy the model is told to follow. An instruction has no independent identity check, so it cannot authenticate. It cannot hold data back, because by the time it reads the input the data has already been sent, so it cannot authorise or minimise. And it has nowhere to write anything, so it cannot record. It fails all four, not by being badly written, but by being the wrong kind of thing. Instructions shape how a model answers, and none of these requirements is about the answer.
That does not make the instruction layer worthless. A prompt that notices a bank statement in what has been typed and coaches the user before they go further is a genuinely good colleague, and habits catch what architecture misses. But it is a coach, not a control. It cannot discharge an obligation or produce the record, so keep it for what it is good at and do not let it stand in a compliance document as the thing that keeps the firm safe.
Put the door in front of matter data and the awkward questions start answering themselves. Which client data went to AI, and can you prove it stayed in bounds? Read the log. On what basis? The standing basis, recorded once, carried on every entry. Did it reach only vetted vendors? The door opens onto those and no others. Can a supervisor see how staff are using it? Yes, per person and per matter. None of that required a fresh lawful basis for every click, a sterner policy, or a cleverer prompt. It required building the route and closing the gap.
Which leaves the practical question, because nobody can do all of this on Monday: what is the order of climb, and where does your firm stand today? That is the next 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.
