Audience: For AI system operators, supply chain managers, and procurement teams implementing G7 AI-SBOM guidance. Also relevant to assessors evaluating AI supply chain documentation completeness and hardware provenance.
The G7 Cybersecurity Working Group published 50 minimum elements for AI SBOMs on May 12, 2026. This guidance is voluntary but will shape procurement requirements across G7 nations. Published through BSI (Germany's Federal Office for Information Security), the framework organizes AI supply chain transparency into 7 clusters covering metadata, models, datasets, system properties, KPIs, security, and infrastructure.
Critical Assessor Notice: Boundaries of Cryptographic Evidence
SWT3 witness anchors prove that specific operational controls were active at a specific point in time. They do not replace the assessor's independent judgment, professional expertise, or regulatory authority. Assessors must verify that anchored evidence is sufficient, appropriate, and relevant to the specific assessment context. Each regulatory framework retains its own assessment authority, methodology, and determination standards.
1. Background
The G7 Hiroshima AI Process established a commitment to AI supply chain transparency in 2023. The Cybersecurity Working Group -- co-led by BSI (Germany) and CISA (United States) -- spent 18 months developing a structured framework for AI-specific SBOMs. The result is a 50-element specification organized into 7 clusters, published by BSI on May 12, 2026.
Unlike traditional software SBOMs (NTIA 2021, CISA 2026), the G7 AI-SBOM framework addresses the unique characteristics of AI systems: model provenance, training data lineage, performance KPIs, hardware dependencies, and security properties that have no equivalent in conventional software supply chains.
The 7 Clusters
| Cluster | Scope | Element Count |
|---|---|---|
| 1. Metadata | SBOM document identity, format, authorship | 8 |
| 2. Models | Model cards, versioning, training provenance, weights integrity | 9 |
| 3. Dataset Properties | Data provenance, quality, training statistics, retention | 7 |
| 4. System-Level Properties | Infrastructure components, runtime environment, integration points | 6 |
| 5. KPIs | Power usage, thermal, water consumption, model performance metrics | 7 |
| 6. Security Properties | Supply chain provenance, threat detection, adversarial resilience | 6 |
| 7. Infrastructure | Hardware inventory, lifecycle tracking, hardware attestation | 7 |
The guidance is voluntary across all G7 nations but is expected to influence procurement language in federal, defense, and critical infrastructure contracts. BSI has indicated that future versions of the German IT-Grundschutz AI module will reference these clusters. CISA's own 2026 SBOM update already incorporates several G7 AI-SBOM concepts.
SWT3 does not generate AI SBOMs -- it witnesses that an AI-SBOM was produced, records its structural properties, and creates a cryptographic anchor proving the document existed with specific characteristics at a specific point in time.
Relationship to EU AI Act Annex IV
Organizations preparing for EU AI Act conformity assessment should note the direct overlap between G7 AI-SBOM clusters and Annex IV technical documentation requirements. Cluster 2 (Models) maps to Annex IV Section 2(b) (design specifications, model architecture). Cluster 3 (Dataset Properties) maps to Annex IV Section 2(d) (training data, datasets). Cluster 7 (Infrastructure) maps to Annex IV Section 2(a) (computing resources). Achieving G7 AI-SBOM coverage generates reusable evidence for Annex IV. See the Annex IV Metrics Guide and Annex VII Data Room Guide for the full EU AI Act mapping.
2. Cluster 1: Metadata
Cluster 1 covers the SBOM document itself -- its format, version, authorship, and completeness. These elements establish the identity and traceability of the AI-SBOM document.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| SBOM format identifier | AI-SBOM.1 | Format code (CycloneDX=1, SPDX=2, custom=0) |
| SBOM version | AI-SBOM.1 | BOM document hash (SHA-256) tracks version changes |
| SBOM author | AI-SBOM.1 | Agent identity recorded via agent_id field |
| SBOM creation timestamp | AI-SBOM.1 | Anchor timestamp (epoch-level precision) |
| Clusters documented | AI-SBOM.1 | clusters_documented factor (0-7 coverage count) |
| Total component count | AI-SBOM.1 | total_components factor (integer count) |
| Document integrity hash | AI-SBOM.1 | SHA-256 BOM hash in witness fingerprint |
| Upstream SBOM references | AI-SBOM.1 | Component count includes upstream dependencies |
The clusters_documented factor in AI-SBOM.1 anchors directly maps to this cluster's completeness requirement. A value of 7 indicates full G7 AI-SBOM coverage. Values below 5 warrant investigation into which clusters are missing from the organization's documentation.
3. Cluster 2: Models
Cluster 2 addresses the AI model itself -- its identity, versioning, training provenance, and weights integrity. This is the largest departure from traditional SBOM practices and requires multiple SWT3 procedures to cover.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Model card presence | AI-MDL.1 | Model card completeness attestation |
| Model name and identifier | AI-MDL.1 | Model identity recorded in anchor factors |
| Model version tracking | AI-MDL.2 | Version hash, drift from baseline |
| Training provenance | AI-MDL.3 | Training pipeline attestation, data lineage |
| Fine-tuning lineage | AI-MDL.3 | Parent model fingerprint, fine-tuning chain |
| Model weights hash | AI-MDL.5 | SHA-256 of model weight files |
| Weights integrity verification | AI-MDL.5 | Hash comparison against registered baseline |
| Model registry status | AI-MDL.8 | Registry check result, registration state |
| Model architecture description | AI-MDL.1 | Architecture metadata in model card fields |
Weights Integrity Witnessing
Witnesses that model weight files were hashed at a specific point in time. This directly addresses the G7 requirement for weights integrity verification -- proving that a specific set of weights was present and unmodified when the AI-SBOM was produced. The static hash_model_file() utility in the SDK computes SHA-256 hashes of weight files without loading them into memory.
Compare AI-MDL.5 anchor fingerprints across deployments. Matching weight hashes prove the same model was deployed. Divergent hashes between production and staging indicate a weights mismatch that must be investigated. Cross-reference with AI-MDL.2 version anchors to confirm the weight hash corresponds to the declared model version.
Model Registry Verification Witnessing
Witnesses that a model's registration status was checked against a model registry. The G7 AI-SBOM framework expects models to be registered and trackable. This procedure records whether the model was found in the registry, its registration state, and when the check was performed.
Unregistered models appearing in production without AI-MDL.8 anchors represent a documentation gap. Query for models that have AI-MDL.5 weights hashes but no corresponding registry check.
4. Cluster 3: Dataset Properties
Cluster 3 covers training data provenance, quality metrics, statistical properties, and retention policies. These elements address the growing regulatory expectation that AI systems document their training data lineage.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Data source provenance | AI-DATA.1 | Data provenance attestation, source count |
| Data licensing and rights | AI-DATA.1 | Licensing status recorded in provenance chain |
| Data quality metrics | AI-DATA.2 | Quality score, completeness, consistency measures |
| Data cleaning and preprocessing | AI-DATA.2 | Pipeline attestation, transformation record |
| Training data statistics | AI-DATA.3 | Dataset size, feature count, class distribution |
| Evaluation/test split ratios | AI-DATA.3 | Train/test/validation split recorded |
| Data retention policy | AI-DATA.4 | Retention period, deletion schedule attestation |
Query AI-DATA.1 through AI-DATA.4 anchors as a group. A complete Cluster 3 evidence chain requires at least one anchor from each of the four procedures. Organizations with AI-DATA.1 anchors but no AI-DATA.4 anchors have documented data sources but not retention -- a common gap in AI-SBOM completeness.
5. Cluster 4: System-Level Properties
Cluster 4 documents the system in which the AI model operates -- infrastructure components, runtime environment, and integration points. This cluster bridges AI-specific elements with traditional SBOM software inventory.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Infrastructure components | AI-SBOM.1 | Infrastructure component count in total_components |
| Software dependencies | AI-SBOM.1 | BOM document hash covering dependency tree |
| Hardware inventory | HBOM-INV.1 | Component count, manifest hash, baseline delta |
| Compute resource allocation | HBOM-INV.1 | Hardware manifest includes compute resources |
| Runtime environment | AI-ENV.1 | Runtime configuration attestation, environment hash |
| Integration endpoints | AI-ENV.1 | Service dependency count, API surface attestation |
Runtime Environment Witnessing
Witnesses the runtime environment configuration of an AI system. The G7 AI-SBOM framework recognizes that the same model deployed in different environments may behave differently. This procedure records the environment's properties -- container images, framework versions, GPU drivers, and service dependencies -- at a specific point in time.
Compare AI-ENV.1 anchors between staging and production. Divergent environment hashes indicate configuration drift that could affect model behavior. Cross-reference with AI-MDL.5 weights hashes to confirm model-environment pairing is consistent across deployments.
6. Cluster 5: KPIs
Cluster 5 covers operational performance indicators -- energy consumption, thermal management, water usage, and model accuracy metrics. This cluster reflects the G7's emphasis on sustainable AI and measurable performance.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Power usage effectiveness | HBOM-PUE.1 | PUE ratio, energy consumption attestation |
| Energy consumption per inference | HBOM-PUE.1 | Per-inference energy metrics |
| Thermal management | HBOM-THERM.1 | Thermal profile attestation, cooling efficiency |
| Cooling infrastructure | HBOM-THERM.1 | Cooling system configuration record |
| Water consumption | HBOM-WATER.1 | Water usage attestation, WUE ratio |
| Model accuracy metrics | AI-PERF.1 | Performance baseline, accuracy/F1/latency measures |
| Performance degradation tracking | AI-PERF.1 | Performance drift from established baseline |
Cluster 5 is the most operationally focused cluster. HBOM-PUE.1, HBOM-THERM.1, and HBOM-WATER.1 provide environmental sustainability evidence increasingly required by EU regulations. AI-PERF.1 anchors track model performance over time -- a series of anchors with declining accuracy indicates model degradation that may warrant re-training or retirement.
7. Cluster 6: Security Properties
Cluster 6 addresses supply chain security, threat detection capabilities, and adversarial resilience. These elements align with existing cybersecurity SBOM practices but extend them to AI-specific attack surfaces.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Supply chain provenance | HBOM-SUPPLY.1 | Supplier hash, verification flag, country of origin |
| Supplier verification status | HBOM-SUPPLY.1 | provenance_verified flag (1=independent, 0=self-attested) |
| Known vulnerability status | AI-CYBER.1 | Threat detection attestation, vulnerability scan record |
| Threat model coverage | AI-CYBER.1 | Threat model completeness, attack surface mapping |
| Adversarial testing results | AI-SEC.1 | Adversarial detection attestation, resilience measures |
| Model poisoning detection | AI-SEC.1 | Data integrity verification, poisoning detection status |
Hardware Supply Chain Witnessing
Witnesses that supply chain provenance was assessed for hardware and software components in the AI system. Records a hash of the supplier information, whether provenance was independently verified, and a hash of the country of origin data. The G7 AI-SBOM framework expects full supply chain transparency -- self-attested claims (provenance_verified=0) are distinguishable from independently verified claims.
The provenance_verified flag is critical for procurement teams. Self-attested supply chain claims (value 0) carry different evidentiary weight than independently verified claims (value 1). Query HBOM-SUPPLY.1 anchors with provenance_verified=0 to identify components with unverified supply chain claims.
8. Cluster 7: Infrastructure
Cluster 7 covers the physical and virtual infrastructure that supports the AI system -- component inventory, lifecycle tracking, and hardware attestation. This cluster overlaps with traditional HBOM practices but adds AI-specific requirements for accelerator hardware and specialized compute.
| G7 Element | SWT3 Procedure | Evidence Produced |
|---|---|---|
| Component inventory | HBOM-INV.1 | Component count, manifest hash, baseline delta |
| Accelerator hardware | HBOM-INV.1 | GPU/TPU/FPGA inventory in manifest |
| Component lifecycle status | HBOM-LIFE.1 | Lifecycle phase attestation, EOL tracking |
| End-of-life tracking | HBOM-LIFE.1 | EOL date, replacement plan attestation |
| Hardware attestation | AI-HW.1 | Hardware identity, firmware hash, attestation chain |
| Firmware integrity | AI-HW.1 | Firmware version hash, secure boot status |
| Country of manufacture | HBOM-INV.1 | Country data in component manifest |
Hardware Identity and Integrity Witnessing
Witnesses that hardware components were attested -- recording their identity, firmware version hash, and secure boot status. The G7 AI-SBOM framework recognizes that AI systems depend on specialized hardware (GPUs, TPUs, neural processing units) whose integrity is critical to model behavior. This procedure witnesses that hardware attestation was performed at a specific point in time.
Cross-reference AI-HW.1 anchors with HBOM-INV.1 inventory anchors. Hardware attestation without corresponding inventory entries -- or inventory entries without attestation -- indicates incomplete infrastructure documentation under Cluster 7.
Lifecycle Tracking Witnessing
Witnesses that component lifecycle status was assessed. The G7 framework expects AI system operators to track end-of-life dates for critical infrastructure components and plan replacements before support ends. This procedure records lifecycle phase and EOL status at a specific point in time.
Components past EOL without replacement plans represent a supply chain risk. Query HBOM-LIFE.1 anchors alongside HBOM-INV.1 anchors to identify infrastructure components approaching or past end-of-life.
9. Quick Start
The following examples demonstrate witnessing AI-SBOM generation using the Python and TypeScript SDKs. Both calls produce SWT3 witness anchors that can be independently verified.
Python
TypeScript
Each witness call records the AI-SBOM event with the specified factors and produces an anchor at the configured clearing level. The anchor string can be verified at sovereign.tenova.io/verify using only the anchor value -- no API keys or vendor access required.
Recommended Witness Cadence
- Cluster 1 -- Metadata (
AI-SBOM.1): Witness on every AI-SBOM generation or update. CI/CD integration recommended. - Cluster 2 -- Models (
AI-MDL.1,AI-MDL.2,AI-MDL.3,AI-MDL.5,AI-MDL.8): Witness on model registration, training, fine-tuning, or deployment promotion. - Cluster 3 -- Datasets (
AI-DATA.1throughAI-DATA.4): Witness on dataset ingestion, quality review, or retention policy changes. - Cluster 4 -- System (
AI-SBOM.1,HBOM-INV.1,AI-ENV.1): Witness on infrastructure changes or quarterly review. - Cluster 5 -- KPIs (
HBOM-PUE.1,HBOM-THERM.1,HBOM-WATER.1,AI-PERF.1): Witness on periodic sustainability reporting or performance degradation detection. - Cluster 6 -- Security (
HBOM-SUPPLY.1,AI-CYBER.1,AI-SEC.1): Witness on vendor onboarding, vulnerability scans, and adversarial testing. - Cluster 7 -- Infrastructure (
HBOM-INV.1,HBOM-LIFE.1,AI-HW.1): Witness on hardware changes, EOL reviews, and firmware updates.
10. Relationship to CISA Guidance
The G7 AI-SBOM Minimum Elements and CISA 2026 SBOM Minimum Elements are complementary frameworks with different origins and scopes.
| Dimension | G7 AI-SBOM (May 2026) | CISA 2026 SBOM (July 2026) |
|---|---|---|
| Origin | G7 Cybersecurity Working Group (BSI/CISA co-led) | CISA (US federal) |
| Scope | AI systems specifically | All software, with AI/infrastructure extensions |
| Structure | 7 clusters, 50 elements | 3 tiers (Baseline, AI Extension, Infrastructure Extension) |
| Binding force | Voluntary (G7 guidance) | Mandatory for US federal contractors (EO 14028) |
| KPIs | Yes (Cluster 5 -- energy, thermal, water, performance) | No |
| Hardware attestation | Yes (Cluster 7 -- firmware hash, secure boot) | Limited (component inventory only) |
| Dataset documentation | Detailed (Cluster 3 -- 7 elements) | Basic (training data sources, dataset lineage) |
The G7 AI-SBOM framework is broader in AI-specific coverage (KPIs, hardware attestation, dataset properties) while CISA's framework carries regulatory weight for US federal procurement. Organizations subject to both should target the G7's 7-cluster structure -- achieving full G7 coverage automatically satisfies CISA's AI Extension and Infrastructure Extension tiers.
SWT3 procedures map to both frameworks. An AI-SBOM.1 anchor with clusters_documented=7 provides evidence for both G7 Cluster 1 completeness and CISA Baseline tier coverage. The witness anchors are framework-neutral -- the same evidence serves both regulatory contexts.
11. Cross-References
- CISA 2026 SBOM Minimum Elements Crosswalk -- US federal SBOM requirements mapped to SWT3 procedures
- HBOM and Battery Passport Crosswalk -- hardware bill of materials and EU Battery Passport evidence
- BSI AI-SBOM Publication (50 Minimum Elements) -- G7 Cybersecurity Working Group framework document
- CISA SBOM Resources -- US federal SBOM guidance and tools
- G7 Hiroshima AI Process -- foundational G7 AI governance commitments
- SWT3 Protocol Specification -- canonical protocol reference
- UCT Registry -- full procedure catalog with framework crosswalks