Define what the supervision record should establish
A checkbox saying AI reviewed is not evidence that the output was checked. The record should let the supervising lawyer understand the task, assess the review performed, and identify anything still open. Design it around the work product, not around a catalogue of every prompt a user typed.
The SRA's material on responsible AI use is relevant to regulated practice. The fields below are an editorial proposal for putting supervision into operation, not an SRA-mandated form. Adapt the record to the team's obligations, client terms, and information-governance policy.
Record the task and the permitted boundaries
| Record | Useful entry |
|---|---|
| Purpose | Prepare a first research note on a defined issue |
| Inputs | Approved authorities and specified matter documents |
| Restrictions | Material excluded from the tool and limits on sharing |
| Output owner | The lawyer responsible for checking this result |
| Completion rule | Sources verified and open issues resolved or expressly reserved |
Keep matter-sensitive details in the approved matter system. A central adoption dashboard usually needs a status and an owner, not the underlying confidential prompt or advice.
Describe the review that actually occurred
For research, record whether citations were opened, passages checked, and later treatment assessed. For drafting, identify which clauses were reviewed against instructions and which assumptions require confirmation. For a chronology, state whether event dates were checked against their source documents.
Consider a draft that correctly extracts a termination date but mistakes an internal target for a contractual deadline. A useful log records the correction and its source. A generic approved label hides the error pattern and gives the team no reason to improve its instructions or training.
Give reviewers a workable escalation route
Set clear reasons to stop and escalate: missing authorities, uncertain confidentiality permissions, conflicting documents, or a result outside the reviewer's competence. Assign a person who can decide what happens next. A junior colleague should not have to resolve a vendor-security question during a filing deadline.
Separate a correctable output error from a suspected disclosure or security incident. Both need an owner, but the latter may require a different internal response. Retain only the information needed to investigate and follow the organisation's established incident process rather than spreading the sensitive material through informal messages.
Review patterns without creating administrative noise
Periodically sample completed logs and compare them with the underlying work. Look for recurring assumptions, unsupported quotations, repeated manual corrections, and tasks where verification consumes more time than expected. Use those findings to narrow the approved use case or improve training.
For in-house teams, distinguish business approval from legal review. For firms, connect the record to the supervising matter lawyer. Avoid presenting the log as proof that every result is accurate or that regulatory compliance is automatic. Its value lies in making responsibility and actual review visible.
Sources and next steps
This is an editorial workflow guide for legal professionals. The suggested checks are our practical recommendations, not a statement that a regulator requires a particular software workflow.
Explore Legal Research and Drafting, or review Judicio's regional coverage and limitations. Check the underlying source and your organisation's approved process before relying on an output.