70. EU AI Act GPAI Code of Practice Explained (2026): What It Means for Model Providers (and What Buyers Should Ask For)

Last Updated: September 12, 2026

The EU AI Act’s General-Purpose AI Code of Practice is no longer a draft, a proposal, or a grace-period document. As of August 2, 2026, the European Commission’s enforcement powers over GPAI model providers are fully active. Fines of up to €15 million or 3% of global annual turnover now apply to providers that fail to meet their obligations — whether or not they have signed the Code. If your organisation develops, fine-tunes, or distributes a general-purpose AI model to EU users, the compliance calendar has already decided when scrutiny begins. This guide tells you exactly what the Code requires, who it covers, and what your organisation must do right now.

The GPAI Code of Practice was published in its final form by the European Commission on July 10, 2025, following a multi-stakeholder drafting process involving nearly 1,000 participants. It entered into application alongside the AI Act’s GPAI obligations on August 2, 2025. The Code covers three chapters — Transparency, Copyright, and Safety and Security — and sets out 12 total commitments that signatories agree to implement. The first two chapters apply to all GPAI model providers. The third, Safety and Security, applies only to providers of models above the 10²⁵ FLOP systemic risk threshold — currently approximately 5–15 companies worldwide. According to the European Commission’s AI policy framework, signing the Code gives providers a recognised compliance pathway; not signing means demonstrating compliance through alternative means — which is significantly harder and attracts considerably more scrutiny.

This guide is designed for AI governance leads, legal and compliance professionals, developers, and business leaders who need a complete, current understanding of GPAI Code of Practice obligations in the post-August 2026 enforcement environment. It covers the definitive 2026 definition of the Code, all three chapters in operational detail, the enforcement timeline, the systemic risk threshold, the GPAI vs. high-risk AI distinction (including the Digital Omnibus amendments), a complete compliance checklist, the copyright training data challenge, and GDPR interactions. Whether you are a GPAI model provider assessing your signing decision or a downstream deployer evaluating vendor compliance posture, this guide gives you the complete picture. You can also read the full EU AI Act compliance guide for the broader Act context alongside this GPAI-specific analysis.

🎯 1. What Is the GPAI Code of Practice — The Definitive 2026 Answer

The General-Purpose AI Code of Practice is a compliance tool released by the European Commission on July 10, 2025, to support providers in meeting their obligations under the EU AI Act. It provides operational guidance specifically for providers of general-purpose AI models — the foundation models that power downstream AI applications — particularly in relation to Articles 53 and 55 of the AI Act, which entered into application on August 2, 2025. The Code was confirmed as an adequate compliance tool by the Commission, the AI Board, and Member States on August 1, 2025 — one day before GPAI obligations became active.

It is a voluntary tool. But voluntary does not mean optional in any practical sense. Providers that do not adopt the GPAI Code of Practice, or a comparable framework, must engage in a more complex compliance effort — building a bespoke framework and demonstrating to the AI Office why it is equally robust to the Code’s requirements. Non-signatories face a higher burden of proof, more information requests, and significantly more detailed scrutiny from the AI Office and national authorities. The prospect of administrative fines of up to €15 million or 3% of global annual turnover — active as of August 2, 2026 — applies regardless of whether a provider has signed the Code. Signing gives you a recognised compliance pathway and a presumption of good-faith engagement. Not signing means proving compliance on your own terms, at your own cost, under active enforcement scrutiny.

The Code was developed through a multi-stakeholder process involving nearly 1,000 participants — AI developers, academics, civil society organisations, national authorities, and international observers — across four rounds of drafting. Three earlier draft iterations were published in November 2024, December 2024, and March 2025 before the final version was published July 10, 2025 — more than two months later than initially planned. That extended drafting process reflects the genuine complexity of operationalising GPAI obligations across a diverse global provider landscape, from frontier labs to open-source developers to enterprise fine-tuners.

The 2026 GPAI Enforcement Reality: The GPAI obligations have applied since August 2, 2025. What arrived on August 2, 2026 was consequence. The AI Office can now request documentation, evaluate models directly, order corrective measures, restrict or withdraw models from the EU market, and impose fines. The gap between a legal requirement and an enforceable one is closed.

The Code is structured as 12 total commitments across three chapters. One commitment governs Transparency. One commitment governs Copyright. Ten commitments govern Safety and Security — but only for systemic risk providers. Each commitment is supported by specific measures that describe how providers can live up to that commitment in practice. The Code also includes a Model Documentation Form — a standardised template that consolidates all information required by the AI Act in a single structured document. For organisations building their AI governance framework, the ISO/IEC 42001 AI management system standard provides a complementary governance layer that addresses many Code requirements through its risk management and documentation controls.

📋 2. The Three Chapters — What Each One Requires in Practice

The Code is organised into three chapters: Transparency, Copyright, and Safety and Security. The first two chapters apply to all GPAI model providers. The third applies only to providers above the systemic risk threshold. Understanding what each chapter requires — and what the practical compliance obligations look like — is the core technical task for any organisation assessing its GPAI posture.

Chapter 1: Transparency (Applies to ALL GPAI Providers)

The Transparency chapter establishes how signatories must meet their transparency duties under Article 53(1)(a)–(b) and Annexes XI and XII of the AI Act. The primary goal is to ensure that critical information flows effectively to both downstream providers and the AI Office, while preserving appropriate levels of commercial confidentiality. Three measures define what compliance looks like in practice.

Measure 1.1 requires signatories to prepare comprehensive model documentation before placing a GPAI model on the EU market. This documentation is completed using the standardised Model Documentation Form — a template that covers all information required under Annexes XI and XII in a single structured document. The form must be completed for each GPAI model, kept current to reflect any material changes, and retained for a minimum of 10 years after the model’s initial release.

Measure 1.2 requires signatories to publish publicly accessible contact details allowing the AI Office and downstream providers to request documentation access. When a downstream provider makes a request for additional information — information they need to understand the model’s capabilities and limitations for their specific integration — the signatory must respond within 14 days, except in exceptional circumstances. This is a significant operational requirement: organisations must have a functioning documentation request process, not just a static document repository.

Measure 1.3 requires that all documented information is controlled for quality and integrity, retained as evidence of compliance, and protected from unintended alteration. The open-source exception applies here: these Transparency commitments do not apply to free and open-source models unless they are classified as a GPAI model with systemic risk.

Chapter 2: Copyright (Applies to ALL GPAI Providers)

The Copyright chapter gives practical effect to Article 53(1)(c) of the AI Act, which requires providers to establish a policy for complying with EU copyright law. This chapter went through significant strengthening between the March 2025 draft and the final July 2025 version — “best efforts” language was replaced by firmer commitments throughout, reflecting the Commission’s intent to make copyright obligations genuinely enforceable rather than aspirational.

The chapter requires signatories to establish, maintain, and execute a comprehensive copyright policy for all GPAI models distributed in the EU — covering internal responsibilities, legal standards, and the processes for handling rightsholders’ complaints. Signatories must reproduce and extract only lawfully accessible copyright-protected content when crawling the web. Critically, they must implement machine-readable rights reservation protocols — respecting opt-out signals from content owners who do not consent to their content being used for AI training. They must also designate a contact point for copyright holder complaints and establish efficient, fair processes for handling them.

An important limitation applies: compliance with the Copyright chapter does not guarantee conformity with EU copyright law. As the Code itself states, adherence “does not substitute for the fundamental obligation to comply with Union and national copyright legislation.” Signatories retain full responsibility for ensuring their operations conform to applicable legal frameworks, including Article 4(3) of Directive (EU) 2019/790 on text and data mining. The Code does not replace GDPR obligations. When GPAI providers process personal data during training, fine-tuning, deployment, or inference, GDPR applies in full alongside AI Act obligations.

Chapter 3: Safety and Security (Systemic Risk Models Only)

The Safety and Security chapter only applies to providers of GPAI models with systemic risk — those above the 10²⁵ FLOP training threshold. This currently applies to approximately 5–15 companies worldwide: primarily the frontier model labs whose most advanced models are now in scope, including OpenAI’s o3, Anthropic’s Claude Opus 4.7, and Google’s Gemini 3.1 Pro as confirmed in the Code’s own documentation.

This chapter sets out 10 commitments requiring systemic risk providers to identify, assess, mitigate, and transparently report safety and security risks throughout the model lifecycle. Key requirements include: conducting and documenting adversarial testing and red-teaming before and after deployment; establishing an incident reporting process for serious incidents to the AI Office; implementing cybersecurity protections for model weights and infrastructure; assessing and documenting systemic risk mitigation measures; and conducting ongoing risk monitoring throughout the model lifecycle. The Safety and Security chapter underwent significant streamlining in the final version — commitments were consolidated and the language made more operationally precise — reflecting the working group chairs’ intent to produce a chapter that frontier labs could actually implement rather than merely sign.

One notable case: xAI signed the Safety and Security chapter only, meaning it must demonstrate compliance with the Transparency and Copyright chapters through alternative adequate means rather than via Code adherence. This is permitted under the Code’s framework but places xAI under a higher burden of proof for those two chapters.

📅 3. Enforcement Status — What Changed on August 2, 2026

The enforcement timeline for GPAI obligations has three distinct phases that every compliance team must understand clearly. Conflating these phases — or assuming that the August 2026 milestone is simply “when the EU AI Act applies” — leads to miscalibrated compliance planning.

Phase 1 — Obligations active, enforcement held back (August 2, 2025 – August 2, 2026): GPAI rules took effect on August 2, 2025, meaning all new models released from that date must comply with Articles 53 and 55 obligations. However, the AI Office’s formal enforcement powers — including the ability to impose fines — were held back for a full year. During this collaborative phase, if signatories did not fully implement all commitments immediately upon signing, the AI Office did not treat them as having breached their commitments, recognising good-faith implementation efforts.

Phase 2 — Full enforcement active (August 2, 2026 onwards): That collaborative phase ended August 2, 2026. From this date, the European Commission enforces all GPAI obligations and may impose fines for any non-compliance. From August 2, 2026, the European Commission and its AI Office can request documentation, run technical evaluations of models, demand compliance and risk-mitigation measures, restrict or withdraw a model from the EU market, and issue fines. For signatories, the Commission focuses enforcement on monitoring adherence to the Code and may treat good-faith Code commitments as a mitigating factor when setting fine amounts. For non-signatories, expect a larger volume of information requests and significantly more detailed scrutiny of every aspect of compliance.

Phase 3 — Legacy model deadline (August 2, 2027): GPAI models placed on the EU market before August 2, 2025 — models that were already live when the obligations entered force — have until August 2, 2027 to be brought into compliance. This is a significant deadline for providers of foundation models released in 2023 and 2024. The window is not open-ended: organisations with legacy models must be actively working toward the 2027 deadline now, not treating it as a distant planning horizon.

🤔 4. Should Your Organisation Sign the GPAI Code of Practice?

The signing decision is the most practically consequential question for any GPAI model provider. It is not simply a legal formality — it determines your compliance pathway, your relationship with the AI Office, your administrative burden, and your exposure to enforcement action. This section frames the decision clearly for every relevant organisation type.

Who Must Consider This Decision

The GPAI Code applies to any organisation that develops or provides a general-purpose AI model placed on the EU market. This is broader than it initially appears. It includes foundation model developers who train models from scratch, fine-tuners who substantially modify a GPAI model to the point where they qualify as providers under the AI Act’s definitions, and organisations that deploy GPAI models to EU users via API or embedded in a product. Current signatories include Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI, OpenAI, ServiceNow, and other providers. About 190 organisations had signed the Code before the transparency rules took full effect.

Downstream deployers who use GPAI APIs but do not modify the underlying model are not directly covered by the GPAI Code — but they have separate obligations under the AI Act as deployers, and their vendor’s compliance posture directly affects their own compliance exposure. If your GPAI model provider is not compliant, that risk propagates downstream. Providers of narrow AI systems that are not general-purpose are not covered by the GPAI chapter at all — they may have obligations under other AI Act provisions, including high-risk system requirements under Annex III.

The Case for Signing

Signing the Code gives you a recognised pathway to demonstrate compliance with Articles 53 and 55. The AI Office’s enforcement scrutiny focuses on whether signatories are adhering to Code commitments — a structured, well-documented compliance demonstration. Signing and adhering, even imperfectly during the implementation period, may be treated as a mitigating factor in fine calculations. It signals good faith to regulators, customers, and enterprise partners who are increasingly requiring evidence of AI compliance in procurement processes. It also reduces the administrative burden compared to building a bespoke compliance framework and explaining to the AI Office why that framework is equally robust to the Code’s requirements.

The Case Against Signing — And the Real Risks

Non-signatories are not automatically non-compliant. The Code is a voluntary tool, and organisations can demonstrate compliance through other adequate means. However, the practical burden of doing so is significant. Non-signatories face more information requests, deeper scrutiny, and bear the full burden of proving compliance themselves without the Code’s structured framework as a guide. The Code should be treated as a quasi-regulatory framework. In practice, most serious GPAI providers operating at scale have signed or are in the process of signing. Open-source GPAI models are generally exempt from the heavy Transparency chapter documentation requirements — provided they do not pose a systemic risk. However, even open-source providers must adhere to the Copyright chapter requirements. This is a distinction many open-source model providers initially misunderstand: open-source status exempts you from transparency documentation, not from copyright compliance obligations.

⚖️ 5. GPAI vs High-Risk AI — Understanding the Critical Difference

One of the most common misconceptions in EU AI Act compliance planning is treating GPAI obligations and high-risk AI system obligations as interchangeable or sequential. They are neither. They are two distinct regulatory layers, governed by different articles, enforced by different bodies, targeting different actors in the AI supply chain, and operating on different compliance timelines. Every AI governance team needs a clear map of how they interact.

GPAI model obligations under Articles 53 and 55 govern the model providers — the companies that build and release foundation models. High-risk AI system obligations under Annex III govern the deployers — the companies that use AI in high-risk applications such as hiring, credit scoring, healthcare triage, and law enforcement decision support. A single AI product can trigger both sets of obligations simultaneously: the underlying GPAI model must comply with GPAI obligations at the provider level, and the application built on top of it must comply with high-risk AI system requirements at the deployer level if it falls under Annex III categories. The GPAI Code of Practice addresses the model provider layer only. It does not substitute for high-risk AI system compliance at the application layer.

The Digital Omnibus (Regulation EU 2026/1744) amended the high-risk AI system compliance deadlines, creating significant planning implications for organisations building on GPAI models. Regulation (EU) 2026/1744 states that the delayed availability of standards, common specifications, guidance, and national competent authorities created implementation problems under the original timetable. The amended deadlines are material: stand-alone high-risk systems classified under Article 6(2) and Annex III become subject to the relevant Chapter III requirements on December 2, 2027. High-risk systems built into regulated products face an August 2, 2028 deadline.

🔬 6. The Systemic Risk Threshold — What It Means and Who It Affects

GPAI models with systemic risk face the most demanding obligations under the Code — the full Safety and Security chapter, with its 10 commitments covering adversarial testing, incident reporting, cybersecurity, and ongoing risk monitoring. Understanding exactly who crosses the systemic risk threshold, and what that determination means operationally, is essential for both model providers and the downstream organisations that deploy their models.

The systemic risk threshold is defined as models trained using more than 10²⁵ floating point operations (FLOPs). The Safety and Security chapter only applies to providers of GPAI models with systemic risk — above the 10²⁵ FLOP threshold — currently a small group of 5–15 companies worldwide. This currently captures primarily the frontier model labs: OpenAI, Google DeepMind, Anthropic, Meta, and Mistral AI above threshold, along with a small number of others. The Code’s own documentation confirms that models including OpenAI’s o3, Anthropic’s Claude Opus 4.7, and Google’s Gemini 3.1 Pro are within scope of the systemic risk chapter.

The threshold is not fixed permanently. As compute costs fall and more organisations train foundation models at scale, the 10²⁵ FLOP threshold will eventually capture a broader set of providers. The Commission has the authority to revise the threshold as the technology landscape evolves. Organisations training large models at significant but currently sub-threshold scale should monitor this closely — what puts you outside systemic risk obligations today may not do so in two or three years.

For most enterprise organisations deploying GPAI APIs — the majority of businesses interacting with foundation models — the systemic risk obligations do not apply directly. Your obligations are as a downstream deployer: ensuring the model provider you rely on has met its GPAI obligations, and separately ensuring your application meets any applicable high-risk AI system requirements under Annex III. The systemic risk chapter’s adversarial testing requirements are, however, directly relevant to downstream deployers for a different reason: the testing and documentation that systemic risk providers must produce is precisely the compliance evidence that enterprise procurement teams should be requesting from their GPAI model vendors. The AI vendor due diligence checklist provides the framework for structuring those vendor assessment conversations.

Systemic risk providers must conduct and document adversarial testing and red-teaming — a requirement that connects directly to the broader discipline of LLM red teaming now required across the industry. The Safety and Security chapter’s incident reporting obligations require providers to notify the AI Office of serious incidents — including outputs that contribute to significant harm, failures of safety measures, or unexpected systemic effects — on a defined reporting timeline.

☑️ 7. GPAI Compliance Checklist — Organised by Provider Type

The following checklist translates the Code’s three chapters into actionable compliance steps, organised by provider category. Use this as a working document alongside your governance team — not as a substitute for legal counsel, but as a practical starting point for compliance planning.

For All GPAI Providers — Transparency and Copyright

• ☐ Determine whether your model qualifies as a GPAI model under the AI Act definition — general-purpose capability covering a wide range of tasks, trained on broad data at significant compute
• ☐ Complete the Model Documentation Form for all GPAI models placed on the EU market — covering all information required under Annexes XI and XII
• ☐ Establish a documentation retention system — minimum 10 years from the model’s initial release date
• ☐ Publish publicly accessible contact details for AI Office and downstream provider documentation requests
• ☐ Build an operational process to respond to downstream provider additional information requests within 14 days
• ☐ Establish a copyright compliance policy covering all GPAI models distributed in the EU — defining internal responsibilities, legal standards, and update cadence
• ☐ Implement technical systems to detect and respect machine-readable opt-out signals (robots.txt and equivalent) during web crawling
• ☐ Designate a contact point for copyright holder complaints with documented response processes
• ☐ Assess whether your model was released before or after August 2, 2025 — this determines your enforcement deadline: now (new models) versus August 2, 2027 (legacy models)
• ☐ Make the signing decision: sign the Code at [email protected] or commit to demonstrating compliance through alternative adequate means with documented justification
• ☐ If signing: complete the Signatory Form and submit to the AI Office’s dedicated signature address

For Systemic Risk Providers — Safety and Security (Additional)

• ☐ Confirm whether your model exceeds the 10²⁵ FLOP training threshold — if uncertain, seek legal and technical assessment
• ☐ Conduct and document adversarial testing and red-teaming exercises before and after deployment
• ☐ Establish a formal incident reporting process for serious incidents to the AI Office — with defined timelines, escalation paths, and documentation standards
• ☐ Implement cybersecurity protections for model weights and training infrastructure — consistent with the Code’s security commitments
• ☐ Assess and document systemic risk mitigation measures across all 10 Safety and Security commitments
• ☐ Establish ongoing risk monitoring throughout the model lifecycle — not solely at initial deployment
• ☐ Produce and publish Framework Reports and Model Reports as required by Safety and Security Measure 10.2

For Downstream Deployers — Not Covered by GPAI Code but Directly Affected

• ☐ Confirm your GPAI model provider has signed the Code or can demonstrate equivalent compliance
• ☐ Request your provider’s Model Documentation Form and review capabilities and limitations relevant to your integration
• ☐ Determine whether your application falls under Annex III high-risk categories — hiring, credit, healthcare, education, law enforcement, border control, critical infrastructure
• ☐ If high-risk: begin conformity assessment preparation for the December 2, 2027 deadline (amended by Digital Omnibus, Regulation EU 2026/1744)
• ☐ Implement Article 50 chatbot disclosure for all interactive AI systems that generate text or interact with users
• ☐ Ensure your AI shadow usage policies address GPAI model access — see Shadow AI compliance risks for the governance framework
• ☐ Include GPAI compliance verification in your vendor due diligence process for all foundation model providers

⚖️ 8. GPAI and Copyright — The Training Data Challenge

The Copyright chapter of the GPAI Code is one of the most practically challenging sections for model providers — and one of the most consequential for the broader AI industry. EU copyright law requires GPAI providers to respect opt-out reservations from text and data mining established under Article 4(3) of Directive (EU) 2019/790. In plain language: if a content owner has published a machine-readable opt-out signal on their content — indicating that they do not consent to their content being used for AI training — a GPAI provider must respect that signal. The Code operationalises this requirement in ways that go beyond what most providers were doing before August 2025.

The December 2025 Commission consultation on machine-readable rights reservation protocols is directly implementing standardised opt-out communication mechanisms — moving toward a common technical standard for how content owners signal their training data preferences, and how providers must honour those signals. Once finalised, these standards will create concrete technical implementation requirements that providers must build into their crawling infrastructure.

The compliance challenge is acute for legacy models. Much of the training data used by existing frontier models was crawled before opt-out frameworks were standardised — before the Code existed, before the AI Act was finalised, and before content owners had practical mechanisms for signalling their preferences at scale. Legacy model providers have until August 2027 to come into compliance, but the legal exposure from pre-2025 crawling remains a live issue in multiple jurisdictions, with copyright litigation ongoing in the US, UK, and EU simultaneously. The Code does not provide retroactive immunity — it establishes a framework for managing copyright compliance going forward.

Providers must implement four practical measures to satisfy the Copyright chapter: technical systems that detect and respect machine-readable opt-out signals during crawling; a comprehensive, publicly documented copyright policy; a designated contact point for rightsholder complaints; and processes for handling complaints efficiently and fairly. The Code’s reinforced language in the final version — replacing “best efforts” with firm commitments — means these are not aspirational targets. They are compliance obligations subject to enforcement review.

An important distinction to retain: Copyright chapter compliance does not guarantee conformity with EU copyright law. The Code explicitly states this. Signatories remain legally responsible for ensuring all their operations conform to applicable Union and national copyright legislation. The Code is a compliance framework, not a safe harbour. For organisations assessing their full copyright exposure alongside GPAI obligations, the AI and copyright guide covers the broader creator-rights landscape in plain English.

🔗 9. How GPAI Obligations Relate to GDPR

The GPAI Code of Practice does not replace GDPR obligations. This is an explicit statement in the Code itself — and one that many compliance teams initially overlook when mapping their EU AI obligations. When GPAI providers process personal data during training, fine-tuning, deployment, or inference, GDPR applies in full alongside AI Act obligations. The two frameworks operate in parallel, not in sequence. Compliance with the GPAI Code does not discharge GDPR responsibilities, and GDPR compliance does not substitute for AI Act compliance.

Several specific intersections require active management. The documentation required by the Transparency chapter is complementary to — but does not substitute for — records of processing activities under GDPR Article 30. An organisation cannot use its AI Act Model Documentation Form as its GDPR processing record: they serve different legal purposes and require different information. Similarly, Transparency chapter documentation complements GDPR privacy notices under Articles 13–14, but does not replace them. When the Copyright chapter policy addresses how personal data embedded in training content is handled, this must be assessed against GDPR Article 6 legal bases — consent, legitimate interest, or other applicable grounds.

For Safety and Security chapter signatories, the cybersecurity requirements interact directly with GDPR Article 32 security of processing obligations and GDPR data minimisation principles. A systemic risk provider that implements robust cybersecurity for its model weights and training infrastructure will satisfy elements of both frameworks — but must document compliance against each separately. Assign responsibility clearly between legal, compliance, and technical teams before the frameworks become siloed.

In practice, the most effective approach is to manage GPAI compliance and GDPR compliance within a single integrated AI governance framework. ISO/IEC 42001:2023 provides exactly this kind of integrated management system — its risk management controls, documentation requirements, and performance evaluation obligations align with both the GPAI Code and GDPR’s accountability framework. Organisations with a mature ISO 42001 AIMS will find many GPAI Code requirements already addressed through their existing governance controls. For teams building governance from the ground up, the corporate AI policy guide provides the practical starting point. And for teams navigating the AI liability questions that arise when autonomous agents interact with EU users, the intersection of GPAI obligations and liability frameworks is increasingly important.

🏁 10. Conclusion — GPAI Compliance Is Now an Enforcement Reality

The GPAI Code of Practice has completed its transition from draft framework to enforced regulatory instrument. As of August 2, 2026, the European Commission holds active enforcement powers over all GPAI model providers operating in the EU market — with fines of up to €15 million or 3% of global annual turnover for non-compliance. The collaborative phase is over. The scrutiny is real. And the compliance gap between organisations that have engaged seriously with the Code and those that have not is now a liability gap.

For GPAI model providers, the signing decision should no longer be under active deliberation. The practical case for signing — a recognised compliance pathway, reduced administrative burden, good-faith engagement as a mitigating factor — outweighs the theoretical case for demonstrating compliance through alternative means, particularly in an early enforcement environment where the AI Office is establishing precedents. For downstream deployers, the GPAI compliance posture of your model vendors is now a material procurement and risk management concern. Requesting Model Documentation Forms, verifying Code signatory status, and including GPAI compliance in vendor assessments are operational requirements, not optional due diligence enhancements. The full picture of EU AI regulation — including how these GPAI obligations interact with the broader regulatory framework — is covered in the AI regulation in 2026 guide. The 2026 consensus is clear: organisations that treat GPAI compliance as a strategic governance priority — rather than a legal department problem to be solved at the last moment — are the ones that will navigate the enforcement environment without disruption.

🔗 Related Articles

• 📖 EU AI Act Explained: A Beginner-Friendly Compliance Guide + Practical Checklist
• 📖 AI Regulation in 2026: 7 New Laws Reshaping How Businesses Use AI
• 📖 ISO/IEC 42001 Explained: Building an AI Management System
• 📖 AI Governance Explained: How to Build an AI Policy Framework
• 📖 LLM Red Teaming for Beginners: The Complete 2026 Guide