EU AI Act GPAI Code of Practice: What Foundation Model Providers Have to Sign Before August 2

The EU Commission's General-Purpose AI Code of Practice is the instrument that operationalizes the GPAI obligations of the EU AI Act on August 2, 2026. Articles 53 through 56 of the AI Act describe what general-purpose model providers owe to the Commission, downstream deployers, and the AI Office. The Code is the working document that translates those articles into measurable practices: model documentation, copyright compliance, systemic-risk monitoring, post-market reporting, and downstream-distribution transparency. Providers that sign the Code get a presumption of compliance with the underlying articles. Providers that decline must show equivalent compliance by other means, audited against the same baseline.

For enterprise deployers, the question is not whether to sign anything. The deployer obligation lives in Article 26, not 53 through 56. The question is what the signatory or non-signatory status of an upstream provider changes about the diligence the deployer owes.

What the Code organizes

The Code is structured into three chapters that track Articles 53 through 56. The first chapter covers transparency and documentation: a model card with stated training data summary, intended uses, known limitations, evaluation methods, and information sufficient for downstream providers to comply with their own AI Act obligations. The second chapter covers copyright compliance: the provider's policy for respecting opt-outs by rights holders and the documentation that demonstrates it. The third chapter covers systemic-risk models specifically and the safety and security obligations Article 55 adds for them.

Each chapter contains "measures" (specific practices) and "key performance indicators" (KPIs) that the AI Office uses to test conformance. The Code is not statute; it is a regulatory instrument with a defined legal effect under Article 56(3): adherence creates the presumption of compliance with the corresponding obligations.

Signatory consequences on August 2

A signatory provider on August 2 has a path to compliance evidence that runs through the Code chapters and the AI Office's evaluation against the KPIs. Downstream deployers can rely on the model card and transparency disclosures the Code requires as a baseline diligence step.

A non-signatory provider still has to comply with Articles 53 through 56. The path to demonstrating compliance runs through the AI Office's direct conformity assessment instead of the Code-based presumption. The provider must produce equivalent documentation, equivalent copyright-policy evidence, and equivalent systemic-risk monitoring on its own. The AI Office can request that documentation and challenge it on conformity grounds.

For deployers buying inference from a non-signatory model, the diligence package downstream is heavier. The deployer cannot cite Code presumption to its own auditor. The deployer has to obtain equivalent disclosure documentation directly from the provider or build the missing pieces from other sources.

What enterprise deployers should ask upstream providers

The Article 26 deployer obligation requires that the deployer use a high-risk system in accordance with the provider's instructions, perform a fundamental-rights impact assessment where applicable, ensure human oversight is in place, monitor the system in operation, and keep the automatically generated logs Article 19 requires. None of that goes away because the upstream provider signed the Code.

The Code does change the documents the deployer can reasonably expect upstream. A signatory provider should be able to supply a Code-aligned model card, a copyright-compliance statement, a systemic-risk summary if applicable, and a downstream-information package that covers training-data origin disclosures.

For the deployer's procurement checklist on August 2, the question to ask each upstream model provider is whether it is a Code signatory. If yes, the deployer can ask for the Code-aligned package directly. If no, the deployer must request the equivalent documentation and assess whether the provider's own conformity work is sufficient to discharge the deployer's reliance.

Systemic-risk models and Article 55

The Code's third chapter is where the bar rises sharply. Article 55 applies to GPAI models with systemic risk, defined by the AI Act as models above a 10^25 FLOPs training-compute threshold or otherwise designated by the Commission. For these models, the provider obligations expand to model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity protection for the model and its physical infrastructure.

The Code translates each of these into measurable practices. Evaluation must use defined methodologies. Adversarial testing must follow a documented red-team protocol with reported results. Serious incidents must be reported to the AI Office within defined timelines and through a defined channel.

Deployers of systemic-risk models inherit second-order obligations. The deployer's logging and monitoring must be sufficient to surface candidate serious incidents to the upstream provider. The deployer's policy enforcement at the AI request layer is the only place certain incident categories become observable: prompt-injection patterns at scale, identity-spoofing patterns, mass-egress patterns. Those incidents are not visible inside the model. They are visible at the AI traffic boundary.

Why the August 2 date matters for deployers

The deployer obligations Articles 26 and 19 impose on high-risk systems take effect August 2, 2026. The GPAI obligations Articles 53 through 56 impose on providers also take effect August 2, 2026, for models placed on the market after that date. Models placed on the market before August 2 get an extended transition window under Article 111.

For a deployer that integrated a foundation model into a high-risk system before August 2, the deployer obligations land on August 2 even though the upstream provider may have a longer runway. The deployer's compliance work cannot wait for upstream documentation if the upstream provider is on the extended timeline.

That is the part most deployer programs are still under-resourced on. The Code-signatory question is one input. The deployer's own logging, oversight, and impact-assessment work has to ship on its own schedule.

DeepInspect

This is the gap DeepInspect closes for the deployer side of the Code-and-Article-26 stack. DeepInspect sits at the AI request boundary as an external enforcement layer, evaluates every request against identity and policy, and writes a per-decision audit record that is independent of the calling application. The record carries the fields Article 19 requires (timestamp, principal identity, data classification, policy ID, outcome) and the fields a deployer needs to surface candidate Article 55 serious incidents to upstream providers (prompt classification, response classification, repeated injection signal, identity-propagation anomalies).

Deployers integrating models from either signatory or non-signatory providers can produce equivalent audit evidence without depending on upstream documentation that may not arrive by August 2. The architecture is stateless and identity-aware: each request is evaluated against the principal calling and the data scope being touched, and the decision and its evidence are committed before the response returns to the application.

If you are facing the August 2 deadline and the upstream provider's Code status is still uncertain, let's talk.