Two Firms, One Final Gap
For the first six modules, the scenario firm was Halstead & Cole LLP — a 90-fee-earner regional practice using commercially-hosted AI tools. This final module introduces a second scenario firm: Thornbury Legal Ltd., a mid-sized commercial firm that has taken a different route — operating a self-hosted contract analysis model on its own infrastructure. The two firms illustrate the two ends of the supply chain configuration spectrum.
Self-hosted ≠ self-governed
Operating an AI model on your own infrastructure does not eliminate the supply chain governance obligations under ISO 42001 Clause 8.4 — it changes their form. Where an API customer's governance burden falls primarily on vendor assessment and contractual controls, a self-hosted operator's burden includes: foundation model licence compliance, inference infrastructure security, fine-tuning data provenance, update pipeline governance, and operational resilience planning. Thornbury Legal has none of these documented. The self-hosted arrangement that appears to give the firm maximum control in fact exposes it to the maximum number of ungoverned supply chain risks.
For Halstead & Cole — using commercially-hosted APIs and SaaS tools — the supply chain gap is narrower but still present: each vendor is a node in a supply chain that the firm has assessed at the product level but not at the component level. OpenAI's API uses Microsoft Azure infrastructure. Microsoft 365 Copilot uses OpenAI models. LEAP AI uses third-party inference components. None of these sub-processor relationships are documented in the firm's governance framework.
ISO 42001 Clause 8.4 requires both firms to close this gap. REG-AIMS-SUP-001 is the supply chain register that does it.
Three Supply Chain Configurations, Three Different Burdens
Clause 8.4 scales with the complexity of the supply chain arrangement. Three configurations arise in law firm AI deployments — each with distinct governance requirements. The clause creates an obligation that applies to every AI system in the register, regardless of how it is procured.
Plain English summary
Clause 8.4 obligates the firm to govern how its AI systems are sourced — not just what they do. A self-hosted model carries more governance burden than a commercially-hosted one because the self-hosted operator becomes responsible for layers the API customer delegates to the vendor. This is not a punishment for sophistication — it is a proportionate response to the fact that the self-hosted operator is in fact making more decisions with less vendor support.
Clause 8.4 and Clause 8.3 are complementary
Clause 8.3 (Module 07 · REG-AIMS-DATA-001) addresses what data goes into AI systems and on what legal basis. Clause 8.4 (this module · REG-AIMS-SUP-001) addresses the governance of the AI components themselves — their provenance, performance standards, and failure modes. The two are complementary: REG-AIMS-DATA-001 records the data dimension; REG-AIMS-SUP-001 records the component dimension. A firm that has one without the other has incomplete supply chain governance under the standard.
What Goes in Each Part of REG-AIMS-SUP-001
REG-AIMS-SUP-001 is a three-part register — one part per supply chain layer. Click each layer to see what it records, which systems it covers, and what an audit would flag if the layer is incomplete.
For each AI vendor in REG-AIMS-SYS-001, document: the vendor's published AI governance framework (ISO 42001 alignment, responsible AI commitments, model update process, bias assessment approach), the contractual AI governance terms in the DPA or service agreement, the vendor's incident response obligations, and whether the vendor has undergone independent AI governance assessment or certification.
This is primarily a desk research exercise for major vendors — OpenAI, Microsoft, and LEAP all publish sufficient information to complete Layer 1. For specialist legal AI vendors (like Thornbury's contract model provider), a formal vendor questionnaire is required.
Audit evidence: the assessment record for each vendor, dated, with source references to vendor documentation.
For each system, document: the hosting jurisdiction, the infrastructure provider (Azure, AWS, GCP, or own servers), the data residency configuration, the security certifications held by the infrastructure provider (ISO 27001, SOC 2, etc.), and the sub-processor relationship between the AI vendor and the infrastructure provider.
For API deployments, much of this is documented in the vendor's security whitepaper. For self-hosted deployments, the firm is the infrastructure provider and must document its own controls.
Audit evidence: the infrastructure certification register, the data residency confirmation, and the sub-processor map.
Document: the foundation model or base model used (where known), the model provider's terms of use (particularly restrictions on fine-tuning, commercial use, and output use), the training data provenance (what datasets were used, consent and copyright concerns), and — for self-hosted fine-tuned models — the provenance of the fine-tuning data specifically.
For Thornbury Legal, Layer 3 requires a legal opinion on the fine-tuning data before the register entry can be marked Confirmed. This is the layer where most firms have the largest documentation gap — and the layer where the regulatory exposure is highest.
Audit evidence: the model licence review, the training data provenance record, the fine-tuning data legal opinion (if applicable).
The Self-Hosted Contract Model — Governance Thornbury Did Not Anticipate
Thornbury Legal Ltd. operates a self-hosted contract analysis model deployed on its own infrastructure. The model was procured from a specialist legal AI vendor and fine-tuned on the firm's historical contracts. It is used daily by its commercial team. The firm believes it controls this system completely. It does not.
The base model on which the fine-tuning was performed was itself trained by a third party — a foundation model provider whose terms govern what the model may be used for, how it may be modified, and what update obligations apply. The inference layer running the model locally uses open-source components with their own licensing and security obligations. The fine-tuning dataset included contracts from Thornbury's former clients. The firm did not obtain those clients' consent for their contracts to be used as AI training data. This is potentially both a breach of client confidentiality under SRA Principle 6 and a UK GDPR violation (almost all commercial contracts contain personal data).
When the vendor released an update to the fine-tuning pipeline last quarter, the firm applied it without any governance review. The new pipeline produced better results in the vendor's tests — but included a model behaviour change that Thornbury's risk register had not flagged and that its human oversight procedure did not catch.
REG-AIMS-SUP-001 forces this question into documented governance rather than leaving it as an unconsidered legacy risk. Before Layer 3 can be marked Confirmed for the self-hosted model, Thornbury must: (1) review the foundation model licence in full; (2) obtain a written legal opinion on the fine-tuning dataset's client-data implications; (3) conduct a DPIA; (4) document the update pipeline governance. Until these are complete, the model should be classified as Under Review and its use restricted to non-client matters.
"Firms should understand the AI tools they use, including how those tools were built, what data they were trained on, and what protections exist for client information at every stage of processing."
— SRA · Compliance Tips for Solicitors Regarding the Use of AI and Technology · 9 February 2026Four Supply Chain Failure Patterns
Most firms fail not because they ignored Clause 8.4 — they fail because some vendor or product assessment existed without extending to the sub-processor, infrastructure, or foundation model layers beneath it. Click each non-conformance category to see what an audit would flag.
The firm has assessed the primary AI vendor (OpenAI, Microsoft, LEAP) but has not mapped the infrastructure and foundation model layers beneath it. The sub-processor relationships, hosting jurisdiction, and model training provenance are unknown. This is the universal baseline failure for API and SaaS deployments.
Audit finding: "Sub-processor relationships and infrastructure-layer governance not documented for any registered AI system. Clause 8.4 obligations partially addressed only at Layer 1."
The firm has reviewed the vendor's data protection terms but has not assessed the vendor's AI governance — how they handle model updates, what their incident response process is, how they manage model drift, and whether they conduct bias assessments. This information is publicly available for major vendors (OpenAI, Microsoft) but has not been reviewed or documented.
Audit finding: "Vendor AI governance frameworks reviewed for data protection only; broader AI governance (model updates, bias assessment, incident response) not reviewed or documented."
For Thornbury Legal, the self-hosted arrangement creates obligations that API access does not: foundation model licence compliance, fine-tuning data provenance (were the training contracts properly consented for AI use?), inference infrastructure security, and update pipeline governance. None of these are documented. The fine-tuning dataset's use of former-client contracts raises both SRA confidentiality and UK GDPR questions that the firm has never formally addressed.
Audit finding: "Self-hosted AI system operates without documented foundation model licence review, fine-tuning data provenance assessment, or update pipeline governance. Client-data exposure potentially unaddressed."
Neither firm has a defined response pathway for a supply chain AI incident — a vendor model update that degrades performance, a foundation model provider that changes its terms to restrict legal use, or a security incident at the infrastructure layer that potentially exposes client data. The lifecycle procedure includes Trigger T8 for supply chain changes — but T8 can only fire if someone is monitoring the supply chain.
Audit finding: "No supply chain incident response procedure defined. Quarterly monitoring of vendor terms and model updates not documented for any registered system."
Building REG-AIMS-SUP-001 in Five Steps
The controlled document that closes Gap 9 is built in five sequential steps. For API and SaaS deployments, the steps are desk-research-driven and can be completed in a working session. For self-hosted deployments (Thornbury Legal), they involve legal review and may extend over weeks.
For each AI vendor, document governance framework and contractual AI terms
Document: the vendor's published AI governance framework (ISO 42001 alignment, responsible AI commitments, model update process, bias assessment approach), the contractual AI governance terms in the DPA or service agreement, the vendor's incident response obligations, and whether the vendor has undergone independent AI governance assessment. For major vendors this is primarily a desk research exercise; for specialist vendors a formal questionnaire is required.
Document the infrastructure layer and the sub-processor map
For each system, record: hosting jurisdiction, infrastructure provider (Azure, AWS, GCP, own servers), data residency configuration, security certifications held by the provider (ISO 27001, SOC 2, etc.), and the sub-processor relationship between the AI vendor and the infrastructure provider. For self-hosted deployments, the firm documents its own controls.
Document the foundation model licence and the training data provenance
Record: the foundation model used (where known), the model provider's terms of use — particularly restrictions on fine-tuning, commercial use, and output use — and the training data provenance. For fine-tuned self-hosted models specifically, record the fine-tuning data provenance and the legal opinion confirming the data was lawfully available for AI training. Without this layer, the foundation model remains an ungoverned risk regardless of how carefully the firm governs Layer 1 and Layer 2.
Designate a monitor and run quarterly reviews
Designate the IT Lead as the supply chain monitor. Quarterly: check vendor terms for material changes, check infrastructure provider certifications for lapses or changes, check foundation model provider announcements for licence or policy changes. Any material change fires Trigger T8 in the lifecycle procedure. Record each monitoring check in the supply chain monitoring log (Part D of REG-AIMS-SUP-001).
Define the escalation path for a supply chain AI incident
A supply chain incident is: a vendor security breach, a material vendor terms change that affects lawfulness, a foundation model licence change that restricts permitted use, or a supply chain component failure that affects AI system performance. The escalation path follows the lifecycle procedure (T8 → Under Review → AGL decision) but adds specific steps for vendor notification obligations and client notification assessment per Module 08's disclosure framework.
Thornbury Legal — minimum actions before production continues
Before REG-AIMS-SUP-001 Part C can be marked Confirmed for the self-hosted model, Thornbury Legal must: (1) obtain and review the foundation model licence in full; (2) obtain a written legal opinion on whether the fine-tuning dataset's use constitutes processing of client personal data and whether consent or another lawful basis was available; (3) conduct a DPIA for the fine-tuning data processing; (4) review and document the update pipeline governance. Until these are complete, the self-hosted model should be classified as Under Review in REG-AIMS-SYS-001 and its use restricted to non-client matters.
What firms cannot verify — and how to document it
Clause 8.4 requires the firm to determine and document its supply chain governance — it does not require the firm to independently verify every vendor claim. Where a vendor makes representations about model training data, bias assessments, or security controls that the firm cannot independently verify, the register documents the representation, its source (public documentation, contractual term, or vendor questionnaire response), and the firm's reliance on that representation. An unverifiable claim is still a governance record; an undocumented claim is a governance gap.
All Nine Gaps Closed. All Sixteen Documents On File.
Completing REG-AIMS-SUP-001 closes the ninth and final gap in the Halstead & Cole and Thornbury Legal AI Management System remediation programme. Both firms now have a complete, ISO 42001-aligned governance architecture — sixteen controlled documents spanning policy, roles, registers, procedures, and client-facing instruments. Below is the complete document suite.
The nine-gap remediation programme — benchmarked against ISO/IEC 42001:2023 and the SRA's AI guidance of 9 February 2026 — is designed to be completed in 90 days. The critical path runs foundation (G1–G4) → operational (G5–G9). A firm that issues POL-AIMS-001 and RACI-AIMS-001 in Week 1, completes the registers by Day 30, and has all procedures operational by Day 75 is in a position to respond to any panel client AI governance questionnaire and satisfy the SRA's expectations — and, with continued quarterly review, build the documented performance history an ISO 42001 certification audit requires.
For Pemberton Capital specifically: the complete document suite, summarised in DOC-AIMS-DISC-001 Template C, answers all five questionnaire questions with specific, dated, document-referenced evidence. The 30-day response window is met. The £620,000 annual relationship is defensible. And the governance architecture that now exists at Halstead & Cole will serve the firm's AI programme for the duration of its growth — not just for this questionnaire cycle.
Final Module Completion Checklist
The completion gate for the final module — and for the entire seven-module ISO 42001 Legal Track. Ticking every box below signals that the complete nine-gap AIMS is operational at Halstead & Cole (with Thornbury Legal's self-hosted configuration addressed in REG-AIMS-SUP-001).