Do all deployers have to use a provider that signed the Code?

No. The Code is a voluntary commitment by providers. Deployers can use a model from a provider that has not signed, but the deployer takes on a heavier evidence burden because the deployer cannot reference the provider's documentation form to characterise the model. In practice, most enterprise procurement teams will prefer providers that signed because the procurement evidence stack is shorter.

Is the Code the only path to Article 53 compliance for providers?

No. Article 53 sets the obligation. The Code is one accepted way to demonstrate compliance. A provider that does not sign the Code can demonstrate compliance through other means, but the burden of proof shifts to the provider. The AI Office published the Code precisely because most providers preferred a documented route to compliance rather than ad hoc justification.

Does the Code apply to open-source GPAI models?

Article 53(2) carves out an exception for providers that release the model under a free and open-source licence and publish the weights, model card, and training summary, unless the model crosses the systemic risk threshold. The carve-out is narrow. A model released under an open licence that has 10^25 FLOPs of training compute still triggers the systemic-risk obligations. Several large open-weight models sit in this category.

How does the Code interact with the deployer's HIPAA, GDPR, or sector-specific obligations?

The Code addresses obligations under the EU AI Act. It does not address HIPAA, GDPR, the EBA guidelines on AI in financial services, the FDA guidance on AI/ML medical devices, or any of the sector-specific regimes. A deployer in a regulated sector has to satisfy the AI Act and the sector-specific regime separately. The architectural primitives overlap: identity-aware enforcement, per-decision audit record, prompt-level classification. The documentation has to map to each regime's vocabulary.

What happens if the Code is updated after we sign a vendor contract?

The Code is a living document. The AI Office can update it through the same multi-stakeholder process that produced the first version. Procurement contracts with GPAI providers should reference the version of the Code in effect at the time of signing and obligate the provider to maintain compliance with subsequent versions or notify the deployer of any divergence. The deployer's runtime architecture should not be coupled to a specific Code version, because the deployer's obligations under the Act persist regardless.

EU AI Act Codes of Practice: What the GPAI Provisions Expect and Where Deployers Sit

The General-Purpose AI Model Code of Practice was published by the EU AI Office on July 10, 2025 as the operational mechanism for the GPAI provisions in Article 53 and Article 55 of the EU AI Act. The Code took practical effect on August 2, 2025, when the GPAI obligations came into force. The Code is voluntary for providers, but signing it is the path of least resistance to demonstrating compliance with the underlying legal obligations. Most major providers have signed. The Code covers transparency, copyright, and, for GPAI with systemic risk, safety and security.

Deployers that build enterprise systems on top of GPAI models inherit a set of downstream obligations the Code does not cover. I want to walk through what the Code commits the provider to, where the deployer obligation begins, and the architectural pattern that satisfies the deployer side.

What the Code commits providers to

The Code has three working chapters. Each one corresponds to a category of obligation in the Act.

Transparency

Providers commit to publishing a model documentation form covering the training process, data sources, evaluation methodology, and operational parameters of the GPAI model. The form is the practical realisation of the Annex XII obligations. Downstream deployers can request the documentation under defined conditions and use it to satisfy their own Annex IV obligations under Articles 11 and 13.

Copyright

Providers commit to a copyright policy that includes a mechanism for upstream rightsholders to opt out of training, a process for the provider to honor the opt-out, and a transparent summary of the training data sources at a level of detail that does not compromise trade secrets. The chapter operationalises Article 53(1)(c) and 53(1)(d).

Safety and security for GPAI with systemic risk

For models that cross the systemic risk threshold (defined in Article 51 and currently anchored to 10^25 FLOPs of training compute), the safety and security chapter sets the additional obligations. Providers commit to model evaluation against systemic risks, adversarial testing, incident reporting to the AI Office, and a Safety and Security Framework covering the model lifecycle.

What the Code does not cover

The Code is a provider-facing instrument. Deployers do not sign it. The deployer's obligations under the AI Act sit outside the Code's text.

Article 12 logging

Deployers carry the Article 12 logging obligation for high-risk systems built on GPAI. The provider's Code commitments do not produce the per-decision audit record the deployer needs.

Article 26 deployer obligations

Article 26 places specific obligations on deployers of high-risk systems: human oversight, input data appropriate to the intended purpose, monitoring of operation, retention of logs, information to affected persons. None of these are discharged by the provider's Code signature.

Article 50 transparency

Article 50 obliges deployers of AI systems that interact with natural persons, generate synthetic content, or perform emotion recognition or biometric categorisation to inform users. The obligation runs to the deployer regardless of what the provider committed to in the Code.

The deployer's runtime architecture

The Code says nothing about the deployer's runtime. The deployer's identity context, policy enforcement, data classification, and audit log are infrastructure the deployer has to build. The provider's Code commitments are evidence the deployer can reference, not architecture the deployer can inherit.

How the Code interacts with deployer compliance programs

The practical effect of the Code is to shift the procurement conversation. A deployer evaluating GPAI providers in 2026 can ask whether the provider has signed each chapter of the Code, and what the provider's documentation under the transparency chapter says about the model's training, evaluation, and intended use.

Procurement evidence

A provider that has signed the Code and published the model documentation form gives the deployer a stack of evidence the deployer can attach to its Annex IV technical documentation. The evidence reduces the deployer's effort to characterise the underlying model. It does not discharge the deployer's obligation to characterise the deployer's specific system.

Risk allocation

The Code's safety and security chapter shifts risk allocation for systemic-risk GPAI. A deployer using a model whose provider committed to adversarial testing and incident reporting carries less residual risk on the model layer than a deployer using a model whose provider has not signed. The procurement decision encodes the risk allocation.

What the Code does not produce

The Code does not produce runtime enforcement, runtime policy, or runtime evidence. A provider can sign all three chapters and the deployer is still responsible for what the deployment does in production on the deployer's data, by the deployer's users, against the deployer's policies.

What the deployer architecture has to provide

The deployer side of the Code's accountability chain is where most enterprise programs are exposed. Four properties matter.

Identity context attached at the request layer

The deployer has to attach identity context to every model request before the request leaves the deployer's boundary. Without identity context, the per-decision evidence cannot identify the natural person behind the request, which means Article 19's logging requirement collapses.

Prompt-level classification

The deployer has to classify the prompt content before the request reaches the model. Classification covers PII, regulated data classes (PHI, financial NPI, biometric data), and the policy-relevant attributes the deployer cares about.

Per-route, per-role policy

Policies attach to model API routes and to user or agent roles. The deployer's policy decision point applies the policy at the request boundary, in front of the GPAI endpoint, before the prompt content reaches the provider.

Tamper-evident audit record

Every decision produces an audit record committed before the response returns to the application. The record is the evidence the deployer presents under Article 12 inquiry, the input the deployer feeds into Article 9 risk management, and the substrate for the deployer's own model risk monitoring.

DeepInspect

This is the problem DeepInspect was built to solve. DeepInspect is the deployer-side enforcement layer for AI traffic to and from any GPAI provider. The proxy attaches identity context, classifies prompt content, enforces per-route and per-role policy, and produces a per-decision audit record that is independent of the application.

The architecture does not depend on which provider's Code signature applies. A request to a signed-Code provider runs through the same proxy as a request to a provider that has not signed. The deployer's compliance posture stays consistent across model providers, which matters as soon as the deployment uses more than one.

For Articles 26, 50, and 19, the proxy's audit record is the deployer's evidence. For Article 13's instructions for use, the proxy's policy configuration is the documented operational boundary. The runtime architecture and the Annex IV technical documentation reference the same primitives.

If you are deploying GPAI in a regulated environment and your AI Act compliance posture depends on the provider's Code signature, your deployer-side obligations are exposed. Book a demo today.