What is a general-purpose AI model?
AI regulation: concepts, institutions and standards
A general-purpose AI model is, in the EU AI Act, a model level legal category for AI that has broad capabilities and can be used across many different tasks or built into many downstream applications. It is not the same thing as a finished AI product, and it is not simply a casual synonym for "foundation model". In practice, it usually means the upstream model layer, such as a broadly capable language, image, audio, or multimodal model that other systems rely on.
What this means
The easiest way to picture a general-purpose AI model is to separate the engine from the vehicle. The model is the engine. A chatbot, coding assistant, document review tool, image editor, or internal staff assistant built on top of it is the vehicle. The AI Act creates a specific category for some of these engines because they can be reused in many different products and contexts.
That legal category matters because the Act is not only interested in what an end user sees. It is also interested in the layer underneath, where broad capability is created and then supplied to other businesses. A company might never release a consumer app and still fall into this category if it puts a broadly capable model on the market for others to integrate.
The phrase is narrower than it first sounds. It does not mean "any important AI model". It does not mean "whatever people in industry call a foundation model". It means a model that displays significant generality, can competently perform a wide range of distinct tasks, and can be integrated into many downstream systems or applications. The legal lens is functional. The question is whether this model is broad enough, reusable enough, and market facing enough to count.
That is why this explainer should be kept distinct from any explainer on foundation models. In everyday AI discussion, "foundation model" is a broad technical and industry term for a large, adaptable model trained on broad data. The EU AI Act did not simply copy that language and move on. It created its own defined category, with its own scope tests, obligations, exemptions, and enforcement path. There is overlap, and often a large overlap, but they are not interchangeable concepts.
It is also important to distinguish a general-purpose AI model from a general-purpose AI system. The model is the underlying trained model. The system is the product or service built around it, including interfaces, guardrails, workflow logic, integrations, and human process. One organisation may provide the model, another may build the system, and a third may deploy that system in real work.
Why it matters
For leaders, this category matters because it changes where responsibility sits in the AI supply chain. If your business buys or integrates a broadly capable upstream model, you need enough information from the model provider to understand the model's capabilities, limitations, acceptable uses, and technical requirements. If that information is thin, your downstream compliance and risk work gets harder.
It also matters commercially. Procurement, contract wording, product architecture, vendor diligence, and launch planning all become easier when you know whether you are dealing with a specialist model, a finished AI system, or a general-purpose AI model. Those are not the same procurement problem, and they do not create the same obligations.
If you sell into Europe, build on European infrastructure, or serve users in the EU, this category can affect you even if your company is based elsewhere. The AI Act reaches beyond the EU's borders when models or systems are placed on the Union market or used there. That makes this a practical business issue, not a niche legal point.
There is a second layer of significance as well. A small subset of general-purpose AI models are treated as posing systemic risk. Those providers face additional duties around evaluation, risk mitigation, incident handling, and cybersecurity. Even if you are not the provider of such a model, you may depend on one. That means your exposure can arrive through a supplier relationship, not only through your own development work.
How it works
In legal terms, the category starts with the model itself. The Act defines a general-purpose AI model as an AI model, including where trained with a large amount of data using self-supervision at scale, that shows significant generality, can competently perform a wide range of distinct tasks regardless of how it is placed on the market, and can be integrated into a variety of downstream systems or applications. The definition excludes models used only for research, development, or prototyping before they are placed on the market.
That means broad capability is central. A narrow model trained only to forecast one machine failure mode in one factory is unlikely to be general-purpose. A broadly capable large language model, image model, code model, or multimodal model is much more likely to be. Reusability matters too. The more a model can serve as the upstream layer for many other tools, the more clearly it fits the category.
Once a model is in scope, the main obligations fall on the provider placing that model on the market. In broad terms, those providers must keep technical documentation for the model, including the training and testing process and evaluation results. They must also provide enough information and documentation to downstream AI system providers so those downstream providers can understand the model and meet their own obligations.
The provider must also put in place a policy to comply with EU copyright law and make a sufficiently detailed public summary of the content used to train the model. Those last two points matter because the Act treats transparency and copyright governance as part of the baseline responsibility for this category, not as optional extras.
There are limited exemptions for some models released under a free and open-source licence, but these exemptions are not blanket immunity. They are conditional, and they do not remove all obligations. They also do not exempt models with systemic risk from the extra duties that apply at that higher tier. This is one of the most common places where businesses oversimplify the position.
The systemic risk layer is where the category becomes more demanding. A general-purpose AI model is presumed to have high-impact capabilities, and therefore be a general-purpose AI model with systemic risk, if the cumulative computation used for its training is above the threshold set in the Act. The current threshold in the Act is 10^25 floating point operations. The Commission can also designate a model as systemic risk if its capabilities or impact are considered equivalent, even if the provider argues that the threshold alone does not tell the full story.
Providers of systemic risk models face more than documentation and public transparency. They are expected to assess and mitigate systemic risks, carry out model evaluations, report serious incidents, ensure an appropriate level of cybersecurity, and notify the AI Office when the threshold is met or it becomes known that it will be met. In plain English, the EU expects extra discipline from the providers of the most capable upstream models because failures there can spread widely across the market.
Timing matters too. The obligations for providers of general-purpose AI models entered into application on 2 August 2025. The Commission's enforcement powers for those obligations start from 2 August 2026. Providers of models already placed on the market before 2 August 2025 have a transition period and must comply by 2 August 2027. For practical purposes, that means this is already live for new models, even though enforcement intensity continues to mature.
The Code of Practice for general-purpose AI models is relevant here as a voluntary compliance tool. It is not the law itself, but it is designed to help providers demonstrate compliance with the legal obligations around transparency, copyright, and, for systemic risk models, safety and security. That gives providers a clearer operational path and gives downstream customers better questions to ask.
For a business leader, the operational test is simple. Ask where the broad capability sits. If your supplier is providing a reusable, adaptable upstream model that many applications can be built on, you may be in general-purpose AI model territory. If your supplier is giving you a finished application with a narrow task and no real model level control, you are more likely dealing with an AI system rather than the model category itself.
Examples
A software company offers a broad language model through an API. Customers use it for drafting, summarising, translation, coding help, and customer support assistants. That upstream API provider is much more likely to be the provider of a general-purpose AI model than the individual firms building specific apps on top of it.
A media business fine tunes an open model into an internal newsroom assistant. If the fine tuning is minor, the business may remain mainly a downstream AI system provider using someone else's general-purpose model. If the modification is significant enough, however, the business may become the provider of a different model with its own obligations. This is why "we only customised it a bit" is not a serious governance answer.
A hospital buys a clinical documentation tool powered by a broad model supplied by a third party. The hospital may never touch model weights or training code, but it still needs to know what sits upstream, what the provider is responsible for, and what information should be passed down for safe and lawful deployment.
A manufacturer builds an internal assistant on top of a widely used multimodal model that can interpret images, manuals, maintenance logs, and sensor descriptions. The manufacturer may not itself be a general-purpose model provider, but contracts, security review, acceptable use, and staff guidance all become easier if the upstream model provider can clearly document the model's capabilities and limitations.
Common misunderstandings
The first misunderstanding is that "general-purpose AI model" just means "foundation model". That is too loose. The two categories often overlap in practice, but the AI Act uses its own legal definition and attaches specific obligations to it. Your internal terminology and the Act's terminology are not automatically the same.
The second misunderstanding is that any big model counts. Size helps, but size alone is not the legal test. The key questions are generality, task range, reusability, market placement, and downstream integration. Some very large models are still narrow in their intended role. Some broadly capable models matter less because they are not yet placed on the market.
The third misunderstanding is that the category only matters to the original developer. In reality, everyone downstream has an interest in whether a model is in scope, because the whole point of the regime is to improve information flow through the value chain. If you are building on top of a model, you should care whether your provider understands and meets these duties.
The fourth misunderstanding is that open-source release makes the issue disappear. Open release can change which obligations apply, but it does not erase the category, and it does not remove systemic risk duties. Leaders should treat "it's open-source" as the start of the diligence conversation, not the end of it.
The fifth misunderstanding is that this is a paperwork category with little operational relevance. In fact, it directly affects vendor diligence, product design, copyright governance, acceptable use controls, incident management, and technical documentation. If the upstream layer is uncertain, downstream control becomes harder.
Risks and boundaries
This category does not tell you whether an AI product is useful, accurate, safe for your specific context, or lawful in every jurisdiction. It tells you where a particular model may sit in the EU AI Act's structure. That is valuable, but it is not a complete risk judgement.
There are also genuine boundary questions. Significant model modification, open-source exemptions, and the precise line between a broad model and a narrower one can be contested in edge cases. The Commission's guidance helps, but it does not remove all interpretation issues. If a major product launch or contractual position depends on the classification, specialist advice is sensible.
Leaders should also avoid assuming that a provider's compliance automatically protects the deployer. The Act spreads responsibilities across the value chain. A provider's documentation can help you, but it does not replace your own governance, privacy, security, procurement, or sector specific duties.
Finally, treat timelines as time sensitive. The basic obligations for general-purpose AI models are already in force, but enforcement practice, codes, templates, and guidance continue to develop. This explainer is for general information and is not legal advice.
What to do next
First, inventory the upstream models your organisation depends on. Do not stop at application names. Find out which underlying models power the tools your teams use, whether through API access, hosted endpoints, or open weights.
Second, establish your role in each case. Are you only a deployer of a finished system, a downstream provider building an application on top of a model, or a provider that has modified a model so substantially that you may have model level obligations yourself? This role mapping is foundational.
Third, ask vendors for the right documents. You want model documentation, intended use information, technical limitations, acceptable use restrictions, support for downstream compliance, and a clear statement on whether the provider considers the model a general-purpose AI model, and if so whether it may fall into the systemic risk tier.
Fourth, review your open-source stack with the same seriousness you apply to commercial vendors. Licence terms, provenance, documentation depth, update cadence, safety controls, and community governance all matter.
Fifth, build a repeatable process. General-purpose model dependence should become a standard part of AI procurement, architecture review, and risk acceptance, not an ad hoc legal query raised late in the project.
Sixth, keep watching the guidance and enforcement path. This is an active regulatory area. A lightweight quarterly review of major supplier notices, Commission guidance, and internal model dependencies will keep surprises smaller.
FAQs
Is a general-purpose AI model the same as a chatbot?
No. A chatbot is usually an AI system or application. A general-purpose AI model is the underlying model layer that may power many different systems, including chatbots.
Is every large language model a general-purpose AI model?
Not automatically. Many are, but the legal test turns on broad capability, generality, downstream reusability, and whether the model is placed on the market.
Can an open-source model still fall under this category?
Yes. Open-source status may change some obligations, but it does not automatically remove the model from the category, and it does not remove systemic risk duties.
What is the difference between a general-purpose AI model and a general-purpose AI system?
The model is the trained model itself. The system is the product or service built around it, including interface, workflow, integrations, and controls.
When do these obligations apply?
For new general-purpose AI models placed on the market, the obligations applied from 2 August 2025. Commission enforcement powers begin from 2 August 2026, and pre-existing models have a later transition date.
Why should a buyer care if the seller is the model provider?
Because downstream compliance depends on upstream transparency. If the model provider cannot explain the model clearly, the buyer carries more operational and legal uncertainty.
Sources
Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (EUR-Lex). Primary source for the legal definition of "general-purpose AI model", the distinction between model and system, the systemic risk threshold, Articles 51 to 55 obligations, and original application dates.
Guidelines for providers of general-purpose AI models (European Commission). Primary source for the application and enforcement timeline, the role of the guidelines, significant versus minor modifications, and practical framing for providers.
Guidelines on the scope of obligations for providers of general-purpose AI models under the AI Act (European Commission). Primary source confirming the scope purpose of the guidance and its role in interpreting who is in scope.
Guidelines on obligations for General-Purpose AI providers (European Commission). Primary source for baseline obligations, downstream information duties, public summary and copyright obligations, open-source nuances, and enforcement timing.
The General-Purpose AI Code of Practice (European Commission). Primary source for the role of the voluntary Code of Practice and its chapters on transparency, copyright, and safety and security.
AI Act (European Commission). Primary source for the wider AI Act framework and implementation context.