What is an AI Bill of Materials (AIBOM)?

An AIBOM is a structured inventory of the AI models, training datasets, third-party libraries, and runtime dependencies inside an AI system. It is the AI-specific extension of the SBOM (Software Bill of Materials) standard now widely used in software procurement. OWASP launched its AIBOM project in 2025; SPDX 3.0 and CycloneDX both added AI/ML support. EU AI Act auditors will increasingly use AIBOM-style evidence to evaluate compliance with Annex IV technical documentation requirements for high-risk systems.

How is AIBOM different from SBOM?

SBOM lists software components, libraries, and dependencies; AIBOM lists everything SBOM does plus the AI-specific layer: foundation models with versions, training data provenance, fine-tuning data, model card information, inference dependencies (vector DBs, embedding models), runtime telemetry, and update/version policy. The difference matters because AI risk is materially different from software risk: bias in training data and model drift have no SBOM equivalent.

Is AIBOM legally required?

Not yet as 'AIBOM' specifically, but the underlying requirements are. EU AI Act Annex IV (technical documentation for high-risk systems) requires much of what an AIBOM documents: training datasets, model architecture, intended use, known limitations. DSGVO DPIA Section 5 (in the EDPB 2026 template) requires training-data lineage. NIS2 requires supply-chain documentation. AIBOM is the convergence format that satisfies all three. Producing one is operationally efficient even before it becomes formally mandatory.

What format should AIBOM be in?

Machine-readable, preferably SPDX 3.0 (with AI profile) or CycloneDX 1.6+ (with ML-BOM extension). PDF is acceptable but not sufficient on its own; auditors increasingly expect machine-readable formats they can parse and cross-reference. The two formats are interoperable; converters exist. Pick whichever your vendor already uses for SBOM and extend it with AI fields rather than maintaining two separate standards.

How often should AIBOM be updated?

Within 30 days of any material change. Material changes include: foundation model swap, new fine-tuning data, new inference dependency (new vector DB, new RAG corpus), change to update/version policy. A vendor whose AIBOM is from 2 years ago but who swapped models last quarter has a stale AIBOM that does not match reality. Make 30-day update a contractual obligation in the AVV.

What if my vendor refuses to provide an AIBOM?

Three options: (1) Accept and document the refusal as a known compliance gap, with reasoning, and add it to your risk register. (2) Negotiate a partial AIBOM that covers what the vendor will disclose. (3) Switch vendors to one that provides full AIBOM. Option 1 is acceptable for low-risk deployments with strong business reasons; Option 3 is the only safe path for Annex III high-risk HR-AI. A vendor who refuses any AIBOM disclosure is unlikely to clear EU AI Act compliance audits in 2026.

AI Bill of Materials (AIBOM) for HR-Tech: 2026 Guide

An AI Bill of Materials (AIBOM) is a structured inventory of the AI models, training datasets, third-party libraries, and runtime dependencies inside an AI system. It is the AI-specific evolution of the SBOM (Software Bill of Materials) standard that has become table stakes in enterprise software procurement, particularly after Executive Order 14028 in the US and CRA in the EU. OWASP launched its AIBOM project in 2025; the Linux Foundation's SPDX 3.0 specification now includes AI/ML profiles; CycloneDX has formal ML-BOM support. The standard is converging and EU AI Act auditors will increasingly use AIBOM-style evidence to evaluate compliance with Annex IV technical documentation requirements for high-risk systems.

For HR-tech buyers, demanding an AIBOM from a vendor is becoming the fastest way to learn whether the vendor has done the engineering work behind their compliance claims. A vendor with a real AIBOM can produce it in days; a vendor without one needs months of internal scrambling, which itself answers the procurement question. The AIBOM also feeds three other compliance artifacts: the DPIA Section 5 (training-data lineage), the AI Act Annex IV technical documentation, and the NIS2 supply-chain note.

This guide explains what an AIBOM contains, how it differs from SBOM, the 7 fields auditors specifically look for, what good versus bad AIBOM looks like, and how to ask your AI vendor for one without triggering months of legal review on their side. Written for the procurement lead, DPO, or AI governance owner who has to make AIBOM part of standard vendor due diligence in 2026.

For the broader compliance framework, see our AI governance and compliance EU pillar. For DPIA Section 5 training-data lineage, which depends on AIBOM data, see the DPIA template guide.

2025OWASP AIBOM project launched; SPDX 3.0 + CycloneDX added AI/ML support

7fields auditors specifically look for in an AIBOM

3downstream compliance artifacts that depend on AIBOM data (DPIA Section 5, Annex IV, NIS2)

daystime a compliant vendor needs to produce AIBOM; months for non-compliant

What Is an AIBOM and How Is It Different from SBOM?

An SBOM lists the software components, libraries, and dependencies inside a piece of software. It is now standard procurement practice: when you buy enterprise software, you expect an SBOM (typically in SPDX or CycloneDX format). It enables vulnerability scanning, license compliance, and supply-chain transparency.

An AIBOM is the AI-specific extension. It lists everything an SBOM lists, plus the AI-specific layer: the AI models used (foundation model name, version, provider), the training datasets (provenance, licensing, synthetic data flags), the fine-tuning data (if any), the model-card information (capabilities, limitations, known biases), the inference dependencies (vector databases, embedding models, RAG corpora), and the runtime telemetry (model version pinning, fallback chain, observability hooks).

The difference matters because AI risk is materially different from software risk. A software vulnerability is bounded: a CVE in library X means library X needs patching. An AI model risk is unbounded: bias in training data, drift in production, dependency on an opaque foundation model whose training process you cannot inspect. SBOM tells you what code runs; AIBOM tells you what intelligence runs and where it came from. Auditors in 2026 want both.

The 7 Fields Auditors Look For

AIBOM field	What it documents	Why auditors care
1. AI models used	Foundation model name, version, provider, deployment region	Maps to AI Act provider obligations and DSGVO third-country transfer
2. Training data provenance	Where training data came from, licensing, scraping vs licensed vs synthetic	Required for DPIA Section 5; bias-source analysis; copyright risk
3. Fine-tuning data (if any)	Customer-supplied data used to fine-tune the model; data sovereignty implications	DSGVO Art. 32 security; customer data segregation; AVV transparency
4. Model card	Capabilities, intended use, known limitations, documented biases	Annex IV technical documentation requirement
5. Inference dependencies	Vector DB, embedding models, RAG corpora, external APIs called at inference	Supply-chain depth; NIS2 reporting; cross-tenant data flow risk
6. Runtime telemetry	Model version pinning, fallback chain, observability hooks, audit log destinations	Post-market monitoring (Annex IV); incident-reporting capability
7. Update and version policy	How model updates are deployed, customer notification policy, rollback support	Change management; co-determination on material changes; reproducibility

Run an AI Governance Assessment

Free 8-minute assessment includes vendor AIBOM readiness checks. Find which vendors can produce a real AIBOM in days vs the ones who would need months. Structured AI report, no signup.

Try It Free

Good AIBOM vs Bad AIBOM

A good AIBOM looks like

All 7 fields populated with specific facts (not proprietary or varies)
Named foundation models with versions (gpt-4-turbo-2025-01, claude-3.5-sonnet-2025-02, etc.)
Training data described by source and licensing, not just publicly available data
Model card linked or attached, with limitations and biases named
Machine-readable format (SPDX 3.0 or CycloneDX ML-BOM), not just PDF
Updated within 30 days of any material change

A bad AIBOM looks like

Fields filled with confidential, proprietary, or N/A
Generic foundation model reference ('we use OpenAI') with no version
Training data: various sources including web crawl
No model card; biases undisclosed
Provided as a marketing PDF with no machine-readable equivalent
Last updated 2 years ago, but vendor swapped models last quarter

How to Ask Your AI Vendor for an AIBOM

The wrong way to ask is via legal: Our legal team requires you provide a comprehensive AI Bill of Materials including all training data, model weights, and proprietary algorithmic information. This triggers months of vendor legal review, escalates to executive level, and produces a watered-down PDF.

The right way to ask is via procurement, framed as standard due diligence: As part of our 2026 AI vendor due diligence, we are collecting AIBOM information aligned with OWASP AIBOM v1.0 / SPDX 3.0 / CycloneDX ML-BOM (vendors preference). What can you provide on the 7 standard fields: AI models, training data provenance, fine-tuning data, model card, inference dependencies, runtime telemetry, and update/version policy?'

This framing has three properties. First, it references published standards, so the vendor knows the request is not bespoke and not legally fishing. Second, it lists the 7 fields explicitly, so the vendor cannot dodge with what do you mean by AIBOM? Third, it lets the vendor choose the format, which keeps it implementable. Most compliant vendors respond within a week with a structured document. Non-compliant vendors respond with we will get back to you, which is also useful information.

The 1-week test. A vendor with a real AIBOM can populate the 7 fields in 1 week. A vendor without one needs 1-3 months. The response time itself is procurement signal. If a vendor cannot answer in a week, treat the rest of their AI Act compliance claims with proportional skepticism.

Run an AI Readiness Check

8-minute AI readiness assessment maps your vendor AIBOM readiness against the 7 fields. Free, structured AI report, no signup. Use it to grade vendors before procurement.

Try It Free

Key Takeaways

1. AIBOM is becoming table stakes. SBOM standard for software; AIBOM standard for AI. EU AI Act auditors will use it.

2. 7 fields auditors look for. AI models, training data, fine-tuning, model card, inference dependencies, runtime telemetry, update policy. Each is specific and verifiable.

3. AIBOM feeds three other artifacts. DPIA Section 5, AI Act Annex IV technical doc, NIS2 supply-chain note. One inventory, three uses.

4. The 1-week test is decisive. Compliant vendor produces AIBOM in a week. Non-compliant needs months. The response time is procurement signal.

5. Ask through procurement, not legal. Reference OWASP/SPDX/CycloneDX standards; list the 7 fields; let the vendor choose the format. Skip months of legal review.

AI Bill of Materials (AIBOM) for HR-Tech: What EU AI Act Auditors Will Ask For in August 2026

What Is an AIBOM and How Is It Different from SBOM?