General-Purpose AI Models Under the EU AI Act

The EU AI Act uses the term general-purpose AI model, often shortened to GPAI model. That terminology matters. Older commercial and policy materials often referred to foundation models, but the final legal framework should be analysed through the Act's GPAI concepts rather than through obsolete draft labels or market shorthand.

A general-purpose AI model is not the same thing as every AI system or software product that uses it. A model may be capable of supporting a wide range of downstream tasks. An AI system may then be built around the model for a particular interface, function, customer workflow or intended purpose. This layered structure is one reason why the Act creates model-level obligations separately from the obligations that may apply to providers and deployers of downstream AI systems.

Model, system and role

The first question is whether the business provides a GPAI model, provides a downstream AI system, deploys an AI system, or performs more than one of those roles. A model provider develops or has developed the model and places it on the market under its own name or otherwise makes it available in a way that falls within the Act. A downstream system provider may integrate a model into a specific AI system. A deployer uses an AI system under its authority in its own operations or services.

The distinction has practical consequences. A company that releases a broadly capable model for integration by others needs to think about GPAI provider duties. A company that builds a recruitment, credit, education, safety or customer-service application on top of that model must still classify the downstream AI system by intended purpose and risk. A business using a third-party tool internally should not assume it has no duties merely because it did not train the model.

This is also why all GPAI-based tools should not be described as high-risk. High-risk classification depends on the downstream AI system, use area and legal criteria. The model layer may carry its own obligations, but that does not automatically convert every application using the model into a high-risk system.

Baseline GPAI provider duties

The Commission summarises the AI Act as introducing rules for providers of general-purpose AI models, including transparency and copyright-related duties. At a practical level, GPAI provider compliance planning should address technical documentation, information for downstream providers, copyright policy, and a public summary of training content prepared according to the framework and templates developed for this purpose.

For a model provider, the practical compliance file should usually ask:

• what model is being placed on the Union market and by which legal entity;
• whether the model qualifies as a general-purpose AI model under the Act;
• what technical documentation exists and how it will be maintained;
• what information downstream providers need in order to understand model capabilities, limits and integration requirements;
• how the provider addresses copyright-related policy duties;
• how the public summary of training content is prepared and kept consistent with official templates and guidance;
• whether the model may trigger the separate systemic-risk layer.

These duties should not be left only to the legal team at the end of development. The required information depends on technical, product, governance, data and licensing inputs. Model cards, technical reports, dataset governance, copyright policies, release processes and customer documentation may all need to fit together.

Systemic-risk GPAI models

The AI Act creates an additional layer for general-purpose AI models with systemic risk. This should be treated as a separate assessment rather than as a rhetorical label for any powerful model. The systemic-risk layer is concerned with models whose capabilities and potential impact may create broader risks that go beyond a single customer deployment.

At a high level, enhanced obligations for systemic-risk models point towards model evaluation, risk assessment and mitigation, serious-incident monitoring and reporting, adversarial testing or similar safety evaluation measures, cybersecurity and safety governance, and continued attention to model-level risks after release. The precise compliance design will depend on the model, its capabilities, its distribution route and current implementing materials.

For providers, the important point is sequencing. A baseline GPAI compliance file may not be enough if the model falls into the systemic-risk layer. Conversely, downstream businesses should avoid assuming that a model provider's systemic-risk duties replace their own need to classify the AI system they build or deploy.

The GPAI Code of Practice

The Commission's General-Purpose AI Code of Practice is an implementation tool for providers of general-purpose AI models, including providers of models with systemic risk. The Commission describes it as a voluntary tool to help providers comply with the AI Act's rules on transparency, copyright, safety and security. The final Code was approved by the Commission in August 2025, according to the Commission's published materials.

The Code should not be treated as mandatory law in itself, and it does not replace the AI Act. It can, however, become highly relevant in practice because it offers a structured way to demonstrate how a provider approaches the Act's GPAI obligations. Providers that do not rely on the Code will still need another credible route to show compliance with the legal requirements that apply to them.

Contracts and downstream documentation

GPAI regulation has an important contractual dimension. Downstream providers may need information from model providers in order to build compliant AI systems. Enterprise customers may need assurances about model provenance, permitted use, security, limitations, copyright policy and documentation updates. Model providers may need terms that limit unsupported use cases and clarify which obligations sit with downstream providers or deployers.

A practical contract review should therefore look beyond ordinary software licensing. It should address access to documentation, update notices, incident communications, integration constraints, prohibited uses, audit support, confidentiality, intellectual property, output-related risk, customer-facing transparency and allocation of AI Act responsibilities across the value chain.

Practical workflow

• Identify whether the technology is a GPAI model, a downstream AI system, or both in different contexts.
• Map the legal roles: model provider, downstream system provider, deployer, importer, distributor or product manufacturer.
• Prepare baseline GPAI documentation before customer negotiations require it.
• Assess whether the systemic-risk layer may apply and who owns that assessment internally.
• Align model documentation, customer contracts and downstream provider information so they do not contradict one another.
• Use the Commission's Code of Practice and templates as implementation references where relevant, without treating them as substitutes for the Act.

Practical takeaway

General-purpose AI model compliance should start at model level, then move to the downstream system and use case. A single AI value chain may include a model provider, an application provider, an EU importer, a distributor, an enterprise deployer and end users. Their obligations are related, but they are not identical.

For EU-facing AI businesses, the core discipline is separation: model obligations, system classification, role mapping, contractual allocation and customer documentation. That separation reduces the risk of using outdated foundation-model language, treating every GPAI-based tool as high-risk, or assuming that another actor in the chain has solved all AI Act duties.

Legal references

• Regulation (EU) 2024/1689, in particular Articles 3, 53, 55 and 113.
• European Commission, AI Act overview, including the Commission's summary of GPAI rules and staged application dates.
• European Commission, General-Purpose AI Code of Practice materials and training-data-summary template materials.