The compliance deck arrives before the contract. It is usually well-designed, reassuringly detailed, and lists certifications that most recipients will not have time to interrogate fully: ISO 27001, SOC 2 Type II, GDPR-ready infrastructure, data residency in approved jurisdictions. By the time procurement reaches legal review, the technology team has already formed a view, and the vendor’s documentation has done its work. The firm feels covered.
It is worth being precise about what that documentation actually covers, and what it does not.
A vendor’s compliance certifications attest to the security and operational standards of the vendor’s own systems and processes. They say something meaningful about how the vendor manages its infrastructure, handles data internally, and maintains its own regulatory posture. What they do not do, and cannot do, is transfer the regulated firm’s obligations to the vendor. When a law firm deploys an AI tool in client-facing work, the SRA’s obligations do not pause while the model processes the query. The firm remains the regulated entity. The tool is, in legal and regulatory terms, a resource the firm has chosen to use.
This distinction matters considerably more than most AI procurement conversations acknowledge.
Where the Liability Gap Opens
The gap is structural, not accidental. AI vendors operate in a commercial market where their customers span industries, jurisdictions and regulatory regimes. Their contracts are written accordingly: broad limitation of liability clauses, exclusions for consequential loss, and indemnity carve-outs that tend to favour the vendor in any scenario involving the firm’s own use of the output. Read a standard enterprise AI contract carefully and you will find that the vendor warrants the availability and security of its platform. It does not warrant the accuracy, completeness or fitness for purpose of what the model produces.
That is not an oversight. It reflects the genuine nature of large language model outputs, which are probabilistic rather than deterministic. The vendor cannot warrant that the model will not hallucinate a case reference, misstate a statutory provision, or produce advice that is subtly wrong in a way that a junior associate under time pressure might not catch. So the vendor does not. The firm, however, remains responsible for the advice that leaves its doors, regardless of what generated the first draft.
The SRA’s position on this is not ambiguous. Firms are responsible for supervising the work they produce and the processes they use to produce it. Deploying an AI tool does not create a new category of supervised entity sitting between the firm and its regulatory obligations. It creates a new workflow that the firm is responsible for supervising. The compliance question is not whether the vendor’s tool is certified. It is whether the firm has adequate processes to ensure that AI-assisted work meets the professional standards the firm is required to maintain.
What the Contract Actually Says
Most firms signing AI contracts in the current market are doing so under time pressure, with technology teams leading procurement and legal review arriving late. The contracts that result tend to reflect the vendor’s preferred risk allocation, not a negotiated position. Several patterns appear consistently.
Limitation of liability clauses in AI vendor contracts frequently cap the vendor’s total liability at the fees paid in the preceding twelve months. For a firm paying a mid-market SaaS subscription, that cap may be materially lower than the potential exposure from a single matter where AI-assisted work contributed to a client loss. The asymmetry is significant and rarely surfaced explicitly during procurement.
Data processing agreements, which vendors typically present as standard and non-negotiable, warrant close attention in a legal services context. The question of what happens to client data that passes through the model, whether it is used for training, how long it is retained, what the vendor’s subprocessor chain looks like, is not always answered clearly by the standard DPA. Where client data is confidential or subject to legal professional privilege, the firm’s obligations under both data protection law and professional conduct rules apply independently of whatever the vendor’s DPA says.
Indemnity provisions, where they exist, typically protect the vendor against claims arising from the firm’s use of the output rather than the reverse. A firm that relies on AI-generated content in client advice and faces a professional negligence claim will find that the vendor’s indemnity, if any, is unlikely to extend to that scenario. The firm’s professional indemnity insurance is the relevant backstop, and insurers are beginning to ask questions about AI use in practice.
The Supervision Question
Beyond the contract, the more immediate practical risk for many firms is not a catastrophic single failure but a gradual erosion of the review processes that would catch incremental errors. AI tools are adopted partly because they accelerate work. The commercial pressure to realise that acceleration can, over time, compress the supervision steps that sit between model output and client delivery.
Regulators are aware of this dynamic. The SRA’s guidance on technology and innovation has consistently emphasised that efficiency gains from technology do not reduce the firm’s obligations around competence and supervision, they change the form those obligations take. A firm that deploys an AI drafting tool without updating its supervision framework, training its fee earners on the tool’s limitations, and documenting its quality control processes is not simply taking a technology risk. It is potentially creating a compliance exposure that sits entirely within the firm, regardless of what the vendor’s documentation says.
This is the practical implication that procurement conversations tend to underweight. The vendor’s compliance posture is a threshold question, not a sufficient answer. The more consequential questions are internal: what is the firm’s policy on AI use in client work, who is responsible for reviewing AI-assisted output before it leaves the firm, and how is that review documented? In the event of a complaint or a negligence claim, those are the questions that will matter.
Negotiating from a More Informed Position
None of this means firms should avoid AI tools, or that vendor certifications are meaningless. It means the procurement conversation should be conducted with a clearer understanding of what the vendor’s compliance documentation does and does not cover, and with legal counsel involved early enough to influence the contract rather than simply review it.
In practice, there are several points worth pressing. Liability caps should be assessed against the firm’s realistic exposure, not accepted as standard. Data processing agreements should be reviewed against the firm’s specific obligations around client confidentiality and privilege, not simply countersigned. The vendor’s position on model training using client data should be confirmed explicitly and in writing, not inferred from general privacy documentation. And the firm’s own internal governance framework for AI use should be developed in parallel with procurement, not after deployment has begun.
Vendors will often present their standard contracts as non-negotiable. Some terms genuinely are. Others are not, and a firm that understands where its regulatory exposure lies is better placed to identify which is which. The compliance certification is the vendor’s answer to the vendor’s regulatory obligations. The firm still needs its own.
This article is for general information only and does not constitute legal advice.
