💡 先搞懂問題
有 ISO 27001 經驗的團隊做 AI 風險評鑑，最順手的做法是打開既有的風險矩陣：列出資產、威脅、弱點，評估機密性、完整性、可用性受損時「對公司」有多嚴重。這張表抓得到模型檔被偷、推論服務當機，卻抓不到另一類問題：貸款評分模型系統性地給某些族群較低分數、生成式客服很有自信地講錯退費規則、自動篩選把某一群求職者排在最後。這些事件裡，公司的損失可能很小，真正受傷的是組織外面的人，所以在只看組織損失的矩陣上，它們常被排在很後面，甚至根本沒列出來。
ISO/IEC 42001 的 6.1.2 AI 風險評鑑（AI risk assessment）就是為這個缺口設計的。它沿用和 27001 相似的三步驟：識別風險、分析後果與可能性、對照準則評估排序；關鍵差別在分析後果時，要評估風險發生時對組織、對個人以及對社會的潛在後果，並在適用時參考 6.1.4 AI 系統影響評估的結果。識別風險時，附錄 C 列出的 AI 風險來源（risk source，可能引發風險的根源）是很好用的檢核表。
生活比喻：餐廳要不要推出生蠔拼盤
一家海鮮餐廳的老闆在考慮夏季推出生蠔拼盤。他先算自己的帳：進貨成本、壞掉要報廢多少、萬一有客人抱怨要退幾桌錢、評價會不會掉。算下來最壞也就是賠一點錢，看起來可以做。
但老闆少算了兩本帳。第一本是客人的：生食海鮮一旦處理不當，吃的人可能腸胃炎送急診，孕婦或免疫力較弱的客人風險更高，這些後果落在客人身上，不會出現在餐廳的損益表上。第二本是更外面的：如果整條街的餐廳都搶著推生蠔，附近養殖場可能過度採收；一旦爆發集體食物中毒，整個夜市的生意和大家對生食的信任都會受影響。把這兩本帳也算進去，同一道菜的風險等級就可能從「可以做」變成「要先加強冷藏與標示，並且不提供給高風險客人」。
比喻有兩個地方要小心。餐廳的傷害多半看得見，有人送急診馬上就知道；AI 造成的傷害常常是隱形又分散的，每個人只吃一點虧，或某個群體長期被系統性地排在後面，沒有人會打電話來抱怨。其次，標準並沒有規定一定要畫三張矩陣或用三個分數，怎麼把三層後果合併進評分，是組織在風險準則和方法裡自己決定的事；它要求的是這三個層面都要被評估到。
🎮 互動實驗室一：風險來源偵探
下面是兩個虛構 AI 系統的描述，畫黃色虛線的句子都是線索。先點一句線索，再點下方的風險來源分類，判斷它屬於附錄 C.3 的哪一類；有些線索其實是一般的資安或營運事項，不是 AI 特有的風險來源。每個案例有 8～9 條線索，答完會說明判斷理由，統計區會顯示這個系統的風險來源集中在哪裡。
🎮 互動實驗室二：三層後果矩陣
選一個風險情境。滑桿一開始只填了「可能性」與「對組織的後果」，也就是只看組織時的評分；請再依你的判斷拉動「對個人或群體」與「對社會」的後果（1～5，數字皆為示意），看矩陣上的點怎麼移動、風險等級是否改變。下方可以切換三層後果的合併方式，比較「取最高值」和「取平均」的差別。
（常見的資安做法）
（6.1.2）
📘 原理補完
AI 風險評鑑和資安風險評鑑差在哪裡
兩者共用同一套管理系統骨架，6.1.2 的步驟也很相似，已經有 ISMS 的組織可以沿用評分框架與文件格式。真正要擴充的是下面幾欄。
| 比較項目 | ISO 27001 資安風險評鑑 | ISO 42001 AI 風險評鑑 |
|---|---|---|
| 關心的問題 | 資訊的機密性、完整性、可用性會不會受損 | AI 系統會不會妨礙組織的 AI 目標，例如公平、透明、穩健、安全、可問責 |
| 後果看誰 | 以對組織的衝擊為主 | 對組織、對個人與對社會的潛在後果都要評估 |
| 常見風險來源 | 威脅與弱點：惡意程式、設定錯誤、人為疏失 | 附錄 C.3：自動化程度、機器學習特性、可解釋性不足、環境複雜度、生命週期與技術成熟度、硬體 |
| 和影響評估的關係 | 沒有對應條文 | 適用時參考 6.1.4 影響評估的結果，影響評估再透過 8.4 實際執行 |
| 方法參考 | ISO/IEC 27005 等 | ISO/IEC 23894（以 ISO 31000 為基礎），附錄 C 可當檢核表 |
| 相同的地方 | 都要事先訂好準則、方法要能產生一致且可比較的結果、要保存評鑑過程與結果的文件化資訊，並在規劃的間隔與重大變更時重新執行 | |
6.1.2 的流程與誰決定什麼
- 標準要求 先有 AI 風險準則（6.1.1）：用來區分可接受與不可接受的風險，並支撐評鑑、處理與影響評估。組織決定 準則分幾級、用矩陣還是門檻值、風險胃納高低。
- 標準要求 識別風險：找出可能幫助或妨礙達成 AI 目標的風險。常見做法 拿附錄 C.3 當檢核表，沿著生命週期逐段問「這裡可能出什麼錯、會傷到誰」。
- 標準要求 分析風險：評估風險發生時對組織、個人與社會的潛在後果，適用時參考影響評估結果，並評估實際的可能性，決定風險等級。組織決定 三層後果怎麼合併成一個等級。
- 標準要求 評估風險：對照準則，排出處理的優先順序，結果交給 6.1.3 風險處理。
- 標準要求 保存 AI 風險評鑑過程的文件化資訊；8.2 再要求依規劃的間隔、以及有重大變更被提出或發生時實際執行並保存結果。組織決定 間隔多久、什麼算重大變更。
實驗室二的「取最高值」和「取平均」就是第 3 步「組織決定」的例子。標準沒有規定合併方式，但平均法有一個陷阱：對個人的嚴重後果會被組織面與社會面的低分稀釋，最後被評成可接受。常見的補救做法是取最高值，或在準則裡預先畫出紅線，例如「對個人有重大影響、又沒有人工覆核的自動化決定，處理前一律不可接受」。
附錄 C.3 的風險來源
附錄 C 是參考性附錄，清單不是全部，也不必逐項寫進 SoA，但很適合拿來避免漏看 AI 特有的問題根源。下表按條號列出，本頁把 C.3.6 與 C.3.7 合併成一類練習。
| 條號 | 風險來源 | 白話說明 | 常見的處理方向（附錄 A 相關控制） |
|---|---|---|---|
| C.3.1 | 環境複雜度 Complexity of environment | 運作環境越開放多變，越難預見所有情況 | 定義運作範圍、擴大測試情境、超出範圍時拒答或轉人工（A.6.2.2、A.6.2.4、A.9.4） |
| C.3.2 | 透明度與可解釋性不足 Lack of transparency and explainability | 說不出系統怎麼運作、為何得出某個結果 | 技術文件、事件紀錄、對使用者的說明（A.6.2.7、A.6.2.8、A.8.2） |
| C.3.3 | 自動化程度 Level of automation | AI 輸出到實際後果之間沒有人類關卡 | 設計人類監督、可撤回機制（A.9.2、A.9.4、A.6.2.2） |
| C.3.4 | 機器學習相關 Machine learning | 資料品質、資料來源、持續學習、漂移 | 資料控制與上線後監控（A.7.2–A.7.6、A.6.2.6） |
| C.3.5 | 系統硬體問題 System hardware issues | 感測器、運算資源、邊緣裝置的故障與限制 | 硬體需求、校正維護、在目標硬體上重新驗證（A.4.5、A.6.2.5） |
| C.3.6、C.3.7 | 生命週期問題與技術成熟度 Life cycle issues, Technology readiness | 流程沒走完，或採用尚未成熟的新技術 | 關卡審查、上線核准、新技術限縮使用範圍（A.6.1.3、A.6.2.2–A.6.2.8） |
方法上，ISO/IEC 23894 是常見的參考。它沿用 ISO 31000 的風險管理流程，再補上 AI 特有的風險來源與生命週期的對應，同一份風險來源清單也出現在它的附錄。它是指引，不提供固定的矩陣或計分公式，也不能拿來驗證；稽核時判定依據仍是 42001 本身。
常見誤解
「個人與社會的後果是影響評估的事，風險評鑑只看公司。」6.1.2 本身就要求分析對組織、個人與社會的後果，影響評估的結果是輸入，而不是取代。兩者各做各的、結論沒有交會，是很常見的稽核發現。
「用外部模型，風險就是供應商的。」模型是別人的，但使用情境、自動化程度與受影響的人是自己的。拿不到外部模型的必要資訊，本身就是透明度不足的風險來源，要列進清單並透過供應商管理處理。
「做一次就好。」模型重新訓練或更換、使用族群擴大、資料來源或部署環境改變、新法規上路、發生重大事故，都可能讓原本的評鑑失效，而且重新評鑑應該在變更上線之前完成。
稽核常見的不符合
稽核員通常會抽一個 AI 系統，請負責人說明風險怎麼識別、後果與可能性怎麼評分、有沒有引用影響評估的結果。常見的不符合包括：直接沿用 ISMS 的資產、威脅、弱點表，後果欄完全沒有對個人或社會的影響；每個系統的風險清單一模一樣，明顯是複製貼上；不同團隊用不同的尺度評分，結果無法比較；風險清單和 AI 系統清單對不起來；模型改版多次，風險評鑑日期卻停在導入那一年；以及準則只有分數沒有接受門檻，或高風險項目沒有由準則指定的層級核准。
✅ 自我檢測
以下 6 題都是原創情境題。單選題點選後立即批改；標示「複選」的題目選好後按「送出這題」。目前得分：0 / 6