Seriesaibom-library

The EU GPAI Model Documentation Form Explained

aibom eu-ai-act gpai code-of-practice model-documentation ai-governance compliance

October 29, 2026 · PlayCISO

TL;DR

The Model Documentation Form is a Word form published by the European Commission on 10 July 2025 with the General-Purpose AI Code of Practice, for documenting a general-purpose AI model under Article 53 and Annexes XI and XII of the AI Act. It has eight sections, and every item is marked for the AI Office, national competent authorities or downstream providers: downstream providers receive their items proactively, authorities only on request. A company that fine-tunes someone else’s model is usually a recipient, not an author.

Put it into practice

Turn the form into AIBOM fields

The AIBOM Format Field Map (Pro) shows where each Model Documentation Form item lives in CycloneDX, SPDX and Croissant, so what a provider sends you lands in your own AIBOM.

Open the Field Map

The Model Documentation Form is a Word form the European Commission published on 10 July 2025 as part of the General-Purpose AI Code of Practice. Providers of general-purpose AI (GPAI) models use it to document what Article 53 and Annexes XI and XII of the AI Act require. Each item is marked for one or more of three recipients, and this page lists every section with those marks, then shows what a company fine-tuning an open model should expect.

Who this is for: GRC leads at GPAI providers filling the form in, and GRC leads and CISOs at companies that build on someone else’s model and want to know what they are entitled to ask for.

Where the form comes from

The Code of Practice has three chapters: Transparency, Copyright, and Safety and Security. The Transparency chapter has one commitment (documentation) and three measures:

Measure 1.1: document at least the information in the Model Documentation Form, keep it up to date, and keep previous versions for 10 years after the model is placed on the market. Using the form itself is optional.
Measure 1.2: publish contact details for requests; give the AI Office what it asks for; give downstream providers their items, and answer their further questions within 14 days save in exceptional circumstances.
Measure 1.3: control the information for quality and integrity and protect it from unintended changes.

The Commission and the AI Board have confirmed the Code is an adequate voluntary tool. Signing it is voluntary; the documentation duties are not.

What the law requires behind the form

Article 53(1)(a) and Annex XI: technical documentation of the model, including training, testing and evaluation results, for the AI Office and national competent authorities on request.
Article 53(1)(b) and Annex XII: information for providers of AI systems who integrate the model (downstream providers), enough to understand its capabilities and limitations and meet their own obligations.
Article 53(1)(c) and (d): a copyright policy and a public summary of the training content, using the AI Office’s template. These are not in the form.
Article 53(2): points (a) and (b) do not apply to models released under a free and open-source licence with public weights, architecture and usage information, unless the model has systemic risk.
Systemic-risk models owe the extra Annex XI Section 2 items (evaluation strategies and results, adversarial testing, system architecture). The Code covers those in its Safety and Security chapter, Measure 10.1, not in this form.

Timing, from the Commission’s Q&A: the GPAI obligations have applied since 2 August 2025; models placed on the market before that date must comply by 2 August 2027; and the Commission’s enforcement powers, including fines, apply from 2 August 2026.

Who sees what

The form marks each item for the AI Office (AIO), national competent authorities (NCAs) or downstream providers (DPs). Items for downstream providers are to be shared proactively. Items for the AI Office or national authorities are shared only on a request from the AI Office, which must state its legal basis and purpose and ask only for what is strictly necessary; national authorities go through the AI Office, typically to assess a high-risk system built on someone else’s model. Everything shared with authorities is covered by the confidentiality rules of Article 78.

The form, section by section

The form has eight sections. The marks below are read from the official DOCX; “Own version” means downstream providers get a differently worded item.

Section and item	AI Office	National authorities	Downstream providers	Notes
General information: provider legal name, model name and versions covered	Yes	Yes	Yes	The model name includes every publicly available version the documentation covers.
General information: model authenticity	Yes	Yes	No	A secure hash for distributed weights, or the endpoint URL for a service. Downstream providers do not get this item: verify integrity yourself.
General information: release date, Union market release date	Yes	Yes	Yes
General information: model dependencies	Yes	Yes	Yes	For a fine-tune or modification: the general-purpose models it was built from. This is the base-model lineage.
Model properties: architecture	Yes	Yes	Yes	A short description, about 20 words.
Model properties: design specifications	Yes	Yes	No	Key design choices, rationale and assumptions.
Model properties: input and output modalities, maximum sizes	Yes	Yes	Yes	Text, images, audio, video; maximum input and output sizes are marked for downstream providers.
Model properties: total model size	Exact	Range	Range	The AI Office gets the parameter count to two significant figures; others get a band such as 5B–15B.
Distribution and licences: distribution channels	Yes	Yes	Own version	Downstream providers get the channels open to them, with the level of access (weights or black-box).
Distribution and licences: licence	Link	Link	Type	Authorities get the licence itself; downstream providers get its type (open source, restricted, proprietary).
Distribution and licences: additional assets	Yes	No	Yes	Training data, code or evaluation code released with the model, and their licences.
Use: acceptable use policy, intended uses, type of AI systems it can be integrated into	Yes	Yes	Yes	Intended uses are about 200 words; the integration list up to about 300.
Use: technical means for integration, required hardware, required software	No	No	Yes	Downstream providers only.
Training process: design specifications, decision rationale	Yes	Yes	No
Data: type, provenance categories, curation methodologies	Yes	Yes	Yes	Provenance is ticked from fixed categories: web crawling, private datasets from third parties, user data, publicly available datasets, data collected through other means, non-public synthetic data, other.
Data: how obtained and selected, scope and characteristics, unsuitable-data and bias measures	Yes	Yes	No	Includes how the provider obtained rights to third-party data, and checks for illegal content and personal data.
Data: number of data points	2 sig. figs	1 sig. fig.	No	Per split (training, testing, validation), with the unit (tokens, documents, images).
Compute: training time and amount of computation	Detailed	Range / order of magnitude	No	Plus the measurement methodology, until a delegated act sets one.
Energy: training energy, benchmarked inference compute	Yes	Yes	No	Training energy in MWh; may be “N/A” if a compute provider withholds the data, with an explanation.

Two things stand out for a downstream provider. You do not receive the model-authenticity evidence, the compute and energy figures, or the detail of how training data was obtained and filtered. And there is no evaluation-results field at all for models without systemic risk. If you need benchmark numbers or a hash, ask for the model card and verify the weights yourself.

What a downstream provider should expect: the Northwind example

Northwind Health (fictional) builds Triage Assistant v2.3 by LoRA fine-tuning mistralai/Mistral-7B-Instruct-v0.3, published on Hugging Face under Apache-2.0. Three questions decide what Northwind should expect.

1. Is Northwind now a GPAI provider? Almost certainly not. The Commission’s guidelines (paragraph 60) give an indicative criterion: a modifier becomes the provider of the modified general-purpose model when the modification uses more than one third of the original model’s training compute. Where that compute is unknown, the threshold for a model without systemic risk becomes one third of 10²³ FLOP (paragraph 61). A rough estimate with the guidelines’ own formula, C ≈ 6 × parameters × training tokens (paragraph 129), and our assumptions (about 500 tokens per ticket, three epochs): 48,210 tickets is about 7 × 10⁷ tokens, and 6 × 7 × 10⁹ × 7 × 10⁷ is around 3 × 10¹⁸ FLOP. That is roughly 10,000 times below the threshold, and a LoRA run uses less compute than this full-model estimate. Northwind is a downstream provider building an AI system.

2. Will Northwind receive a Model Documentation Form for its base model? Probably not, and it should not plan on one. The base model is released under Apache-2.0 with public weights, so the Article 53(2) exemption from Annexes XI and XII applies unless it is a systemic-risk model. It was also first published in May 2024, before 2 August 2025. Mistral AI is listed as a signatory of the Code, but the exemption still applies to this open-weight model. Northwind relies on the public model card instead.

3. What if Northwind switched to a closed model behind an API? Then it should expect the downstream-provider items in the table above and may ask the provider for more, with an answer due within 14 days under a signatory’s Code commitments.

Either way, the facts belong in Northwind’s own AIBOM, so they travel with the system and survive a vendor change:

Form item	Where Northwind records it (fictional values)
Model dependencies	`mistralai/Mistral-7B-Instruct-v0.3` as the ancestor of `northwind/triage-assistant` 2.3.0 (CycloneDX `pedigree.ancestors`)
Model authenticity	The SHA-256 of the base weights Northwind downloaded and verified, in `hashes`; its own adapter is signed with Sigstore in CI
Licence	Apache-2.0 for the base model; proprietary for the adapter and the fine-tuning data
Release date and distribution	Base model first published on Hugging Face in May 2024; Northwind’s system is an internal API
Intended uses and acceptable use	Customer-support reply drafting for human approval; no medical advice, no autonomous sending
Input and output modalities	Text in, text out; record the context-window limit vLLM is configured with
Required software	vLLM 0.6.x
Data provenance and curation	Base model: whatever the supplier’s model card states (record it as the supplier’s claim). Fine-tune: `northwind/support-tickets-2025`, 48,210 de-identified tickets; eval set `triage-eval-v4`

Northwind Health and its Triage Assistant are a fictional example used across the PlayCISO AIBOM Library. All names, figures and evaluation results for it are invented for illustration.

Northwind’s system-level duties are a separate question. Its assistant is not high-risk, as our Annex IV walkthrough explains, but the same AIBOM would feed Annex IV if that changed.

How the form relates to AIBOM formats

The form is a document, not a file format, but nearly every item has a home in CycloneDX or SPDX 3.0: model dependencies in the pedigree, the licence, intended uses in the model card considerations, data provenance in dataset components. The standards comparison includes a field-by-field crosswalk, and the SBOM vs AIBOM vs MLBOM explainer covers where the model-level documentation sits in the wider BOM family. If you are a GPAI provider, generating the form from your AIBOM keeps the two consistent; the AIBOM Template & Model Card Generator is a starting point. Unsure of your role under the Act? Use the EU AI Act Role & Risk Classifier. All AIBOM guides by role are on the AIBOM Library hub.

Frequently asked questions

What is the GPAI Model Documentation Form?

A Word form published by the European Commission on 10 July 2025 as part of the Transparency chapter of the General-Purpose AI Code of Practice. It collects in one place the information that providers of general-purpose AI models must document under Article 53(1)(a) and (b) of the AI Act and Annexes XI and XII, and marks each item for the AI Office, national competent authorities or downstream providers.

Is the Model Documentation Form mandatory?

The form is not. The Code of Practice is voluntary, and signatories may choose to use the form. The duties behind it are mandatory: every provider of a general-purpose AI model must document the Annex XI information for the authorities and the Annex XII information for downstream providers, unless the open-source exemption in Article 53(2) applies. Providers that do not follow the Code must show other adequate means of compliance.

What information must GPAI providers give downstream providers?

Annex XII sets the minimum: the tasks the model is for and the systems it can be built into, the acceptable use policy, release date and distribution methods, how it interacts with other hardware or software, relevant software versions, architecture and parameter count, input and output modalities and formats with maximum sizes, the licence, the technical means needed to integrate it, and the type, provenance and curation of the training, testing and validation data.

Do open-source AI models need a Model Documentation Form?

Not for Annexes XI and XII, if the model is released under a free and open-source licence that allows access, use, modification and distribution and its weights, architecture and usage information are public, and it is not a model with systemic risk. Open-source providers must still have a copyright policy and publish a summary of the training content.

Does fine-tuning a model make me a GPAI provider?

Rarely. The Commission’s guidelines give an indicative criterion: a modifier becomes the provider of the modified general-purpose model when the modification uses more than one third of the original model’s training compute (or, if that is unknown, more than one third of 10^23 FLOP for a model without systemic risk). A LoRA fine-tune on a few tens of thousands of documents is many orders of magnitude below that. You are then a downstream provider building an AI system, with system-level obligations instead.

How quickly must a GPAI provider answer a downstream provider?

Under Measure 1.2 of the Code’s Transparency chapter, signatories commit to providing additional information that downstream providers need within a reasonable timeframe and no later than 14 days of receiving the request, save for exceptional circumstances. They also commit to publishing contact details for such requests.

Sources

Checked on 29 October 2026. PlayCISO is not affiliated with any standards body or vendor named here. This is general information, not legal advice.

Turn the form into AIBOM fields

The AIBOM Format Field Map (Pro) shows where each Model Documentation Form item lives in CycloneDX, SPDX and Croissant, so what a provider sends you lands in your own AIBOM.

Open the Field Map