Practical legal AI

AI Contract Review: What It Does, Where It Fails and How UK Firms Should Use It

by Hamza Suleman

AI contract review is the use of software to assist with tasks such as locating provisions, extracting information, comparing wording with stated requirements, identifying issues for review and preparing draft changes. The Law Society describes contract review as one legal use case for AI, while warning that firms should test whether a supplier's claims match the problem the firm actually needs to solve. Source: Law Society

That definition matters because AI contract review is not one task. Finding a clause, interpreting its effect, applying a playbook and drafting a change require different evidence and different levels of professional judgement.

What AI contract review actually does

A useful way to assess an AI contract review tool is to separate four possible functions.

Locate and extract

The system identifies text that may answer a defined question, such as the governing-law provision or the stated notice period. Treat the result as an extraction to verify against the document, not as a legal conclusion. The Law Society notes that strict data extraction may call for a different technical approach from generative text production. Source: Law Society

Compare with stated requirements

The system compares wording with a supplied playbook, checklist or fallback position. The firm should be able to identify which requirement was applied and see the contract wording on which the result depends. This is a proposed review control, not a claim that every product provides it.

Flag an issue

A flag should direct attention to a review question. It should not be treated as proof that a clause is acceptable, unacceptable or missing. The reviewer still needs the relevant text, the agreement as a whole and the instructions for the matter.

Prepare a draft change

A system may produce suggested wording or a redline. That output remains a draft. The SRA says solicitors remain responsible for work produced with AI assistance and must provide competent service and effective supervision. Source: SRA warning notice Source: SRA Code of Conduct

Where AI contract review can fail

The SRA identifies inaccurate information and client confidentiality as particular concerns when AI is used in legal services. It warns that seemingly convincing output may have no factual basis and that both paid and free tools may lack safeguards appropriate to confidential information. Source: SRA warning notice

For a contract-review workflow, convert those general risks into test cases. The following are proposed test cases rather than claims about a particular product:

Run representative examples before relying on a tool. Record the expected answer, the output, the supporting passage and the reviewer's decision. A failed test should lead to correction, a narrower use or a stop decision.

What AI contract review cannot decide for the firm

Even when software extracts the right words, the firm still has to decide what those words mean for the matter. That decision may depend on instructions, commercial context, the rest of the agreement and the firm's professional judgement.

Keep these decisions outside an unreviewed automated step:

This is a proposed decision boundary. It avoids treating a text comparison as though it had resolved the client's objective.

What the SRA expects when firms use AI

The SRA's Code of Conduct requires solicitors to provide a competent and timely service. Where a solicitor supervises or manages others providing legal services, the solicitor remains accountable for that work and must supervise it effectively. Source: SRA Code of Conduct, paragraphs 3.2 to 3.6

The Code also requires the affairs of current and former clients to be kept confidential unless disclosure is required or permitted by law or the client consents. Source: SRA Code of Conduct, paragraph 6.3

The SRA's AI warning notice applies those existing obligations to AI-assisted work. It says that using an AI tool does not transfer responsibility for the quality and accuracy of work. It also calls for appropriate human oversight, informed professional judgement and a proportionate, risk-based approach. Source: SRA warning notice

The practical point is not that one approval process fits every firm. The firm needs controls proportionate to the work, the information involved and the consequence of an error.

A safe AI contract review workflow for a small firm

The following operating model is a proposed starting point. It must be adapted to the firm's work and obligations.

Define the task

State the contract type, the review question, the governing playbook and what the system must not do. A request to identify specified provisions is easier to test than a request to review an agreement generally.

Approve the information route

Before uploading a document, confirm what information the service receives, where it goes, who may access it, how long it is retained and whether the firm's approval covers that use. The SRA says client information should enter AI systems only where appropriate contractual, technical and organisational safeguards are in place. Source: SRA warning notice

Run the first pass

Require the output to point back to the relevant contract text. Preserve the input, tool version or configuration where available, output and time of review so the result can be examined later.

For each finding, a review record can include:

This is a suggested evidence structure. It makes it possible to distinguish a useful first pass from an unsupported conclusion.

Check against the agreement and instructions

The reviewer checks the extracted text, definitions, cross-references, schedules, amendments and the client's instructions. The reviewer also records any issue the system missed or overstated. This is a proposed quality-control checklist.

Make and record the human decision

Name the person authorised to accept, amend, escalate or reject the output. The SRA's supervision guidance says firms should make clear what is delegated, to whom and with what expectations for direction, supervision and control. Source: SRA effective-supervision guidance

Build a test set that reflects the workflow

A demonstration supplied by a vendor may show that a feature can produce an output. It does not establish that the output meets a particular firm's requirements. The Law Society recommends interrogating whether a technology company's claims align with the challenges faced by the firm or team. Source: Law Society

Create a small, controlled test set from examples the firm is authorised to use. Synthetic examples can be useful for testing clearly defined failure modes without exposing client information. If historical documents are considered, confirm that their use and the proposed information route are permitted before including them.

The test set should contain more than straightforward examples. Add cases designed to reveal whether the system:

These are proposed evaluation scenarios. The firm should select scenarios that reflect its own contracts, instructions and risk decisions.

Before the test begins, write down what counts as a pass, what requires human correction and what would make the proposed use unacceptable. Do not redefine success after seeing the output.

Decide whether the workflow is ready

A firm may not be ready to test AI contract review if it cannot yet identify the workflow owner, the review standard or the approved information route. In that situation, documenting the current process may be more useful than selecting software.

Questions to resolve first include:

These are operational readiness questions, not regulatory requirements. A clear stop decision is preferable to a trial that cannot produce reliable evidence.

What useful success evidence looks like

Avoid relying only on whether reviewers liked the interface. A bounded proof should show what happened on the agreed test set.

Useful records may include extraction accuracy for the defined fields, the number and nature of missed issues, false flags, unsupported conclusions, corrections required, review time and any example that could not be completed safely. These are proposed measures, not promised results or universal benchmarks.

The evidence should support one of four decisions: stop, narrow the use, continue testing or proceed to a separately approved implementation. It should also record limitations that remain unresolved.

How the software market fits

Products may be designed around different jobs, data routes and integrations. Use the buying criteria below to test the product against the firm's actual workflow rather than treating categories or feature lists as rankings.

Define the job before choosing software

Write down the workflow in operational terms:

Agree the decision owner before inviting suppliers. That person should be able to state what evidence will justify stopping, narrowing or continuing the purchase. Record which questions belong to the workflow owner, information-security reviewer, data-protection lead and responsible legal reviewer. This is a suggested allocation exercise, not a prescribed governance structure.

Buying criteria for a UK firm

Information security and data use

Ask what information the supplier receives, where it is processed, who can access it, how it is protected, whether it is used to train models, how long it is retained and how deletion is evidenced.

The SRA says client information should enter an AI system only where appropriate contractual, technical and organisational safeguards are in place. It says firms should understand access, training and retention arrangements. Source: SRA warning notice

The ICO recommends due diligence on third-party AI systems, clear allocation of controller and processor responsibilities, audit or checking rights, and agreed accuracy expectations where relevant. Its guidance is currently marked as under review following legislative change, so confirm the current position during procurement. Source: ICO

Jurisdiction and source coverage

Ask the supplier to identify the jurisdictions and source sets used for the exact feature being tested. Require a demonstration showing how the system handles a clause governed by the law relevant to the firm's work. Do not infer jurisdictional suitability from a general claim that the product is designed for legal use.

Playbook control

Ask whether the firm can supply its own positions, fallbacks and escalation rules. Check how a reviewer can identify which rule produced a flag or draft. This is a proposed verification control, not a statement that every product offers playbook functionality.

Evidence and review

Require each material finding to point back to the contract text. Decide which outputs require review and who may approve them. The SRA says solicitors remain accountable for work carried out through those they supervise and must supervise effectively. Its AI warning notice says AI use does not transfer responsibility for quality or accuracy. Source: SRA Code of Conduct Source: SRA warning notice

Integration and permissions

Map every system the product can read from or write to. Test whether matter-level permissions, information barriers and approval steps remain effective. The Law Society's buying guide recommends assessing compatibility and integration with existing systems before purchase. Source: Law Society

Commercial model

Ask the supplier to state every charge that could apply to the proposed workflow. Check whether charging is linked to users, documents, usage, storage, integrations, implementation, support or another unit. Use the supplier's current written quotation and terms. Do not rely on an undated directory or an assumed market price.

Exit and portability

Ask how the firm can retrieve documents, playbooks, configuration, audit records and outputs at the end of the service. Confirm deletion responsibilities and any transition assistance in writing. The NCSC's supplier-assurance questions include return of data and assets, transfer to another supplier and secure disposal at contract exit. Source: NCSC supplier assurance questions

Understand the product category

Use categories to narrow the search, not to rank products:

These are working procurement categories, not claims about named vendors. A product should be assessed on its current documented behaviour and the result of the firm's own bounded test.

Check pricing without inventing a market rate

Published pricing is often incomplete or dependent on scope. For each candidate, request a written total for the defined workflow and record:

This is a pricing-enquiry checklist. It does not claim that a particular charging model or amount is typical.

Review the supplier terms as part of the product

The operational promise in a demonstration is only one part of the buying decision. Compare it with the written contract, data terms, service description and support arrangements. Record any capability that was shown but is not included in the proposed package. This is a procurement recommendation.

For an AI service processing personal data, the ICO recommends documenting roles and responsibilities and using contracts that permit appropriate checks on compliance. Its guidance also recommends setting acceptable accuracy expectations before procurement where accuracy is relevant. Source: ICO

Run a bounded pilot

The following is a proposed evaluation method, not a regulatory prescription.

Freeze the test set

Use representative, authorised examples with expected results recorded before the software is run. Do not use live confidential material until the information route is approved.

Define acceptance and rejection

List the findings the system must identify, the errors that require rejection and the evidence the reviewer must be able to inspect.

Keep the comparison fair

Run the same tasks against the same playbook. Record configuration changes rather than adjusting one candidate until it passes.

Measure review work as well as output

Record missed issues, false flags, unsupported conclusions, time needed for checking and any step that could not be audited. These are proposed evaluation measures.

End with a written decision

Choose to stop, narrow, continue or proceed to a separately governed implementation. Record the evidence, limitations, owner and next approval required.

Questions to take into a demonstration

Frequently asked questions

Can AI review a contract without human checking?

For legal work in an SRA-regulated firm, using AI does not remove professional responsibility, and the SRA calls for appropriate human oversight. The appropriate check depends on the task and risk. Source: SRA warning notice

Is a public chatbot suitable for client contracts?

Do not assume so. The SRA warns that AI services may lack contractual and technical safeguards needed for confidential information. The firm should approve the specific service and information route before use. Source: SRA warning notice

What should a firm test first?

Start with one bounded, repeated task and representative examples. Define the expected result and rejection conditions before running the tool. This is a practical testing recommendation, not a regulatory rule.

If your firm needs to decide whether one contract workflow is suitable for a bounded proof, book a free fit call.