The EU AI Act places binding obligations on anyone who provides a general-purpose AI model in the EU, and the General-Purpose AI Code of Practice is the main way providers show they meet them. The Code was published on 10 July 2025 and confirmed by the European Commission and the AI Board as an adequate voluntary tool on 1 August 2025. It has three chapters: Transparency, Copyright, and Safety and Security. This guide explains who the Code is for, what each chapter asks providers to do, how the dates and enforcement work after the Digital Omnibus on AI, and what the Code means for organisations that build agents and products on top of someone else's model. It is for AI governance, security, legal and procurement leads and executives. For the wider Act, see the EU AI Act Compliance Guide.
Key takeaways
- The obligations are in the Act, not the Code. Articles 53 and 55 of Regulation (EU) 2024/1689 bind GPAI model providers whether or not they sign; the Code is one recognised way to demonstrate compliance until harmonised standards exist.
- Two chapters apply to every GPAI provider. Transparency (technical documentation and downstream information) and Copyright (a copyright policy that respects machine-readable opt-outs) cover all general-purpose AI models.
- Safety and Security is only for systemic-risk models. Its ten commitments, including a Safety and Security Framework, a Model Report and serious incident reporting, apply to providers of models with systemic risk under Article 55.
- Enforcement with fines started on 2 August 2026. The Commission can fine providers up to 3% of worldwide annual turnover or EUR 15 million, whichever is higher, and models placed on the market before 2 August 2025 must comply by 2 August 2027.
- Most enterprises are downstream, not providers. Fine-tuning a model usually does not make you a provider unless the modification uses more than one third of the original training compute, but you still depend on the provider's documentation to meet your own duties.
Scope: who and what is covered
The Act defines a general-purpose AI model (Article 3(63)) as a model that displays significant generality, can competently perform a wide range of distinct tasks and can be integrated into a variety of downstream systems, excluding models used only for research, development or prototyping before market placement. A general-purpose AI system (Article 3(66)) is an AI system built on such a model. The Code addresses the model layer: obligations sit with the provider (Article 3(3)), the body that develops the model, or has it developed, and places it on the market under its own name.
Thresholds the Commission uses
| Question | Commission position (GPAI guidelines) | Practical effect |
|---|---|---|
| Is it a GPAI model? | Indicative criterion: training compute above 10^23 FLOP and able to generate language (text or audio), text to image or text to video. Exceptions exist in both directions. | Most modern foundation models and many mid-size open models fall in scope. |
| Does it have systemic risk? | Presumed where cumulative training compute exceeds 10^25 FLOP; the Commission can also designate a model on its own initiative or after a scientific panel alert. | Article 55 duties and the Safety and Security chapter apply. |
| When must the Commission be told? | Without delay and within two weeks at the latest once the threshold is met or it becomes known it will be met. | The provider may argue the model does not present systemic risk; the Commission decides. |
| Does a fine-tuner become a provider? | Only where the modification uses more than one third of the original model's training compute. | Below that line, document the changes and the new training data. |
| Open-source release? | Exempt from Article 53(1)(a) and (b) technical documentation duties if released under a free and open-source licence with weights, architecture and usage information public, and not monetised. | Copyright policy and training content summary still apply; no exemption for systemic-risk models. |
Non-EU providers must appoint an authorised representative in the EU (Article 54), with the same open-source exemption. The Commission guidelines are not legally binding: only the Court of Justice of the EU can interpret the Act authoritatively, and borderline models need a case-by-case assessment.
Who has signed
Signing is done by sending the Signatory Form to the AI Office. As listed on the Commission's Code page at the time of writing, signatories include Accexible, AI Alignment Solutions, Aleph Alpha, Almawave, Amazon, Anthropic, Black Forest Labs, Bria AI, Cohere, Cyber Institute, Domyn, Dweve, Euc Inovação Portugal, Fastweb, Google, Humane Technology, IBM, Lawise, LINAGORA, Microsoft, Mistral AI, Open Hippo, OpenAI, Pleias, re-inventa, ServiceNow, Virtuo Turing and WRITER. xAI signed the Safety and Security chapter only and must show compliance with the transparency and copyright obligations by alternative adequate means. The Commission updates the list as signatures are confirmed, so check it before relying on a supplier's status.
Key obligations
The table maps each legal obligation to the chapter that operationalises it. Measure and commitment numbers follow the final Code as summarised by Freshfields; read the Code text itself before relying on a specific measure.
| AI Act obligation | Applies to | Code chapter | What the Code asks |
|---|---|---|---|
| Art. 53(1)(a) technical documentation (Annex XI) for the AI Office and national authorities | All GPAI providers (open-source exemption applies) | Transparency, Measures 1.1 to 1.3 | Model Documentation Form covering model properties, distribution and licensing, use, training, data, testing, compute and energy; keep it current and retain it for 10 years after market placement; protect its integrity. |
| Art. 53(1)(b) information for downstream providers (Annex XII) | All GPAI providers (open-source exemption applies) | Transparency | Supply additional information needed by downstream providers no later than 14 days, save for exceptional circumstances, while protecting trade secrets. |
| Art. 53(1)(c) copyright policy, including rights reservations under Art. 4(3) of Directive (EU) 2019/790 | All GPAI providers | Copyright, Measures 1.1 to 1.5 | One policy for all models; only lawfully accessible content; no circumvention of technological protection measures; exclude sites recognised by EU or EEA courts or authorities as persistently infringing; honour robots.txt and other machine-readable opt-outs; safeguards against infringing outputs; a point of contact and complaint mechanism. |
| Art. 53(1)(d) public summary of training content | All GPAI providers | Commission template (published 24 July 2025), not a Code chapter | Publish the summary using the AI Office template. |
| Art. 55(1)(a) model evaluation including documented adversarial testing | Systemic-risk providers | Safety and Security, Commitments 2 and 3 | Identify risks from several sources, build risk scenarios, run state-of-the-art evaluations and estimate probability and severity. |
| Art. 55(1)(b) assess and mitigate systemic risks | Systemic-risk providers | Commitments 1, 4, 5, 7 and 8 | A Safety and Security Framework notified to the AI Office; acceptance criteria; mitigations robust to fine-tuning and jailbreaks; a Model Report before market placement; clear internal responsibility. |
| Art. 55(1)(c) serious incident tracking and reporting without undue delay | Systemic-risk providers | Commitment 9 | Initial reports within 2, 5, 10 or 15 days depending on the harm, updates every four weeks, records kept for at least five years. |
| Art. 55(1)(d) cybersecurity for the model and its physical infrastructure | Systemic-risk providers | Commitment 6 | Security mitigations against unauthorised access, release or theft of the model, including insider threats, against a defined security goal. |
Transparency chapter in practice
- Documentation is a living record: the Model Documentation Form is optional as a format, but the information it lists is what the AI Office and downstream providers will ask for. Treat it like a controlled document with versioning and approval.
- Two audiences: some fields go only to the AI Office and national authorities on request, others to downstream providers. Mark which is which, and protect the repository with access control and change logging.
Copyright chapter in practice
- Crawler governance: crawlers must read and obey robots.txt and other appropriate machine-readable protocols, and providers must tell rightsholders how their crawlers behave. Publish crawler user agents.
- Source exclusion: maintain a blocklist of sites recognised as persistently infringing on a commercial scale; the Code expects an EU list to be published for this purpose.
- Output safeguards: technical measures to reduce reproduction of protected works, and acceptable use terms that prohibit infringing use, including for open-source releases.
- Complaints: a named contact and complaint route for rightsholders with responses in a reasonable time. See the AI Training Data Provenance and Copyright Exposure Guide for the data lineage side.
Safety and Security chapter in practice
The chapter is structured as a risk management lifecycle. The Framework (Commitment 1) is updated at least every 12 months. The Model Report (Commitment 7) describes the evaluations, the risk acceptance decision and the mitigations and is updated when the basis for acceptance is materially undermined. According to summaries of the Code, Commitment 10 covers keeping internal documentation (reported as 10 years) and publishing summarised Framework and Model Reports to be published where needed. Security mitigations (Commitment 6) are where traditional security teams contribute most: model weight protection, privileged access to training and serving infrastructure, insider risk controls and monitoring. According to Freshfields, the RAND SL3 benchmark is retained only as an optional reference point and the security obligation does not apply to models less capable than models already publicly downloadable.
Timeline and current status
| Date | Event | Source |
|---|---|---|
| 3 July 2025 | Closing plenary of the drafting process | Commission |
| 10 July 2025 | Final Code published and received by the Commission | Commission |
| 24 July 2025 | Template for the public summary of training content published (updated 26 March 2026) | Commission |
| 1 August 2025 | Commission and AI Board adequacy decisions on the Code | Commission |
| 2 August 2025 | Chapter V GPAI obligations apply to new models | Art. 113 |
| 27 July 2026 | Digital Omnibus on AI, Regulation (EU) 2026/1744, enters into force | EUR-Lex metadata |
| 2 August 2026 | Article 101 fines apply; Commission enforces full compliance | Art. 113, Commission FAQ |
| 2 August 2027 | Deadline for models placed on the market before 2 August 2025 | Commission FAQ |
The Digital Omnibus on AI moved the high-risk application dates (Annex III systems to 2 December 2027, Annex I systems to 2 August 2028) but the AI Act Service Desk shows no amendment to Articles 53, 55 or 101, and the 2 August 2025 date for Chapter V is unchanged. Independent trackers report that the Omnibus added AI Office enforcement powers (Articles 75a to 75d) that reach GPAI providers; check the consolidated text before relying on that detail. During the first year the Commission said it would work closely with providers, particularly Code signatories, and would not treat good-faith partial implementation as a breach. That grace period has ended. For the high-risk regime, see the EU AI Act High-Risk AI Systems Guide.
Enforcement and penalties
- Who enforces: the Commission, through the AI Office, supervises GPAI model providers directly.
- Fines (Article 101): 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 infringes the relevant provisions, fails to answer a documentation request under Article 91 or supplies incorrect, incomplete or misleading information, fails to comply with a measure under Article 93, or refuses access for an evaluation under Article 92.
- Due process: the Commission must communicate preliminary findings and give the provider an opportunity to be heard before deciding a fine.
- Effect of signing: the Commission says signing reduces administrative burden and gives more legal certainty than other routes. Non-signatories must show alternative adequate means of compliance, which the Commission assesses. Once harmonised standards are published, compliance with them gives a presumption of conformity to the extent they cover the obligations.
What it means for AI agents and non-human identities
Most organisations building agents are downstream: they call a provider's model through an API or host open weights. The Code still matters to them in three ways.
- Documentation feeds your own compliance: Annex XII information and the 14-day response commitment are what you need to assess capabilities and limitations before wiring a model into an agent with tools. Ask for it in procurement, store it, and record which model version each agent uses. See the AI Supply Chain and AI-BOM Guide.
- Model access is an NHI problem: API keys, service principals and workload identities that call provider endpoints, or that can read model weights, are the credentials Commitment 6 is ultimately about. Stolen keys enable exfiltration through the inference API (MITRE ATLAS AML.T0024) and tampered models or dependencies are an AI supply chain compromise (AML.T0010, and OWASP LLM03:2025 Supply Chain). Vault, scope and rotate these credentials and log every call. See the Agentic AI Compliance Guide.
- Fine-tuning and the provider line: if your team fine-tunes a model with large compute budgets, track the compute used. Crossing one third of the original training compute can make you the provider of a new model with the full Article 53 duties.
- Training data hygiene: copyright policies govern what goes in, but the same pipelines can sweep in secrets. Truffle Security's analysis of 12,000 live secrets in LLM training data shows why crawled corpora need scanning as well as opt-out filtering.
Compliance steps
- Classify your role per model: provider, downstream provider, deployer, or modifier. Record the compute estimate and the reasoning, especially near the 10^23 and 10^25 FLOP lines.
- Decide on the route: sign the full Code, sign selected chapters, or document alternative adequate means. Write down why, because the AI Office will ask.
- Build the documentation set: complete the Model Documentation Form, split authority-only and downstream fields, put it under change control and set a 10-year retention rule.
- Stand up copyright controls: crawler opt-out handling, an infringing-site blocklist, lawful-access checks, output safeguards, and a complaint inbox with a response SLA. Publish the training content summary on the Commission template.
- For systemic-risk models, run the lifecycle: draft the Safety and Security Framework, notify it, run and document adversarial evaluations, set acceptance criteria, write the Model Report before release and rehearse the 2, 5, 10 and 15 day incident reporting clocks with a tabletop exercise. See the AI Red Teaming Guide.
- Secure the model estate: privileged access to weights and training clusters, insider risk monitoring, NHI inventory for every key and service account touching the model, and alerting on unusual inference volumes.
- Test and roll back: pilot the documentation and incident processes on one model first, review gaps against the Code, then extend. Keep the previous Framework version so you can revert if an update is found inadequate.
- Review on a cycle: at least every 12 months for the Framework, and on every material model update or Commission guidance revision.
Choosing a route
| Situation | Usual route | Trade-off |
|---|---|---|
| Large provider with frontier models | Sign all three chapters | Most legal certainty; commitments become the AI Office's yardstick and publication duties apply. |
| Provider disputing some measures | Sign one chapter, show alternatives for others (the xAI pattern) | Flexibility, but the alternative evidence must stand on its own. |
| Small or open-source provider below systemic risk | Sign Transparency and Copyright, or self-document | Open-source exemption narrows documentation duties; copyright policy and summary remain. |
| Enterprise using third-party models | No signature; contract for documentation | Depends on supplier evidence; verify the signatory list rather than marketing claims. |
Detection and measurement
- Percentage of in-scope models with a current, approved Model Documentation Form.
- Median time to answer downstream information requests against the 14-day commitment.
- Copyright complaints received, closed and overdue; crawler opt-out violations found in audits.
- Serious incidents reported within the applicable clock, and days since the last incident drill.
- Credentials with access to model weights or provider APIs that are unowned, unrotated or over-scoped.
Framework mapping
| Code area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Other |
|---|---|---|---|
| Legal obligations and route decision | GV.OC-03 | PM-13 (workforce for compliance roles) | ISO/IEC 42001 AI management system |
| Downstream documentation and supplier terms | GV.SC-05 | SA-4, SR-3, SR-5 | OWASP LLM03:2025 Supply Chain |
| Evaluation and adversarial testing | ID.RA-01, ID.IM-01 | CA-8 | MITRE ATLAS |
| Serious incident reporting | RS.CO-02 | IR-6 | Art. 55(1)(c) |
| Model and infrastructure security | PR.AA-05, PR.DS-01 | AC-6, SR-3 | ATLAS AML.T0010, AML.T0024 |
Common failure patterns
- Assuming not signing means not covered: the obligations apply by law; non-signatories simply carry a heavier burden of proof.
- Trusting a supplier's word on signature status: the list changes, and partial signatures exist. Check the Commission page and record the date checked.
- Losing track of fine-tuning compute: teams that iterate on open weights without logging compute cannot show they stayed below the one-third line.
- Treating robots.txt as the whole copyright answer: the chapter also covers lawful access, infringing-site exclusion, outputs and complaints.
- Incident clocks with no owner: a 2-day reporting window fails if nobody is on call to classify the harm. Name the owner and the deputy.
- Ignoring the credentials around the model: weight stores and provider API keys protected by long-lived static secrets undermine every security commitment.
Practitioner checklist
- Record your role (provider, downstream, modifier) for every model, with compute estimates.
- Check supplier signature status on the Commission list and note the date.
- Complete and version the Model Documentation Form with 10-year retention.
- Answer downstream information requests within 14 days and track it.
- Implement crawler opt-out handling, an infringing-site blocklist and a complaints route.
- Publish the training content summary on the Commission template.
- For systemic-risk models, notify the Framework, write the Model Report and drill incident clocks.
- Inventory, vault and rotate every key and service account with model or weight access.
- Review the Framework and documentation at least every 12 months and on major updates.
Standards and references
- European Commission: The General-Purpose AI Code of Practice
- European Commission: General-Purpose AI Code of Practice, drafting and adequacy
- European Commission: Guidelines on obligations for general-purpose AI providers (Q&A)
- AI Act Service Desk: Article 53, Obligations for providers of general-purpose AI models
- AI Act Service Desk: Article 55, Obligations for providers of GPAI models with systemic risk
- AI Act Service Desk: Article 101, Fines for providers of general-purpose AI models
- EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
- Freshfields: The final General-Purpose AI Code of Practice, a short guide
Related NHI Mgmt Group resources: EU AI Act Compliance Guide · EU AI Act Prohibited Practices Guide · AI Training Data Provenance and Copyright Exposure Guide · AI Governance Guide. This guide summarises the EU General-Purpose AI Code of Practice and the related AI Act obligations and is not legal advice.