EU AI Act GPAI: What General-Purpose AI Model Providers Owe Under Article 51 and the Article 53 Code of Practice

Article 51 of the EU AI Act sets a separate obligation track for general-purpose AI models. Article 52 defines the systemic-risk threshold at a cumulative training compute of 10^25 floating-point operations. Article 53 requires the provider to draw up technical documentation, to make information available to downstream providers, and to put in place a policy to respect Union copyright law. The GPAI obligations took effect August 2, 2025, ahead of the high-risk obligations. The Code of Practice published by the AI Office sets the practical compliance roadmap for the most-deployed foundation models in 2026, and downstream deployers integrating these models into high-risk systems carry their own obligations under Article 25.

I want to walk through what counts as a general-purpose AI model, what the Article 51 obligations actually require, where the systemic-risk threshold sits, and what an enterprise deployer of a third-party foundation model owes on top of the provider's obligations.

Mandate

The GPAI regime in the EU AI Act is structured as two layers. The base obligations in Article 51 apply to all GPAI providers. The systemic-risk obligations in Article 52 apply to GPAI providers whose models cross the compute threshold.

What counts as general-purpose AI

Article 3(63) defines a general-purpose AI model as a model that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications. Foundation models like GPT-4, Claude, Gemini, Llama, Mistral, and similar systems fall within this definition. Single-task models, including most fine-tuned domain-specific models without significant generality, sit outside it.

Article 51 base obligations

Article 51 requires every GPAI provider to draw up and keep up to date the technical documentation of the model, to make information available to downstream providers integrating the model into their AI systems, to put in place a policy to respect Union copyright law, and to publish a sufficiently detailed summary of the training data. The base obligations apply regardless of compute scale. A provider releasing a foundation model into the Union market without these artifacts faces an Article 99 Tier 3 finding.

Article 52 systemic-risk threshold

Article 52 sets the systemic-risk threshold at a cumulative training compute of 10^25 floating-point operations. The threshold captures the largest current foundation models. The AI Office can designate a model as systemic-risk even below the threshold based on the model's capabilities, the number of registered business users, the reach across the Union, or the cumulative number of end users. Designation triggers the systemic-risk obligations in Article 55, including model evaluations against current best-practice protocols, adversarial testing, serious incident reporting, and cybersecurity protection.

Code of Practice and the AI Office

The AI Office, established under Article 64, publishes the Code of Practice that translates Article 51 and 55 obligations into concrete compliance measures. The 2025-2026 Code covers transparency requirements, copyright compliance approaches, systemic-risk mitigation expectations, and the reporting cadence to the AI Office. Providers signing on to the Code obtain a presumption of compliance with the underlying articles. Providers not signing on must demonstrate compliance through alternative means and bear the audit burden.

Compliance gap

The GPAI obligations create a gap that runs in two directions. The model provider's documentation may be sparse on the data and policy details a downstream deployer needs. The downstream deployer integrating the model into a high-risk system carries Article 25 obligations that depend on this documentation existing.

The downstream deployer's Article 25 obligation

Article 25 recharacterizes a downstream provider as the provider of a high-risk system when the downstream entity puts its name on the system, makes substantial modifications, or modifies the intended purpose in a way that brings the system into high-risk classification. The downstream provider then owes the full Article 16 through 27 obligations on top of the integration. The GPAI provider's documentation must support the downstream conformity assessment. Where the documentation is incomplete, the downstream provider's file is incomplete by reference.

The systemic-risk model evaluation requirement

Article 55 requires systemic-risk GPAI providers to perform model evaluations against current best-practice protocols, including adversarial testing. The evaluations must cover capabilities, limitations, and risks at the systemic level. The evaluation results feed into the documentation Article 53 requires providers to make available. A downstream high-risk deployer integrating the model relies on the provider's evaluation to scope the risk management process under Article 9.

Copyright compliance is operationally vague

The Article 51 obligation to put in place a policy respecting Union copyright law and the Article 53(1)(d) obligation to publish a sufficiently detailed summary of training data are still being operationalized through the Code of Practice. Providers have taken different positions on what level of detail satisfies the summary obligation. Downstream deployers cannot fully verify the training data composition and operate with residual risk.

Open-source GPAI exemptions are narrow

Article 53(2) exempts certain open-source GPAI from a subset of the obligations, where the model parameters, weights, and architecture are publicly available and where the provider does not monetize the model. The exemption does not extend to systemic-risk models even when open-source, and the conditions for monetization-free release are narrow. A downstream deployer relying on an open-source model still inherits the Article 25 substantial-modification analysis.

Mandate vs Compliance

The text of Article 51 is high-level. The Code of Practice is the practical bridge. The infrastructure that survives a downstream high-risk audit, while a separate obligation, depends on the GPAI documentation being current and complete.

Disclosure test

The AI Office or a national competent authority asks the GPAI provider for the technical documentation under Annex XI, the training-data summary under Annex VIII Section B, and (for systemic-risk providers) the model evaluation results. A compliant provider produces the artifacts within the timelines the Code sets. The downstream deployer producing the high-risk conformity file uses the provider's documentation as the upstream input. A gap at the provider level cascades into the deployer's file.

Vendor liability for downstream high-risk deployment

The GPAI provider's Article 51 obligation ends at the model boundary. The downstream provider's Article 25 obligation begins where the model is integrated into the high-risk system. Where the integration introduces material changes (custom system prompts, fine-tuning, retrieval-augmented generation against proprietary data), the downstream provider takes on full provider obligations for the resulting system. The recharacterization under Article 25 is not optional.

Compliance gap

The compliance gap at the integration boundary is the gap between the provider's documentation and the operational record-keeping the downstream high-risk system must produce. The provider documents the model. The downstream system must document the operational decisions it makes using the model. The operational record-keeping is the Article 12 mandate the downstream system owes, regardless of how thorough the GPAI provider's documentation is.

DeepInspect

This is the architecture the downstream high-risk deployer needs at the operational boundary. DeepInspect sits at the AI request boundary as an external enforcement layer that operates as a stateless proxy between authenticated users or agents and any GPAI endpoint. Every HTTP request to GPT, Claude, Gemini, Llama, Mistral, or any other foundation model passes through the proxy. The proxy evaluates per-route, per-role policies using identity context the calling application supplies. The per-decision audit record is committed by the proxy, independent of both the foundation model provider and the downstream application.

The record contains a verified identity for the requester, the role and authorization context, the data classification applied to the prompt, the GPAI model and version actually called, the policy version that governed the decision, the decision outcome, and a cryptographic signature that prevents post-hoc modification. The proxy enforces per-route policies on which GPAI vendors a given role can call, which categories of data can flow to which model, and which policy bypasses require independent approval. The downstream Article 12 record-keeping is satisfied at the operational boundary regardless of which foundation model the system relies on.

If you are facing the August deadline, let's talk.

Beyond the EU AI Act

The same operational architecture supports adjacent obligations on GPAI integration. The NIST AI Risk Management Framework puts the deploying enterprise inside the Map and Measure functions even when the foundation model comes from a third party. The Fannie Mae and Freddie Mac AI governance frameworks treat the model as a vendor component but the decisions about borrower files as the lender's responsibility, which the operational record-keeping captures. Each regime accepts the same architectural record at the operational boundary.