Providers of general-purpose AI (GPAI) models carry their own set of duties under the EU AI Act, separate from the high-risk system rules, and the Commission has been able to fine them since 2 August 2026. Chapter V of Regulation (EU) 2024/1689 sets baseline obligations for every GPAI model provider in Article 53, a mandate rule for non-EU providers in Article 54, and extra duties for models with systemic risk in Article 55. This guide explains who counts as a GPAI provider, what each obligation requires in practice, how the voluntary Code of Practice fits, and what evidence a compliance, security or model governance team should keep. It is written for model providers, organisations that fine-tune or modify models, and the security and legal teams that support them. Status checked against the official Commission and EUR-Lex pages on 13 November 2026.
Key takeaways
- The obligations are already live. Chapter V has applied since 2 August 2025 and the Commission's fining power under Article 101 since 2 August 2026; models placed on the market before 2 August 2025 have until 2 August 2027.
- Every GPAI provider has four core duties. Article 53(1) requires technical documentation, information for downstream providers, a copyright policy and a public summary of training content.
- Systemic risk adds security engineering duties. Article 55 requires state of the art model evaluation including adversarial testing, systemic risk assessment and mitigation, serious incident reporting and adequate cybersecurity for the model and its physical infrastructure.
- The compute presumption is 10^25 FLOP. A model trained with more than 10^25 floating point operations is presumed to have high impact capabilities, and the provider must notify the Commission within two weeks.
- The Code of Practice is the practical route. The Commission and the AI Board have confirmed the July 2025 Code as an adequate voluntary tool for showing compliance with Articles 53 and 55 until harmonised standards are published.
Who the GPAI chapter applies to
Article 3(63) defines a general-purpose AI model by its generality: a model that displays significant generality and can competently perform a wide range of distinct tasks, and that can be integrated into a variety of downstream systems or applications. Models used only for research, development or prototyping before they are placed on the market are outside the definition. The Commission's Q&A notes that recital 98 treats models with at least a billion parameters, trained on large amounts of data using self-supervision at scale, as displaying significant generality, and that large generative models are the typical example.
The GPAI rules attach to the model and its provider, not to the AI system built on it. A company that builds a chatbot on a third-party model is a downstream provider of an AI system; its duties come from the system rules (for example Article 50 transparency, or the high-risk rules if the use case is listed). See the EU AI Act Provider vs Deployer Obligations Guide for the system-level roles.
| Your position | Are you a GPAI model provider? | What applies |
|---|---|---|
| You train a general-purpose model and place it on the EU market or release it (API, download, product) | Yes | Article 53; Article 54 if established outside the EU; Article 55 if the model has systemic risk |
| You release a model under a free and open-source licence with weights, architecture and usage information public | Yes, with a partial exemption | Article 53(1)(c) and (d) still apply; (a) and (b) do not, unless the model has systemic risk |
| You fine-tune or modify a third-party GPAI model | Possibly, for the modification | The Commission Q&A states that obligations for a modifier who becomes a provider are limited to the modification (recital 109); the Commission guidelines of 18 July 2025 set the criteria |
| You integrate a third-party model into your own AI system | No (you are an AI system provider) | System rules; you receive Article 53(1)(b) information from the model provider |
| You only use an AI system built on a model | No (deployer) | Deployer duties such as Article 4 AI literacy and Article 50 where relevant |
Timeline and enforcement
The dates below come from Article 113, Article 111(3) and the Commission's AI Act policy page. The Digital Omnibus on AI, which entered into force on 27 July 2026, moved the high-risk dates but, as of the Commission page checked on 13 November 2026, did not change the GPAI dates; it strengthened the AI Office's role in supervising AI systems built on GPAI models.
| Date | What happens for GPAI providers | Source |
|---|---|---|
| 1 August 2024 | Regulation enters into force | Commission AI Act policy page |
| 10 July 2025 | General-Purpose AI Code of Practice published | Commission Code of Practice page |
| 18 July 2025 | Commission guidelines on the scope of GPAI obligations published | Commission guidelines page |
| 24 July 2025 | Template for the public summary of training content published | Commission template page |
| 2 August 2025 | Chapter V (Articles 51 to 56) applies, together with governance and penalties chapters, except Article 101 | Article 113(b) |
| 2 August 2026 | Commission enforcement powers apply, including Article 101 fines | Article 113(b); Commission guidelines page |
| 2 August 2027 | Deadline for models placed on the market before 2 August 2025 | Article 111(3); Commission guidelines page |
Article 101(1) allows the Commission to fine a GPAI provider up to 3% of total worldwide annual turnover in the preceding financial year or EUR 15 million, whichever is higher, where the provider intentionally or negligently infringed the Regulation, failed to answer a document or information request under Article 91, supplied incorrect, incomplete or misleading information, failed to comply with a measure under Article 93, or failed to give the Commission access to the model for evaluation. Supervision sits with the AI Office in the Commission, not with national market surveillance authorities. For every milestone across the Act, see the EU AI Act Implementation Timeline Tracker.
Article 53: obligations for every GPAI provider
Technical documentation (Article 53(1)(a), Annex XI)
The provider must draw up and keep up to date technical documentation of the model, including its training and testing process and the results of its evaluation, containing at least the Annex XI elements, and supply it to the AI Office and national competent authorities on request. The Code of Practice Transparency chapter provides a Model Documentation Form for this. Treat the form as a controlled record: version it per model release, assign an owner, and record which items are shared only with authorities.
Information for downstream providers (Article 53(1)(b), Annex XII)
Providers of AI systems that integrate the model must receive enough information to understand its capabilities and limitations and to meet their own obligations. In practice this is the model card, acceptable use and integration documentation, known limitations, and evaluation results relevant to integrators. Security teams should make sure the downstream package covers what an integrator needs for its own risk work: supported input and output modalities, known failure modes such as prompt injection susceptibility, and the safety features an integrator can switch on.
Copyright policy (Article 53(1)(c))
The provider must put in place a policy to comply with Union copyright law, in particular to identify and comply with a reservation of rights under Article 4(3) of Directive (EU) 2019/790 (the text and data mining opt-out), including through state of the art technologies. The Code of Practice Copyright chapter sets out practical measures. Engineering evidence matters here: crawler configuration, how machine-readable opt-outs are honoured, and logs that show the policy ran.
Public summary of training content (Article 53(1)(d))
The provider must publish a sufficiently detailed summary of the content used for training, using the AI Office template published on 24 July 2025. The Commission describes the template as a common minimal baseline giving an overview of training data, including data sources and information on data processing. See the AI Training Data Provenance and Copyright Exposure Guide for how to build the underlying data inventory.
Cooperation and the open-source exemption
Article 53(3) requires cooperation with the Commission and national competent authorities. Article 53(2) removes the documentation duties in points (a) and (b) for models released under a free and open-source licence whose parameters, including weights, architecture information and usage information, are made publicly available. The exemption never applies to models with systemic risk, and it never removes the copyright policy or the training content summary.
Article 54: authorised representatives for non-EU providers
Before placing a GPAI model on the Union market, a provider established in a third country must appoint, by written mandate, an authorised representative established in the EU. The provider must enable the representative to perform the mandated tasks, and the representative must provide a copy of the mandate to the AI Office on request. The representative must be able to hold the technical documentation and answer the AI Office, so choose one with access to the documentation repository rather than a mailbox service. The open-source exemption applies to this duty on the same terms as Article 53(2), again with no exemption for systemic-risk models.
Systemic risk: classification and notification
Article 51(1) classifies a GPAI model as having systemic risk if it has high impact capabilities, evaluated with appropriate technical tools and methodologies, or if the Commission designates it on the Annex XIII criteria. Article 51(2) presumes high impact capabilities when the cumulative amount of computation used for training is greater than 10^25 floating point operations. The Commission can change the threshold by delegated act under Article 51(3).
- Notification: under Article 52(1) the provider notifies the Commission without delay and in any event within two weeks after the threshold is met or it becomes known that it will be met. The Commission states that notifications are submitted through the EU SEND platform.
- Plan the compute count early: the two-week clock can start before training finishes ("it becomes known that it will be met"), so the training compute budget approval is the natural trigger for the legal review.
- Arguments against classification: the provider may present arguments with its notification that, despite meeting the threshold, the model does not present systemic risk. Keep the evaluation evidence that supports that position.
Article 55: duties for systemic-risk models
Article 55 applies in addition to Article 53. Most of it is security and assurance engineering, which is why security teams at frontier model providers carry much of the delivery.
| Article 55(1) duty | What it requires | Evidence to keep |
|---|---|---|
| (a) Model evaluation | Evaluation in accordance with standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing, to identify and mitigate systemic risks | Evaluation plans, red team scopes and reports, results per model version (Annex XI section 2 also asks for evaluation strategies, adversarial testing and system architecture) |
| (b) Systemic risk assessment and mitigation | Assess and mitigate possible systemic risks at Union level, including their sources, from development, placing on the market or use | Risk register, mitigation decisions, release gating records |
| (c) Serious incidents | Keep track of, document and report without undue delay to the AI Office, and as appropriate national competent authorities, relevant information about serious incidents and possible corrective measures | Incident log, notification records, corrective action tracking |
| (d) Cybersecurity | Ensure an adequate level of cybersecurity protection for the model and the physical infrastructure of the model | Security architecture, access reviews for weights, insider risk controls, test results |
The Code of Practice Safety and Security chapter applies only to systemic-risk providers and sets out state of the art practices for managing those risks. For the incident side, map the Article 55(1)(c) process into your wider reporting clock work; see the AI Incident Reporting Guide.
What "adequate cybersecurity" means in practice
The Act does not list controls, so providers build from established practice. The threats most specific to model providers are theft of model weights, tampering with training data or checkpoints, and compromise of the identities that run training and deployment pipelines.
- Weights as crown jewels: keep weights in dedicated storage with access limited to named roles and workload identities, encryption with customer or provider managed keys, and logging of every read. See the AI Model Theft Response Playbook.
- Training pipeline integrity: sign checkpoints and datasets, record provenance, and treat data poisoning (OWASP LLM04:2025 Data and Model Poisoning) and supply chain risk (OWASP LLM03:2025 Supply Chain) as in-scope threats.
- Machine identities: training clusters, evaluation harnesses and inference services run on service accounts, tokens and cloud roles. Short-lived credentials and per-pipeline identities limit the blast radius if one is stolen. See the AI Model Security Guide.
- Physical infrastructure: Article 55(1)(d) names it explicitly, so data centre access, hardware supply and colocation contracts belong in the evidence pack.
The Code of Practice and other routes to compliance
Articles 53(4) and 55(2) let providers rely on codes of practice within the meaning of Article 56 to demonstrate compliance until a harmonised standard is published. The General-Purpose AI Code of Practice, published on 10 July 2025, has three chapters: Transparency and Copyright, which apply to all GPAI providers, and Safety and Security, which applies only to systemic-risk providers. The Commission and the AI Board have confirmed it as an adequate voluntary tool.
| Route | How it works | When it suits |
|---|---|---|
| Sign the whole Code | Follow the three chapters; the Commission says signatories benefit from reduced administrative burden and more legal certainty | Most providers, especially those without a mature internal framework |
| Sign some chapters | Follow the signed chapters and show the remaining obligations by other adequate means (the Commission page notes one provider signed only the Safety and Security chapter) | Providers with an established approach for one area |
| Alternative adequate means | Show compliance directly against Articles 53 and 55 with your own documented framework | Providers able to defend a bespoke method to the AI Office |
| Harmonised standards | Once published, conformity with them is the standard route | Future; track standardisation progress |
The Commission's earlier Q&A explains that adherence to the Code is a way to demonstrate compliance but does not create a presumption of conformity, and that Code commitments may be taken into account when fines are set under Article 101(1).
Building the compliance programme
- Inventory models and roles: list every model you train, release, fine-tune or integrate, and record for each whether you are the GPAI provider, a modifier, or an AI system provider. Note the market placement date (before or after 2 August 2025).
- Measure training compute: record cumulative training FLOP per model and per planned run, so the 10^25 presumption and the two-week notification can be assessed before training ends.
- Decide the compliance route: Code signatory, partial signatory or alternative means, and record the decision with legal sign-off.
- Produce the Article 53 pack: Model Documentation Form or equivalent, downstream information, copyright policy with crawler evidence, and the public training summary on the AI Office template.
- Appoint the representative: non-EU providers sign the Article 54 mandate before EU placement.
- For systemic-risk models, add Article 55 processes: evaluation and red team programme, risk register, incident reporting runbook, and a security control set for weights and infrastructure.
- Test the evidence: run an internal request exercise, simulating an Article 91 request, and time how long it takes to produce the documentation set. Fix gaps before the AI Office asks.
- Maintain: update documentation per model release and re-check obligations for each significant modification.
Small and large organisations
A start-up releasing an open-weight model under a free and open-source licence mainly needs the copyright policy and the training summary, and should confirm the exemption conditions hold. A company that fine-tunes a third-party model for internal use is usually not a GPAI provider at all, but it should record the analysis. A frontier lab carries the full Article 55 load and will normally need a dedicated team that spans security, evaluation and legal.
Measuring readiness
- Documentation coverage: percentage of released models with a current Model Documentation Form or equivalent (target 100%).
- Request response time: time to assemble the full technical documentation set in a mock AI Office request.
- Training summary currency: released models whose public summary matches the current version.
- Opt-out compliance: share of crawled sources checked against machine-readable rights reservations, from crawler logs.
- Evaluation cadence (systemic risk): model versions released with completed adversarial testing before release.
- Incident handling (systemic risk): time from detection of a serious incident to AI Office notification.
Framework mapping
| AI Act provision | Related framework | Use |
|---|---|---|
| Article 53(1)(a) and (b) documentation | ISO/IEC 42001:2023 AI management system documentation requirements | Reuse the AIMS documented information structure for model records |
| Article 55(1)(a) evaluation and adversarial testing | NIST AI 600-1 Generative AI Profile; MITRE ATLAS | Scope red team exercises and select test techniques |
| Article 55(1)(b) risk assessment | NIST AI RMF 1.0 (Map, Measure, Manage functions) | Structure the systemic risk register |
| Article 55(1)(d) cybersecurity | OWASP Top 10 for LLM Applications 2025 (LLM03, LLM04); NIST CSF 2.0 GV.SC-01 | Threat model the pipeline and suppliers |
These mappings are aids for building evidence. None of them creates a presumption of conformity under the AI Act. See the EU AI Act vs ISO/IEC 42001 guide for the management system overlap.
Common failure patterns
- Assuming fine-tuning never makes you a provider: significant modifications can, and the analysis should be recorded per model, not assumed.
- Treating open source as a full exemption: the copyright policy and training summary still apply, and systemic-risk models get no exemption.
- Counting compute after training: the notification clock can start when it becomes known the threshold will be met, so a post-hoc count can already be late.
- A copyright policy with no technical evidence: a written policy that crawlers do not implement does not show compliance with the rights reservation duty.
- Weights protected like ordinary files: broad storage roles and long-lived keys on training infrastructure undermine the Article 55(1)(d) duty.
- Ignoring the 2027 deadline for legacy models: models placed on the market before 2 August 2025 still need full compliance by 2 August 2027.
Practitioner checklist
- Record, per model, whether you are a GPAI provider, a modifier or an AI system provider, and the market placement date.
- Track cumulative training compute against the 10^25 FLOP presumption and set the notification trigger at budget approval.
- Decide and document the compliance route: full Code, partial Code or alternative adequate means.
- Complete technical documentation and downstream information per Annex XI and Annex XII for every non-exempt model.
- Implement and evidence the copyright policy, including machine-readable opt-out handling in crawlers.
- Publish the training content summary on the AI Office template and update it per release.
- Appoint an EU authorised representative by written mandate if established outside the EU.
- For systemic-risk models, run documented adversarial testing, keep a systemic risk register and rehearse serious incident reporting to the AI Office.
- Protect weights, checkpoints and training identities with least privilege, short-lived credentials and read logging.
- Run a mock Article 91 information request each year and fix the gaps it shows.
Standards and references
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- European Commission: Guidelines for providers of general-purpose AI models
- European Commission: Guidelines on the scope of obligations for providers of general-purpose AI models
- European Commission: The General-Purpose AI Code of Practice
- European Commission: Explanatory notice and template for the public summary of training content
- European Commission: General-purpose AI models in the AI Act, questions and answers
- European Commission: AI Act regulatory framework and timeline
Related NHI Mgmt Group resources: EU AI Act Compliance Guide · EU AI Act High-Risk AI Systems Guide · EU AI Act Provider vs Deployer Obligations Guide · Frontier AI Model Risk Frameworks Guide. This guide summarises the general-purpose AI model obligations in Regulation (EU) 2024/1689 and is not legal advice.