What counts as a general-purpose AI model
The EU AI Act treats general-purpose AI (GPAI) models as a distinct category with their own rulebook — Chapter V — separate from the risk tiers that govern AI systems. A GPAI model is one trained on a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks, and that can be integrated into a variety of downstream systems. In plain terms: the large language and multimodal foundation models that most Irish SMEs build products on top of.
There is an important line to hold in your head throughout this guide. Chapter V regulates the model — the underlying engine. The rest of the Act regulates AI systems — the products built from those engines. The same organisation can wear both hats, but the obligations attach to what you actually do: train and release a model, or take someone else's model and ship a system.
- •GPAI model = a broadly capable model (e.g. a foundation LLM) that can be adapted to many tasks.
- •GPAI system = an AI system based on a GPAI model, that can serve a variety of purposes.
- •The Chapter V duties below sit on the model provider — the entity that develops the model and places it on the market under its own name or trademark.
The four baseline duties every GPAI provider owes (Article 53)
Article 53(1) sets a floor that applies to every provider of a GPAI model placed on the EU market, regardless of size or capability. There are four duties, and they are cumulative:
- (a) Technical documentation — draw up and keep current the model's technical documentation, including its training and testing process and evaluation results, containing at least the information set out in Annex XI, and provide it to the AI Office and national competent authorities on request.
- (b) Information for downstream providers — prepare, keep current and make available documentation to the providers who will integrate your model into their AI systems, containing at least the elements in Annex XII, so they understand the model's capabilities and limitations and can meet their own obligations.
- (c) Copyright-compliance policy — put in place a policy to comply with Union copyright law, in particular to identify and respect a reservation of rights expressed under Article 4(3) of the Copyright in the Digital Single Market Directive ((EU) 2019/790).
- (d) Public training-content summary — draw up and make publicly available a sufficiently detailed summary of the content used to train the model, following the template published by the AI Office.
Two of these — (a) and (b) — are about traceability down the supply chain: the model provider hands the downstream builder enough to understand and document what they are shipping. The other two — (c) and (d) — are about the training data itself, and they are the ones that reach even lightweight releases. Note the framing throughout: these are not one-off filings. 'Keep current' means the documentation is a living artefact that tracks the model as it is updated.
The open-source partial exemption (Article 53(2))
There is a targeted relief for genuinely open models. Under Article 53(2), the duties in 53(1)(a) and (b) — the technical documentation and the downstream-provider documentation — do not apply to providers of models released under a free and open-source licence that allows access, use, modification and distribution, and whose parameters, including the weights, model architecture and usage information, are made publicly available.
Read the boundaries carefully, because they are where teams get caught out. The exemption never covers the copyright-compliance policy (c) or the public training-content summary (d) — those apply to open and closed models alike. And it evaporates entirely for a model that carries systemic risk: an open-source model over the threshold in the next section owes the full set of obligations, including the Article 55 duties.
- •A permissive licence alone is not enough — weights, architecture and usage information must be publicly available.
- •The copyright policy and the training-content summary always apply, even to open-source releases.
- •The exemption does not apply to a GPAI model with systemic risk.
When a model carries 'systemic risk' (Article 51)
A second, heavier tier applies to the most capable models. Article 51 classifies a GPAI model as carrying systemic risk when it has 'high-impact capabilities' — capabilities that match or exceed those of the most advanced models. The Act attaches a concrete presumption to make this operable: a model is presumed to have high-impact capabilities when the cumulative amount of compute used for its training, measured in floating-point operations (FLOP), is greater than 10^25.
The AI Office can also designate a model as carrying systemic risk on the basis of other criteria — number of parameters, dataset size, number of registered EU business or end users — even below the compute threshold. For most SMEs, the honest answer is that you are almost certainly not training a systemic-risk model; the 10^25 FLOP frontier is the territory of a handful of well-resourced labs. But you should know the line exists, because it changes the obligations completely.
The two-week notification (Article 52)
The systemic-risk tier comes with a hard deadline. Under Article 52, where a model meets the 10^25 FLOP condition — or where it becomes known that it will meet it — the provider must notify the Commission without delay, and in any event within two weeks of the requirement being met or of it becoming foreseeable. A provider that believes its model does not present systemic risk despite crossing the threshold can say so in the notification and present arguments, but the notification itself is not optional.
This is the clearest example in Chapter V of the Act's continuous-compliance logic: the duty is triggered by a measurable fact about the training run, and the clock starts the moment that fact is knowable — not at some annual review.
The extra duties for systemic-risk models (Article 55)
On top of the Article 53 baseline, providers of GPAI models with systemic risk owe a further set of obligations under Article 55 that look a lot like an operational safety regime:
- Model evaluation — perform evaluation using standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing (red-teaming) to identify and mitigate systemic risks.
- Systemic-risk assessment and mitigation — assess and mitigate possible systemic risks at Union level, including their sources, that may stem from the development, placing on the market or use of the model.
- Serious-incident tracking and reporting — keep track of, document and report relevant information about serious incidents and possible corrective measures to the AI Office and, as appropriate, to national competent authorities, without undue delay.
- Cybersecurity — ensure an adequate level of cybersecurity protection for the model and its physical infrastructure.
These duties do not have an end state. Evaluation, incident tracking and mitigation run for as long as the model is on the market — which is exactly why treating GPAI compliance as a document you file once, rather than a programme you operate, does not work at this tier.
The GPAI Code of Practice: the practical route to compliance
Article 53 and Article 55 tell you what to achieve; they say less about exactly how. That gap is filled by the GPAI Code of Practice, facilitated by the AI Office under Article 56. Until a harmonised European standard is published, adherence to an approved code of practice is the primary way a provider can demonstrate compliance with the Chapter V obligations — it operates as a presumption-of-conformity mechanism, the same pattern the Act uses for high-risk systems and harmonised standards.
For a provider, signing up to and following the Code is the path of least resistance: it translates the statutory duties into concrete measures on documentation, copyright and — for systemic-risk models — safety and security. A provider that chooses not to rely on the Code must instead demonstrate compliance by other adequate means, and be ready to show its working to the AI Office.
Are you a model provider or a downstream deployer?
This is the question that decides whether Chapter V lands on you at all, and it is where most Irish SMEs will land on the lighter side. The GPAI provider is the entity that develops the model and places it on the market under its own name or trademark. If you consume a model through an API, or deploy an off-the-shelf open-weights model without materially changing it, you are typically a downstream provider of an AI system or a deployer — you owe the system-level obligations (including the Article 50 transparency duties), not the Chapter V model duties.
There is one nuance worth flagging. A downstream organisation that substantially fine-tunes or modifies a GPAI model can itself become the provider of a GPAI model in respect of that modification — but only for the modification, and the relevant compute is that of the fine-tuning, not the original training run. In practice most fine-tunes fall well short of the systemic-risk threshold. Getting this classification right, and documenting it, is the first move: it determines which obligations you generate.
Timeline, penalties and where Veritome fits
The dates matter. The GPAI obligations in Chapter V have applied since 2 August 2025 — well ahead of the high-risk regime, whose main application date Regulation (EU) 2026/1744 moved to 2 December 2027. So GPAI is not a future problem; for providers it is a live one. Enforcement of the GPAI rules runs through the Commission and the AI Office rather than solely the national authorities, and the fines have their own track: under Article 101 the Commission may fine a GPAI model provider up to €15 million or 3% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
Veritome's classification wizard flags when a system relies on or constitutes a general-purpose AI model, and separates the model-provider hat from the downstream-provider hat so you are not accidentally taking on Chapter V duties you do not owe — or missing ones you do. From there the engine maps the applicable obligations, whether that is the Article 50 disclosures for a downstream chatbot or the full Article 53 and 55 set for a provider, and keeps the documentation live rather than static. This article is general information about the EU AI Act, not legal advice — for a specific model or product, take qualified advice.