IA 360
Regulatory Framework

GPAI Code: who signed it and what it actually demonstrates

The GPAI Code is a voluntary route for demonstrating AI Act compliance, not immunity. This guide connects signatories, chapters, duties and verifiable evidence.

Admin IA360 5 min read AI-generated Leer en español
GPAI Code: who signed it and what it actually demonstrates

On 10 July 2025, the Code of Practice for General-Purpose AI Models, or GPAI Code of Practice, was published. The European Commission describes it as a voluntary tool that helps providers demonstrate how they comply with AI Act obligations. It is not a new law, permission to sell any model, or a permanent certificate of good conduct.

The distinction matters to a company buying an API, integrating a model or assessing a supplier. A logo on the signatory list identifies the compliance route a provider chose; it does not by itself reveal which model is covered, which risks were assessed or whether a particular measure works. Those answers live in documents, processes and evidence that must be connected to an obligation.

The transferable skill is to read any regulatory promise through a five-question chain: what legal duty exists, who it applies to, which operational commitment develops it, what evidence demonstrates it, and which model and version it covers. If one link is missing, a signature remains useful information but cannot establish compliance.

First separate the law from the voluntary route

Article 53 of Regulation (EU) 2024/1689 requires covered GPAI model providers to maintain technical documentation, give information to those integrating the model, implement an EU copyright-compliance policy and publish a sufficiently detailed summary of training content. Article 55 adds evaluation, mitigation, incident-monitoring and cybersecurity duties for GPAI models with systemic risk.

The Code turns parts of those duties into more specific commitments and measures. Its Transparency and Copyright chapters offer a route for demonstrating Article 53 compliance; Safety and Security serves the smaller group subject to Article 55. The Commission's guidelines on the scope of GPAI obligations note that those duties became applicable on 2 August 2025. They also clarify who is a provider, when a substantial modification may create a new provider, and which partial exemptions may apply to certain models released under a free and open licence.

Joining is voluntary; complying with the law is not. Article 53 allows providers to rely on codes of practice while no harmonised standard covers the obligation. A provider that does not join must demonstrate alternative adequate means. The formal presumption of conformity is attached to European harmonised standards to the extent that they cover the obligations, not merely to a company's presence on the Code's list.

Who appears on the list, and what the list cannot say

When checked on 31 July 2026, the official list maintained by the Commission contained 23 signatories to the full Code: Accexible, AI Studio Delta, Aleph Alpha, Almawave, Amazon, Anthropic, Black Forest Labs, Bria AI, Cohere, Domyn, Dweve, Fastweb, Google, IBM, Lawise, LINAGORA, Microsoft, Mistral AI, Open Hippo, OpenAI, Pleias, ServiceNow and WRITER. The page itself warns that names may be added as signatures are confirmed. It is a dated snapshot, not a permanent industry census.

xAI occupies a different position: it signed only the Safety and Security chapter. Its signature therefore does not cover the Code route for transparency and copyright, which it must demonstrate through alternative adequate means. Simply saying that xAI “signed the Code” would erase a material distinction.

The correct unit of analysis is not always the company either. One firm may offer models released before and after the applicable date, versions with different scopes, or products that are not themselves GPAI models. The signature identifies a provider assuming commitments; the evidence needs to identify models, versions, dates and measures. For procurement, that granularity matters more than counting familiar names.

Transparency: documentation does not mean total publication

The official Transparency chapter contains three measures. Signatories prepare model documentation using the common form, update it when relevant information changes, and protect its quality, integrity and security. The documentation is meant to help downstream integrators understand capabilities and limitations and to enable authorities to supervise compliance.

An important limit prevents an exaggerated reading: not all information in the form is published on the web. The document distinguishes material intended for downstream providers from material intended for the AI Office or national authorities. The latter is supplied following a request that states its legal basis and purpose, and should be limited to what is strictly necessary for the supervisory task. Protections for intellectual property, confidential business information and trade secrets still apply.

“Transparent” therefore does not mean “entirely open”. A serious check asks whether documentation is current, whether it explains capabilities and limitations for the intended use, and whether a channel exists to request relevant additional information. A marketing PDF with no version, intended recipient or change history does not pass that test.

Copyright: policy, lawful access and rights reservations

The official Copyright chapter requires an implemented and updated policy for complying with Union copyright law. If a provider crawls the web, it commits not to circumvent effective technological measures restricting access, such as paywalls, and to exclude sites recognised at the time of crawling for persistently and repeatedly making infringing content available.

It must also use appropriate technology to identify and comply with machine-readable reservations of rights. The Code mentions following instructions expressed through the Robots Exclusion Protocol, robots.txt, and allows for widely adopted, technically workable standards. It does not turn robots.txt into a court judgment or resolve ownership disputes: it organises a compliance practice that can later be assessed.

The chapter also adds proportionate safeguards against outputs that reproduce protected training content in an infringing way, terms of use that prohibit such uses, an electronic point of contact and an accessible complaints mechanism. Useful evidence is therefore not “we have a policy”. It is the policy version, how the crawler treats access controls, how rights reservations are recorded, which output controls operate and how sufficiently precise complaints are handled.

Safety: only systemic-risk models, across the lifecycle

The official Safety and Security chapter does not apply to every GPAI model. Its commitments concern providers of models with systemic risk. At its core is a state-of-the-art Safety and Security Framework describing assessment and mitigation processes, criteria for deciding whether risk is acceptable, internal tiers or thresholds, allocated responsibilities and update procedures.

The framework cannot remain an opening statement. A signatory must apply it across the model lifecycle, identify risk scenarios, analyse probability and severity, evaluate capabilities and propensities, introduce mitigations and reassess. Serious incidents, near misses, changed risks or relevant advances in the state of the art may trigger a review. Updates carry a changelog explaining what changed and why, while the AI Office receives access to the framework and updates as specified by the chapter.

This structure separates a promise from a control. “We assess safety” is a claim; a risk inventory, testing protocols, acceptance criteria, results, mitigations, accountable owners and incident records form an auditable chain. Signing commits a provider to that method, but the Code itself says adherence does not constitute conclusive evidence of compliance.

How to check a provider without confusing signals

Assessment should begin with the model and version, not the company's general reputation. The next questions are whether the model falls within GPAI scope, whether it presents systemic risk and which chapters its provider signed. That classification determines which evidence is relevant.

For transparency, seek dated documentation, capabilities, limitations, integration conditions and an update channel. For copyright, seek the current policy, treatment of access restrictions and machine-readable reservations, output controls and complaint handling. For systemic safety, seek the framework, scenarios, evaluations, acceptance criteria, mitigations, governance and incident records. No single document answers every layer.

Not signing does not prove non-compliance either. It means the provider chose another route and must be able to explain alternative adequate means to the authority. Signing reduces uncertainty about the method; it does not remove verification. The durable question is not “is the name on the list?”, but “which obligation, for which model, is demonstrated by what evidence and within what limit?” That chain remains useful as signatories, versions and technical standards change.

This article was produced with artificial intelligence under human editorial oversight.

Share this article

This website uses cookies to improve the browsing experience. Cookie policy.

↑↓ navigate ↵ open esc close