# AIBOM as Compliance Evidence: AI Act, 42001

> A crosswalk from AIBOM, model card and dataset card fields to the EU AI Act, ISO/IEC 42001 Annex A and NIST AI RMF, plus what the AIBOM cannot prove.

Source: https://playciso.com/blog/aibom-compliance-evidence-eu-ai-act-iso-42001 · Published: 2026-10-29 · Publisher: PlayCISO (https://playciso.com)

---

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 EvidenceFields that hold itEU AI ActISO/IEC 42001 Annex ANIST AI RMF Inventory entry: what the system and model areCycloneDX `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 XIA.4.2 Resource documentation; A.6.2.7 AI system technical documentationGOVERN 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 developmentMAP 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 SuppliersMAP 4.1; MANAGE 3.2 Licences and suppliers of each component`licenses`, `supplier` on every component, including ancestorsArt. 25(4); what you should receive from a GPAI provider: Art. 53(1)(b), Annex XIIA.10.3 Suppliers; A.4.4 Tooling resourcesGOVERN 6.1; MANAGE 3.1 Training, fine-tuning and test datasetsCycloneDX `data` components; SPDX `dataset_DatasetPackage` (`dataset_dataCollectionProcess`, `dataset_dataPreprocessing`, `dataset_intendedUse`); Croissant RAI `rai:dataCollection`; a datasheetArt. 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 preparationMAP 2.3; MEASURE 2.1 Data provenance and integrityDataset `version`, `hashes`, `contents.url`, `governance.owners`Art. 10(2)(b) (origin of data); Art. 15(5) (data poisoning)A.7.5 Data provenanceMAP 4.1 Data quality and biasSPDX `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 systemsMEASURE 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 alongsideA.7.6 Data preparation (de-identification); A.7.4MEASURE 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, 4A.6.2.4 AI system verification and validationMEASURE 2.1; MEASURE 2.3 Performance for groups`considerations.fairnessAssessments`; per-group metricsArt. 13(3)(b)(v); Annex IV 3A.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 usersMAP 1.1; MAP 2.2; MAP 3.3 Human involvementSPDX `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 vulnerabilitiesRuntime 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 resourcesMEASURE 2.7; MAP 4.2 Tools, MCP servers, RAG indexes, APIs`services` with `endpoints`, `authenticated`, `x-trust-boundary`, `data` flowsAnnex IV 1(b), 2(c)A.4.4 Tooling resources; A.4.5 System and computing resourcesMAP 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 modelsMAP 4.2 Version history and change recordOne AIBOM per release; a diff between releasesAnnex IV 6; Annex IV 2(f); Art. 13(3)(c)A.6.2.7 (kept up to date); A.6.2.6MANAGE 4.1 (change management) Release tied to each eventModel version or AIBOM serial number written to request and deploy logsArt. 12 (logs); deployers keep logs at least six months, Art. 26(6)A.6.2.8 AI system recording of event logsMANAGE 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](/tools/aibom-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](/blog/eu-ai-act-annex-iv-technical-documentation-template) explains why). It is pursuing ISO/IEC 42001 and reports against the NIST AI RMF. What its AIBOM gives its auditor: ControlWhat the AIBOM showsStrength A.7.5 Data provenanceData components for `northwind/support-tickets-2025` and `northwind/triage-eval-v4`, each with version, SHA-256, contents URL and ownerStrong A.6.2.4 Verification and validationTwo 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 useUse case and two out-of-scope uses (medical advice, autonomous sending)Strong A.10.3 SuppliersBase model `mistralai/Mistral-7B-Instruct-v0.3` pinned by revision with its Apache-2.0 licence; runtime libraries with versions and licencesStrong for components; the supplier assessment itself lives elsewhere A.6.2.8 Event logsNot in the AIBOM. Northwind logs which model and index version produced each draftEvidence elsewhere MEASURE 2.11 Fairness and biasNo group metricsGap _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](/tools/aibom-gap-finder-lab) (Pro) practises. For the field-by-field detail of each section, see [the data section](/blog/aibom-data-section-datasets-licensing) and [evaluation, intended use and risk](/blog/aibom-evaluation-intended-use-risk). ## What the AIBOM does NOT prove Not provenWhyWhere the evidence comes from That the contents are trueAn 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 AIBOMThe file describes a release, not a host.Deploy logs, signature verification at load time AI policy, roles and competenceNot inventory facts.ISO/IEC 42001 A.2, A.3, A.4.6; NIST GOVERN 1–2; AI Act Art. 4 AI literacy measures Risk managementThe 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 assessmentsEffects 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 oversightA 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 reportsThe 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 monitoringProcess 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 deploymentA 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](/blog/who-can-attest-ai-model) explains which parties can vouch for which facts, and [using an AIBOM in incident response](/blog/aibom-incident-response-which-model-was-running) 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](/blog/aibom-questions-to-ask-ai-vendors) turns this into a request list, and the [AI Standards Crosswalk](/tools/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 - AI Act Article 10: data and data governance - AI Act Article 11: technical documentation - AI Act Annex IV: technical documentation - AI Act Article 12: record-keeping - AI Act Article 13: transparency and provision of information to deployers - AI Act Article 15: accuracy, robustness and cybersecurity - AI Act Article 25: responsibilities along the AI value chain - AI Act Article 26: obligations of deployers - AI Act Article 53: obligations for providers of general-purpose AI models - AI Act Annex XII: information for downstream providers - AI Act Article 4: AI literacy (AI Act Service Desk) - ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system (first edition, December 2023) - RiskProfs: ISO 42001 Annex A controls list (public summary) - TCSA: ISO/IEC 42001 controls (public summary) - NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023 - CycloneDX 1.7 JSON reference (component, pedigree, modelCard, service, vulnerability analysis) - SPDX 3.0.1: AIPackage - SPDX 3.0.1: DatasetPackage _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._