Seriesaibom-library

AIBOM as Compliance Evidence: AI Act, 42001

aibom eu-ai-act iso-42001 nist-ai-rmf grc compliance ai-governance audit-evidence

October 29, 2026 · PlayCISO

TL;DR

An AIBOM is good evidence for the factual parts of AI compliance: what the system and model are, what they are built from, what data trained and tested them, how they were evaluated, what they can reach and how they changed. That supports EU AI Act Articles 10, 11 (Annex IV), 13 and 15, and Article 53 for general-purpose models; ISO/IEC 42001 Annex A controls such as A.4.2, A.6.2.4, A.6.2.7, A.7.5, A.9.4 and A.10.3; and NIST AI RMF subcategories such as GOVERN 1.6, MAP 4.1, MEASURE 2.1 and MANAGE 3.2. It does not prove the contents are true, or that risk management, impact assessment, human oversight or monitoring work.

Put it into practice

Build the EU AI Act documentation from your AIBOM

The EU AI Documentation Builder (Pro) assembles Annex IV technical documentation and the GPAI Model Documentation Form from your AIBOM facts, and marks what still has to come from elsewhere.

Open the Documentation Builder

An AIBOM is evidence for the factual parts of AI compliance: what the system and model are, what they are built from, what data trained and tested them, how they were evaluated, what they can reach and how they changed. The table below maps each AIBOM, model card and dataset card field to the EU AI Act, ISO/IEC 42001 Annex A and the NIST AI RMF. The second table lists what an AIBOM cannot prove.

Who this is for: GRC and compliance leads who must show an auditor, a regulator or a customer where each AI requirement is evidenced, and CISOs who sign off on that evidence.

How to read the crosswalk

“Supports”, not “satisfies”. A field is evidence toward a requirement. None of these requirements is met by a file alone.
EU AI Act. Articles 10, 11 (with Annex IV), 13 and 15 apply to providers of high-risk AI systems; Article 53 applies to providers of general-purpose AI (GPAI) models. Text checked on the AI Act Service Desk, which shows the Act as amended by the Digital Omnibus on AI. Not sure which apply to you? Start with the EU AI Act Role & Risk Classifier.
ISO/IEC 42001:2023. Annex A has 38 reference controls in nine areas, A.2 to A.10. The standard is paywalled. We give control numbers and titles from two independent public summaries that agree; check them against your licensed copy.
NIST AI RMF 1.0 (NIST AI 100-1, January 2023). Subcategory IDs and wording are from the published PDF.
The mapping is ours. It is a reasoned reading, not an official crosswalk from any of the three bodies.

The crosswalk

Evidence	Fields that hold it	EU AI Act	ISO/IEC 42001 Annex A	NIST AI RMF
Inventory entry: what the system and model are	CycloneDX `metadata.component`, model `name`, `version`, `supplier`, `purl`, `hashes`; BOM `serialNumber` + `version`	Art. 11; Annex IV 1(a), 1(c). GPAI: Art. 53(1)(a), Annex XI	A.4.2 Resource documentation; A.6.2.7 AI system technical documentation	GOVERN 1.6
Design: task, approach, architecture	`modelCard.modelParameters` (`task`, `approach`, `architectureFamily`); SPDX `ai_typeOfModel`, `ai_domain`	Annex IV 2(b), 2(c)	A.6.2.2 AI system requirements and specification; A.6.2.3 Documentation of AI system design and development	MAP 2.1
Lineage: pre-trained and third-party models	`pedigree.ancestors`; SPDX `descendantOf`; Hugging Face `base_model`	Annex IV 2(a); Art. 15(5) (model poisoning via pre-trained components); Art. 25(4)	A.6.2.3; A.10.3 Suppliers	MAP 4.1; MANAGE 3.2
Licences and suppliers of each component	`licenses`, `supplier` on every component, including ancestors	Art. 25(4); what you should receive from a GPAI provider: Art. 53(1)(b), Annex XII	A.10.3 Suppliers; A.4.4 Tooling resources	GOVERN 6.1; MANAGE 3.1
Training, fine-tuning and test datasets	CycloneDX `data` components; SPDX `dataset_DatasetPackage` (`dataset_dataCollectionProcess`, `dataset_dataPreprocessing`, `dataset_intendedUse`); Croissant RAI `rai:dataCollection`; a datasheet	Art. 10(2)(a)–(e); Annex IV 2(d). GPAI: training-content summary, Art. 53(1)(d)	A.4.3 Data resources; A.7.2 Data for development and enhancement of AI systems; A.7.3 Acquisition of data; A.7.6 Data preparation	MAP 2.3; MEASURE 2.1
Data provenance and integrity	Dataset `version`, `hashes`, `contents.url`, `governance.owners`	Art. 10(2)(b) (origin of data); Art. 15(5) (data poisoning)	A.7.5 Data provenance	MAP 4.1
Data quality and bias	SPDX `dataset_knownBias`; Croissant RAI `rai:dataBiases`, `rai:dataLimitations`; dataset card “Bias, Risks, and Limitations”	Art. 10(2)(f)–(h), 10(3)	A.7.4 Quality of data for AI systems	MEASURE 2.11
Personal and sensitive data	`classification`, `sensitiveData`; SPDX `dataset_hasSensitivePersonalInformation`, `dataset_anonymizationMethodUsed`; Croissant RAI `rai:personalSensitiveInformation`	Art. 10 (and Art. 4a for special categories used to detect bias); GDPR sits alongside	A.7.6 Data preparation (de-identification); A.7.4	MEASURE 2.10
Evaluation results	`performanceMetrics` with `slice` and `confidenceInterval`; SPDX `ai_metric`, `testedOn`; Hugging Face `model-index`	Art. 15(1), 15(3); Art. 13(3)(b)(ii); Annex IV 2(g), 3, 4	A.6.2.4 AI system verification and validation	MEASURE 2.1; MEASURE 2.3
Performance for groups	`considerations.fairnessAssessments`; per-group metrics	Art. 13(3)(b)(v); Annex IV 3	A.5.4 Assessing impacts on individuals or groups (the assessment itself lives elsewhere)	MEASURE 2.11
Intended use, out of scope, limitations	`considerations.useCases`, `technicalLimitations`; SPDX `ai_informationAboutApplication`, `ai_limitation`; model card “Uses”	Art. 13(3)(b)(i), (iii); Annex IV 1(a), 1(h)	A.9.4 Intended use of the AI system; A.8.2 System documentation and information for users	MAP 1.1; MAP 2.2; MAP 3.3
Human involvement	SPDX `ai_autonomyType`	Art. 13(3)(d); Art. 14 (the oversight assessment, Annex IV 2(e), is not in the AIBOM)	— (pointer only)	MAP 3.5 (pointer only)
Runtime, weights format and vulnerabilities	Runtime components with `version` and `purl`; weights-format property; `vulnerabilities` with `analysis` (VEX)	Art. 15(4), 15(5); Annex IV 2(h)	A.6.2.6 AI system operation and monitoring; A.4.4 Tooling resources	MEASURE 2.7; MAP 4.2
Tools, MCP servers, RAG indexes, APIs	`services` with `endpoints`, `authenticated`, `x-trust-boundary`, `data` flows	Annex IV 1(b), 2(c)	A.4.4 Tooling resources; A.4.5 System and computing resources	MAP 4.1; MAP 4.2
Signature and build provenance	`externalReferences` types `digital-signature` and `attestation`	Annex IV 2(h); supports Art. 15(5)	A.6.2.5 AI system deployment (verify before deploy); A.10.3 for supplied models	MAP 4.2
Version history and change record	One AIBOM per release; a diff between releases	Annex IV 6; Annex IV 2(f); Art. 13(3)(c)	A.6.2.7 (kept up to date); A.6.2.6	MANAGE 4.1 (change management)
Release tied to each event	Model version or AIBOM serial number written to request and deploy logs	Art. 12 (logs); deployers keep logs at least six months, Art. 26(6)	A.6.2.8 AI system recording of event logs	MANAGE 4.3

The NIST subcategories most often cited for AI supply chains, verbatim from AI 100-1:

GOVERN 1.6: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.”
MAP 4.1: “Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third party’s intellectual property or other rights.”
MEASURE 2.1: “Test sets, metrics, and details about the tools used during TEVV are documented.”
MANAGE 3.2: “Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance.”

Where the evidence lives: AIBOM, model card or dataset card

The AIBOM carries the inventory, lineage, hashes, runtime, services, vulnerabilities and links to signatures. It is the evidence for “we know what we run”: ISO/IEC 42001 A.4.2 and A.10.3, NIST GOVERN 1.6 and MAP 4.1.
The model card carries intended use, limitations and evaluation in prose a deployer can read, which is what Article 13 asks for. Model card templates compared covers the formats; the Model Card Scorer (Pro) checks a card for missing sections.
The dataset card carries the data governance facts of Article 10(2) and ISO/IEC 42001 A.7. Dataset card templates compared covers the formats; the Dataset Card Builder (Pro) builds one.

Keep one source. Northwind generates the cards from the same data as its CycloneDX file, so the three never disagree. The same fact in each format is lined up in the AIBOM Format Field Map (Pro).

Worked example: Northwind’s evidence file

Northwind Health (fictional) runs Triage Assistant v2.3, which is not high-risk under the AI Act (the Annex IV guide explains why). It is pursuing ISO/IEC 42001 and reports against the NIST AI RMF. What its AIBOM gives its auditor:

Control	What the AIBOM shows	Strength
A.7.5 Data provenance	Data components for `northwind/support-tickets-2025` and `northwind/triage-eval-v4`, each with version, SHA-256, contents URL and owner	Strong
A.6.2.4 Verification and validation	Two metrics (fictional): answer-accuracy 0.87 on `northwind/triage-eval-v4`, toxicity rate 0.2%	Partial: no confidence interval, no robustness test, no group metrics, no signed test report
A.9.4 Intended use	Use case and two out-of-scope uses (medical advice, autonomous sending)	Strong
A.10.3 Suppliers	Base model `mistralai/Mistral-7B-Instruct-v0.3` pinned by revision with its Apache-2.0 licence; runtime libraries with versions and licences	Strong for components; the supplier assessment itself lives elsewhere
A.6.2.8 Event logs	Not in the AIBOM. Northwind logs which model and index version produced each draft	Evidence elsewhere
MEASURE 2.11 Fairness and bias	No group metrics	Gap

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 pattern is typical: inventory, data and supplier controls are well evidenced; testing and fairness are thin. Finding those gaps before the auditor does is what Spot the Gaps: AIBOM Lab (Pro) practises. For the field-by-field detail of each section, see the data section and evaluation, intended use and risk.

What the AIBOM does NOT prove

Not proven	Why	Where the evidence comes from
That the contents are true	An AIBOM is a claim by whoever wrote it. A signature proves who, not whether.	Independent testing, a third-party attestation, or an audit
That production matches the AIBOM	The file describes a release, not a host.	Deploy logs, signature verification at load time
AI policy, roles and competence	Not inventory facts.	ISO/IEC 42001 A.2, A.3, A.4.6; NIST GOVERN 1–2; AI Act Art. 4 AI literacy measures
Risk management	The AIBOM can list a risk and a mitigation, not the process that found them.	AI Act Art. 9 and Annex IV 5; ISO/IEC 42001 Clause 6; NIST MAP 5, MANAGE 1
Impact assessments	Effects on people and society are judgements, not fields.	ISO/IEC 42001 A.5; AI Act Art. 27 (fundamental rights impact assessment, certain deployers)
Effective human oversight	A yes/no flag says a human is involved, not that oversight works.	AI Act Art. 14 and Annex IV 2(e); NIST MAP 3.5
Signed, dated test reports	The AIBOM holds results, not the reports Annex IV 2(g) asks for.	Test logs and reports, dated and signed by the responsible people
Conformity and monitoring	Process documents.	AI Act Art. 17 quality management system, Art. 47 declaration of conformity (Annex IV 8), Art. 72 post-market monitoring (Annex IV 9), Art. 73 serious incidents
Copyright policy (GPAI)	A policy, not a component.	AI Act Art. 53(1)(c)
That metrics hold in deployment	A test-set score is not field performance.	NIST MEASURE 2.3 (“conditions similar to deployment”) and monitoring data

The first two rows matter most. An auditor who accepts an AIBOM at face value is accepting a self-declaration. Who can attest to an AI model, and to what explains which parties can vouch for which facts, and using an AIBOM in incident response shows a case where the AIBOM was right about the release and wrong about one host.

Evidence from vendors

For models you buy, the evidence comes from the supplier. Article 25(4) of the AI Act requires a provider of a high-risk AI system to have a written agreement with suppliers of AI tools, services and components covering the information and help it needs; free and open-source components are exempt, except general-purpose AI models. A GPAI provider must give downstream providers the Annex XII information (Article 53(1)(b)). The AIBOM questions to ask every AI vendor turns this into a request list, and the AI Standards Crosswalk maps the control objectives across ISO/IEC 42001, ISO/IEC 27001, the AI Act and the NIST AI RMF.

Next steps

Score where you are: the AIBOM Maturity Self-Assessment (Pro) rates your AI supply-chain transparency and produces a board one-pager.
Build the documentation: the EU AI Documentation Builder (Pro) assembles Annex IV and the GPAI Model Documentation Form from your AIBOM facts.
Read the full GRC path on the AIBOM Library hub.

Frequently asked questions

Can an AIBOM be used as evidence for the EU AI Act?

Yes, for the factual parts. An AIBOM supplies much of the technical documentation in Article 11 and Annex IV (system description, components, development, data, testing, cybersecurity, changes) and supports Articles 10, 13 and 15. It does not supply the risk management system, human oversight assessment, quality management system, declaration of conformity or post-market monitoring plan.

Which ISO/IEC 42001 controls does an AIBOM support?

Mainly the documentation and data controls in Annex A: A.4.2 resource documentation, A.6.2.3 documentation of AI system design and development, A.6.2.4 verification and validation, A.6.2.7 AI system technical documentation, the A.7 data controls including A.7.5 data provenance, A.9.4 intended use and A.10.3 suppliers. It supports evidence for them; it does not show the management system works.

How does an AIBOM map to the NIST AI RMF?

Most directly to GOVERN 1.6 (AI system inventory), MAP 2.1 and 2.2 (tasks, methods, knowledge limits), MAP 4.1 and 4.2 (risks and controls for components, including third-party data and software), MEASURE 2.1, 2.3, 2.7 and 2.11 (test sets and metrics, performance, security, fairness) and MANAGE 3.1 and 3.2 (third-party resources and pre-trained models).

What is the difference between a model card and an AIBOM for compliance?

A model card is prose for people: intended use, limitations, evaluation. An AIBOM is a machine-readable inventory: components, versions, hashes, lineage, data, services and vulnerabilities. Auditors usually want both: the card answers transparency requirements, the AIBOM proves the inventory and supply chain. Generate the card from the same source as the AIBOM so they agree.

Is ISO/IEC 42001 Annex A mandatory?

Annex A lists reference controls. As with ISO/IEC 27001, an organisation decides which apply and justifies its choices in a statement of applicability. The standard is paywalled; read the published text before relying on any control wording.

Does a signed AIBOM prove compliance?

No. A signature proves who issued the AIBOM and that it was not changed. It does not prove the contents are true or complete. For that you need independent testing, an attestation from a party with something to lose, or an audit.

Sources

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

Build the EU AI Act documentation from your AIBOM

The EU AI Documentation Builder (Pro) assembles Annex IV technical documentation and the GPAI Model Documentation Form from your AIBOM facts, and marks what still has to come from elsewhere.

Open the Documentation Builder