A general-purpose AI model is a component that can be integrated into many systems, while an AI system is a machine-based system designed to operate with varying autonomy for explicit or implicit objectives, with a specific intended purpose. The model provider's Chapter V duties and the system provider's Chapter III duties are separate, and integration, modification or a change of intended purpose can shift roles, including under Article 25 for high-risk systems.
How should the boundary be described in a record?
A record should name the model, its version, and the system it is integrated into, and should state the system's intended purpose separately from the model's general capabilities. The model description should cover what the model can do across tasks, while the system description should cover the specific task, users, inputs, outputs and deployment context for that system. Keeping those two descriptions in one paragraph, or using the model name as the system name, obscures the boundary and makes later classification work harder. Teams should use separate identifiers for model versions and system versions, link them explicitly, and record the integration date and the party responsible for each layer. That structure allows a change at either layer to be assessed without rewriting the whole file.
When does integration create a new system assessment?
Every integration of a general-purpose model into a system with a new intended purpose creates a system assessment question, even where the model itself is unchanged. The downstream provider must assess the system against Article 5, Article 6 and the Annexes, Article 50, and any sectoral rules that apply to the use, on the facts of that deployment. The model provider's documentation informs that assessment but does not complete it. A downstream team should therefore start its assessment from the intended purpose and the affected people, use the downstream pack as an input, and carry out its own testing and risk work for the system. A system that is described only by reference to the model it uses has not been assessed as a system at all.
For the broader regulatory framework, see General-purpose AI models overview.
When does modification change the role?
Modification of a model or a system can change the role analysis. For high-risk systems, Article 25 provides that a deployer, importer, distributor or other third party can become the provider where it puts its name or trademark on the system, makes a substantial modification, or changes the intended purpose so that the system becomes high-risk. For models, a downstream modification that significantly changes generality, capabilities or systemic risk can create a new provider question for the modified model. Teams should record every modification, assess whether it is substantial, and record the role conclusion with reasons. A modification log that records only the technical change, without the role assessment, leaves the most consequential question unanswered.
How do prompts, retrieval and tooling affect the boundary?
Prompt design, retrieval sources, tool use and workflow design are system-level choices, even where they use a general-purpose model without changing the model itself. They affect the system's behaviour, its outputs, and its risks, and they should be recorded as part of the system description. A system that retrieves from a sensitive source, calls an external tool, or acts without human review presents different questions from a system that uses the same model for a bounded drafting task. The model provider cannot assess those choices, because they are made downstream. Downstream teams should therefore document the full system, including prompts, data sources, tools and human involvement, and should test the system as deployed, not only the model in isolation.
How should contracts reflect the boundary?
Contracts should reflect the boundary by allocating model-level and system-level responsibilities to the party that controls them, and by providing for information flow, update notification, incident reporting and change control. A contract that labels a downstream provider as a mere user, while that provider in fact determines the intended purpose and deployment, does not settle the statutory role. Conversely, a contract that makes a model provider responsible for downstream system decisions it does not control creates an unworkable allocation. The contract file should be read alongside the role record, and any mismatch between the contract label and the actual control should be recorded and resolved. Legal review should focus on control and purpose, not only on the labels the parties have chosen.
Continue with Downstream information flow for general-purpose AI models.
What does this guide not decide?
This guide does not decide whether a particular artefact is a model or a system, whether a modification is substantial, whether a role has changed under Article 25, or whether a system is high-risk or prohibited. It does not assess an integration, a prompt design, or a contract. Those questions turn on the actual artefact, the intended purpose, the modification, the control exercised, and the consolidated legal text. A team should confirm the boundary and the roles for each product with a competent authority or legal adviser, keep the model and system records distinct but linked, and revisit the boundary whenever the integration or the purpose changes.
Frequently asked questions
Does using a general-purpose model make my product a general-purpose model?
Not necessarily. Using a model to build a system with a specific intended purpose creates a system assessment question. Whether the downstream party is also a provider of a modified model depends on the modification and on the role analysis, including Article 25 for high-risk systems. Record the model, the system, the purpose and the roles separately.
Can a model provider's documentation settle my system classification?
No. Model documentation informs the system assessment, but classification turns on the system's intended purpose, deployment context and the relevant Annex, on the facts of that system. The downstream provider must carry out its own assessment and testing for the system as deployed.
What counts as a substantial modification?
The Act treats a substantial modification as a change that affects compliance or the intended purpose in a material way, and the assessment depends on the change and the system. Record the change, assess its effect on compliance and purpose, and record the role conclusion with reasons, seeking qualified review where the position is borderline.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗Commission AI Act Service Desk timeline ↗European Commission AI Act overview ↗