General-Purpose AI System: EU AI Act Definition and Compliance Obligations

A general-purpose AI system is an AI system built on a general-purpose AI model that can serve a variety of purposes — for direct use or for integration into other AI systems. That breadth is precisely what makes the concept important: the obligations that attach to it depend not on the model underneath, but on what the system actually does.

The EU AI Act definition

Article 3 of Regulation (EU) 2024/1689 defines a general-purpose AI system (at point 66) as:

"an AI system which is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use and for integration in other AI systems."

Three elements are load-bearing. First, the system must rest on a general-purpose AI model — the large-scale, trained foundation (a large language model, a multimodal model, or similar). Second, the system itself must have multi-purpose capability; a system locked to a single narrow task by design is unlikely to qualify. Third, that capability must extend to both standalone deployment and downstream integration: a chatbot offered directly to end users qualifies, as does an AI assistant embedded in a third-party application.

The definition sits alongside two others that are easy to conflate: the general-purpose AI model (Article 3, point 63 — discussed below) and the AI system itself (Article 3, point 1 — any machine-based system inferring outputs from inputs to generate predictions, recommendations, decisions, or content).

GPAI system vs GPAI model: the distinction that matters most

The EU AI Act treats the model and the system as legally distinct, and getting this wrong misaligns your obligations.

A GPAI model (Article 3, point 63) is the trained artefact — the underlying neural network or equivalent, trained on broad data, capable of performing a wide range of tasks. GPAI models are governed by Chapter V (Articles 51–56). All GPAI model providers owe baseline obligations under Article 53: technical documentation, information for downstream builders, a copyright compliance policy, and a summary of training data. Providers of models classified as systemic-risk (Article 51, triggered by training compute above 10²⁵ floating-point operations or by Commission designation) face an additional layer under Article 55: model evaluations, adversarial testing, cybersecurity measures, and serious-incident reporting.

A GPAI system (Article 3, point 66) is what a provider or integrator builds on top of that model and places on the market or puts into service. It is the product, not the engine. The obligations that govern a GPAI system are those that govern any AI system — determined by how the system is used, not by the architecture it runs on.

This separation is deliberate. Chapter V obligations follow the model, not the system. When a company builds a customer-service assistant on a third-party large language model, the model provider retains the Article 53 baseline obligations and, if applicable, the Article 55 systemic-risk obligations. The company that builds and deploys the assistant is the provider of an AI system, and its obligations run through the standard provider stack: classification under Articles 5 and 6, and — if the system is high-risk — the full requirements of Articles 9–15 and 16–17, conformity assessment under Article 43, and registration under Article 49.

There is no duplication by design. The Act does not require a GPAI system provider to re-run Chapter V obligations it doesn't owe. What it does require is that the system provider classifies its system correctly and cannot use the argument "we just wrapped a model" to sidestep the obligations that the system's own use attracts.

How a GPAI system is classified

A GPAI system is classified like any other AI system: by its use.

The starting point is Article 6, read together with Annex III. Article 6(1) captures AI systems that are safety components of products already governed by EU product-safety law (listed in Annex I — machinery, medical devices, and so on). Article 6(2) captures systems whose intended purpose falls within one of the eight high-risk areas listed in Annex III: biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services (including creditworthiness assessment and health/life insurance pricing), law enforcement, migration and border control, and the administration of justice and democratic processes.

A GPAI system that is general in principle but deployed for a specific Annex III purpose inherits the high-risk classification for that deployment. A conversational assistant used in a credit-scoring workflow is high-risk because of where it sits, not because of what model it runs on.

The Article 6(3) filter applies equally. A system that falls nominally within an Annex III area escapes the high-risk classification if it poses no significant risk of harm to health, safety, or fundamental rights — for example, it performs a narrow procedural task, improves the result of a human activity already completed, or detects decision patterns without replacing or influencing a human assessment. The one firm boundary: any system that profiles natural persons is always high-risk, regardless of the filter. Providers relying on Article 6(3) must document the assessment and register it.

Below the high-risk threshold, a GPAI system may be limited-risk. Article 50 applies where the system interacts directly with natural persons (chatbot disclosure duty under Article 50(1)), generates synthetic content (marking obligations), or processes biometric data in ways that trigger Article 50(3) disclosures. A GPAI system used internally with no direct natural-person contact and no Annex III use is minimal-risk: no mandatory obligations, though voluntary codes of conduct are encouraged.

The obligations do not transfer from the model. A company that builds on a systemic-risk model is not thereby a systemic-risk model provider. Conversely, it cannot assume that the model's Article 55 evaluations satisfy its own Article 9 risk management obligations for the system it places on the market.

Examples

A customer-service chatbot built on a foundation model. The system provider integrates a third-party large language model and deploys a chat interface for consumer inquiries. The model provider keeps its Article 53 obligations (and Article 55 if systemic-risk). The system provider classifies its system: the use is general customer service — not an Annex III area, not safety-critical, interacting directly with natural persons. Classification: limited-risk under Article 50(1), requiring disclosure to users that they are interacting with an AI system. No high-risk obligations apply.

A recruitment screening assistant at a mid-size HR-tech company. The company builds an automated CV-screening tool on a general-purpose model and markets it to employers. Recruitment screening and evaluation of persons for employment falls under Annex III, point 4(a). The system is high-risk. The company is the provider under Article 16. It owes a risk management system (Article 9), data governance (Article 10), technical documentation (Article 11, Annex IV), logging (Article 12), transparency to deployers (Article 13), human oversight (Article 14), accuracy and robustness requirements (Article 15), a quality management system (Article 17), conformity assessment under Article 43 using the Annex VI internal-control route, a declaration of conformity (Article 47), and registration in the EU database (Article 49). The model provider's Chapter V obligations are separate and unaffected.

A developer who embeds a GPAI model into a third-party product and puts their own name on it. Under Article 25, a company that substantially modifies an AI system or places it on the market under its own name becomes the provider for that system. The Article 25 mechanism means a downstream integrator cannot shelter behind the upstream model provider's obligations — once you rebrand or substantially change the system, you own the provider stack.

Frequently Asked Questions

Q: Does building on a GPAI model make my product a GPAI system?

Yes, if the resulting product retains multi-purpose capability. A narrow, task-locked application that happens to use a large language model internally may not qualify as a GPAI system if the AI component is constrained to a single defined function. The key test is whether the system, as placed on the market or put into service, has the capability to serve a variety of purposes. If it does, Article 3, point 66 applies. Classification for compliance purposes — unacceptable, high, limited, or minimal risk — then follows from the system's actual use under Articles 5 and 6.

Q: If I use a GPAI model whose provider has already done Article 53 compliance, does that satisfy my own obligations?

No. Article 53 obligations stay with the model provider. Your obligations as a system provider are separate: you classify your system under Article 6, and if it is high-risk, you run the full Article 9–15 and 16–17 stack, conduct a conformity assessment under Article 43, and register under Article 49. The model provider's technical documentation and information package (required under Article 53) is an input to your own technical file, not a substitute for it.

Q: Can a GPAI system be high-risk, limited-risk, or minimal-risk?

Yes to all three. Classification depends on use, not architecture. A GPAI system used for an Annex III purpose — creditworthiness assessment, recruitment screening, biometric identification — is high-risk. A GPAI system that interacts directly with consumers in a general context is limited-risk under Article 50. A GPAI system used entirely in a back-office context with no natural-person contact and no Annex III scope is minimal-risk. The model underneath does not set the tier; the system's intended purpose and deployment context do.

Q: What happens when a company integrates a third-party GPAI model and puts the product on the market under its own name?

Article 25 applies. A company that places an AI system on the market under its own name or trademark, substantially modifies a system, or repurposes it for a use different from the original intended purpose, becomes the provider of that system for EU AI Act purposes. It inherits the full provider obligations (Article 16 onwards). The original model provider retains its Chapter V obligations, but that does not reduce the new system provider's liability for the system it ships.

Q: When did GPAI model obligations come into force?

Chapter V obligations — covering GPAI models under Articles 51–56 — have applied since 2 August 2025. GPAI models already on the market before that date have until 2 August 2027 to comply. The Digital Omnibus agreed in May 2026 deferred the high-risk system deadline (Article 6 + Annex III) for stand-alone systems to 2 December 2027, but that deferral does not touch Chapter V. GPAI model obligations are live now.

Q: Does my GPAI system need to be registered in the EU database?

Only if it is high-risk. Article 49 requires providers of high-risk AI systems to register in the EU database established under Article 71 before placing the system on the market or putting it into service (with limited exceptions for law-enforcement, migration, and border-control systems, which go into a non-public section). A limited-risk or minimal-risk GPAI system has no registration obligation under Article 49, though providers who invoke the Article 6(3) exemption must document and register that assessment.

Related terms

• General-Purpose AI Model — the trained artefact governed by Chapter V; the foundation on which a GPAI system is built
• AI System — the base definition (Article 3, point 1) that underlies both GPAI and non-GPAI systems
• AI Risk Classification — how Article 6 and Annex III determine the tier for any AI system, including GPAI systems
• Article 6: High-Risk Classification Rules — the classification test and the Article 6(3) filter
• Systemic Risk — the threshold at which a GPAI model draws additional obligations under Article 55
• GPAI Compliance — the obligations in Articles 53 and 55 that model providers owe, and how they interact with system-provider duties