A GPAI Code signature is not a supplier pass

A name on the European Commission’s GPAI Code signatory list can shorten a supplier review. It cannot finish one. The signature identifies a compliance route chosen by a model provider; it does not identify the exact model behind an SME’s API, freeze that model’s version or approve the system built around it.

That distinction became operational on 2 August 2026, when the Commission’s enforcement powers started to apply to providers of general-purpose AI models. The obligations themselves have applied since 2 August 2025 to models placed on the Union market after that date. Models already on the market before then have a separate compliance deadline of 2 August 2027.

For an ordinary customer, this does not create a duty to audit the provider on behalf of the AI Office. Nor does buying an API make the customer the provider of the underlying model. It changes the quality of question a buyer can ask: not merely “is your company on the list?”, but “which legal entity and model are we buying, which route covers them, and which evidence reaches us?”

The signature belongs to a provider

The General-Purpose AI Code of Practice is voluntary. It gives providers a structured way to demonstrate compliance with the AI Act’s model-level duties. Providers that do not sign may use other adequate means, but the Commission says they must explain those measures and can expect more detailed information requests because the AI Office has less visibility into their approach.

That makes adherence relevant. It does not turn the signatory page into a product register. The Commission’s public list names organisations. It does not list every commercial API endpoint, hosted region, model snapshot, fine-tuned derivative or service reseller through which an SME may obtain access.

Procurement therefore needs an identity chain:

1. Contracting entity: the company named on the order form and invoice.
2. Model provider: the entity that developed and placed the GPAI model on the Union market.
3. Service operator: the entity hosting the API, gateway or managed platform.
4. Model identifier: the marketed name plus a stable version, release or snapshot identifier.
5. Compliance route: the relevant Code commitments or the provider’s stated alternative means.

Those names may all point to one company. They may also describe a reseller, cloud marketplace and model developer in three different jurisdictions. A logo cannot resolve that chain.

Read the chapters, not the badge

The GPAI Code has three chapters. Transparency and Copyright address the duties applying to providers of general-purpose models. Safety and Security addresses the additional obligations for models with systemic risk.

The distinction matters because adherence is not always all-or-nothing. The Commission says that an opt-out from a chapter removes the benefit of using that chapter to facilitate demonstration of compliance. Its signatory page also records a concrete partial case: xAI signed the Safety and Security chapter only and must demonstrate compliance with the transparency and copyright obligations through alternative adequate means.

That is not evidence of failure. It is evidence that “signed” is too small a field for a supplier register.

Public signal	What it establishes	What the buyer still needs
Provider appears on the signatory list	The provider has committed to the Code route described by the Commission	Contracting entity, model identity and applicable chapters
Provider is absent from the list	No public Code adherence is shown	The alternative adequate means used to demonstrate compliance
Safety and Security chapter applies	Systemic-risk controls are in scope for the relevant provider or models	Which models are covered and which customer-facing security information is available
API is sold in the EU	The service is commercially available	Who placed the underlying model on the Union market and when

Source: European Commission GPAI Code page and signing Q&A. Last verified 2026-08-11.

The same discipline applies when a cloud marketplace says a model is “EU ready” or “AI Act aligned”. Those phrases are not fields in Article 53. Ask which provider obligation and document the statement refers to.

Article 53 creates different evidence lanes

The AI Act does not require every technical record to be published to every customer. It creates different audiences for different information.

First, the provider must draw up and maintain technical documentation of the model, including training and testing information and evaluation results. That material is for the AI Office and national competent authorities on request. A buyer should not expect the provider to hand over its entire confidential authority file.

Second, the provider must make information and documentation available to providers of AI systems that intend to integrate the model. Under Article 53(1)(b), that information should let the downstream provider understand the model’s capabilities and limitations and meet its own AI Act obligations. This is the lane most likely to matter when an SME embeds a model in a product under its own name.

Third, the provider must maintain a Union copyright policy and publish a sufficiently detailed summary of the content used to train the model. The training-content summary is public. It should be linkable from the supplier record rather than replaced with a sales assurance.

These lanes produce a realistic request:

• do not demand confidential authority documentation as a condition for an ordinary API trial;
• do request the public training-content summary and copyright-policy information;
• when integrating the model into an AI system, request the downstream information needed to understand capabilities, limits, input and output formats and integration conditions;
• record where each document lives, its date and the model version to which it applies.

A supplier response can be proportionate. The weakness to avoid is a single PDF titled “compliance” that mixes corporate policy, model marketing and system instructions without saying which legal obligation or version each section covers.

The model version is the procurement unit

An SME does not experience a provider in the abstract. It experiences a model version through a service configuration. Performance, context limits, safety filters, data retention, region availability and deprecation dates can change even while the provider’s name remains on the Commission’s list.

The supplier register should therefore use the version as its operating unit. For each use, keep:

• provider and contracting legal entities;
• model name, release or snapshot identifier and hosting route;
• date first used and, where the provider supplies it, date placed on the EU market;
• Code adherence and chapters, or the stated alternative route;
• links to the training-content summary and downstream documentation;
• approved business use, data classes and prohibited inputs;
• test results for the actual workflow;
• owner, review date and replacement path.

This is not a demand to recreate the provider’s AI Act file. It is a way to prevent three different systems from being recorded as “uses Vendor X”. When one model is deprecated or its terms change, the owner can find the affected workflows without searching invoices and source code.

Put change notice in the contract

The Code requires providers to keep relevant information up to date. A customer still needs a route by which material changes arrive. Public documentation that changes silently is not a change-control process.

For a production service, request notice of:

• model replacement, retirement or an automatic alias moving to a new version;
• a change in the model-provider or hosting entity;
• withdrawal from the Code or a change in the chapters followed;
• a material revision to the training-content summary, acceptable-use terms or integration limits;
• a serious security or capability issue that affects the contracted use;
• a change in the location or retention of customer inputs and outputs.

Not every update should trigger a legal review. Route it first by effect. A corrected documentation link may only need the register updated. A new model snapshot should trigger the acceptance tests tied to the workflow. A provider-role, data-location or compliance-route change belongs with the contract owner.

The contract should also prevent a convenient ambiguity: an unversioned alias must not move a high-impact workflow to a materially different model without notice and a rollback route. Version pinning is a technical control; notice and rollback make it an operating control.

Test one supplier record

Choose the GPAI service most widely used in the business. Open the Commission’s current signatory page, then compare it with the order form, API configuration and internal supplier register.

Can the team name the contracting entity, model provider, exact model version and relevant Code chapters? Can it open the public training-content summary? If the model is embedded in a product, does the team have the provider information needed to understand capabilities and limitations? Is there a person who will receive a change notice and decide whether to retest?

If one answer is missing, add that field before requesting another policy document. The useful result is not a larger compliance folder. It is a versioned chain from public commitment to contracted service to tested use — one that still makes sense after the supplier changes the model behind the name.