From Legal Threshold to Runtime Checkpoint: Operationalising the Substantial-Modification Test for Fine-Tuned GPAI Models

Author: #Japmandeep Singh Ahluwalia

Affiliation: Luxyn Ethics & Governance, Gurgaon, India

https://www.aimsguard.org/

Abstract

The EU AI Act imposes graduated obligations on providers of general-purpose AI (GPAI) models. A critical unresolved question concerns modifications: when does fine-tuning cross from insubstantial adjustment to substantial modification, triggering new provider obligations? Hacker and Holweg (2026) propose a hybrid legal test combining compute-based thresholds with consequence scanning. Their framework, however, stops at the threshold. It does not address how an organisation actually enforces that finding inside a running system. This paper closes that gap by demonstrating how the Accountability Triggers framework—hard-coded execution checkpoints that pause high-risk AI decisions and require documented human review—can operationalise the substantial-modification test as a runtime mechanism. When a fine-tuning event crosses the hybrid threshold, the trigger halts deployment and forces documented human review, discharging both the Article 14 human oversight obligation and the documentation burden for the "new manufacturer" defence under the revised Product Liability Directive. The paper provides a worked example from a regulated sector and addresses the framework's limitations.

Keywords: EU AI Act, GPAI, substantial modification, human oversight, accountability triggers, fine-tuning, product liability

1. Introduction

The EU AI Act creates a layered compliance regime. GPAI providers face transparency obligations under Articles 53–55. High-risk AI systems face more stringent requirements under Title III, including Article 14's human oversight mandate. The Digital Omnibus agreement of 7 May 2026 delayed these obligations but left the substance unchanged.

A significant gap persists between legal requirements and operational reality. The gap is most visible with fine-tuned GPAI models. When an organisation modifies a foundation model, when does that modification become legally "substantial" enough to trigger new obligations? Hacker and Holweg (2026) answer the when question with a hybrid test combining compute-based thresholds and consequence scanning. Their framework is analytically sound and practically useful—as far as it goes.

It does not go far enough.

Their test determines substantiality at the point of modification assessment. It does not specify how an organisation enforces that finding when the modified model moves into production. The compliance burden under the AI Act, particularly Article 14's human oversight requirement and the revised Product Liability Directive's (2024/2853) "new manufacturer" provisions, attaches to operational systems, not to static compliance documents. An organisation that correctly identifies a modification as substantial but lacks a mechanism to enforce the associated obligations at runtime has not solved the compliance problem. It has merely identified it.

This paper argues that the Accountability Triggers framework—hard-coded execution checkpoints that pause high-risk AI decisions at defined thresholds and require documented human review—provides the missing operational layer. The contribution is twofold. First, I show how the hybrid substantial-modification test can be translated into trigger conditions that fire at runtime. Second, I demonstrate how the resulting checkpoint creates an audit trail that satisfies Article 14's documentation requirements and supports the "manufacturer" defence under the revised PLD.

The argument proceeds in six parts. Section 2 summarises Hacker and Holweg's framework, emphasising what it achieves and where it stops. Section 3 establishes why a legal threshold requires runtime enforcement. Section 4 presents the Accountability Triggers architecture and its application to fine-tuning. Section 5 works through a realistic example. Section 6 addresses limitations honestly. Section 7 concludes with recommendations for regulators and practitioners.

A note on framing: this paper is written from a practitioner's perspective. The orientation is operational. Regulatory theory is useful only insofar as it produces outcomes that can be implemented, audited, and defended.

2. The Substantial-Modification Problem

Hacker and Holweg (2026) address a specific regulatory ambiguity. The EU AI Act imposes obligations on GPAI providers. The Act defines a provider as the entity that develops a GPAI model or has it developed and places it on the market. The ambiguity arises with modifications: when an organisation fine-tunes an existing model, does it become a new provider?

The answer matters. A substantial modification triggers the full range of provider obligations. A non-substantial modification does not. The distinction also matters for liability. The revised Product Liability Directive (2024/2853) provides that a person who substantially modifies a product outside the original manufacturer's control becomes a manufacturer and may be liable for defects. This creates a parallel between "new provider" under the AI Act and "new manufacturer" under the PLD—a connection Hacker and Holweg rightly emphasise.

They propose a hybrid legal test for determining substantiality. The test has two components. First, a compute-based threshold: if the fine-tuning intervention consumes compute beyond a defined proportion of the original training compute, the modification is presumptively substantial. Second, consequence scanning: the modifying entity must assess whether the modification introduces or amplifies risks. A modification that clears the compute threshold or produces a positive consequence-scan result is substantial and triggers provider obligations.

The test is sensible. The compute threshold provides objectivity and predictability. Consequence scanning captures risk-based considerations that a pure compute metric would miss. The paper further proposes a federated compliance structure: joint testing, FMEA, a shared registry, documentation duties, and a lighter track for SMEs.

This is valuable work. It resolves the when question with a test that is both legally grounded and technically feasible.

But the paper stops at the threshold. It does not address the how question: how does an organisation enforce the substantiality finding once it has been made? The federated compliance model describes what should happen—joint testing, shared documentation—but not when it should happen relative to the modification event itself, or who is responsible for triggering the associated obligations at the right moment.

This is not a criticism of Hacker and Holweg. Their contribution was never meant to be operational. The gap between legal threshold-setting and operational enforcement remains, and it is a gap practitioners must fill.

3. Why a Legal Test Needs a Runtime Mechanism

The compliance gap is not theoretical. It manifests in practical questions organisations are asking now.

Consider a regulated financial institution planning to fine-tune an off-the-shelf LLM for a customer-facing advisory function. The legal team applies the Hacker-Holweg test. They calculate the compute delta. They perform consequence scanning. They conclude the modification is substantial.

Now what?

The legal memo sits in a document repository. The technical team continues with the fine-tuning pipeline. The model is deployed. No mechanism ensures that the compliance obligations triggered by the "substantial" finding are enforced at the point of deployment. No checkpoint prevents deployment if documentation is incomplete. No structured process ensures that human oversight, as required by Article 14, occurs at the right moment and is properly recorded.

This is not a failure of legal analysis. It is a failure of operational design.

Article 14 requires that high-risk AI systems be designed with appropriate human-machine interface tools so that they can be effectively overseen by natural persons during use (EU AI Act, Art. 14(2)). The oversight measures can be built into the system by the provider (Art. 14(3)(a)) or implemented by the deployer (Art. 14(3)(b)). The natural persons assigned to oversight must be enabled to correctly interpret outputs, decide not to use the system, and intervene or interrupt its operation (Art. 14(4)(a)–(e)).

The key phrase is "built into the high-risk AI system." Article 14 contemplates oversight that is embedded, not bolted on. It anticipates oversight as a system feature, not a procedural afterthought.

The PLD's "new manufacturer" provision has a similar operational dimension. Under the revised directive, a person who substantially modifies a product becomes a manufacturer and may face liability for defects (PLD, Art. 8(2)). A robust defence requires ongoing evidence that the modification was performed with due care and that the resulting product was appropriately tested and monitored. This evidence must be produced at the time of modification, not reconstructed for litigation.

The gap is between threshold identification and operational enforcement. Hacker and Holweg's test tells you when you have crossed the line. It does not tell you how to ensure the line is enforced.

This is where the Accountability Triggers framework enters.

4. The Accountability Triggers Architecture Applied to Fine-Tuning

The Accountability Triggers framework is a set of hard-coded execution checkpoints that pause a high-risk AI decision at a defined threshold and require documented human review before the system proceeds. It operationalises Article 14 by embedding oversight into the system itself.

The framework has three components: trigger conditions, checkpoint mechanics, and audit-trail generation.

4.1 Trigger Conditions

A trigger is a pre-defined condition that, when met, halts the system's execution. For the fine-tuning context, I propose three trigger categories corresponding to Hacker and Holweg's hybrid test and the broader compliance obligations it activates.

Compute-delta triggers. The hybrid test's first component is a compute threshold. An organisation should define a specific compute-delta limit. When fine-tuning exceeds that limit, the trigger fires. The exact threshold value is a matter for implementation; the principle is that the trigger fires on an objective, pre-defined metric.

Behavioural-drift triggers. Fine-tuning can alter model behaviour in ways not captured by compute metrics. A model may exhibit qualitative behavioural differences—shifts in reasoning, alignment, or risk profiles—that suggest substantial modification even if the compute delta is modest. Behavioural-drift triggers are harder to implement. I address this difficulty in Section 6. The principle is clear: the trigger framework should include mechanisms for detecting and responding to behavioural changes that could indicate substantial modification.

FMEA-flagged consequence categories. Hacker and Holweg's consequence scanning requires assessing whether the modification introduces or amplifies risks. An organisation can operationalise this by incorporating FMEA into the modification pipeline. When a modification falls into a high-consequence category under FMEA, the trigger fires.

The three trigger categories are complementary. A well-designed implementation would use all three, with a checkpoint firing when any trigger condition is met. The trigger framework does not replace legal judgment. It enforces that judgment at runtime.

4.2 Checkpoint Mechanics

When a trigger fires, the system pauses. The checkpoint halts deployment. The system does not proceed until a human reviewer completes a structured review and documents the outcome.

The reviewer must have access to the evidence that caused the trigger to fire. If the trigger was compute-delta based, the reviewer sees the compute calculations. If it was behavioural-drift based, the reviewer sees the drift metrics. If it was FMEA-based, the reviewer sees the FMEA results.

The review is not a rubber stamp. The reviewer must confirm that the modification has been properly assessed, that the consequences have been appropriately classified, and that the resulting compliance obligations have been identified. If the reviewer identifies gaps or errors, they can reject the deployment.

The review must be documented in a format that is auditable and defensible. The documentation should include: the trigger that fired and the evidence supporting it; the reviewer's analysis and conclusion; the actions taken; and the timestamp and reviewer identity.

This is not administrative overhead. It is the operationalisation of Article 14(4)(c), which requires that natural persons assigned to oversight be enabled to "correctly interpret the high-risk AI system's output" and "decide, in any particular situation, not to use the system." The checkpoint forces those capabilities into the deployment process.

4.3 Audit Trail and Legal Mapping

The checkpoint generates an audit trail that serves two legal purposes.

First, it documents compliance with Article 14. The article requires high-risk AI systems to be designed "with appropriate human-machine interface tools" that enable effective oversight (Art. 14(2)). The Accountability Triggers framework embeds oversight into the system architecture. The checkpoint ensures that the oversight event occurs at the point of deployment, when the modification is actually made, not as a disconnected compliance exercise. The audit trail provides evidence that oversight occurred, what the oversight context was, and what action was taken.

Second, the audit trail supports the "new manufacturer" defence under the PLD. Under the revised directive, a person who substantially modifies a product becomes a manufacturer and may face liability for defects (PLD, Art. 8(2)). A robust defence requires evidence that the modification was performed with due care and that the resulting product was appropriately tested and monitored. The trigger framework's documentation provides that evidence: it shows that the substantiality assessment was made, that the resulting obligations were identified, and that the modification proceeded only after documented review.

The audit trail also maps onto ISO/IEC 42001 Clause 8 requirements. Clause 8 requires operational control across the entire AI system lifecycle, including design, development, verification, deployment, operation and monitoring, and change management (ISO/IEC 42001:2023, Clause 8.1). It also requires risk and impact assessments at planned intervals and when significant changes occur (Clause 8.2). The trigger checkpoint operationalises Clause 8's change-management requirements. The audit trail provides the documentation Clause 8 requires.

5. Worked Example: Fine-Tuning a Financial Advisory LLM

Consider a UK-based financial institution, WealthGuard Ltd., that plans to fine-tune an off-the-shelf GPAI model for a customer-facing financial advisory function. The fine-tuning will use proprietary financial data to improve the model's performance.

WealthGuard's legal team applies the Hacker-Holweg hybrid test.

First, the compute-delta component. The original model required 1,000,000 FLOP-hours of training compute. The proposed fine-tuning requires 400,000 FLOP-hours. The compute delta is 40% of the original. If the AI Office's guidance suggests a one-third FLOP threshold, the fine-tuning exceeds this threshold. The compute-delta trigger fires.

Second, consequence scanning. WealthGuard's team performs an FMEA. They identify potential failure modes: the fine-tuned model may provide inaccurate or inappropriate financial advice. The consequences include customer financial loss, regulatory action, and reputational damage. The FMEA classifies these as high-consequence categories. The FMEA-consequence trigger fires.

The Accountability Triggers framework halts deployment. The system does not proceed until a human reviewer completes the required review.

The reviewer—a senior compliance officer with relevant domain expertise—receives the evidence: the compute-delta calculation, the FMEA results, and a summary of the intended use case. The reviewer confirms that the substantiality assessment is accurate, that the modification is indeed substantial, and that the organisation has identified the resulting compliance obligations. They document the review.

The organisation then treats the fine-tuned model as a new system for compliance purposes. It meets the GPAI provider obligations under Articles 53–55. It implements the required high-risk system measures, including Article 14 oversight. It maintains the documentation required for the PLD "manufacturer" defence.

The alternative scenario—where no runtime checkpoint exists—would have resulted in deployment without enforced review. The legal memo would have identified the substantial modification. The technical team would have deployed the modified model. No mechanism would have forced the compliance handoff. This is the gap the Accountability Triggers framework closes.

6. Limitations

The framework has limitations that must be acknowledged honestly.

6.1 Behavioural Drift Detection

Behavioural-drift triggers require the ability to detect changes in model behaviour that could indicate substantial modification. This is a hard technical problem. A model may exhibit shifts in reasoning strategy not captured by standard benchmarks (Betley et al., 2025). Detecting such shifts requires sophisticated evaluation approaches.

The framework does not solve this problem. It flags it. Organisations implementing behavioural-drift triggers will need to invest in evaluation tooling and maintain it as the model and the use context evolve.

6.2 SME Capacity Constraints

The framework imposes a documentation and review burden. For large institutions with mature compliance functions, this is manageable. For SMEs, it may be prohibitive. Hacker and Holweg's federated compliance model includes a lighter track for SMEs, but the trigger framework does not automatically provide such a track.

An SME might adopt a simpler trigger set—perhaps compute-only or compute-plus-FMEA—and use automated review assistance where feasible. But the core requirement of documented human review remains. This is a genuine challenge.

6.3 Jurisdictional Variation

The framework is grounded in the EU AI Act and the revised PLD. Organisations operating in jurisdictions without equivalent legislation will not face the same legal requirements. The trigger framework may still be useful as a risk-management tool, but its compliance value is jurisdiction-dependent.

6.4 The Enforceability Question

The trigger checkpoint halts deployment until human review occurs. This works in a controlled deployment pipeline. It is less clear how it would operate in contexts where the modification occurs outside such a pipeline—for example, through continuous learning or online fine-tuning. The revised PLD addresses this by providing that the manufacturer is liable for defects that might appear through the continuous learning of an AI system where the system remains under the manufacturer's control (PLD, Recital 40). The trigger framework would need to be adapted for continuous-learning contexts.

7. Conclusion and Recommendations

The Hacker-Holweg substantial-modification test answers an important question: when does a GPAI modification trigger new legal obligations? It does not answer the operational question: how does an organisation enforce that finding at runtime? This paper has argued that the Accountability Triggers framework provides the missing operational layer.

A compliance document that identifies a substantial modification is necessary but not sufficient. The obligations triggered by the finding—Article 14 human oversight, PLD "manufacturer" documentation, ISO/IEC 42001 change-management controls—attach to operational systems. They must be enforced at the point of deployment. The Accountability Triggers framework embeds that enforcement into the system architecture. Trigger conditions fire on compute-delta, behavioural drift, and FMEA-consequence flags. The checkpoint forces documented human review. The audit trail maps onto the legal obligations.

The framework has limitations, which I have documented honestly. Behavioural-drift detection is technically difficult. SME capacity is a real constraint. Jurisdictional variation limits applicability. These limitations do not invalidate the framework. They are conditions for its implementation.

Recommendations for Regulators

Provide implementation guidance for Article 14. Regulators should provide practical guidance on embedding oversight into system architectures, including checkpoint mechanisms.

Clarify the substantial-modification test's operational implications. Regulators should clarify what happens after the threshold is crossed—what processes and documentation are required.

Establish safe harbours for documented oversight. A robust audit trail that demonstrates compliance with Article 14 should provide a safe harbour against enforcement action, absent evidence of bad faith or material negligence.

Recommendations for Practitioners

Implement trigger checkpoints before fine-tuning deployments. A trigger framework can be implemented incrementally. Start with compute-delta triggers and expand to FMEA and behavioural-drift triggers as capability develops.

Use the audit trail as a defence, not just a compliance burden. The documentation generated by trigger checkpoints is evidence of due care. Treat it as such.

Engage with the AI Office and standard-setting bodies. The framework is an implementation proposal. It will benefit from refinement based on regulatory feedback and practical experience.

Acknowledgements

This paper draws on the author's experience as an AI governance practitioner and founder of Luxyn Ethics & Governance. The author holds the Oxford AI Ethics credential from Said Business School – University of Oxford and the ISO 42001 Lead Implementer certification from BSI. The Accountability Triggers framework and AIMS Guard prototype are documented. The author was selected for the Global Trust Challenge Prototyping Phase and has presented at UK AI Public Sector Week. A version of this work was presented at the Cambridge AI in Education Summit in October 2026.

References

Betley, J., Tan, D., Warncke, N., Sztyber-Betley, A., Bao, X., Soto, M., Labenz, N., & Evans, O. (2025). Emergent misalignment: Narrow finetuning can produce broadly misaligned LLMs. arXiv preprint arXiv:2502.17424.

European Parliament and Council. (2024). Directive (EU) 2024/2853 on liability for defective products. EUR-Lex.

European Parliament and Council. (2024). Regulation (EU) 2024/1689 (EU AI Act). Articles 14, 53–55.

European Parliament and Council. (2026). Digital Omnibus Agreement of 7 May 2026 amending the EU AI Act deadlines.

Hacker, P., & Holweg, M. (2026). The regulation of fine-tuning: Federated compliance for modified general-purpose AI models. Computer Law & Security Review, 60, Article 106234.

ISO/IEC. (2023). ISO/IEC 42001:2023 – Information technology – Artificial intelligence – Management system. Clause 8.

Luxyn Ethics & Governance. Accountability Triggers framework and AIMS Guard prototype. 

Frequently Asked Questions

What is the substantial-modification test for fine-tuned GPAI models under the EU AI Act?

The substantial-modification test, proposed by Hacker and Holweg (2026), uses a hybrid approach combining compute-based thresholds with consequence scanning to determine when fine-tuning of a general-purpose AI model crosses from insubstantial adjustment to substantial modification, which triggers new provider obligations under the EU AI Act.

What are Accountability Triggers and how do they operationalize the substantial-modification test?

Accountability Triggers are hard-coded execution checkpoints in running AI systems that pause high-risk AI decisions and require documented human review. When a fine-tuning event crosses the substantial-modification threshold, these triggers halt deployment and force documented human review, fulfilling both Article 14 human oversight obligations and documentation requirements.

What is Article 14 of the EU AI Act and what does it require?

Article 14 of the EU AI Act mandates human oversight for high-risk AI systems. The Accountability Triggers framework operationalizes this requirement by ensuring that modifications triggering new obligations are reviewed and documented by humans before deployment.

How does the revised Product Liability Directive relate to GPAI model modifications?

The revised Product Liability Directive (2024/2853) includes a 'new manufacturer' defence provision that attaches to operational systems. Accountability Triggers help organizations discharge this burden by documenting human review of substantial modifications before deployment.

What is the key gap that this paper addresses in existing compliance frameworks?

While Hacker and Holweg's hybrid test answers when a modification becomes substantial, this paper closes the gap of how organizations actually enforce that finding inside a running system at runtime, moving compliance from static documents to operational checkpoints.

What are the transparency obligations for GPAI providers under the EU AI Act?

GPAI providers face transparency obligations under Articles 53–55 of the EU AI Act, with additional stringent requirements for high-risk systems under Title III, including the human oversight mandate of Article 14.