If your organization develops, fine-tunes, or places a GPAI model on the EU market, you have been subject to transparency, documentation, and copyright obligations since August 2025. If you are a SaaS company integrating a GPAI model API into a commercial product you sell to EU customers, your contracts with foundation model providers now matter for compliance purposes in ways they did not before. And if your GPAI model has been trained using more than 10^25 floating-point operations — a threshold that currently applies to roughly 5 to 15 providers worldwide — you face an additional layer of safety and security obligations that the Code of Practice's third chapter addresses in detail.
TL;DR
- GPAI obligations under Articles 51 to 56 of the EU AI Act became operative on August 2, 2025, for models placed on the market after that date. Providers of models already on the market before August 2, 2025, have until August 2, 2027, to comply.
- All GPAI providers must maintain technical documentation, provide training data summaries, establish a copyright policy, and share relevant information with the AI Office and downstream integrators on request.
- The GPAI Code of Practice, published July 10, 2025, is voluntary but carries presumption-of-compliance benefits. Providers that do not adhere must independently demonstrate compliance to the AI Office.
- Full AI Office enforcement powers — including fines up to €15 million or 3% of global annual turnover — took effect August 2, 2026.
- Downstream providers that integrate GPAI models into commercial AI systems are not GPAI providers under the AI Act unless they fine-tune or substantially modify the underlying model — but they depend on GPAI providers' documentation to satisfy their own high-risk AI obligations.
What Counts as a GPAI Model Under the EU AI Act
The AI Act defines a general-purpose AI model in Article 3(63) as an AI model trained with 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 or applications. The definition explicitly excludes AI models used for research, development, or prototyping activities before they are placed on the market.
The Commission's July 18, 2025 guidelines on GPAI model scope clarify the definitional boundaries. The guidelines confirm that the GPAI definition is functional — it is determined by what a model can do, not by its architecture or training paradigm. A model that can perform text generation, summarization, translation, coding, question answering, and other tasks across diverse domains fits the definition regardless of whether the provider markets it as a "large language model" or a "foundation model." A narrow, single-purpose AI system that performs only one specific task — classifying images of a specific product category, for example — is not a GPAI model.
Fine-tuned models occupy a nuanced position. A downstream provider that takes a GPAI model and fine-tunes it for a specific domain — a legal research assistant fine-tuned on case law, a medical documentation assistant fine-tuned on clinical notes — may become a GPAI provider in respect of their modifications, depending on whether the fine-tuning preserves the model's general-purpose character or narrows it to a single application. The Commission's guidelines indicate that fine-tuning that narrows a model to a genuinely single-purpose application can remove it from the GPAI definition for the fine-tuned version. Fine-tuning that maintains broad applicability across multiple tasks while adding domain-specific capabilities does not remove it. This determination must be made for each fine-tuned model, documented, and available for AI Office review.
Open-source GPAI models are generally exempt from the transparency and documentation obligations of Article 53 — but not from the copyright compliance obligation, and not if they present systemic risk. Providers of free and open-source GPAI models are exempted from the transparency requirements unless the model poses a systemic risk. The exemption applies specifically to the requirement to provide technical documentation to the AI Office and downstream providers, not to the copyright policy requirement that applies to all GPAI providers.
The Two-Tier Obligation Structure: All Providers vs Systemic Risk Providers
The GPAI compliance framework divides into two tiers based on the model's assessed risk level. The first two chapters of the Code of Practice — Transparency and Copyright — apply to all GPAI model providers. The third chapter, Safety and Security, only applies to providers of GPAI models with systemic risk, currently a small group of 5 to 15 companies worldwide.
Systemic risk designation applies to GPAI models that meet the threshold criteria of Article 51: models trained using more than 10^25 floating-point operations are presumed to present systemic risk. The AI Office can also designate a model as presenting systemic risk based on criteria including the number of users it can reach, its capabilities across multiple high-impact domains, and the extent to which it could be used to undermine democratic institutions or critical infrastructure. As of May 2026, models from OpenAI, Google DeepMind, Anthropic, Meta, and a small number of other providers meet the systemic risk threshold. The vast majority of organizations deploying or building on GPAI models are not systemic risk providers.
For the majority of GPAI providers — those below the systemic risk threshold — the compliance obligations are concentrated in transparency and copyright. These are not trivial obligations, but they are substantially less demanding than the safety framework that systemic risk providers must maintain.
For these providers, safety and security obligations are substantial — and aligning GPAI governance with cybersecurity compliance frameworks is not optional.
Transparency Obligations for All GPAI Providers
Article 53(1)(a) requires GPAI providers to draw up and keep up-to-date technical documentation. The Model Documentation shall be updated regularly, but older versions shall be kept for at least 10 years after the model has been withdrawn from the market. This retention requirement is operationally significant: it means that documentation is not just a current-state artifact but a versioned historical record that must be maintained through the model's full operational lifetime and a decade beyond.
The documentation must cover the model's technical properties, training methodology, the energy and compute resources consumed during training, the intended use cases and foreseeable misuse cases, known limitations and failure modes, and the performance evaluation results. The model documentation form included in the Code of Practice provides a structured template that distinguishes between information intended for the AI Office, national supervisory authorities, and downstream integrators. Documentation for downstream integrators focuses on what those integrators need to build compliant applications on top of the GPAI model — information about capabilities, limitations, and API behavior that enables a downstream provider to complete their own conformity assessment for any high-risk AI system built on the foundation model.
Information sharing with downstream providers is one of the most operationally significant aspects of the transparency obligation. Signatories must provide additional information, within 14 days of a request from a downstream provider, to enable them to have a good understanding of the capabilities of the GPAI model relevant to its integration into downstream providers' AI systems. This 14-day response obligation runs from the downstream provider's request — meaning that GPAI providers need to have the relevant documentation available and a workflow for processing these requests, not just documentation that theoretically exists somewhere in their systems.
The public training data summary is a distinct transparency deliverable. The European Commission published a template for the public summary of training content of GPAI models, requiring providers to give an overview of the data used to train their models. This summary must include the categories of data sources, the types of data included, the time periods covered, and whether personal data was included. The summary must be publicly accessible — it is the instrument through which copyright holders and affected individuals can understand what data contributed to training and exercise their rights accordingly.
Copyright Compliance Obligations
Article 53(1)(c) requires all GPAI providers to establish and implement a policy to comply with EU copyright law, in particular the Text and Data Mining (TDM) exceptions under the Digital Single Market Directive (EU) 2019/790.
The copyright policy must address three core dimensions. First, the provider must have conducted due diligence on the lawfulness of training data acquisition — verifying that training data was obtained through lawful access, and that any TDM exception relies on content that was lawfully accessible. Web crawling systems deployed for training purposes must limit access to legally available content only. Second, the provider must have a mechanism for identifying and honoring rights reservations — content marked with the rights-reserved signal under Article 4(3) of the DSM Directive indicating that the rights holder does not permit TDM. A GPAI model trained on content that bears a machine-readable rights reservation without authorization has been trained in violation of EU copyright law regardless of whether the content was publicly accessible. Third, the policy must be documented, maintained, and updated as the training process and data sources evolve.
The copyright compliance obligation does not exhaust the provider's legal responsibilities. The Code of Practice explicitly notes that adherence to the copyright chapter does not substitute for the obligation to comply with EU and national copyright law. The copyright policy demonstrates the provider's compliance governance; it does not immunize the provider from liability for specific infringements.
Safety and Security Obligations for Systemic Risk Providers
For the small group of providers whose models meet the 10^25 FLOP threshold, the Code of Practice's third chapter introduces a comprehensive safety and security governance framework that has no parallel in the obligations for standard GPAI providers.
Systemic risk providers must create a Safety and Security Framework that governs model development, evaluation, deployment, and incident response. They must conduct ongoing model evaluations — triggered by training milestones, deployment changes, and inference scale changes — to identify and assess systemic risks. They must define risk acceptance criteria: thresholds above which identified systemic risks are deemed unacceptable, triggering a decision about whether to continue development, modify the model, or implement additional safeguards. They must implement cybersecurity measures protecting both the model and the physical infrastructure it runs on.
Serious incident reporting is a specific obligation for systemic risk providers. The criteria for what constitutes a "serious incident" are not fully specified in the Code of Practice — this is one of the acknowledged gaps that the Code leaves providers to determine in their own implementation — but the obligation to report and the requirement to create a "Safety and Security Model Report" for the AI Office are concrete. The framework must be confirmed within four weeks of a provider determining that its model meets the systemic risk threshold, and at minimum two weeks before market launch.
How SaaS Companies and Downstream Integrators Are Affected
The most important threshold determination for most organizations is whether they are GPAI providers or downstream integrators — because the compliance obligations differ structurally.
A company that integrates OpenAI's GPT-4o API into a customer service product is a downstream provider, not a GPAI provider. It does not bear GPAI obligations unless its integration involves fine-tuning the model in a way that preserves its general-purpose character. Its obligations are determined by the nature of its AI system: if the customer service product makes significant decisions about individual consumers' service access, it may be a high-risk AI system under Annex III, and the EU AI Act's high-risk compliance framework applies. If it is a general chatbot providing informational responses, the Article 50 transparency disclosure requirement — informing users they are interacting with AI — applies.
What changes for downstream integrators is their contractual relationship with GPAI providers. To complete their own conformity assessment for any high-risk AI system built on a GPAI model, they need the technical documentation that the GPAI provider is obligated to produce. The technical documentation requirements for high-risk AI systems — and how they interact with the documentation obligations that GPAI providers must satisfy for downstream integrators — create a documentation dependency chain that high-risk AI deployers must address in their contracts with model providers.
Specifically, downstream integrators building high-risk AI systems on GPAI foundations need: documentation about the GPAI model's capabilities, limitations, and known failure modes to complete Annex IV technical documentation; information about the training data to assess potential bias sources and data governance compliance; details about the model's intended uses and prohibited uses to verify that their deployment context is within the supported scope; and the provider's copyright compliance policy as evidence supporting the downstream application's own regulatory documentation.
Signatories commit to enabling downstream providers to comply with their obligations pursuant to the AI Act and providing such information within a reasonable timeframe, but no later than 14 days. Organizations building high-risk applications on GPAI models should include contractual provisions that specifically invoke this 14-day documentation access right, define the scope of documentation the GPAI provider must maintain and share, and allocate responsibility between provider and integrator for compliance gaps that arise from documentation failures.
The Code of Practice: Voluntary but Consequential
The GPAI Code of Practice is voluntary in the technical sense — providers are not legally required to sign it. But the practical compliance environment makes the voluntary/mandatory distinction less significant than it appears.
A GPAI model provider that adheres to the Code of Practice will benefit from a presumption of compliance with its AI Act obligations and may face fewer information requests and enforcement actions from the AI Office, even though they are not required to comply with the Code of Practice until August 2, 2026. Providers that do not adhere must demonstrate compliance with the AI Act through alternative means and must explain to the AI Office how their chosen measures ensure compliance. Non-signatories should expect more scrutiny and more information requests from the AI Office, particularly regarding lifecycle changes and model modifications.
Non-signatories must independently demonstrate compliance, including through detailed explanations or gap analyses, and should expect more scrutiny from the AI Office — especially regarding lifecycle changes and model modifications. The practical effect of non-adoption is not that the obligations disappear — it is that the evidentiary pathway for demonstrating compliance becomes more demanding and more ad hoc. For most providers, signing the Code and implementing its structured compliance framework produces a better regulatory risk profile than maintaining equivalent compliance through a proprietary approach.
Practical Compliance Workflow
The compliance workflow for GPAI obligations follows a sequence that mirrors the documentation lifecycle the Code requires.
Inventory and classification begins with confirming whether your organization is a GPAI provider and which tier applies. This requires assessing whether any model your organization develops, fine-tunes with general-purpose preservation, or places on the EU market meets the GPAI definition; whether any such model meets the systemic risk threshold; and whether any models you develop qualify for the open-source exemption. Maintaining a centralized inventory of AI systems that distinguishes between GPAI models developed in-house, fine-tuned models with potentially modified scope, and third-party GPAI models integrated into downstream applications — is the foundational operational step that all subsequent compliance activities depend on. Learn more about how companies audit AI usage across their organization. Learn more about why you can't vibe code your way to compliance.
Documentation development for GPAI providers requires completing the Model Documentation Form structure, including technical properties, training data summary, intended use cases, known limitations, evaluation results, and energy consumption data. The documentation must be versioned — older versions retained for 10 years — and must be updated when material model changes occur. Updates that change the model's capabilities, data sources, or risk profile trigger a documentation update obligation, not just a preference.
Copyright policy establishment requires documenting the organization's approach to training data acquisition, rights reservation compliance, and TDM exception reliance. The policy must be maintained and updated as training processes and data sources change.
Downstream provider infrastructure requires a process for receiving, evaluating, and responding to documentation requests from downstream providers within 14 days. For high-volume GPAI providers, this is a customer service function as much as a compliance function — downstream integrators completing conformity assessments need timely access to current documentation.
Governance and monitoring requires treating GPAI compliance as a continuous operational function rather than a launch deliverable. Implementing AI governance frameworks that maintain current documentation, track model changes, and manage the downstream provider communication obligations that GPAI status creates — prevents the documentation drift that is the most common compliance failure in complex AI governance programs.
When GPAI Models Feed High-Risk AI Systems
A specific compliance interaction arises when a GPAI model is integrated into a high-risk AI system under Annex III. In this scenario, both the GPAI obligations and the high-risk AI system obligations apply — to different parties or potentially to the same party, depending on whether the GPAI provider and the high-risk system deployer are the same organization.
The EU AI Act's Article 25 addresses the responsibility allocation between providers and deployers in downstream integration. When a GPAI provider knows that their model will be used as a component of a high-risk AI system, they must cooperate with the high-risk system's provider to enable the conformity assessment. This cooperation obligation flows directly from the transparency chapter's documentation sharing requirements.
When a GPAI model is used to build an AI system that makes consequential decisions affecting individual rights in employment, credit, healthcare, or other Annex III domains, the Fundamental Rights Impact Assessment required of the deployer cannot be completed without adequate documentation from the GPAI model provider about the model's capabilities, limitations, and known failure modes. The FRIA and the conformity assessment are the mechanisms through which the downstream deployer demonstrates that their high-risk application is safe and rights-respecting — but both depend on the upstream GPAI provider having maintained the documentation the Code requires.
Common Mistakes
Assuming that only foundation model developers bear GPAI obligations is the most widespread misconception. Organizations that fine-tune general-purpose models for broad downstream distribution — maintaining the model's general-purpose character across the fine-tuning — become GPAI providers in respect of their modifications. The Code explicitly addresses this scenario: special provisions apply to downstream fine-tuners who become providers, and the transparency obligations attach to the modified model.
Treating documentation as a launch artifact rather than a maintained record is a structural governance failure. The 10-year retention requirement for prior model versions means that documentation is a historical record as well as a current state. Organizations that produce documentation at launch and do not update it when the model is retrained, fine-tuned, or deployed in new contexts are non-compliant even if the launch documentation was initially correct.
Assuming that open-source exemption covers copyright obligations is incorrect. The open-source exemption applies specifically to the transparency requirements of Article 53. The copyright compliance obligation — establishing and maintaining a policy that complies with EU copyright law and honors rights reservations — applies to all GPAI providers, including open-source model developers.
Neglecting to establish a downstream provider documentation request workflow before enforcement begins means that when an integrator sends a documentation request, there is no process to respond within 14 days. The 14-day response obligation is not discretionary — it flows directly from the Code's commitment on downstream information sharing.
FAQ
What is general-purpose AI under the EU AI Act?
An AI model trained with large amounts of data using self-supervision at scale, capable of performing a wide range of distinct tasks, and integrable into a variety of downstream systems. The definition is functional — based on capability breadth — not architectural.
Who is responsible for GPAI compliance?
Providers who develop, fine-tune (with general-purpose preservation), or place GPAI models on the EU market. Downstream integrators who build on GPAI APIs without fine-tuning are not GPAI providers, but they depend on GPAI provider documentation to complete their own high-risk AI system compliance obligations.
Do companies using third-party AI models have obligations?
Yes — but primarily under the high-risk AI system framework if their application falls within Annex III, not under the GPAI provider obligations. They have a right to receive documentation from the GPAI provider within 14 days of request, which they need to complete their own conformity assessments.
What documentation is required for GPAI?
Technical documentation covering model capabilities, training data summary, intended and prohibited uses, known limitations, evaluation results, and energy consumption data — maintained and versioned, with older versions retained for at least 10 years. Plus a copyright compliance policy documenting training data acquisition practices and rights reservation compliance.
Does GPAI automatically count as high-risk AI?
No. GPAI and high-risk AI are independent classification criteria. A GPAI model is not automatically high-risk under Annex III. A GPAI model integrated into an Annex III application becomes part of a high-risk system — triggering the high-risk compliance framework — but the GPAI model itself remains governed by the GPAI chapter obligations, not Annex III.
GPAI compliance is now an active enforcement landscape, not a future planning concern. The AI Office's enforcement powers took effect August 2, 2026. The Code of Practice establishes the baseline that the AI Office will use to evaluate compliance. Organizations that develop GPAI models, distribute them, or build commercial products that depend on their documentation are operating in a compliance environment where the documentation infrastructure is not optional — it is the evidentiary foundation on which the entire value chain depends.
