EU AI Act Article 25: when SaaS inherits GPAI provider obligations

Article 25(1) provides that any distributor, importer, deployer, or other third party shall be considered a provider of a high-risk AI system if they: (a) put their name or trademark on a high-risk AI system already placed on the market; (b) make a substantial modification to a high-risk AI system already placed on the market; or (c) modify the intended purpose of an AI system not classified as high-risk in a way that makes it high-risk. Article 25(4) applies the same logic to GPAI models: a downstream actor who substantially modifies a GPAI model becomes a provider of that GPAI model.

The Act defines substantial modification (Article 3(23)) as a change not foreseen by the provider in the initial conformity assessment, affecting performance, intended purpose, or compliance posture. For GPAI models, the threshold is unsettled. The GPAI Code of Practice consultation closed in March 2026 without clean resolution. Conservative interpretations: fine-tuning beyond LoRA-level adjustments, training on substantial proprietary data, modifying the system prompt to fundamentally alter behaviour, removing or weakening safety guardrails.

Prompt engineering using publicly available APIs: low inheritance risk. Light fine-tuning (LoRA adapters, instruction tuning on small datasets): unsettled - lean low risk if documented. Heavy fine-tuning (full-weight fine-tuning, training on proprietary corpus, RLHF on customer data): high inheritance risk. RAG over proprietary data: low risk (does not modify the model). Multi-model orchestration (chaining several models with custom logic): low risk for the individual models, but the orchestrated system may itself need Provider classification.

If you inherit GPAI Provider status under Article 25(4), Article 53 obligations apply: maintain technical documentation, prepare and make available a summary of training data, implement a policy for copyright compliance, cooperate with the European AI Office. For systemic-risk GPAI models (those above the compute threshold or designated), Article 55 obligations also apply: model evaluation, adversarial testing, incident reporting, cybersecurity protection. Most fine-tuned SaaS models do not reach systemic-risk thresholds, but the baseline Article 53 obligations are non-trivial.

First, document your modifications precisely. A clear paper trail showing you did not substantially modify the model is your best defence in a regulator dialogue. Second, prefer techniques that the unsettled guidance generally accepts as non-substantial (LoRA, RAG, prompt engineering). Third, if you must heavily fine-tune, plan for Article 53 compliance from day one: training-data documentation, copyright policy, downstream-user transparency. Fourth, consider commercial alternatives - using a less customised but ToS-clear model from a major provider sometimes makes more business sense than running your own fine-tune.