Europe’s model rules make documentation part of the product

The July 2025 general-purpose AI code separates transparency, copyright and systemic-risk work. Downstream teams need evidence that follows a specific model version.

An AI model can sit inside many products, from a search assistant to an office drafting tool. The company using it may know the model’s name while knowing little about its training, limitations or evaluation. Europe’s general-purpose AI framework makes that information gap part of the regulatory discussion. Documentation becomes something downstream teams need to evaluate and maintain, rather than a brochure that accompanies a purchase.

The European Commission’s [10 July 2025 announcement](https://ec.europa.eu/commission/presscorner/api/files/document/print/en/ip_25_1787/IP_25_1787_EN.pdf) described a voluntary code intended to support compliance with general-purpose AI obligations. Its chapters cover transparency, copyright, and safety and security, with the latter directed at providers of models with systemic risk. The [code resources](https://digital-strategy.ec.europa.eu/en/policies/ai-code-practice) and [training-content template announcement](https://digital-strategy.ec.europa.eu/en/news/commission-presents-template-general-purpose-ai-model-providers-summarise-data-used-train-their) explain related implementation materials. This article analyses that 2025 package, not every subsequent amendment or an individual company’s compliance.

The distinction between a voluntary route and the underlying law matters. Signing a code is not a general certificate that every product using a model is safe or lawful. Different obligations can attach to the model provider, the company integrating it and the organisation deploying a particular system. A buyer needs qualified jurisdiction-specific review when determining those roles. This is educational policy analysis, not legal advice.

An original illustrative vendor embeds a foundation model in a document assistant for small employers. It asks the provider for version-specific documentation, supported languages, relevant evaluations and a change-notification process. It also records how its own retrieval system supplies material to the model. A model document may describe capabilities, but it cannot describe every failure introduced by the vendor’s database, prompt or interface.

Now imagine the provider replaces the model behind an unchanged commercial label. The assistant’s wording becomes more confident and its handling of non-English documents changes. The vendor should be able to identify when the change occurred and which evaluations were rerun. A purchasing file that contains only the original launch announcement cannot support that investigation. Model identity needs to be precise enough to connect evidence with actual use.

Copyright documentation presents another boundary. A summary of training content may improve transparency, but it does not tell the downstream vendor whether every generated answer is free of rights concerns. The vendor still needs a policy for user-provided materials, retained documents and publication. Staff should distinguish a provider’s stated approach from a legal conclusion about a particular output.

Safety evidence also has a scope. An evaluation conducted with one language, a controlled interface and restricted tools may not transfer to an assistant that can email documents or edit records. In the illustrative product, the company can first test drafting without action permissions. It can examine the consequences of incorrect statements, misleading summaries and requests that try to override the intended task before considering broader functions.

Procurement can make this practical. Ask suppliers to deliver the documentation they say exists, identify missing information and specify how updates will arrive. Test whether the company can replace the model without losing its accepted document collection or evaluation cases. An unresolved dependency should appear in the purchasing decision. A confident sales response is different from a usable file that engineers and reviewers can inspect.

The benefit of the 2025 package is a more concrete vocabulary for requesting information. Its limitation is that documentation can be complete in form while weak in substance, outdated or disconnected from deployment. Reviewers need to check whether stated capabilities and restrictions match the product’s design. A form with every box filled still requires judgment about what the evidence actually establishes.

For organisations adopting AI, the immediate editorial lesson is to treat documentation as an ongoing product dependency. Keep the relevant model version, provider materials, local evaluations and change decisions together. Read the applicable rules at the time of the decision, rather than treating a historical announcement as the current legal position. This turns regulatory information into a basis for accountable engineering without mistaking it for automatic approval.

A small team can start with a single inventory row linking the application owner to the model documentation. When a provider changes the model, that owner can identify the affected product and schedule a focused evaluation. This makes the evidence manageable without inventing a broad compliance claim.