Pro tool · AIBOM Library · EU AI Act

EU AI Documentation Builder

Draft the two EU AI documents your AIBOM feeds: the Annex IV technical documentation a provider of a high-risk AI system must hold, and the Model Documentation Form a general-purpose AI model provider fills in under the Code of Practice. Answer each item with guided questions, see what is still missing per section, and download the assembled document.

Who this is for: GRC and compliance leads who must assemble the documentation, and CISOs who own the cybersecurity items and the evidence behind them. Downstream providers can use the form mode as the checklist of what a model vendor owes them.

A drafting aid, not legal advice. It does not decide whether the AI Act applies to you; for that, start with the EU AI Act Role & Risk Classifier.

Loading…

TL;DR

What this tool is

Two documents, item by item: the EU AI Act Annex IV technical documentation for a high-risk AI system (27 items across the nine points) and the GPAI Code of Practice Model Documentation Form (45 items across its eight sections).
Each item shows what the text asks, guided questions, the elements to cover, and where the answer usually comes from in your AIBOM (the CycloneDX, SPDX 3.0 and Croissant fields).
For the GPAI form, every item carries the form’s own recipient marks (AI Office, national competent authorities, downstream providers), and you can view and export the items for one recipient only.
A live completeness score per section, a list of what is still missing, and downloads: the assembled document as PDF and Markdown, a CSV of every item and its status, and a JPG summary.
"Load Northwind example" fills either document for the AIBOM Library’s fictional support assistant. It is an illustration: that assistant is probably not high-risk, and Northwind is not a GPAI provider. Runs in your browser; nothing is uploaded. Not legal advice.

Annex IV: every item the builder asks

Annex IV of Regulation (EU) 2024/1689 lists the minimum content of the technical documentation that Article 11(1) requires before a high-risk AI system reaches the market. Article 18 then requires it to be kept for 10 years. The AI Act Service Desk timeline, which reflects the Digital Omnibus on AI, gives 2 December 2027 for Annex III high-risk systems and 2 August 2028 for AI in Annex I products. Point 3 is split here into the five things it names, so none is skipped. The last column says whether an AIBOM usually supplies the answer.

1. General description

Point	What it asks	Source
1(a)	Intended purpose, provider and versionIts intended purpose, the name of the provider and the version of the system reflecting its relation to previous versions.	Your AIBOM supplies this
1(b)	Interaction with other hardware, software and AI systemsHow the AI system interacts with, or can be used to interact with, hardware or software, including other AI systems, that are not part of the system itself, where applicable.	Your AIBOM supplies this
1(c)	Software and firmware versions, update requirementsThe versions of relevant software or firmware, and any requirements related to version updates.	Your AIBOM supplies this
1(d)	Forms in which it is placed on the marketAll the forms in which the AI system is placed on the market or put into service, such as software packages embedded into hardware, downloads, or APIs.	Your AIBOM supplies this
1(e)	Hardware it is intended to run onThe description of the hardware on which the AI system is intended to run.	Your AIBOM supplies part of thisThe deployment manifest or infrastructure-as-code.
1(f)	Product photos, marking and internal layoutWhere the AI system is a component of products, photographs or illustrations showing external features, the marking and internal layout of those products.	Usually not in the AIBOMProduct documentation. Not an AIBOM concern.
1(g)	User interface provided to the deployerA basic description of the user interface provided to the deployer.	Usually not in the AIBOMProduct and UX documentation. Not an AIBOM concern.
1(h)	Instructions for use for the deployerInstructions for use for the deployer, and a basic description of the user interface provided to the deployer, where applicable (the official text repeats the user-interface item).	Your AIBOM supplies part of thisThe instructions for use (Article 13) document.

2. Elements and development

Point	What it asks	Source
2(a)	Development methods and third-party componentsThe methods and steps performed for the development of the AI system, including, where relevant, recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified by the provider.	Your AIBOM supplies this
2(b)	Design specificationsThe general logic of the system and its algorithms; key design choices with rationale and assumptions, including about the persons or groups it is intended to be used on; main classification choices; what it optimises for and the relevance of parameters; expected output and output quality; trade-offs made to meet the Chapter III, Section 2 requirements.	Your AIBOM supplies this
2(c)	System architecture and computeThe system architecture, explaining how software components build on or feed into each other and integrate into the overall processing; the computational resources used to develop, train, test and validate the system.	Your AIBOM supplies this
2(d)	Data requirements (datasheets)Where relevant, the data requirements in terms of datasheets describing the training methodologies and techniques and the training data sets used: a general description, provenance, scope and main characteristics; how the data was obtained and selected; labelling procedures; data cleaning methodologies.	Your AIBOM supplies this
2(e)	Human oversight assessmentAssessment of the human oversight measures needed under Article 14, including the technical measures needed to help deployers interpret the outputs (Article 13(3)(d)).	Usually not in the AIBOMA human oversight assessment written by the product and risk owners.
2(f)	Pre-determined changesWhere applicable, a detailed description of pre-determined changes to the system and its performance, with the technical solutions adopted to keep it compliant.	Your AIBOM supplies part of this
2(g)	Validation and testingThe validation and testing procedures, the validation and testing data and their main characteristics, metrics for accuracy, robustness and other Chapter III, Section 2 requirements, potentially discriminatory impacts, and test logs and all test reports dated and signed by the responsible persons.	Your AIBOM supplies this
2(h)	Cybersecurity measuresCybersecurity measures put in place. Article 15 sits behind this point; 15(5) names data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws.	Your AIBOM supplies this

3. Monitoring, functioning and control

Point	What it asks	Source
3	Capabilities, limitations and overall accuracyIts capabilities and limitations in performance, and the overall expected level of accuracy in relation to its intended purpose.	Your AIBOM supplies part of this
3	Accuracy for specific persons or groupsThe degrees of accuracy for specific persons or groups of persons on which the system is intended to be used.	Your AIBOM supplies part of this
3	Foreseeable unintended outcomes and risksThe foreseeable unintended outcomes and sources of risks to health and safety, fundamental rights and discrimination, in view of the intended purpose.	Your AIBOM supplies part of this
3	Human oversight measures in placeThe human oversight measures needed under Article 14, including the technical measures put in place to help deployers interpret the outputs.	Usually not in the AIBOMThe human oversight design and the instructions for use.
3	Specifications on input dataSpecifications on input data, as appropriate.	Your AIBOM supplies part of this

4. Performance metrics

Point	What it asks	Source
4	Appropriateness of the performance metricsA description of the appropriateness of the performance metrics for the specific AI system.	Your AIBOM supplies part of this

5. Risk management system

Point	What it asks	Source
5	Risk management systemA detailed description of the risk management system in accordance with Article 9.	Usually not in the AIBOMThe Article 9 risk management system and risk register. Not an AIBOM concern.

6. Lifecycle changes

Point	What it asks	Source
6	Changes through the lifecycleA description of relevant changes made by the provider to the system through its lifecycle.	Your AIBOM supplies this

7. Standards applied

Point	What it asks	Source
7	Harmonised standards or other solutionsThe harmonised standards applied in full or in part, with references published in the Official Journal; where none were applied, a detailed description of the solutions adopted and a list of other standards and technical specifications applied.	Your AIBOM supplies part of thisThe conformity assessment file.

8. Declaration of conformity

Point	What it asks	Source
8	EU declaration of conformityA copy of the EU declaration of conformity referred to in Article 47.	Usually not in the AIBOMThe signed EU declaration of conformity (Article 47). Not an AIBOM concern.

9. Post-market monitoring

Point	What it asks	Source
9	Post-market monitoring system and planA detailed description of the system in place to evaluate performance in the post-market phase under Article 72, including the post-market monitoring plan referred to in Article 72(3).	Usually not in the AIBOMThe post-market monitoring plan. The AIBOM ties each incident to an exact version.

The Model Documentation Form, with who gets each item

The European Commission published the Model Documentation Form on 10 July 2025 as part of the Transparency chapter of the General-Purpose AI Code of Practice. It collects what Article 53(1)(a) and (b) and Annexes XI and XII ask of providers of general-purpose AI models. The marks below are read from the official DOCX. Items for downstream providers are shared proactively; items for the AI Office or national competent authorities only on a request from the AI Office. Where the form gives authorities and downstream providers differently worded versions of an item, both are listed. Using the form is voluntary; the duties behind it are not, except that open-source models outside the systemic-risk tier are exempt from Annexes XI and XII (Article 53(2)).

Section	Item	AIO	NCAs	DPs
General information	Legal name of the model providerThe legal name of the model provider.	Yes	Yes	Yes
General information	Model name and versions coveredThe unique identifier for the model, including the identifier for the collection of models where applicable, and a list of the names of the publicly available versions covered by the documentation.	Yes	Yes	Yes
General information	Model authenticityEvidence that establishes the provenance and authenticity of the model, for example a secure hash if binaries are distributed, or the URL endpoint for a service, where available.	Yes	Yes	No
General information	Release dateDate when the model was first released through any distribution channel.	Yes	Yes	Yes
General information	Union market release dateDate when the model was placed on the Union market.	Yes	Yes	Yes
General information	Model dependenciesIf the model is a modification or fine-tune of one or more general-purpose AI models already on the market, the name(s), and version(s) where more than one exists. Otherwise N/A.	Yes	Yes	Yes
Model properties	Model architectureA general description of the model architecture, for example a transformer architecture.	Yes	Yes	Yes
Model properties	Design specifications of the modelA general description of the key design specifications of the model, including rationale and assumptions, to give basic insight into how it was designed.	Yes	Yes	No
Model properties	Input modalitiesText, images, audio, video, or other (specify).	Yes	Yes	Yes
Model properties	Maximum input sizeFor each selected input modality, the maximum input size, or N/A if not defined.	Yes	No	Yes
Model properties	Output modalitiesText, images, audio, video, or other (specify).	Yes	Yes	Yes
Model properties	Maximum output sizeFor each selected output modality, the maximum output size, or N/A if not defined. In the official form only the downstream-provider box is ticked for this line.	No	No	Yes
Model properties	Total model size (exact)The total number of parameters, with at least two significant figures, for example 7.3*10^10 parameters.	Yes	No	No
Model properties	Total model size (range)The range within which the total number of parameters falls.	No	Yes	Yes
Distribution and licences	Distribution channels in the Union marketThe methods of distribution through which the model has been made available in the Union market, each with a link to how it can be accessed where available and the level of access (for example weights-level or black-box).	Yes	Yes	No
Distribution and licences	Distribution channels for downstream providersThe methods of distribution through which the model can be made available to downstream providers.	No	No	Yes
Distribution and licences	Licence (link)A link to the model licence(s), or a copy on request from the AI Office under Article 91, or a statement that no model licence exists.	Yes	Yes	No
Distribution and licences	Licence type for downstream providersThe type or category of licence under which downstream providers can use the model (free and open-source, less permissive with restrictions, or proprietary). Without a licence, describe how access is provided, such as terms of service.	No	No	Yes
Distribution and licences	Additional assetsAny additional assets made available (training data, data processing code, training code, inference code, evaluation code), how each can be accessed and under which licence.	Yes	No	Yes
Use	Acceptable use policyA link to the applicable acceptable use policy (or a copy attached), or a statement that none exists.	Yes	Yes	Yes
Use	Intended usesEither the uses intended by the provider, or the uses the provider restricts or prohibits (beyond EU and international law, including Article 5), as stated in the instructions for use, terms, marketing and technical documentation.	Yes	Yes	Yes
Use	Type and nature of AI systems it can be integrated intoThe type and nature of AI systems the model can, or should not, be integrated into (for example conversational assistants, decision support, autonomous systems, cybersecurity, surveillance).	Yes	Yes	Yes
Use	Technical means for integrationA general description of the technical means (instructions for use, infrastructure, tools) needed to integrate the model into AI systems.	No	No	Yes
Use	Required hardwareAny hardware, with version, required to use the model. N/A if not applicable, for example a model offered through an API.	No	No	Yes
Use	Required softwareAny software, with version, required to use the model. N/A if not applicable.	No	No	Yes
Training process	Design specifications of the training processThe main steps or stages of training: methodologies and techniques, key design choices and assumptions, what the model is optimised for, and the relevance of different parameters.	Yes	Yes	No
Training process	Decision rationaleHow and why key design choices were made in model training.	Yes	Yes	No
Training, testing and validation data	Data type and modalitySelect all data modalities used.	Yes	Yes	Yes
Training, testing and validation data	Data provenanceSelect all source categories that apply. For the definitions, the form points to the AI Office template for the public summary of training content.	Yes	Yes	Yes
Training, testing and validation data	How data was obtained and selectedThe methods used to obtain and select training, testing and validation data, including annotation and synthetic-data generation, and, for third-party data, how the rights were obtained if not already in the public summary of training content.	Yes	Yes	No
Training, testing and validation data	Number of data points (authorities version)Size of the training, testing and validation data, each with the unit (tokens, documents, images, hours of video), to at least one significant figure, for example 3x10^13 tokens.	No	Yes	No
Training, testing and validation data	Number of data points (AI Office version)The same, to at least two significant figures, for example 1.5x10^13 tokens.	Yes	No	No
Training, testing and validation data	Scope and main characteristics of the dataDomain, geography, language and modality coverage of the training, testing and validation data, where applicable.	Yes	Yes	No
Training, testing and validation data	Data curation methodologiesThe processing that turned acquired data into training, testing and validation data: cleaning, normalisation, augmentation.	Yes	Yes	Yes
Training, testing and validation data	Measures to detect unsuitable dataMethods to detect unsuitable data sources given the intended uses, including illegal content, child sexual abuse material, non-consensual intimate imagery and personal data leading to unlawful processing.	Yes	Yes	No
Training, testing and validation data	Measures to detect identifiable biasesMethods used in data acquisition or processing to address the prevalence of identifiable biases in the training data.	Yes	Yes	No
Computational resources	Training time (range)What period is measured, and the range its duration falls in.	No	Yes	No
Computational resources	Training time (wall-clock and hardware days)What period is measured, the duration in wall-clock days and in hardware days (for example 4x10^5 Nvidia A100 days), each to at least one significant figure.	Yes	No	No
Computational resources	Training compute (order of magnitude)Measured or estimated training computation in floating point operations, to its order of magnitude, for example 10^24 FLOP.	No	Yes	No
Computational resources	Training compute (two significant figures)The same, to at least two significant figures, for example 2.4x10^25 FLOP.	Yes	No	No
Computational resources	Compute measurement methodologyUntil a delegated act under Article 53(5) sets one, the method used to measure or estimate training computation.	Yes	Yes	No
Energy consumption	Training energy (MWh)Measured or estimated training energy in megawatt-hours, to at least two significant figures. N/A if it cannot be estimated because a compute or hardware provider lacks critical information.	Yes	Yes	No
Energy consumption	Energy measurement methodologyHow training energy was measured or estimated (it may be estimated from compute). If it cannot be estimated, the type of information you lack.	Yes	Yes	No
Energy consumption	Benchmarked inference computeBenchmarked computation used for inference in floating point operations, to at least two significant figures, for example 5.1x10^17 FLOP.	Yes	Yes	No
Energy consumption	Inference benchmark methodologyThe computational task (for example generating 100,000 tokens) and the hardware (for example 64 Nvidia A100s) used to measure or estimate inference computation.	Yes	Yes	No

AIO: AI Office. NCAs: national competent authorities. DPs: downstream providers. The form has no evaluation-results item: those are owed only by providers of models with systemic risk (Annex XI, Section 2), which the Code covers in its Safety and Security chapter.

The Northwind example, and why it is only an illustration

Northwind Health runs Triage Assistant v2.3, which drafts replies to customer-support tickets for a human agent to approve. It is a LoRA fine-tune of mistralai/Mistral-7B-Instruct-v0.3 (Apache-2.0), served with vLLM, with a help-centre retrieval index and one MCP tool server.

Annex IV: the assistant is very likely not high-risk. Drafting support replies is not an Annex III purpose, and “triage” here means sorting tickets, not emergency patient triage (Annex III point 5(d)). The example fills Annex IV anyway, to show what each item looks like and where its AIBOM helps. It leaves the hardware, per-group accuracy, risk management system and declaration of conformity blank on purpose, as the Annex IV walkthrough explains.
GPAI form: Northwind is a downstream provider, not a GPAI provider. Its fine-tune uses a tiny fraction of the compute the Commission's guidelines treat as making a modifier the provider of a new model, and its open-weight base model is exempt from Annexes XI and XII. The example fills the form for the fine-tuned model as an exercise; the form explainer walks through the reasoning.

Fictional example. Northwind Health, Triage Assistant and its datasets, services, scores and URLs are invented for illustration; the base model and open-source libraries are real. The Mistral parameter count is from the public model config.

How the completeness score works

Every item counts once. A section's score is the share of its items that are done; the overall score is the share across the document.
Where the text names several elements (Annex IV point 2(g) names six), you tick the ones your answer covers. An answer with some elements unticked counts half, plus a share for each element covered.
“Not applicable” is offered only where the official text allows it (“where applicable”, “where relevant”, or the form's own N/A instructions), and it counts only with a reason.
Very short answers and “TBD” count as a quarter at most. Dates must be real dates.
In form mode, choosing a recipient scores and exports only that recipient's items, so you can check the downstream-provider pack on its own.

Where the answers come from

Most system-description, data, testing and cybersecurity items come straight out of a good AIBOM. The AIBOM Format Field Map is the source of the field hints in each item, the Dataset Card Builder produces the datasheet Annex IV point 2(d) asks for, the Model Card Scorer checks the evaluation evidence, and the AI Model Attestation Planner covers signed test reports and model authenticity. For how the same evidence maps to ISO/IEC 42001 and NIST AI RMF, read the AIBOM as compliance evidence. All guides by role are on the AIBOM Library hub.

Sources

Annex IV and Articles 11, 15 and 18 checked against the AI Act Service Desk text, and the form items and recipient marks against the official DOCX, on 29 October 2026. The AI Act text has already been amended once by the Digital Omnibus on AI; check it again before relying on a date.

PlayCISO is not affiliated with the European Commission or the AI Office. This is general information, not legal advice.

Frequently asked questions

Is there an official template for EU AI Act technical documentation?

Not a general one. Annex IV sets the minimum content, not a format. Article 11, as amended by the Digital Omnibus on AI, says the Commission will establish a simplified technical documentation form for SMEs, start-ups and small mid-caps, which notified bodies must accept. We could not find that form published as of 29 October 2026, so until it appears the nine Annex IV points are the template.

What is the difference between Annex IV and the GPAI Model Documentation Form?

Annex IV documents a whole high-risk AI system and is written by its provider for national authorities and notified bodies. The Model Documentation Form documents a general-purpose AI model under Article 53 and Annexes XI and XII, for the AI Office, national authorities and downstream providers. A company can be the author of the first and only a recipient of the second.

Which Model Documentation Form items go to downstream providers?

In the official form, downstream providers are marked for the provider and model name, release dates, model dependencies, architecture, input and output modalities with maximum sizes, the size range, the distribution channels open to them, the licence type, additional assets, the acceptable use policy, intended uses, the AI systems it can be built into, the technical means for integration, required hardware and software, data type, data provenance and data curation methods. They do not get model authenticity, compute, energy or the detail of how data was obtained.

Can I generate Annex IV documentation from an AIBOM?

Partly. A good AIBOM supplies most of the system description (point 1), the third-party models, design, architecture, data, testing and cybersecurity items in point 2, and the change history in point 6. It does not supply the user interface, the human oversight assessment, the risk management system, the declaration of conformity or the post-market monitoring plan. The builder marks each item accordingly.

Does a customer-support chatbot need Annex IV documentation?

Usually not. Annex IV applies to high-risk AI systems: safety components of Annex I products, or systems used for an Annex III purpose such as employment, credit scoring or emergency patient triage. A bot that drafts support replies for a human to approve is normally none of these. Check your own system with a classifier and, for a real decision, with counsel.

If every item is complete, is my system compliant?

No. The score measures whether each item has an answer that covers what the text names, not whether the answer is good news or legally sufficient. Compliance also depends on the requirements the documentation describes, the conformity assessment and the quality management system. This tool is a drafting aid, not legal advice.

More free security tools

The tools people use most on PlayCISO.

All tools

Prompt Scan

Catch injected instructions hiding in content your AI agent should only read.

ISO/IEC 27090 Readiness

Score your readiness against the first international standard for AI security threats.

CVE Trends

Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.

Firewall Lab

Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.

NIST CSF 2.0 Assessment

Self-assess all six Functions, from Govern to Recover, and see your weakest one.

APT Naming Rosetta Stone

Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.