報導概述

2026 年 4 月，七大工業國(G7)資安工作組(Cybersecurity Working Group)正式發布《Software Bill of Materials for AI。 Minimum Elements》，由德國 BSI、義大利 ACN、法國 ANSSI、加拿大 CSE、美國 CISA、英國 NCSC、日本 NCO 共同署名，並由歐盟執委會(European Commission)參與。這是 G7 自 2025 年 6 月發布「SBOM for AI 共同願景」後，首份具體列出最小元素清單的延伸文件。

文件提出七大群集(cluster)共 50 餘項建議元素，涵蓋 Metadata、System Level Properties、Models、Datasets Properties、Infrastructure、Security Properties、Key Performance Indicators。文件明確指出「這些最小元素不具強制力，不創設新的法規或標準」，但其價值在於。當歐盟《AI Act》Article 11 與 Annex IV 在 2026 年 8 月對高風險 AI 系統全面適用、歐盟《Cyber Resilience Act》(CRA)的 SBOM 義務於 2027 年 12 月生效時，這份 G7 共識實質上預先勾勒了七國認可的「最低答卷格式」。

對台灣讀者而言，本文件值得分析的關鍵並非條列翻譯，而在於三個面向。

1. 第一，它如何回應過去 12 個月已實際發生、且仍在加劇的 AI 模型供應鏈攻擊浪潮；
2. 第二，外銷導向的台灣企業在未啟動 EU AI Act 直接合規前，可能透過供應鏈條款被間接拉入合規範圍；
3. 第三，本框架與我國正在推動的 AIMS(AI Management System，AI 管理系統，對應 ISO/IEC 42001。2023)導入路徑如何銜接。

本報告聚焦在「這份框架背後解決的真實威脅」與「台灣組織該如何取捨採用」，而非逐項翻譯七個 cluster。

本質判讀

1. 為何此時推出「最小元素」?——一個被低估的攻擊面

過去 18 個月，AI 模型供應鏈攻擊已從研究議題進入實證階段。依公開資料。研究人員於 2025 年發現，Hugging Face 平台上「下載量前 1,000 名」模型中，曾被檢出存在某種程度汙染或可疑成分者比例不低；參數高效微調(PEFT， Parameter-Efficient Fine-Tuning)盛行帶來 LoRA Adapter 投毒。新型態——惡意微調權重檔僅數10 MB，卻可植入難以區分於合法微調的後門；TensorFlow、MLflow 等 ML 框架已出現具 CVE 編號的可遠端利用漏洞；PyPI 與 npm 上的 ML 相關套件遭 typosquatting(仿冒名稱)攻擊頻繁。

業界統計指出，從模型遭汙染到被偵測，平均需 197 天——這個數字若放在傳統 IT 系統屬於極端嚴重的延遲，但在 AI 供應鏈中卻是常態。原因不在偵測技術不足，而在於「下游組織根本不知道自己用了什麼」。一個微調後的客服機器人，其權重可能來自上游基礎模型 A，A 又微調自 B，B 又從 C 蒸餾而來——當 C 被植入後門，整條鏈路上沒有人有完整的物料清單可追溯。

這正是 G7 此時推出 SBOM for AI 最小元素的真實動機。在攻擊面尚未完全失控之前，先把「可追溯」這件事的最低共識先確立下來。

2. 與傳統 SBOM 的關鍵分野

文件第三頁有一句關鍵敘述，常被忽略。「AI systems are also software systems. Therefore， SBOMs still remain valid for AI systems. The minimum elements in an SBOM for AI are in addition to the general SBOM minimum elements.」

這句話的政策意涵是。G7 並未另起爐灶，而是承認既有 SBOM(NTIA 最小元素、SPDX、CycloneDX)為基礎，AI 為其延伸。對 CISO 而言這代表兩件事。

• 既有的 SBOM 治理流程(漏洞掃描、授權管理、簽章驗證)可以複用，不必砍掉重練。
• 但既有流程的「可掃描對象」必須擴充——除了 .so / .jar / npm 套件外，現在還包括模型權重檔(.safetensors / .gguf / .pt)、訓練資料集、提示詞模板(system prompt)、向量資料庫、外部 API 依賴等。

3. 七個 cluster 為何是這七個——設計取捨揭露

從工作組決議的軌跡可看出，有兩個元素被刻意排除。

• AI 系統的「決策自主性層級」(Level of Autonomy)——文件第三章明確指出此項雖重要，但「在不同司法管轄區可能透過安全(safety)要求另行處理」，因此不納入 SBOM 範疇。這是一個聰明的政治切割。把 SBOM 守在「資安透明度」議題，避開「AI 風險治理」更具爭議的領域。
• 訓練成本／碳排放——這是 EU AI Act 通用型 AI 模型(GPAI)已部分要求的項目，但 G7 不重複造輪。

對讀者的啟示。SBOM for AI 不是「AI 治理萬靈丹」。它解決的是「供應鏈成分透明」這一件事，組織若以為導入 SBOM 就完成 AI 治理，會是嚴重誤判。AIMS(ISO/IEC 42001)、AI 風險管理框架(NIST AI RMF)、隱私衝擊評估(DPIA)，仍是並行需要的治理工具。

框架解析

1. 框架定位與設計意圖

• 發布單位：G7 Cybersecurity Working Group(七國資安工作組)，由 2025 年加拿大主席國與 2026 年法國主席國共同推動，由義大利 ACN 與德國 BSI 共同主導 SBOM for AI 工作流。
• 法律位階：非強制性指引(non-binding guidance)。文件第一頁即明文「does not create requirements， standards， or legislation」。
• 設計目標：在 EU AI Act 全面施行(2026/8)、美國 EO 14028 後的 SBOM 推動、CRA 對 SBOM 的隱含要求(2027)之間，建立七國共同認可的最小資訊集，避免各國自行發展不相容的 AI 供應鏈透明度標準。
• 核心理念。「AI 系統也是軟體系統」——延伸而非取代既有 SBOM；以群集(cluster)為單位而非單一扁平清單，便於未來擴充。

2. 七個 Cluster 的結構與邏輯關係

文件給出的七 cluster 雖宣稱「除 Metadata 外，其餘地位相等」，但從資安風險治理角度可重新分組理解。
邏輯閱讀順序建議。Metadata(誰做的、何時做的、簽章是誰)→ Models / Datasets(核心成分)→ SLP / Infrastructure(執行環境)→ Security Properties / KPI(控制與度量)。

3. 鍵概念與術語

幾個容易被混淆或被低估的元素，需要特別釐清。

• Model hash value(模型雜湊)

這是文件中最具立即實作價值的元素。它對應的真實威脅是 Hugging Face 模型替換攻擊——攻擊者用相同模型名稱上傳替換版本。若下游沒有雜湊驗證，下次拉取(pull)時即取得後門版本。對應的雜湊演算法須採 IANA Hash Function Textual Names，且需符合 NIST 認可的安全演算法(如 SHA-256、SHA-3)。

• Dataset provenance(資料集來源)

這是 AI SBOM 相較傳統 SBOM 最創新的維度。傳統 SBOM 只關心程式碼，但 AI 系統的行為很大一部分由資料決定。文件要求記錄資料來源(network crawling、商業協議)、預處理、標註步驟、合成資料的生成方法。這對應的威脅是訓練資料投毒——攻擊者在公開資料集中植入觸發樣本(trigger sample)，使模型在特定輸入下出現後門行為。

• Model dependency relationship(模型依賴關係)

特別包含「派生(derivation)關係」——文件明確要求 SBOM 應能表達「Model A 微調自 Model B」、「Model A 從 Model C 蒸餾而來」。這對應「級聯汙染」(cascading contamination)——一個被汙染的基礎模型，其下游所有微調版本都繼承後門。沒有派生關係的紀錄，就無法在偵測到上游問題時，快速盤點下游受影響範圍。

• SBOM generation context(生成情境)

文件區分「before build」、「build」、「after build」三個情境。對 AI 而言，這對應「pre-training」、「fine-tuning」、「inference deployment」三個截然不同的階段——不同階段產出的 SBOM，覆蓋的成分清單完全不同。這也是 AI SBOM 必須動態維護而非「上線前一次性產出」的根本原因。

4. 應用場景與適用邊界

最適用情境

• 開發高風險 AI 系統且需面對 EU AI Act Article 11／Annex IV 技術文件審查的供應商
• 提供基礎模型(foundation model)或商用 LLM 給下游整合者的模型供應商
• 採購／導入第三方 AI 元件、需建立採購風險評估的甲方組織
• 軟體開發商需向客戶證明其 AI 元件成分可追溯時

適用邊界與限制(文件未明說但須注意)

• 不適用於封閉商用 API。若僅使用 OpenAI／Anthropic／Google API，使用者本身難以建立完整 SBOM，因為模型內部成分由供應商掌握。此情境下，SBOM 的責任主體在 API 提供商。
• 不解決執行時期(runtime)攻擊。SBOM 是靜態文件，無法偵測 prompt injection(提示詞注入)、jailbreak、agentic AI 的工具濫用等執行時期攻擊。
• 資料集 SBOM 在私有資料情境的可行性受限。包含個資、營業秘密、醫療資料的訓練集無法公開提供雜湊或內容描述，文件對此尚未提供處理建議。

5. 與相關框架的對照關係

台灣目前無對應 AI SBOM 的本地強制規範。2025 年通過的《人工智慧基本法》聚焦於原則與治理結構，未涉及具體技術文件格式。實務上，對台灣外銷企業而言，國際客戶的供應鏈條款比本地法規更具拘束力。

實作落差：理論 vs. 實務

文件描繪的是理想完整實作，但業界現況有明顯落差。
落差來源主要有三：成本(資料 provenance 的回溯整理工作量極大)、工具不成熟(SPDX 3.0 AI Profile 仍在演進中)、組織政治(揭露訓練資料來源可能引發著作權爭議)。

影響評估

1. 採用價值評估矩陣

2. 多維度影響評估

• 對採購與契約面的影響

EU AI Act Article 11 的合規責任在「provider」(提供者)身上，但下游整合者(deployer)會被供應鏈條款拉入要求。歐盟客戶與台灣供應商簽約時，會要求台灣供應商在交付 AI 元件時附上技術文件——這就是 SBOM for AI 的場景。預期 2026 下半年起，台灣外銷企業會開始收到客戶寄來的「AI 元件 SBOM 模板」，要求填寫並回傳。

• 對既有管理系統的整合衝擊

―   與 ISMS(ISO 27001。2022)。A.5.21(資通供應鏈管理)、A.5.22(供應商服務監測與審查)、A.8.30(外包開發)三條控制項，原本就涵蓋供應商風險，AI SBOM 是其落地證據之一，整合度高。

―   與 PIMS(ISO 27701)。Dataset sensitivity 元素若涉及個資，與 PIMS 的「資料處理紀錄」(Record of Processing Activities， ROPA)有部分重疊，需注意不要建立兩套不一致的紀錄。

―   與 AIMS(ISO 42001。2023)。高度互補。AIMS 的條款 8.2「AI 系統影響評估」需要的成分輸入，正是 SBOM for AI 的內容。導入 AIMS 的組織應將 SBOM for AI 視為附帶必備產出，而非新工作。

• 國際合規連動性

―   EU AI Act(高度連動)。2026/8/1 起對高風險 AI 系統全面適用 Annex IV 要求。Annex IV 第 2 點要求記錄訓練資料來源、品質、預處理；第 3 點要求記錄監測能力——這正是本 G7 文件 DP cluster 與 KPI cluster 的範疇。

―   EU CRA(中度連動)。2027/12/11 起含數位元素的產品須提供 SBOM；含 AI 元件者同步適用。

―   美國 NIST AI RMF(中度連動)。非強制，但聯邦採購與大型企業採購多將其列為參考。

―   SEC AI 重大性揭露(弱連動)。美國上市公司面對 AI 相關重大風險揭露時，可能需要證明風險評估完整性，SBOM 是支持文件之一。

• 台灣本地實體環境的適用性

台灣常見三類 AI 應用情境對應建議。

―   科技產業 AI 應用(製程預測、瑕疵檢測)：模型多為自研，但訓練資料涉及製程營業秘密。Dataset provenance 與 Dataset sensitivity 需發展「不揭露內容、僅揭露結構與處理流程」的內部 SBOM 實作版本。

―   金融業／醫療業 AI 應用：受金管會、衛福部規範，建議將本 G7 元素納入主管機關後續可能發布的 AI 應用指引前的內部準備。

―   政府機關 AI 採購：建議在採購規範中要求供應商提供 SBOM for AI，作為驗收文件之一，具體格式可參考 SPDX 3.0 AI Profile 或 CycloneDX ML-BOM。

參考觀點

• 本文件的真正受眾是「採購方」，不只是「開發方」

文件的表面定位是給 AI 開發者與部署者使用，但實質政策設計上，最大受益者是甲方採購組織。當客戶與供應商議約時，這份七國共識提供了一份「可寫進採購規格的標準索取清單」，把過去「請說明你的 AI 怎麼做的」這種模糊要求，變成 50 餘項具體欄位。

這個觀點的政策意涵。台灣甲方組織(含政府機關、大型企業)若不主動採用此清單作為採購要求，將錯失將供應鏈風險前推至供應商的最佳時機。等到 2027 年歐盟 CRA 全面強制後再被動因應，採購議價的時間視窗已關閉。

反向思考。本觀點的限制是，若供應商市場過於集中(如僅有少數基礎模型供應商可選)，甲方議價力有限，索取 SBOM 可能變成形式化文件——這時 SBOM 仍有「事後追溯」價值，但「事前風險篩選」價值減弱。

• Dataset cluster 是台灣製造業最具落地價值、也最被低估的部分

七個 cluster 中，Datasets Properties (DP) 是傳統 IT 安全人員最不熟悉、但對台灣製造業最有實質意義的維度。製造業 AI 應用大量使用自有資料訓練——製程資料、產線影像、設備感測——這些資料的「品質、來源、標註、處理」直接決定模型可信度。

當製造業客戶(歐美原廠或下游品牌)開始要求供應商證明 AI 系統可靠時，他們問的不是「你用了什麼框架」(這部分風險低)，而是「你的模型用了什麼資料訓練」(這部分風險高且不透明)。Dataset provenance 與 Dataset statistical properties 元素，正是回答這類問題的標準格式。

對涉及機密製程的廠商，完整 Dataset cluster 揭露會洩露競爭優勢。實務上應發展「對內完整、對外抽象」的雙層 SBOM——對外提供結構性描述與處理流程，不揭露具體資料內容。這個雙層做法 G7 文件並未明示，是本報告的補充建議。

• Security Properties cluster 的「Vulnerability referencing」是個未爆彈

文件第 22 頁的 Vulnerability referencing 元素，要求連結到「AI 模型／系統已知漏洞的可利用性資料庫」。但目前並沒有一個成熟的 AI 模型漏洞資料庫——MITRE 的 ATLAS(AI 對抗手法)與 CVE 體系，對 ML 特有的「對抗樣本」、「模型逆向」、「資料萃取」等攻擊，識別與編號機制都還未成熟。

傳統 CVE 體系針對程式碼漏洞設計，但 AI 攻擊(如 backdoor trigger、jailbreak prompt)並非「程式碼缺陷」，難以套用 CVE 描述格式。OpenSSF 於 2025 年底推出的「AI Scorecard」嘗試填補此空缺，但尚未獲得業界共識。

本元素短期內難以「完整填寫」。建議組織採務實做法——能對應到 CVE 的標準漏洞照填，AI 特有風險則以連結至自家 security.txt 或漏洞揭露程式(VDP， Vulnerability Disclosure Program)的方式處理。這個元素的成熟需要 2–3 年的生態系建構。

若組織為求形式完整而胡亂填寫此元素(例如「目前無已知漏洞」)，反而會在後續被檢視時被認定為「未盡善意揭露」——這比留白還糟。

• 本框架是「治理工具」，被誤用為「打勾清單」就失去價值

七個 cluster、50 餘項元素的視覺呈現，容易讓組織把它當成「填完就合規」的清單。但文件第 3 頁明確說「SBOM for AI by itself is not sufficient for increasing cybersecurity along the supply chain」——SBOM 必須連接到漏洞掃描、安全告警、威脅情資工具才有意義。

類比傳統 SBOM 的失敗案例—許多組織從 2021 年美國 EO 14028 後開始產生 SBOM，但 SBOM 產出後沒有接入漏洞掃描工具(如 OSV-Scanner、Trivy)，實際上對降低 Log4Shell 等事件的反應時間幾乎沒有幫助。SBOM for AI 若重蹈覆轍，將成為「合規檔案夾」而非「風險治理槓桿」。

採用本框架的組織應同步規劃下游消費鏈——SBOM 產出後送往哪些工具?由誰閱讀?觸發什麼流程?沒有想清楚這些問題就先導入，會陷入「文件生產線」而非「風險治理」。

• 本文件刻意保留的「決策自主性」議題，會在 2026 下半年回流

文件第 23 頁討論章節明確指出，「AI 系統的決策層級或自主性」(level of decision making or autonomy)雖被認可為相關，但本次不納入。原因是「不同司法管轄區可能透過安全要求另行處理」。

這是個典型的政治切割。EU AI Act 已用「禁止 / 高風險 / 有限風險 / 最小風險」四級分類處理 AI 的自主性議題；美國 OMB M-24-10 對「rights-impacting」與「safety-impacting」AI 另有分類。G7 不重複造輪是合理的，但這個議題不會消失——隨著 Agentic AI(代理型 AI)2026 年大規模商用，「這個 AI 有多大自主決策範圍」會成為採購方必問的問題。

本 SBOM 框架雖未直接涵蓋自主性，組織在規劃內部 SBOM 模板時，可在 SLP cluster 的「Intended application area」元素中自行擴充自主性層級描述。提前佈局，避免 2026 下半年另一波客戶問卷潮時手忙腳亂。

採用規劃重點(Adoption Planning Focus)

1. 框架對組織的核心價值命題

對台灣組織而言，採用 G7 SBOM for AI 最小元素的根本價值有二。對外，它是面對歐美客戶、歐盟監管、跨國採購條款時的「可被審查」格式；對內，它是把零散的 AI 治理證據(資料來源、模型版本、安全控制)整合為「可被稽核」結構的最低共識骨架。

它不是合規清單，而是讓供應鏈風險可以對話的共同語言。組織採用它的目的，是讓「我們的 AI 是用什麼做的」這個問題從每次都重新答辯，變成有固定欄位可填、可比較、可審視。

2. 採用前的評估重點

• 盤點現況的「AI 元件家底」

在導入 SBOM 結構前，先做一次 AI 資產清單盤點。許多組織會驚訝地發現自家 AI 元件數量遠超預期——除了正式的 ML 模型，還包括外掛的 LLM API、向量資料庫、第三方 AI plugin、員工自行接入的 Copilot 工具。沒有完整清單，SBOM 結構再完美也是建在沙上。建議的盤點視角。自研模型、第三方權重檔、第三方 API、第三方 ML 函式庫、訓練／微調資料集、prompt 模板與 system prompt 庫。

• 選擇承載格式時，避免「自創格式」陷阱

G7 文件刻意不指定資料格式。實作時應選擇既有國際標準。SPDX 3.0 AI Profile(Linux 基金會主導，與 SPDX 2.x 既有 SBOM 工具鏈相容)或 CycloneDX ML-BOM(OWASP 主導，自 1.5 版起支援 ML 元件)。避免自創 Excel 或 Word 模板——一旦客戶要求機讀格式，自創格式無法轉換。

• 與既有管理系統的整合策略

―   已導入 ISO 27001。2022 者。SBOM for AI 應掛在 A.5.21 / A.5.22 / A.8.30 的證據範圍下，不另立新流程。

―   已導入 ISO 27701 者。注意 Dataset sensitivity 元素的處理紀錄與 ROPA 一致性。

―   已啟動 ISO 42001 導入者。SBOM for AI 是條款 8.2(AI 系統影響評估)的天然產出，建議合併規劃而非分開推動。

―   尚未導入任何管理系統者。先以 ISMS 為底盤導入較具規模經濟，AI SBOM 為其延伸；不建議直接從 AIMS 切入而跳過 ISMS。

• 認證取得策略——目前不存在「SBOM for AI 認證」

本 G7 文件不是認證標準，沒有對應的第三方驗證機制。組織採用後的「可信度」主要透過。(1) SBOM 採用 NIST 認可的數位簽章；(2) 嵌入既有 ISO 認證(27001 / 42001)的稽核範圍；(3) 透過供應鏈風險管理服務商(如 SBOM 平台供應商)的審核服務間接背書。

• 裁適(Tailoring)原則——不需 50 項全填

―   G7 明文這 50 餘項是「最小集合」，但對中小型組織而言，全數填寫的成本與價值不成比例。建議裁適原則。

―   必填：Metadata 全部、Model 的 name/version/producer/hash、Dataset 的 name/provenance/sensitivity、Infrastructure 的 software 依賴清單。

―   重要但可分階段。Model properties、Dataset content、Security controls。

―   次階段：KPI cluster、Model external references、Vulnerability referencing(待生態系成熟)。

3. 規劃導入時建議納入的考量因素

• 資料來源 provenance 的回溯整理工作量

若組織既有 AI 模型已上線數年，回溯訓練資料來源與處理步驟可能極困難。建議的折衷。對既有模型採「best-effort 揭露」，明確標註「歷史資料部分無完整紀錄」；對新訓練／微調模型，從第一天起就建立完整紀錄。

• 揭露程度的法律風險審視

Dataset provenance 揭露網路爬取來源時，可能引發著作權爭議(如紐約時報訴 OpenAI)。Dataset sensitivity 揭露個資處理時，可能引發個資法／GDPR 合規檢視。建議的處理。揭露給客戶的版本與揭露給主管機關的版本可不同，前者著重結構性描述，後者著重完整性。

• 工具鏈成熟度與廠商鎖定

SBOM for AI 的工具生態尚在演進，2026 年市場上號稱支援 AI SBOM 的工具多有不同實作差異。建議的對策。選擇支援開放格式輸出(SPDX / CycloneDX)的工具，避免被特定廠商的私有格式鎖定。

• 跨部門協作的組織設計

SBOM for AI 的填寫橫跨資料科學團隊(Models、Datasets)、IT 部門(Infrastructure)、資安部門(Security Properties)、法遵部門(Dataset license、Dataset sensitivity)、產品團隊(System Level Properties)。沒有跨部門協調機制，SBOM 會卡在某一團隊手上。建議由資安部門牽頭，建立輕量化的「AI 元件審核會議」(如每季一次)，各部門帶各自負責的 cluster 元素到場校對。

• 版本演進與供應鏈動態變化的因應

本 G7 文件明文「The list of proposed minimum elements is open for further expansion」。組織不應把當前版本當定本——應訂閱 G7 Cybersecurity Working Group 的後續發布、追蹤 SPDX / CycloneDX 規格演進、關注 EU AI Office 的子法與指引發布。

報告說明

本分析僅為文件編撰過程的資料整理，不構成顧問專業意見。組織在規劃 EU AI Act、CRA 或其他合規路徑時，建議委請熟悉相關領域的專業人事，也歡迎來電聯繫台灣應用軟件顧問，提供專業建議。

本報告引用之公開資料以分析時點(2026 年 5 月)為準，G7 文件後續若有更新版本或補充指引，相關建議應據以調整。

對於本文件提及的攻擊統計數據(如 Hugging Face 模型汙染比例、AI 模型遭汙染至偵測平均 197 天)，原始來源為業界研究報告，僅供趨勢理解，組織內部風險評估應採用適用於自身情境的資料。