General-purpose AI obligations reach the model supply chain
The EU's rules for general-purpose AI models made documentation, copyright policies and information about model changes part of the relationship between suppliers and application builders.
An application company could select a model in an afternoon and still spend weeks establishing what information it could obtain from the supplier. For providers placing new general-purpose AI models on the European market, the AI Act set requirements at the model layer: information for downstream builders, a copyright policy, a public summary of training content and, for models presenting systemic risk, additional evaluation and risk management.
The Commission formally adopted its detailed guidelines on 19 November 2025, following earlier draft guidance. They addressed a different question from whether a finished application belonged to a high-risk use category. A general-purpose model could support many applications, with its provider responsible for the underlying model. For startups, the guidance explained what should accompany a model and when modifying one could create provider responsibilities.
Application and enforcement followed separate timetables
The Commission distinguished the start of the obligations from the start of enforcement. Obligations for new models applied from 2 August 2025; the Commission’s enforcement powers were scheduled to apply from 2 August 2026. Providers of models already on the market before that initial deadline had until 2 August 2027 to comply. Providers placing new models on the market still had to meet those obligations during the first year, before enforcement powers took effect.
- 2 August 2025
New-model obligations apply
Providers placing new general-purpose models on the market must meet their applicable duties.
- 2 August 2026
Commission enforcement powers
The July guidance identifies this as the start of the Commission’s enforcement powers.
- 2 August 2027
Earlier models must comply
Transition deadline for models already on the market before 2 August 2025.
The Commission's timetable separates the start of obligations, scheduled enforcement powers and the transition period for existing models.
A procurement team needed the identity and release history of the specific model being supplied; the supplier's age would not establish its regulatory status. A vendor could have both earlier models and newly released models in its catalogue. Commercial contracts also needed to accommodate replacements. An application that automatically moved to a new upstream version could change its evidence base without its customer changing the application’s name.
Documentation became an input to the product
The transparency obligations included keeping technical documentation and providing information to businesses integrating the model into AI systems. For an application builder, that information could support a more informed understanding of capabilities, limitations and intended integration. It could not establish whether a particular workflow was reliable with the customer’s data, permissions and operating conditions.
Startups needed to retain the information associated with each model version they had evaluated and identify material changes in subsequent releases. A security review, customer assurance document or product test based on one version should not be assumed to describe every future version. Better upstream documentation could reduce uncertainty while leaving substantial application testing with the product team.
The Code offered a voluntary route to compliance
The final General-Purpose AI Code of Practice provided a method for meeting the obligations. It comprised chapters on Transparency, Copyright, and Safety and Security. The first two addressed the general provider obligations; the third concerned the smaller group of models with systemic risk. Providers could follow the Code voluntarily or demonstrate compliance through other adequate methods.
Customers could assess which commitments a supplier had adopted and examine the records supporting them. A claim of participation alone did not answer how a model was evaluated, how a rights reservation was respected or how an incident would be handled. Compliance services could help suppliers perform and maintain this work. Their value depended on the quality of the records and procedures behind a claim of compliance.
Model modification required a separate judgement
The adopted guidelines did not treat every modification as creating a new general-purpose model provider. They focused on significant changes to generality, capabilities or systemic risk and described an indicative criterion based on training compute. They also made clear that the guidance was not binding law and that individual cases still required assessment. A product team could not infer its role solely from using the word fine-tuning.
Where a downstream modifier became a provider, the guidance connected certain duties concerning documentation and training data to that modification. Recording the base model, additional data, training process and resulting changes therefore served a practical purpose beyond reproducibility. It helped the company explain what it had contributed and where its responsibilities might begin, particularly when selling a modified model to other developers.
Open weights did not answer every evidence question
Qualifying models released under a free and open-source licence could receive exceptions from certain documentation duties, provided the required parameters and information were publicly available and the model did not present systemic risk. The guidelines expressly preserved the obligations to maintain a copyright policy and publish a training summary. Access to weights was therefore not equivalent to a complete account of how training material had been obtained.
For a startup choosing between a hosted model and one it operated itself, licensing, operating cost and evidence availability all belonged in the comparison. Running the model itself could provide operational control while increasing the company’s own deployment and support work. A lower inference bill alone did not resolve the supplier question. The rules made model provenance and change management part of delivering a dependable enterprise product.
A model release required continuing support
For a small model provider, the cost of supporting downstream customers deserved a place in its pricing. Buyers could need documentation updates, explanations of evaluation methods and advance notice of changes. If those requests triggered a fresh manual exercise for every account, revenue growth could bring a matching increase in specialist support costs. Maintaining a usable record for each release offered a way to spread that work across customers.
A company selling compliance tools faced a different challenge. Its product needed access to the engineering records where training, testing and release decisions were actually made. A polished register populated only after a model shipped could leave the most difficult evidence missing. Its value would come from making accurate records easier to maintain throughout development, while allowing qualified people to make the legal and technical judgements that a database could not settle.
Sources
- C(2025) 7719 final: Commission Guidelines on the scope of the obligations for providers of general-purpose AI models (opens in a new tab)
European Commission
- Learn more about the guidelines for providers of general-purpose AI models (opens in a new tab)
European Commission
- General-Purpose AI Code of Practice now available (opens in a new tab)
European Commission
Published
