Map the Data Before You Can Govern It
Before writing a single governance procedure, Halstead & Cole must understand exactly what data moves through each AI system — from the fee earner's keyboard to the model's inference server and back. Most law firms that have had AI-related data breaches did not know this map existed. This section builds it.
Each row below maps one AI system from input data through inference to output. The governance status column shows the current control state. Every cell coloured red is a current gap. This is the working definition of the problem Module 04 solves.
HC-SYS-001 — Commercial LLM (Claude Sonnet · Anthropic PBC)
HC-SYS-002 — Contract Review Tool (Vendor Unknown)
HC-SYS-003 — Word Macro Prompts (Internal)
UK GDPR Article 46 — The International Transfer Obligation
Under UK GDPR Article 46, a controller may only transfer personal data to a third country (such as the United States) where appropriate safeguards are in place. The approved mechanisms under the UK GDPR are: (a) the UK International Data Transfer Agreement (UK IDTA); (b) the UK Addendum to the EU Standard Contractual Clauses; or (c) an adequacy regulation covering the destination country. The United States does not have a UK adequacy regulation in force as of 2026. When Halstead & Cole submits client personal data to the Anthropic API, it is executing an international transfer with no documented safeguard in place. This is RISK-003 in REG-AIMS-RISK (RS = 20). This module closes it.
Data Governance — Knowing What Enters the AI and What Comes Back
ISO/IEC 42001 Clause 8.3 requires the organisation to ensure appropriate measures are in place for data used in AI systems — covering acquisition, processing, storage, and disposal. At Halstead & Cole, this means a documented procedure that every fee earner using an AI tool shall follow. The document is SOP-AIMS-DATA-001.
What Clause 8.3 Actually Requires — In Plain English
Clause 8.3 of ISO/IEC 42001:2023 requires the organisation to implement appropriate measures for data management across the AI system lifecycle. For Halstead & Cole, "appropriate measures" means: knowing what categories of data are permissible inputs to each AI tool; ensuring personal data is not submitted to a cloud AI tool without a valid legal basis and DPA; defining how long AI-generated outputs are retained; and establishing a deletion procedure when a matter closes. The SOP does not need to be long — it needs to answer four questions for every AI system: what data goes in, where does it go, how long is it kept, and how is it deleted?
Define permissible data categories for each AI system
The SOP shall specify, per AI system, which categories of data fee earners are permitted to submit. For HC-SYS-001: fee earners may submit anonymised matter facts, general legal questions, and draft text for style improvement. Fee earners shall not submit: client names, addresses, financial information, or any data that would identify an individual, until a signed DPA and valid UK Article 46 transfer mechanism are in place. For HC-SYS-003: fee earners shall not use the Word macro for any input containing identifiable client data until the inference location of the macro is confirmed as either local or covered by an executed DPA. Data minimisation is not a nice-to-have — it is a UK GDPR Article 5(1)(c) requirement.
Establish a DPA tracking register as part of SOP-AIMS-DATA-001
The SOP shall include or reference a DPA tracking register: a simple table recording, for each AI system using cloud inference, the vendor name, DPA reference number, execution date, transfer mechanism type (UK IDTA or UK Addendum to SCCs), and review date. No personal data shall be submitted to any system where the DPA status field is blank or marked "not executed." The AIMS Programme Lead shall update this register whenever a DPA is signed and shall notify the AI Risk Owner (Priya Anand) within 24 hours. The tracking register is assigned document ID REG-AIMS-DPA-001 and shall be stored in the AIMS document control register alongside SOP-AIMS-DATA-001.
Define data retention periods for AI inputs and AI-generated outputs
UK GDPR Article 5(1)(e) requires that personal data is kept no longer than necessary for the purpose for which it was processed. For AI systems, this creates two distinct retention questions. First: how long does the vendor retain input data submitted via the API? This must be documented per system in REG-AIMS-DPA-001 — obtained from the vendor's data processing terms. Second: how long does the firm retain AI-generated outputs? The SOP shall specify: AI-generated drafts that are incorporated into client files shall follow the firm's standard matter file retention policy (minimum 6 years post-matter close, consistent with Limitation Act 1980). AI-generated outputs that are not incorporated into a client file shall be deleted within 30 days.
Address legal professional privilege — the specific risk for law firms
This provision is unique to legal practice and has no direct ISO 42001 clause equivalent — but it is a critical SRA compliance requirement. The Upper Tribunal has held that uploading a client's confidential document to an open-access AI tool may waive legal professional privilege over that document. SOP-AIMS-DATA-001 shall include an explicit prohibition: legally privileged documents — including client communications, counsel's opinions, and privileged litigation materials — shall not be submitted to any AI system where the vendor's terms of service permit use of API inputs for model training or safety research. The SOP shall define how fee earners identify whether a document is privileged and the escalation path when in doubt (AI Risk Owner approval required before submission).
Establish a data deletion procedure for matter close and subject access requests
The SOP shall specify what happens to AI-related data when a client matter closes. For HC-SYS-001: the AI System Owner shall confirm with the vendor, via the DPA terms, whether a deletion request can be submitted for data processed during the matter. Where the DPA provides for deletion on request, the AIMS Programme Lead shall submit a deletion request within 30 days of matter close. Where the vendor does not provide deletion capability, this shall be documented as a residual risk in REG-AIMS-RISK and reviewed at the next annual AIMS Management Review. Under UK GDPR Article 17, individuals may request erasure of their personal data. If a client or data subject makes such a request, the deletion procedure under the DPA is the operative mechanism — and if no DPA exists, the firm has no mechanism to comply.
Document control block and fee earner communication requirement
SOP-AIMS-DATA-001 shall carry the full AIMS document control block: Document ID, Version 1.0, Issue Date, Approver (COLP — Priya Anand), Classification (Internal — Controlled), Retention (7 years, UK Companies Act 2006), Review trigger (annually, or following any AI-related data incident or new AI system deployment). The SOP shall be communicated to all fee earners who use any of the three in-scope AI systems. Communication shall be documented: a signed acknowledgement record or a timestamped email trail constitutes evidence of communication. Under ISO 9001:2015 Clause 7.3, awareness of the policy is not sufficient — documented evidence of communication is required. Undocumented communication is, for audit purposes, communication that did not occur.
"Priya issued SOP-AIMS-DATA-001 to all fee earners on a Thursday afternoon. By Friday morning she had four replies asking what to do about client files they had already submitted to the commercial LLM. That was the moment she understood that the data governance problem was not hypothetical. It had already happened."
— Halstead & Cole LLP — AIMS Implementation NarrativeWhen the AI Vendor Updates the Model — What Does the Firm Do?
ISO/IEC 42001 Clause 8.2 requires organisations to manage AI systems throughout their lifecycle — from the decision to acquire them through to their retirement. For Halstead & Cole, this addresses RISK-004 directly: HC-SYS-001's underlying model has been updated twice since the firm started using it. Neither update was assessed. Neither was recorded. The output quality may have changed both times without anyone knowing.
Why Model Version Changes Are a Governance Event, Not an IT Event
When an AI provider updates the underlying model — even a minor version increment — the system's behaviour can change materially. Tone may shift. Citation patterns may change. The model's handling of ambiguous legal questions may produce different outputs. For a law firm, where the output of the AI system is used in client advice, a silent model change is a silent change to the quality of that advice. ITIL 4's Change Enablement practice defines a change as "the addition, modification or removal of anything that could have an effect on IT services." An AI model update is a change under this definition. It requires documentation, assessment, and controlled implementation — not automatic acceptance. Clause 8.2 of ISO/IEC 42001:2023 formalises this as a management system requirement, not just a technology preference.
Stage 04 is the stage most frequently encountered in practice. Anthropic and other commercial AI providers update their models on a continuous basis. Without a documented procedure, every update is an uncontrolled change to a system the firm relies on for client-facing outputs. SOP-AIMS-LIFECYCLE-001 shall specify the following procedure for model version changes:
Pin the model version in all production API configurations
The AI System Owner for HC-SYS-001 shall immediately update all API call configurations to specify the model version string explicitly (e.g., the specific dated model release identifier from the provider's documentation) rather than a generic alias such as "latest." This is OBJ-005 from REG-AIMS-OBJ-001. From the date of pinning, any change to the model version is a deliberate decision, not an automatic update. The pinned version shall be recorded in REG-AIMS-SYS-001 v1.1 with the date of pinning documented.
Assess every proposed model version change before implementation
When the AI System Owner identifies that a newer model version is available — or when the current pinned version is deprecated by the vendor — a model change assessment shall be completed before the API configuration is updated. The assessment shall cover: (a) what the vendor has documented about behavioural changes in the new version; (b) a sample test comparing outputs from the current and proposed new version on at least five representative matter types; (c) the AI Risk Owner's written approval if any material output quality difference is observed. The assessment shall be documented with reference ID format CHG-AIMS-SYS-001-[nnn] and filed in the AIMS document control register.
Apply version control to all AI prompts — including the Word macro instructions
This closes RISK-011, RISK-012, and RISK-013 for HC-SYS-003. The AIMS Programme Lead shall extract all prompt instructions currently embedded in Word macros and store them in a version-controlled repository — this may be a Git repository, a SharePoint document library with version history enabled, or a structured folder on the firm's document management system, provided version history is retained and recoverable. Each prompt version shall carry: a unique version identifier, the date it was introduced, the name of the person who approved it, and a description of what changed from the previous version. The prompt in effect at any given time shall be deterministic: if a client matter generates an AI output on a given date, it shall be possible to identify exactly which prompt version was used.
Treat model deprecation notices as critical change events
AI providers issue advance notices when a model version is to be deprecated. These notices shall be monitored by the AI System Owner and treated as a triggered change event under Stage 04. The AI System Owner shall: notify the AIMS Programme Lead and AI Risk Owner within 24 hours of receiving a deprecation notice; initiate a model change assessment (step 02 above) within five working days; complete the change and update REG-AIMS-SYS-001 before the deprecation date. Failure to complete the change before deprecation may result in API call failure — a service disruption that affects the firm's ability to use the AI system for active matters. This is an operational risk, not merely a governance concern.
The ITIL 4 Connection — Change Enablement Applied to AI
ITIL 4's Change Enablement practice defines three change types by risk and frequency. Standard changes are pre-approved, low-risk, and well-understood — a prompt wording adjustment that does not change the output category qualifies. Normal changes require assessment and approval before implementation — a model version upgrade is a normal change. Emergency changes are implemented with minimum process due to urgency — a critical model bug fix requiring immediate rollback is an emergency change. SOP-AIMS-LIFECYCLE-001 shall adopt this classification explicitly. The classification of each AI change type determines the level of documentation required, the approval authority, and the speed at which the change can be implemented. This provides proportionality without sacrificing auditability.
Your AI Vendor Is Part of Your Risk Profile — Whether You Have a Contract with Them or Not
ISO/IEC 42001 Clause 8.4 requires the organisation to determine and implement appropriate controls for externally provided AI systems or components that could affect the AIMS. At Halstead & Cole, this means formally assessing and contracting with every AI vendor before client data enters their systems. Currently, this has not happened for any of the three in-scope systems.
What "Supply Chain Governance" Means for a Law Firm Using AI
Supply chain governance under ISO/IEC 42001 Clause 8.4 has three components for Halstead & Cole. First: supplier assessment — before a new AI system is deployed, the vendor's data processing terms, security posture, and UK GDPR compliance position shall be formally assessed. Second: contractual controls — a Data Processing Agreement shall be executed with every vendor whose systems receive personal data, specifying the purposes for which data may be processed and prohibiting use for model training without consent. Third: ongoing review — the supplier register shall be reviewed annually and whenever the vendor materially changes its terms of service. An AI vendor that changes its terms to permit training on API inputs without notice has materially changed the risk profile of the firm's data submitted through that vendor's API.
| Review Trigger | Required Action | Owner | ISO Clause |
|---|---|---|---|
| Annual (each year from AIMS establishment date) | Review all entries in REG-AIMS-SUP-001. Confirm DPAs are current. Re-assess vendor security posture. Update risk scores in REG-AIMS-RISK where vendor position has changed. | AIMS Programme Lead | Cl. 8.4 / Cl. 9.3 |
| Vendor ToS change (any material amendment) | Assess impact of ToS change on data processing basis, training-use prohibition, and transfer mechanism. If the change removes protections previously relied upon, suspend use and notify COLP within 24 hours. | AI System Owner (per system) | Cl. 8.4 / Cl. 6.1 |
| New AI system proposed for deployment | Complete supplier assessment for new vendor before any personal data is submitted. Assessment shall follow the template in SOP-AIMS-LIFECYCLE-001 Stage 01. DPA must be executed before production deployment. | AIMS Programme Lead + COLP | Cl. 8.4 / Cl. 8.2 |
| AI-related data incident involving vendor | Initiate incident procedure PROC-AIMS-INC-001 (Module 05). Assess whether the incident constitutes a UK GDPR personal data breach requiring ICO notification within 72 hours under DPA 2018 Section 67. | COLP (Priya Anand) | Cl. 10.1 / UK GDPR Art. 33 |
Vendor Exit Strategy — The Dependency Risk Most Firms Ignore
REG-AIMS-SUP-001 shall include a vendor exit strategy for each supplier. The exit strategy does not need to be immediately executable — it needs to be documented. For Anthropic (HC-SYS-001): identify an alternative commercial LLM provider with comparable capability and GDPR-compliant data processing terms; document the prompt migration steps; estimate the time to switch. For the HC-SYS-002 vendor (once identified): document the contractual exit provisions and data deletion process. A firm with a documented exit strategy is a firm that has genuinely assessed its AI supplier dependencies — and that assessment is itself evidence of governance maturity that an SRA auditor or PI insurer will recognise.
The Disclosure the SRA Says You Must Already Be Making
ISO/IEC 42001 Annex A, Control A.2 requires organisations to implement appropriate transparency measures for AI systems. The SRA's compliance tips, updated 9 February 2026, state explicitly: "it should always be made clear to clients where they are interfacing with AI." At Halstead & Cole, no AI-assisted correspondence or document has ever carried this disclosure. Every AI output the firm has produced for clients in the last eight months has been sent without it.
This Is Not a Future Obligation — It Is a Current One
The SRA Code of Conduct for Firms 2019, Rule 7.1, requires firms to give clients information in a way they can understand and in a manner that meets their needs. The SRA's February 2026 AI guidance makes the transparency requirement explicit. Neither provision has a future commencement date. They apply now. When the dispute resolution team at Halstead & Cole sends a client a research summary produced by HC-SYS-001 without disclosing that AI was used, the firm is in breach of both the SRA Code Rule 7.1 and the SRA's own AI guidance. This has been the case for every AI-assisted output the firm has produced since it began using the commercial LLM. The disclosure document produced in this section remedies this from the date of issue — it does not remedy what has already been sent. The COLP should consider whether retrospective disclosure to any client who acted materially on AI-assisted advice is appropriate.
Two Distinct Disclosure Types for Halstead & Cole
DOC-AIMS-DISC-001 shall define two disclosure formats. Type A — Inline disclosure: a short statement embedded in AI-assisted correspondence or documents, appearing prominently near the top of the document. Used for: letters, research summaries, contract review outputs, or any document where AI was used to draft, summarise, or analyse. Type B — Client engagement disclosure: a paragraph in the firm's Client Care Letter and Terms of Engagement, informing clients at the outset of the matter that the firm uses AI tools and explaining the human oversight process. This proactive disclosure satisfies the transparency obligation prospectively and avoids repeated inline disclosures on every document — provided the client has been informed at matter inception. Halstead & Cole shall implement both types. Type B shall be added to the Client Care Letter template immediately upon issue of DOC-AIMS-DISC-001.
AI Assistance Disclosure
AI Tools — Client Information Notice
"It should always be made clear to clients where they are interfacing with AI."
— SRA Compliance Tips for Solicitors Regarding the Use of AI and Technology · Updated 9 February 2026Issue DOC-AIMS-DISC-001 and update the Client Care Letter template immediately
The Type B disclosure shall be added to the Client Care Letter template used by all practice groups within five working days of this module being completed. The updated template shall be version-controlled in the firm's document management system. The AIMS Programme Lead shall notify all fee earners of the update and confirm that the new template is in use. For any active matter where the Client Care Letter was issued before the disclosure was added, the supervising solicitor shall assess whether a supplementary disclosure letter to the client is appropriate — particularly for matters where AI-assisted work has already been delivered.
Train all fee earners on when and how to apply the Type A inline disclosure
The Type A disclosure shall be applied to every document or correspondence where AI assistance was used in drafting, summarisation, or analysis. "AI assistance" includes: any use of HC-SYS-001, HC-SYS-002, or HC-SYS-003 to produce text or analysis that is included in the output sent to the client. It does not include: using AI tools solely for internal research that is not reflected in the client-facing document. The distinction matters — it requires fee earner judgment, which requires training. The AIMS Programme Lead shall deliver a 30-minute training session covering when the disclosure applies, how to complete it, and why it matters, within 15 working days of DOC-AIMS-DISC-001 issue. Attendance shall be recorded.
Monitor compliance with the disclosure requirement as an AIMS performance metric
Clause 9.1 of ISO/IEC 42001:2023 requires the organisation to monitor, measure, analyse, and evaluate AI system performance. The disclosure compliance rate is an AI governance metric: what percentage of AI-assisted documents sent to clients in a given quarter carried the Type A disclosure? The AI Risk Owner (Priya Anand) shall include this metric in the quarterly AIMS performance review from the date DOC-AIMS-DISC-001 is issued. A 100% compliance target is appropriate — the SRA's obligation does not permit partial compliance. If any AI-assisted document is identified as having been sent without the required disclosure, this shall be logged as an AIMS non-conformance under Clause 10.1 and assessed for whether client notification is required.
What Halstead & Cole Can Tell the Panel Client Now
The panel client's AI-governance questionnaire asked whether the firm has: a documented AI policy (yes — POL-AIMS-001), a named AI governance lead (yes — Priya Anand, COLP), a risk assessment for AI tools used (yes — REG-AIMS-RISK), a client disclosure procedure for AI-assisted outputs (yes — DOC-AIMS-DISC-001), and a data processing agreement with AI vendors (in progress — DPA-HC-SYS-001-001 target 30 days). Four of five questions can now be answered affirmatively. The fifth has a documented completion plan with a named owner and a deadline. That is a fundamentally different answer to the questionnaire than "we don't have a governance framework" — and it is a commercially meaningful difference.
Phase 3 Completion Checklist
All items on this checklist shall be complete before Halstead & Cole progresses to Module 05 (Human Oversight, Incident Management & Supply Chain Audit). These are minimum requirements under ISO/IEC 42001:2023 Clauses 8.2, 8.3, and 8.4, and Annex A Control A.2. Any incomplete item means the operational controls of the AIMS are not in place.
Module 04 — Complete
Halstead & Cole LLP now has documented data governance procedures, a lifecycle management framework with model version pinning and prompt version control, a formally assessed and contracted AI supplier register, and a client disclosure procedure that satisfies both the SRA's February 2026 AI guidance and ISO/IEC 42001 Annex A Control A.2. The panel client questionnaire can now be answered. Proceed to Module 05 when every item on the Phase 3 checklist has been completed and countersigned by the Senior Partner and COLP.
Module 05 — Preview: Human Oversight & Incident Management
Module 05 builds the controls that operate every day a fee earner uses an AI tool. The Human-in-the-Loop procedure (PROC-AIMS-HITL-001) defines exactly how a fee earner reviews, approves, and signs off an AI-assisted output before it reaches a client — closing RISK-001 and RISK-002 from REG-AIMS-RISK. Module 05 also builds the AI Incident Procedure (PROC-AIMS-INC-001): what Halstead & Cole does when the AI produces a fabricated citation, sends incorrect advice to a client, or triggers a potential UK GDPR breach requiring ICO notification. By the end of Module 05, the firm will have a fully operational governance framework — one that can withstand an SRA thematic review visit.