The unanswered question behind every AI deployment in legal practice
When Halstead & Cole's litigation team began using GPT-4o for case chronologies, no one asked the question that ISO 42001 Clause 6.1 requires every organisation to ask before deploying an AI system: what happens when this goes wrong, how likely is that, and what is the impact on a client?
The tool was adopted because it was fast and the output looked accurate. The consideration that guided the decision was not a risk assessment — it was a usability impression. That impression is not governance. It is not a control. And when an AI-generated case chronology contains a fabricated date, a transposed party name, or a citation that does not exist, the absence of a prior risk assessment is not a mitigating factor. Under both ISO 42001 and the SRA's framework, it is an aggravating one: it demonstrates that the firm deployed a system without exercising the professional judgment the standard requires.
Ayinde v Haringey / Al-Haroun v Qatar National Bank [2025] EWHC 1383 (Admin) recorded 18 fabricated AI citations. Dame Victoria Sharp P's judgment established that the submission of AI-generated content without verification is a matter of professional conduct, not merely a technology error. A risk assessment process that identifies "hallucination in legal citation" as a known risk — and then documents a control (verification before filing) — is the paper trail that demonstrates the firm treated AI as a professional tool rather than an infallible search engine. The absence of that paper trail is the absence of that demonstration.
This article explains what Clause 6.1 requires of law firms, why most assessments miss the AI-specific risk factors, and how to build REG-AIMS-RISK-001 — a structured risk and impact register with a worked assessment for each of Halstead & Cole's three AI systems. It also introduces the distinction the standard draws between risk assessment (ongoing, system-level) and impact assessment (triggered, deployment-specific) — a distinction most firm-level AIMS implementations conflate.
Clause 6.1: two obligations, one register
When planning for the AI management system, the organization shall consider the issues referred to in Clause 4.1 and the requirements referred to in Clause 4.2, and determine the risks and opportunities that need to be addressed to give assurance that the AIMS can achieve its intended outcome(s); prevent, or reduce, undesired effects; and achieve continual improvement.
The organization shall plan: actions to address these risks and opportunities; how to integrate and implement the actions into its AI management system processes; and how to evaluate the effectiveness of these actions.
Clause 6.1 creates two distinct but linked obligations, and law firms routinely conflate them or satisfy neither:
Obligation 1 — Risk assessment (continuous)
The standard requires an ongoing process for identifying and evaluating risks at the system level — not a one-time exercise at deployment. For each AI system in REG-AIMS-SYS-001, the firm must maintain a current risk assessment that covers: the likelihood of the risk materialising given the firm's specific use context, the impact if it does, and the controls in place to reduce both. This is the risk register in REG-AIMS-RISK-001 Part A.
Obligation 2 — Impact assessment (triggered)
Clause 6.1, read with Clause 8.4 and Annex A.2 of ISO 42001, requires a specific impact assessment when: (a) a new AI system is being deployed for the first time, (b) an existing system is being extended to a new use case or practice area, or (c) a material change occurs to an existing system (model version change, significant prompt change). This is the impact assessment form in REG-AIMS-RISK-001 Part B. It is not the same as the ongoing risk register — it is a point-in-time structured analysis that must be completed before deployment or change.
Many ISO 42001 implementation guides treat these as synonymous. They are not. Risk assessment is the standing process — it produces the risk register, which is updated quarterly. Impact assessment is the event-triggered deep-dive — it produces a per-system assessment document, which is required before each new deployment or material change. A firm that has a risk register but no impact assessment process fails Clause 6.1. A firm that runs impact assessments but has no standing risk register also fails. REG-AIMS-RISK-001 contains both instruments in one controlled document.
Annex A of ISO 42001 provides a control set that cross-references the risk factors the standard considers most significant for AI systems. The controls most relevant to law firm AI deployments include: A.2.2 (AI system impact assessment), A.3.2 (AI system objectives — risk to people), A.4.7 (data quality governance), and A.6.1.6 (transparency of AI-assisted decisions to affected parties). Each control in Annex A has a corresponding risk that, if unmitigated, feeds directly into the risk register.
Why the SRA and ISO 42001 demand the same thing in different language
The SRA's guidance of 9 February 2026 does not use the phrase "risk assessment." It uses the concept of professional judgment: solicitors must apply professional judgment to AI output before relying on it, and they must consider the risks to clients before deploying AI tools in client matters. This is risk assessment under a different name.
"Solicitors should consider the risks of using AI tools before adopting them in practice, including the risk of AI-generated errors going undetected."SRA · Compliance Tips for Solicitors Regarding the Use of AI and Technology · 9 February 2026
The SRA's framing implies that the risk consideration should happen before adoption — not after a client complaint has crystallised it. This pre-deployment obligation is precisely what ISO 42001 Clause 6.1 codifies. A firm that has completed REG-AIMS-RISK-001 for each of its AI systems can demonstrate to the SRA — and to Pemberton Capital's panel questionnaire — that it considered AI risks before deploying those systems in client work, not as a retrospective exercise.
The Pemberton Capital questionnaire's third question — effectively "how do you identify and manage AI-specific risks?" — is a Clause 6.1 probe. A firm that can produce REG-AIMS-RISK-001, even in draft form, has an answer. A firm that cannot is telling a £620,000/year client that it uses AI without a structured process for understanding what could go wrong.
Five patterns of Clause 6.1 failure — and the risk matrix law firms need
The eight AI-specific risk factors for law firms
Standard risk registers apply generic risk factors — likelihood, impact, severity. ISO 42001 Annex A and the legal sector's AI risk landscape require eight factors specific to AI in legal practice. REG-AIMS-RISK-001 scores each system against all eight.
The risk heat map — scoring methodology
REG-AIMS-RISK-001 uses a 5×5 likelihood/impact matrix. Each of the eight risk factors is scored on both axes (1–5), and the product score determines the risk rating: Low (1–4), Medium (5–9), High (10–19), Critical (20–25). Controls reduce the likelihood score — not the impact score. A catastrophic outcome remains catastrophic even if it is made less likely by a control.
Negligible
Minor
Moderate
Major
Catastrophic
Almost certain
Likely
Possible
hallucin.
Unlikely
Rare
◈ Marker: GPT-4o hallucination risk in litigation use — Likelihood 3 (Possible) × Impact 4 (Major) = Score 12 (High) · Controls reduce likelihood, not impact
Building REG-AIMS-RISK-001: the five-step assessment process
The risk register closes Gap 4 and is the analytical foundation for Gaps 5, 6, 7, and 8. Without it, the controls in those gaps cannot be proportionately calibrated — you cannot determine the right oversight mechanism (Gap 8) without knowing the risk level, and you cannot decide whether client disclosure is required (Gap 7) without having assessed the impact on affected parties.
Worked assessment — AIMS-SYS-001: GPT-4o in Litigation
The following extract shows the Part A risk assessment for Halstead & Cole's GPT-4o deployment, as it would appear in REG-AIMS-RISK-001 at initial issue — before controls are fully implemented. This represents the honest baseline: inherent risk high, controls partially in place, residual risk still elevated until PROC-AIMS-HITL-001 (Gap 8) is fully implemented.
The worked assessment above shows two High-rated risks remaining unmitigated at initial register issue: Transparency/Client Disclosure (score 15) and Human Oversight Adequacy (score 16). These scores will remain at High until G7 (DOC-AIMS-DISC-001) and G8 (PROC-AIMS-HITL-001) are implemented. REG-AIMS-RISK-001 must record these as open risks with target remediation dates. An AI system with unmitigated High risks may continue in use if the AGL explicitly accepts the residual risk in writing and records a remediation timeline — it may not continue in use as though the risk does not exist.
REG-AIMS-RISK-001: AI Risk & Impact Register
The controlled document that closes Gap 4 is available below. It includes Part A (the eight-factor risk register with scoring methodology, pre-populated for AIMS-SYS-001 through AIMS-SYS-004 as worked examples), Part B (the structured impact assessment form for new deployments and material changes), a risk acceptance record for High-rated residual risks, and the quarterly review log.
Part A: 8-factor risk register with 5×5 scoring matrix, worked assessments for AIMS-SYS-001 to 004, residual risk ratings, and control documentation · Part B: impact assessment form for new deployments · Risk acceptance record for High+ residual risks · Quarterly review log · Version control. Complete Part A for each registered system before G5–G8 remediation begins.
Implementation sequence: Part A risk assessments for AIMS-SYS-001 (GPT-4o) and AIMS-SYS-003 (Copilot Outlook) should be completed first — both carry unmitigated High risks that must be on record before those systems continue in client-facing use. AIMS-SYS-002 (Copilot Word) and AIMS-SYS-004 (LEAP AI) are lower priority but must be assessed within 30 days of register issue. Any system identified in the G3 discovery sweep that does not yet have a Part A entry must be assessed before it enters or continues in client work.
REG-AIMS-RISK-001 is the document that gives the rest of the AIMS its proportionality rationale. The oversight mechanism in PROC-AIMS-HITL-001 (G8) is calibrated to the risk tier from this register. The client disclosure trigger in DOC-AIMS-DISC-001 (G7) depends on the impact assessment in Part B. The data governance controls in REG-AIMS-DATA-001 (G6) are prioritised by the confidentiality and data leakage scores here. Without Part A being current and complete, those downstream documents are structurally disconnected from the evidence base that justifies their controls.
G4's position in the remediation programme
Gap 4 is the analytical pivot of the entire AIMS. Completing it closes the last Critical prerequisite before the operational controls (G5–G8) can be meaningfully implemented. The 90-day programme from this point proceeds in two parallel tracks:
The next article covers Gap 5: AI system lifecycle management under ISO 42001 Clause 8.2. Once the risk register is in place and systems are classified by risk tier, the lifecycle procedure provides the governance framework for what happens to those systems over time — from pre-deployment approval through active monitoring to decommissioning.