Substantial Modification Assessment
Fine-tuning a GPAI model for use in a high-risk system raises the question of whether the modification constitutes a substantial modification under Article 3(23), and whether it triggers the provider boundary shift under Article 25(1)(b). This assessment is central to determining the organisation’s regulatory obligations.
The Legal and Regulatory Advisor assesses the fine-tuning activity against three criteria. First, does the fine-tuning change the model’s intended purpose as documented by the GPAI provider? A general-purpose text generation model fine-tuned for medical triage or credit assessment has undergone a change of intended purpose. Second, does the fine-tuning alter the model’s risk profile? Fine-tuning on domain-specific data may introduce new bias patterns, failure modes, or accuracy characteristics absent from the base model. Third, does the fine-tuning affect the model’s compliance with the GPAI provider’s own obligations under Articles 51 to 56? Fine-tuning may void safety evaluations or alignment testing conducted on the base model.
Where any criterion is satisfied, the modification is likely substantial. The organisation should treat itself as a provider with full Article 16 obligations and prepare the AISDP accordingly. The assessment and its reasoning are documented in the Fine-Tuning Provider Boundary Determination artefact.
Key outputs
- Substantial modification assessment with three-criteria analysis
- Provider status determination
Provider Obligation Transfer Determination
Where the substantial modification assessment determines that the organisation has assumed provider status, the full set of provider obligations under Article 16 transfers to the fine-tuning organisation. These include maintaining the AISDP (Article 11), conducting conformity assessment, signing the Declaration of Conformity, affixing CE marking, registering in the EU database, establishing post-market monitoring, and reporting serious incidents.
The determination document should clearly delineate which obligations are satisfied by the GPAI provider’s existing compliance artefacts and which fall exclusively on the downstream organisation. For example, the GPAI provider’s technical documentation may partially satisfy AISDP Module 3 requirements for the base model architecture, but the fine-tuning organisation bears full responsibility for documenting the fine-tuning process, the evaluation results, and the system-level integration.
The AI Governance Lead reviews and approves the obligation transfer determination, ensuring that all assumed obligations are assigned to specific roles with clear timelines for fulfillment. This determination should be made during Phase 3 (Architecture and Design), since it materially affects the scope and cost of the remaining delivery phases.
Key outputs
- Provider obligation transfer determination document
- Obligation-to-role assignment matrix
- AI Governance Lead approval
Decision Flow for Borderline Cases
Not all fine-tuning activities produce a clear determination. Some cases are genuinely borderline: the fine-tuning may narrow the model’s domain without clearly changing its intended purpose, or the risk profile may shift modestly without crossing a definitive threshold. The decision flow for these cases must be documented to demonstrate a rigorous and defensible analysis.
The decision flow should proceed through sequential questions. Has the model’s intended purpose as stated by the GPAI provider been changed? If yes, provider status is triggered. If no, has the model’s risk profile changed materially, considering new bias patterns, new failure modes, altered accuracy characteristics, or new deployment populations? If yes, provider status is likely triggered. If no, has the GPAI provider’s own safety or alignment testing been invalidated by the fine-tuning? If yes, provider status is triggered.
For genuinely ambiguous cases where none of these questions produces a clear answer, the Legal and Regulatory Advisor should apply the precautionary principle: treat the organisation as a provider. The compliance cost of assuming provider obligations unnecessarily is materially lower than the enforcement risk of incorrectly claiming deployer status for a system that a competent authority later determines should have been treated as provider-level.
The decision flow, including the reasoning at each step and the individuals involved in the determination, is retained in the evidence pack. If the organisation determines that provider status is not triggered, the justification must be specific and evidence-based, not merely a statement that the modification was minor.
Key outputs
- Borderline case decision flow documentation
- Precautionary principle application record (where applicable)