在正式進入對照之前，有個名詞要先講清楚：數位發展部這套框架的正式名稱是《人工智慧風險分類框架》——是「分類」，不是「分級」。這個用字差異不是文字遊戲：數發部政務次長侯宜秀在公開場合特別強調過，台灣的設計刻意採用「分類」而非「分級」概念，這正是跟歐盟 AI 法案（採風險分級監管）的關鍵差異之一。如果你在簡報或文章裡寫成「風險分級框架」，內行的聽眾會覺得你沒讀過原始文件。
這套框架已於 2026 年 7 月 7 日正式發布並生效，依據《人工智慧基本法》第 16 條訂定，核心呈現形式是一份「AI 風險管理措施檢核表」，供各目的事業主管機關訂定 AI 風險管理規範之用，同時也是產業界理解台灣 AI 風險治理體系的參考文件。
框架把 AI 風險分成 3 大類、共 20 項子類別：
| 類別 | 內容重點 | 子類別數 |
|---|---|---|
| A 類：AI 系統本身之技術設計缺陷 | 安全漏洞、透明性不足、行為偏離意圖、危險能力、隱私保護、智財侵害、歧視偏見、錯誤訊息 | 8 項（A1-A8） |
| B 類：部署後操作及人機互動問題 | 過度依賴、喪失人類自主性、生成違法內容、詐欺深偽、網路攻擊、Agent 授權外行為 | 6 項（B1-B6） |
| C 類：社會結構與環境衝擊 | 競爭秩序失衡、權力集中、不平等加劇、創作價值受損、環境傷害、認知作戰與資訊主權 | 6 項（C1-C6） |
框架本身是原則性、方法論層級的文件，不會告訴你「該用哪個 GCP 服務」。這一步的對照，是把官方風險項目落地成具體技術控制：
| 官方風險項目 | 對應 GCP Security 控制 | 對應本系列篇目 |
|---|---|---|
| A5 隱私與個資保護 | Sensitive Data Protection（原 Cloud DLP，資料掃描遮罩）、VPC Service Controls（邊界圈定） | Week 3 |
| A1 安全漏洞與攻擊 | IAM 最小權限、Cloud Armor、Model Armor | Week 2、Week 4 |
| B1 過度依賴與不安全使用 | IAM Approval 流程、人工審核機制設計 | 主題二 Week 4 |
| B6 AI 自主代理之授權外行為 | Workload Identity、IAM Conditions、Agent 權限分層 | 主題二全系列 |
| A2 缺乏透明性／可解釋性 | Cloud Audit Logs、Google SecOps（原 Chronicle）可觀測性 | Week 5 |
官方框架給的是「你該盤點哪些風險」，不會給「你該怎麼技術落地」。這中間的落差，正是企業資安團隊（尤其是想申請 GCP Security GDE 認證的技術人）能發揮價值的地方——把原則性風險項目，轉譯成可以實際部署、可以稽核驗證的技術控制清單。可以落地在企業級的部署正是本主題的價值，Week 5 會有一篇完整的合規對應總表，把整個系列 30 篇的技術內容，逐項扣回這張官方風險分類表。
iThome鐵人賽
看影片追技術