Fine-tuning a foundation model? When the EU AI Act makes you a general-purpose AI provider

Where things stand

The AI Act's obligations for providers of general-purpose AI models have applied since 2 August 2025. The Commission said the AI Office was preparing its compliance assessments ahead of enforcement of those rules from August 2026². A Cloud Security Alliance research note published on 3 August 2026 summarised the AI Office's powers as including requests for documentation, model evaluations, corrective measures and fines⁷.

Alongside the law sit two practical instruments. The GPAI Code of Practice, published on 10 July 2025, has three chapters: transparency, copyright, and safety and security. The first two give all GPAI providers a way to demonstrate compliance with Article 53; the third applies only to providers of models with systemic risk under Article 55¹⁶. The transparency chapter includes a Model Documentation Form¹. The Commission also finalised a template for the public summary of training data⁵.

The line between deployer and provider

The Commission's guidelines on GPAI providers address downstream modification directly. As summarised by commentators³⁴:

• An indicative criterion is whether the training compute used for the modification exceeds one third of the compute used to train the original model.
• If the original compute isn't known, one third of the threshold for presuming a model is general-purpose is used instead.
• Minor changes typically don't make you a provider.
• If you do become a provider, your obligations generally concern the modification: documentation, training data summary and copyright policy covering the additional compute and data. Modifying a model with systemic risk brings the full systemic-risk obligations.

Why this matters even if you are well below it

First, customers ask. In enterprise procurement, "we use RAG, not fine-tuning" is a much easier answer with evidence behind it. Second, upstream providers' documentation flows down to you: the Model Documentation Form exists partly so downstream providers can understand the models they build on¹. Third, the same records support obligations that apply to your AI systems regardless of the model rules, such as the literacy duty in Article 4 and the timeline in the Digital Omnibus roadmap.

What I'd put in place

1. Log training compute for every model you train or tune, with the method used to estimate it. It's cheap to capture at the time and very hard to reconstruct later.
2. Keep a model lineage record: base model and version, upstream documentation received, datasets, licences and changes. The supply chain practices in AI model supply chain security overlap heavily.
3. Document data provenance and copyright handling for any data you train on, including how rights reservations are respected.
4. Prefer adaptation over retraining where it meets the need. RAG and lighter tuning are usually cheaper as well as simpler to govern; see long context vs RAG.
5. Map once, reuse often. Tie these records into a framework such as ISO 42001 so the same evidence serves EU, US and Gulf requirements.

How I can help

I help AI companies design training and deployment pipelines that produce compliance evidence as a by-product. As a fractional CTO I can own that work. Or analyse your challenge and bring the result to a call.