Seriesaibom-library

EU AI Act Annex IV Documentation, Item by Item

aibom eu-ai-act annex-iv technical-documentation high-risk-ai ai-governance compliance

October 29, 2026 · PlayCISO

TL;DR

Annex IV of the EU AI Act (Regulation (EU) 2024/1689) lists the minimum content of the technical documentation that a provider of a high-risk AI system must draw up before the system reaches the market, keep up to date and hold for 10 years. It has nine points; points 1 and 2 have eight sub-items each. A good AIBOM supplies most of the system description, development, data, testing and cybersecurity items, but not the risk management system, the declaration of conformity or the post-market monitoring plan.

Put it into practice

Map Annex IV to your AIBOM fields

The AIBOM Format Field Map (Pro) shows which CycloneDX, SPDX and Croissant field feeds each Annex IV point, so you can see what your AIBOM already covers.

Open the Field Map

Annex IV of the EU AI Act lists what the technical documentation of a high-risk AI system must contain, at a minimum. It has nine points. Below, each point is explained in practice, mapped to the AIBOM fields that supply it, and filled in for a fictional support assistant, with an honest note on why that assistant would usually not be high-risk at all.

Who this is for: GRC and compliance leads who must assemble the documentation, and CISOs who own the cybersecurity point and need to know what evidence their team will be asked for.

Who must produce Annex IV documentation?

The provider of a high-risk AI system. Article 11(1) says the documentation must be drawn up before the system is placed on the market or put into service, kept up to date, and contain at least the elements of Annex IV. Article 18 then requires it to be kept for 10 years.

A system is high-risk under Article 6 in two ways: it is a safety component of, or itself, a product covered by the EU laws listed in Annex I that needs third-party conformity assessment; or it is used for one of the purposes listed in Annex III (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice and democratic processes). Even an Annex III system is not high-risk if it does not materially influence decisions, for example a narrow procedural task, unless it profiles people.

Deployers do not write Annex IV. But Article 25 makes a deployer, distributor or importer the provider if it puts its name on a high-risk system, substantially modifies one, or changes a system’s intended purpose so that it becomes high-risk.

Two points from the current text, which includes the amendments made by the Digital Omnibus on AI:

Simplified form. SMEs, start-ups and small mid-caps (SMCs) may provide the Annex IV elements in a simplified manner, using a form the Commission is to establish; notified bodies must accept it. We could not find that form published as of 29 October 2026.
Dates. The AI Act Service Desk timeline gives 2 December 2027 for Annex III high-risk systems and 2 August 2028 for AI in Annex I products.

Not sure where your system lands? Run it through the EU AI Act Role & Risk Classifier first.

Is a customer-support assistant high-risk?

Usually not, and our worked example is chosen to show why. Northwind Health (fictional) runs Triage Assistant v2.3, which drafts replies to customer-support tickets for a human agent to approve.

It is not on the Annex III list. Drafting support replies is not employment, credit, education or any other listed purpose.
“Triage” here means sorting tickets, not patients. Annex III point 5(d) covers systems that evaluate and classify emergency calls, dispatch emergency services, or act as emergency healthcare patient triage systems. Northwind’s assistant does none of these.
It does not price health insurance (Annex III point 5(c)) or decide eligibility for public benefits (point 5(a)).
Medical advice is explicitly out of scope. A system that gave medical advice would raise a different question: whether it is a medical device under EU medical-device law, which Annex I lists.

So why fill in Annex IV for it? Because the documentation discipline is the same for any AI system, buyers increasingly ask for Annex IV-style answers regardless of risk tier, and the example shows exactly where an AIBOM helps and where it does not. Change one fact, for example Northwind using the assistant to rank incoming messages by medical urgency and route them to clinicians, and the analysis moves towards point 5(d). At that point this table stops being an exercise.

Annex IV, point by point

The second column paraphrases the official text closely; read the full wording before relying on it. The Northwind column is an excerpt; the complete example AIBOM files are in the Pro AIBOM Template Library.

Point	What it asks	AIBOM fields that supply it	Northwind Health (fictional)
1(a)	Intended purpose, provider name, system version and its relation to previous versions	CycloneDX `metadata.component` name and version, `metadata.supplier`, `modelCard.considerations.useCases`; SPDX `informationAboutApplication`	Northwind Health; Triage Assistant v2.3 (model 2.3.0). Drafts replies to support tickets for a human agent to approve. Release notes state what changed from v2.2.
1(b)	How it interacts with hardware or software, including other AI systems, outside itself	CycloneDX `services` and `dependencies`; the RAG index as a `data` component	Reads and writes tickets through the `ticketing-mcp` tool server; retrieves from `northwind-helpcentre-index`, refreshed weekly.
1(c)	Versions of relevant software or firmware, and update requirements	The SBOM part: components with `version`, `purl`, `hashes`	vLLM 0.6.x; base model `mistralai/Mistral-7B-Instruct-v0.3`; LoRA adapter 2.3.0.
1(d)	Every form in which it is placed on the market or put into service (package, download, API)	CycloneDX `externalReferences`, `services[].endpoints`	An internal API used by Northwind’s own support agents. Not sold.
1(e)	Hardware it is intended to run on	No dedicated AIBOM field; record as `properties` or in the deployment manifest	The GPU server class vLLM runs on (record make, model and count).
1(f)	For a component of a product: photos or illustrations of the product, marking, internal layout	Not an AIBOM concern	Not applicable: software only.
1(g)	Basic description of the user interface provided to the deployer	Not an AIBOM concern	Screenshot and description of the agent console showing the draft and the Approve button.
1(h)	Instructions for use for the deployer (and, again, the user-interface description: the official text repeats it)	`modelCard.considerations` (`useCases`, `technicalLimitations`); the model card’s “Uses” section	Out of scope: medical advice and autonomous sending. Agents must read every draft before approving.
2(a)	Development methods, including pre-trained systems or third-party tools and how they were used, integrated or modified	CycloneDX `pedigree.ancestors`; SPDX `descendantOf`; Hugging Face `base_model` with `base_model_relation: adapter`	LoRA fine-tune of Mistral-7B-Instruct-v0.3 (Apache-2.0) on Northwind’s 2025 support tickets.
2(b)	Design specifications: general logic, key design choices and assumptions, what it optimises for, expected output quality, trade-offs	`modelCard.modelParameters` (`approach`, `task`, `architectureFamily`, `modelArchitecture`), `considerations.performanceTradeoffs`	Task: text-generation. Choice: a small open-weight model so ticket data stays in-house, accepting lower accuracy than a larger hosted model.
2(c)	System architecture (how components build on each other) and the compute used to develop, train, test and validate	CycloneDX component tree + `dependencies` graph; SPDX `AIPackage` energy fields	vLLM → model + adapter → RAG retrieval → `ticketing-mcp`. Training compute for the LoRA run (record GPU hours).
2(d)	Data requirements: datasheets on training methods and data sets, provenance, scope, how data was obtained and selected, labelling, cleaning	CycloneDX `data` components (`contents`, `classification`, `sensitiveData`, `governance`); SPDX `DatasetPackage` (`dataCollectionProcess`, `dataPreprocessing`, `anonymizationMethodUsed`, `knownBias`); Croissant RAI	`northwind/support-tickets-2025`: 48,210 de-identified tickets, Jan–Dec 2025, no direct identifiers after de-identification, proprietary. Eval set `triage-eval-v4`: 1,200 labelled tickets.
2(e)	Assessment of human oversight measures (Article 14) and of what helps deployers interpret outputs (Article 13(3)(d))	Not an AIBOM concern	A human agent approves every draft; the console shows the help-centre passages the draft relied on.
2(f)	Pre-determined changes to the system and its performance, and how compliance is maintained through them	The data component’s update cadence (SPDX `datasetUpdateMechanism`)	The weekly RAG index refresh is a planned change; the model weights do not change between releases.
2(g)	Validation and testing: procedures, test data, metrics for accuracy, robustness and discriminatory impact; dated and signed test logs and reports	CycloneDX `modelCard.quantitativeAnalysis.performanceMetrics`; SPDX `metric`, `metricDecisionThreshold`; Hugging Face `model-index`	Fictional: answer-accuracy 0.87 on `triage-eval-v4`; toxicity rate 0.2% on an internal red-team set. Gap: no robustness or discriminatory-impact test yet.
2(h)	Cybersecurity measures put in place	CycloneDX `hashes`, `signature`, `vulnerabilities`; provenance attestation linked from the AIBOM	Weights in safetensors; model signed with Sigstore in CI; in-toto/SLSA build provenance. The write scope of `ticketing-mcp` is documented as a risk.
3	Monitoring, functioning and control: capabilities and limitations, accuracy for specific persons or groups, foreseeable unintended outcomes and risks, human oversight, input data specifications	`modelCard.considerations` (`technicalLimitations`, `ethicalConsiderations`, `fairnessAssessments`); SPDX `limitation`, `safetyRiskAssessment`	Overall accuracy 0.87 (fictional). Accuracy per customer group not measured: a gap. Foreseeable misuse: an agent approving a draft that strays into medical advice.
4	Why the performance metrics are appropriate for this system	Metric definitions only	Answer accuracy measures what agents need (a correct draft); toxicity rate covers tone towards customers.
5	The risk management system (Article 9)	Not an AIBOM concern	Lives in the risk register, not the AIBOM.
6	Relevant changes made by the provider through the lifecycle	One AIBOM per release; a diff between releases	AIBOM v2.2 → v2.3 diff: new fine-tune, new eval set version.
7	Harmonised standards applied (published in the Official Journal), or the other solutions and standards used	SPDX `standardCompliance`	Check the Official Journal for references before claiming one. List any other standards actually applied.
8	A copy of the EU declaration of conformity (Article 47)	Not an AIBOM concern	Not applicable: not high-risk (see below).
9	The post-market monitoring system and plan (Article 72)	Not an AIBOM concern, but the AIBOM ties each incident to an exact version	Not required, but Northwind logs which model and index version produced each draft.

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.

What the AIBOM covers, and what it does not

Counting the 23 rows above:

The AIBOM supplies it directly: 1(a), 1(b), 1(c), 1(d), 2(a), 2(b), 2(c), 2(d), 2(g), 2(h) and 6. These are the facts a machine-readable inventory holds anyway: what the system is, what it is built from, what data trained it, how it was tested and how it is protected.
The AIBOM helps: 1(e), 1(h), 2(f), 3, 4 and 7, where it holds part of the answer (a limitation, an update cadence, a metric, a standard) but the rest is prose.
Somewhere else entirely: 1(f), 1(g), 2(e), 5, 8 and 9: the product photos, user interface, human oversight assessment, risk management system, declaration of conformity and post-market monitoring plan.

Two things a GRC lead should take from this. First, point 2(d) asks for “datasheets” in so many words; a datasheet per dataset (see the standards comparison) answers it better than a free-text paragraph. Second, point 2(g) asks for metrics on robustness and discriminatory impact and for dated, signed test reports. Most AIBOMs carry one or two accuracy numbers and nothing else, as Northwind’s does. That is the most common gap.

For the CISO: point 2(h) is short (“cybersecurity measures put in place”) but Article 15 sits behind it. Model signing, provenance attestations, the serialization format of the weights, known vulnerabilities in the serving stack and the permissions of any tool the model can call all belong here, and all of them can be recorded in the AIBOM.

How Annex IV differs from the GPAI documentation

Annex IV is about a whole system placed on the market for a high-risk purpose. Annexes XI and XII are about a general-purpose AI model, documented by its provider for the AI Office and for the companies that build on it. A company like Northwind can be a provider under the first and only a recipient under the second. The GPAI Model Documentation Form explainer covers that side.

Start from the AIBOM

If you have no AIBOM yet, build one first; most of points 1 and 2 then fall out of it. The AIBOM parameters checklist lists the fields, the AIBOM Template & Model Card Generator produces the file and the card, and the AIBOM Diff produces the change record for point 6. To map Annex IV against ISO/IEC 42001 and NIST AI RMF controls, use the AI Standards Crosswalk. The AIBOM Library hub has the full reading path for GRC.

Frequently asked questions

What must EU AI Act technical documentation contain?

For a high-risk AI system, at least the nine points of Annex IV: a general description of the system; a detailed description of its elements and development, including data, testing and cybersecurity; information on monitoring, functioning and control; why the performance metrics are appropriate; the risk management system; changes over the lifecycle; the standards applied; a copy of the EU declaration of conformity; and the post-market monitoring system and plan.

Who has to write Annex IV technical documentation?

The provider of a high-risk AI system, before placing it on the market or putting it into service (Article 11). Deployers do not, unless Article 25 turns them into a provider, for example by putting their name on the system, making a substantial modification, or changing a system’s intended purpose so that it becomes high-risk.

When does Annex IV apply?

With the high-risk rules. The AI Act Service Desk timeline, which reflects the Digital Omnibus on AI, gives 2 December 2027 for high-risk systems listed in Annex III and 2 August 2028 for AI in products covered by Annex I. Check the timeline before planning, because these dates have already moved once.

Is there an Annex IV template?

The Act sets the 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, and that notified bodies must accept it. We could not find that form published as of 29 October 2026. Until then, the nine Annex IV points are the template.

How long must technical documentation be kept?

Article 18 requires the provider to keep the technical documentation at the disposal of national competent authorities for 10 years after the high-risk AI system has been placed on the market or put into service, together with the quality management system documentation and the EU declaration of conformity.

Does an AIBOM satisfy Annex IV?

Partly. A good AIBOM supplies most of point 1 (description, versions, interactions), much of point 2 (third-party models, architecture, data, testing, cybersecurity) and the change history in point 6. It does not supply the human oversight assessment, the risk management system, the declaration of conformity or the post-market monitoring plan.

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.

Map Annex IV to your AIBOM fields

The AIBOM Format Field Map (Pro) shows which CycloneDX, SPDX and Croissant field feeds each Annex IV point, so you can see what your AIBOM already covers.

Open the Field Map