Auditors, procurement teams, and downstream deployers are no longer satisfied with a high-level description of your AI systems. They want the full composition: which foundation models, which training and fine-tuning data, which third-party API dependencies, which prompt templates, which runtime tools, which vulnerabilities you have scanned for, and which vendors are in the chain. This is an AI Supply Chain Bill of Materials — an AI-SBOM — and it is rapidly becoming the artefact that gets attached to every EU AI Act file, every security questionnaire, and every enterprise procurement review.
TruthVouch Compliance Autopilot assembles your AI-SBOM automatically from data you already have in the platform, versions every snapshot, exports in the formats your auditors and downstream engineering teams actually use, and links each published SBOM straight to your compliance obligations as evidence.
Why AI-SBOMs Matter
Traditional software SBOMs, championed by CISA and the NTIA, were the response to a decade of supply chain attacks like SolarWinds and Log4Shell. Regulators and standards bodies have now extended the same logic to AI: if you cannot enumerate what goes into your AI system, you cannot govern it, you cannot defend it, and you cannot prove compliance.
The pressure is coming from several directions at once:
- EU AI Act Article 11 and Annex IV require providers of high-risk AI systems to maintain technical documentation covering model architecture, training data, data governance, and third-party components — kept up to date for the lifetime of the system.
- EU AI Act Article 13 requires the same information, in usable form, to be provided to downstream deployers so they can meet their own obligations.
- NIST AI Risk Management Framework — specifically the Map function — calls for explicit enumeration of AI system components, data sources, and supply chain dependencies as a prerequisite for risk identification.
- ISO/IEC 42001 requires a documented AI management system that tracks the composition and lifecycle of every AI system in scope.
- GDPR Article 30 requires records of processing activities, which for AI systems increasingly means enumerating the model providers and data processors involved.
- SOC 2 auditors are asking for AI-specific vendor inventories as part of CC-series controls on third-party risk.
The industry is standardising on CycloneDX ML (v1.6 adds first-class model and dataset components) and the SPDX 3.0 AI profile as the machine-readable formats to exchange this information. A compliant AI-SBOM answers, in a form a regulator or customer can actually parse: what is in this AI system, where did each piece come from, and what is the risk profile of each component.
What Auto-Populates vs What You May Need to Register
The SBOM is assembled from data already owned by other TruthVouch products. If your teams have been using TruthVouch for vendor assessments, prompt governance, or endpoint discovery, most of the work is already done. The table below shows what flows in automatically and where you might need to register something first.
| SBOM Component | Source Product | Auto-populated? | What to do if empty |
|---|---|---|---|
| Vendor components | Advisory (Vendor Assessments) | Yes — vendor name, assessment score, derived risk level | Run a vendor assessment from Advisory for each foundation-model or AI-API vendor in use |
| Prompt components | Governance (Prompt Inventory) | Yes — includes shadow-prompt detection flagged prompts | Ingest prompts via the Prompt Inventory; shadow prompts discovered by Sentinel are auto-registered |
| Tool components | Sentinel (Workstation Inventory) | Yes — from RunningTools and IdePlugins discovered on endpoints | Deploy Sentinel to engineering workstations; no manual registration required |
| Vulnerability components | Governance (MCP Scan Findings) | Yes — client-wide, scoped to the AI system’s MCP servers | Run an MCP scan from Governance; findings flow into the SBOM on next regeneration |
| DPIA Assessments | Compliance Autopilot | Yes — from DPIA Assessments linked to this AI system | Create a DPIA from the AI System detail page for any system processing personal data |
| Knowledge / RAG sources | Compliance Autopilot (Knowledge Documents) | Yes — documents linked to the AI system | Link Knowledge Base documents used as RAG context to the AI system record |
| Datasets | Compliance Autopilot | Yes — training-data and fine-tuning datasets registered against the system | Register training and fine-tuning datasets on the AI System detail page |
The SBOM is strictly a consolidation layer. It never asks you to re-enter data that lives somewhere else in the platform — and every component in an exported SBOM is traceable back to the source record, which matters for audit defence.
Step 1: Navigate to Your AI System
- Log in to app.truthvouch.ai
- Open Compliance Autopilot from the left sidebar
- Select AI Systems
- Click the AI system you want to generate an SBOM for
You will land on the AI System detail page. The SBOM tab sits alongside the existing tabs for the system (Overview, DPIA, Training Data, Risk, and so on).
If you do not yet have the AI system registered, create it from the AI Systems list first. A minimum viable record is name, owner, lifecycle stage, and risk classification — everything else the SBOM needs can be linked in later.
Step 2: Open the SBOM Tab
Click the SBOM tab at the top of the AI System detail page.
On first visit, the tab shows an empty state with a Generate SBOM button and a preview of the sources TruthVouch will pull from. The preview tells you, before you commit to a version, exactly how many vendors, prompts, tools, vulnerabilities, knowledge documents, DPIAs, and datasets will be included.
If the preview is thinner than you expected, this is the moment to check whether the relevant product modules are populated — it is much faster to add a missing vendor assessment or link a missing Knowledge Base document now than to regenerate later.
Step 3: Preview the Sources
Use the Manageable Sources panel on the SBOM tab to review and, where appropriate, toggle individual component sources on or off.
You will typically want every source enabled for a full regulatory artefact. The common reason to exclude one is scoping — for example, a pilot system where MCP scanning has not yet been extended to its servers, and you would rather publish a clean SBOM flagged as “MCP scan pending” than one with empty vulnerability data.
Each source row shows:
- The source product (Advisory, Governance, Sentinel, Compliance Autopilot)
- The number of candidate components that will be pulled in
- The last time those upstream records were updated
Tip: If a source shows zero candidates and you believe that is wrong, the upstream record is probably not linked to this AI system. The fix is in the source product, not in the SBOM tab — for example, ensure the vendor assessment has this AI system selected in its scope, or that the Knowledge Document is linked to the system.
Step 4: Generate Your First Version
With the sources reviewed, click Generate SBOM. TruthVouch queries every enabled source, assembles the components into the nine standard sections, and writes an immutable snapshot to the SBOM version history.
The generated version opens in the main pane, organised into nine expandable section accordions — one per component type (model providers, datasets, fine-tuning data, RAG sources, prompt templates, tools and SDKs, third-party API dependencies, known vulnerabilities, and data processing activities). Each accordion shows the component count in its header and a table of components when expanded.
At the top of the version view you will see:
- Compliance badges — one per regulatory framework the SBOM covers (EU AI Act Art. 11, EU AI Act Art. 13, GDPR Art. 30, ISO 42001, NIST AI RMF Map, SOC 2). Badges light up automatically based on which sections have populated components.
- The toolbar — Regenerate, Export menu (CycloneDX JSON, CycloneDX XML, SPDX, PDF), and Source preview.
- Version metadata — version number, who generated it, generation timestamp, and status (draft or published).
Publish the version when you are satisfied with it. Publishing the SBOM is what triggers the two downstream effects described in Steps 6 and 7: versioning becomes immutable, and an evidence artefact is created for compliance linking.
Step 5: Exporting — CycloneDX, SPDX, or PDF
TruthVouch exports the same SBOM version in three standards-compliant formats. Use the Export menu in the SBOM toolbar. Which one you pick depends on who is on the receiving end.
| Format | Best for | Why |
|---|---|---|
| CycloneDX ML v1.6 (JSON) | Engineering and security pipelines, SAST/SCA tooling, supplier intake workflows | Widest tool support; first-class ML model and dataset components; trivially parsed by existing SBOM ingestion pipelines |
| CycloneDX ML v1.6 (XML) | Enterprises with XML-first SBOM tooling or legacy procurement portals | Same schema as JSON, different serialisation — pick whichever your counterpart asks for |
| SPDX 3.0 AI profile (JSON) | Open-source programs, organisations standardising on SPDX across software and AI | Aligns AI-SBOM with existing SPDX-based software supply chain governance |
| Human-readable PDF | Board packs, auditor walkthroughs, vendor questionnaires, regulator submissions | Rendered via QuestPDF with compliance mappings, component tables, and version metadata. Nobody wants to read raw JSON in a board meeting |
A common pattern is to export CycloneDX for your security team’s ingestion pipeline, SPDX for your open-source program office, and a PDF for the audit or customer package — all generated from the same published version, so the three artefacts are guaranteed consistent.
Step 6: Versioning and Diffs
Every published SBOM is an immutable snapshot. Regenerating does not overwrite the previous version — it creates a new one, linked to its parent in a version chain. This means you can always produce the exact SBOM that was handed to a customer or regulator six months ago, even after your AI system has changed substantially.
The version timeline on the SBOM tab lists every version in reverse chronological order with its status, generation method, author, and timestamp. Select any two versions and click Compare to open the diff view.
The diff endpoint computes, between the two selected versions:
- Added components — things that are in the newer version but not the older
- Removed components — things that have dropped out
- Changed components — same component identity, different attributes (for example, a vendor whose risk rating changed, or a prompt whose content was updated)
This is the mechanism you use when a regulator or customer asks, “What changed in the supply chain of this AI system between your Q1 and Q3 audits?” The answer is a deterministic diff you can attach to the response, not a reconstruction.
A good operational rhythm is to regenerate the SBOM on a monthly cadence and on any significant change — a new model provider, a major prompt rewrite, a new data source, or a newly discovered vulnerability. The diffs then give you a cheap audit trail of supply-chain change.
Step 7: How the SBOM Links to Your Compliance Obligations
Publishing an SBOM is not just a documentation exercise — it creates an EvidenceArtifact in your compliance workspace with artifact_type = ai_sbom. This artefact is automatically eligible for linking to the obligations that SBOMs satisfy.
In the Compliance Autopilot dashboard, obligations derived from the frameworks below will see the new evidence artefact as a candidate and, where the auto-linking rules apply, attach it directly:
- EU AI Act Article 11 — Technical documentation (Annex IV content)
- EU AI Act Article 13 — Transparency information provided to deployers
- GDPR Article 30 — Records of processing activities (vendor and processor inventory)
- ISO 42001 — AI management system, supply chain controls
- NIST AI Risk Management Framework — Map function, supply chain component enumeration
- SOC 2 — Third-party vendor inventory control
The effect is that one action — publishing an SBOM version — satisfies evidence requirements across multiple frameworks simultaneously. You no longer upload the same PDF to six different obligation lockers. You publish once, and the obligations point back to the single source of truth.
If your compliance team has written custom obligation rules, they can add the ai_sbom artefact type to any additional obligation’s evidence criteria, and future published versions will link automatically.
FAQ and Troubleshooting
Why is the vulnerability section empty even though I have run scans? MCP scan findings are scoped client-wide but are only pulled into an AI system’s SBOM when MCP servers are linked to that specific system. In Governance, confirm that the MCP servers relevant to this AI system are associated with it. If the association is missing, create it and regenerate the SBOM.
Can I add a component manually if TruthVouch did not auto-detect it? Yes. Inside any section accordion you can add components by hand. Manually added components are marked as such in the export so auditors can distinguish them from auto-detected ones.
Does regenerating the SBOM affect existing evidence links? No. Previously published versions stay in place along with their evidence artefacts. A new version creates a new evidence artefact; historical obligations remain linked to their historical evidence.
How are shadow prompts included? The prompt inventory in Governance flags prompts as shadow-discovered when Sentinel detects them on endpoints without a matching governed entry. These flow through into the Prompt Templates section of the SBOM with their shadow status preserved, which is useful evidence for EU AI Act transparency reviews.
Is there a CI/CD integration that uploads SBOMs on every build?
Not yet. Today the SBOM is generated in the Compliance Autopilot UI and exported in CycloneDX, SPDX, or PDF. For automation, use the REST API endpoints under /api/v1/compliance/ai-systems/{id}/sbom — but there is no pre-built GitHub Action or dedicated CI uploader.
Which export format should I give to an EU AI Act conformity assessor? The PDF is the format assessors actually read. Attach the CycloneDX JSON alongside as the machine-readable backing artefact so they can verify counts and component details programmatically if they choose.
Next Steps
You have generated, published, and exported your first AI-SBOM — and linked it to your compliance obligations as evidence. Here is what to build on next:
- Run Your First AI Compliance Assessment — Pair your SBOM with a full Compliance Autopilot assessment to see which obligations the SBOM now satisfies and where you still have gaps.
- Register every AI system — The SBOM is per system. If you have a dozen production AI systems, each needs its own entry in Compliance Autopilot → AI Systems and its own published SBOM. Bulk importing AI systems from a CSV is supported from the AI Systems list view.
- Schedule regeneration — Pick a monthly cadence that matches your governance review rhythm. The diff view turns this into a low-cost audit trail.
- Book a compliance walkthrough — Our team can review your first SBOM with you and help calibrate which regulatory mappings matter most for your procurement and audit landscape.