💡 先搞懂問題
做完 AI 風險評鑑與影響評估，手上會有一份排好優先順序的風險清單。接下來最常見的兩種失敗剛好相反。一種是清單做完就放著，沒有人決定要怎麼處理，風險還在原地；另一種是直接把附錄 A 的 38 項控制全部標成「適用、已實施」，再回頭替它們找風險，結果稽核員隨便抽一項問「這個控制是為了處理哪個風險？證據在哪裡？」就答不出來。
條文 6.1.3 AI 風險處理（AI risk treatment）要把這段路接起來：先依評鑑結果選擇處理選項，決定實施這些選項所需的全部控制；再把這些控制和附錄 A 比對，確認沒有漏掉必要的；接著產出適用性聲明（Statement of Applicability，SoA），交代哪些控制是必要的、為什麼納入、附錄 A 中被排除的控制為什麼排除、是否已經實施；最後擬定風險處理計畫，請指定的管理階層核准計畫與殘餘風險（residual risk，處理後仍留下的風險）。條文 8.3 再要求真的去實施，並驗證處理有沒有效。
生活比喻：社區診所對照衛生單位的建議清單
想像一家社區診所做完感染風險評估，發現候診區擁擠、器械消毒流程靠口頭交接。院長和護理長開會決定：候診區改成預約制（降低）、某些高風險的處置不再自己做，轉介給醫院（避免）、醫療糾紛另外投保（轉移），走廊盆栽可能積水這件小事就先接受。決定完之後，護理長拿出衛生單位發的感染管制建議清單，一條一條對照：有些項目診所已經做了，打勾並註明在哪份紀錄；有些項目正在做，寫上預定完成日；有些項目像是「負壓隔離病房管理」，診所根本沒有隔離病房，就寫下「本診所不收治需隔離的病人，轉介由合作醫院處理」。最後整份對照表和改善計畫一起交給院長簽名，院長也同時簽下「其餘的風險我們接受」。
比喻有兩處要注意。第一，衛生單位的清單常被當成「照做就好」的標準答案，42001 的附錄 A 卻不是窮舉清單：組織應該先從自己的風險出發決定控制，附錄 A 是拿來比對有沒有漏，組織也可以加入自己設計或來自其他框架的控制，這些同樣要寫進 SoA。第二，診所寫「沒有隔離病房」很直觀，AI 的排除理由卻常常沒那麼明顯：一家只用外部 API 的公司以為自己「沒有開發」，其實它組裝提示詞、接上資料、把系統放上線，系統層級的測試與供應商管理一樣跑不掉。排除要以自己的 AI 角色與風險評鑑結果為依據，而不是「感覺用不到」。
🎮 互動實驗室一：SoA 建置器
先選一個虛構組織，讀完它的 AI 角色、已經做到與還沒做到的事。接著替 12 項附錄 A 控制逐一決定「適用・已實施」「適用・規劃中」或「不適用」，再選一個理由。每一列選完會立刻檢查；全部填完後按「產生 SoA」，會列出示意的適用性聲明與抓到的常見錯誤。控制的說明是白話整理，不是標準原文。
🎮 互動實驗室二：處理選項分診與人類監督
每張卡片是一個已經評鑑過的 AI 風險情境。先選處理選項：降低（加控制讓可能性或後果變小）、避免（不做或改變用途）、轉移（透過合約或保險讓他方分擔後果）、接受（風險夠低，正式接受並記錄）。選完後，如果系統會繼續使用，再選人類監督的方式：人在迴路中、人在迴路上，或人在迴路外。
📘 原理補完
6.1.3 要求的四件事
條文 6.1.3 的邏輯和 ISO 27001 的 6.1.3 幾乎一樣，有 ISMS 經驗的人可以直接對照。第一，依風險評鑑結果選擇適當的處理選項。第二，決定實施這些選項所需的全部控制，並和附錄 A 比對，確認沒有遺漏必要的控制；附錄 A 不是窮舉清單，組織自己設計或取自其他框架的控制也可以，附錄 B 則是每項控制的實作指引。第三，產出 SoA，內容包括必要的控制、納入的理由、附錄 A 控制被排除的理由，以及是否已經實施；排除可以是因為風險評鑑認為不需要，或法規等外部要求沒有要求。第四，擬定 AI 風險處理計畫，並取得指定管理階層對計畫與殘餘風險的核准。42001 和 27001 最大的差別在比對的對象：42001 的附錄 A 是 38 項 AI 專屬控制，分布在 A.2 到 A.10 九個主題，各主題的數量依序是 AI 政策 3 項、內部組織 2 項、AI 系統資源 5 項、影響評估 4 項、AI 系統生命週期 9 項、AI 資料 5 項、給利害關係者的資訊 4 項、AI 系統的使用 3 項、第三方與客戶關係 3 項。
四種處理選項怎麼比
| 處理選項 | 做法 | AI 情境的例子（虛構） | 要注意的地方 |
|---|---|---|---|
| 降低 | 加控制，讓風險發生的可能性或後果變小 | 貸款評分的拒絕案件加人工覆核、監控群體誤拒率 | 最常用；控制要能被驗證有效，8.3 會追問 |
| 避免 | 不做這個活動，或改變用途讓風險消失 | 不上線用臉部影像推測情緒來決定優惠的功能 | 是正式選項，要留下決策紀錄；改變用途後要重新評鑑 |
| 轉移 | 透過合約、保險讓他方分擔後果 | 與 API 供應商約定故障賠償、投保錯誤回答的補償責任 | 轉出去的是財務後果，受影響者的傷害並沒有消失，常要搭配降低 |
| 接受 | 風險在準則內，正式接受並記錄 | 補貨 AI 偶爾多訂少量低價耗材 | 要由風險擁有者或指定管理階層核准，不是「沒處理」的代名詞 |
四種選項是實務上最常見的分法，ISO 31000 與 ISO/IEC 23894 的風險管理指引列得更細，例如移除風險來源、為了追求機會而承擔風險。標準沒有規定一定要用哪一套分類，組織在風險準則裡自行定義即可。
人類監督：三種常見位置
人類監督（human oversight）是讓人能理解、監看 AI 系統，必要時介入或停止它。42001 附錄 A 沒有一項控制直接叫這個名字，但它會出現在負責任開發的目標、系統需求與規格、負責任使用的流程與給使用者的資訊等地方，也是降低 AI 風險最常用的手段；歐盟 AI 法第 14 條則對高風險 AI 系統明確要求人類監督。下面三種說法是業界常用的分類，不是 42001 的正式用語。
| 監督方式 | 運作方式 | 適合的情境 | 常見陷阱 |
|---|---|---|---|
| 人在迴路中 human-in-the-loop | AI 提出建議，每一筆都要人確認才生效 | 單筆對個人影響重大、數量人力可以負荷，例如拒貸、記過 | 量太大時變成蓋章；要給覆核者看得懂的依據與推翻權限 |
| 人在迴路上 human-on-the-loop | AI 自動執行，人即時監看，能隨時中止或接手 | 量大、單筆影響較小，例如內容審核、瑕疵檢測、客服對話 | 監看指標與停機門檻要事先訂好，否則看了也不知道何時該停 |
| 人在迴路外 human-out-of-the-loop | AI 自動執行，人只在事後抽查或檢視報表 | 影響低、錯誤容易被發現與修正，例如內部摘要、固定格式快訊 | 不是「沒有監督」，仍要有定期檢視與異常時的處理方式 |
另外也常聽到「人在指揮（human-in-command）」，指由人決定什麼時候、用什麼方式使用 AI 系統，以及要不要停用，屬於更上層的治理安排。不論選哪一種，都要防範自動化偏誤（automation bias），也就是人太相信機器，不再仔細檢查。覆核紀錄裡的推翻比例是很好的觀察指標：長期接近零可能只是在蓋章，太高則可能代表模型不堪用（示意判讀，門檻由組織自訂）。
寫一份站得住的 SoA：步驟
- 先確認組織的 AI 角色（開發者、提供者、使用者等）與範圍內的 AI 系統清冊，這是判斷適用與否的基礎。
- 從風險處理決定出發，列出需要的控制，包括附錄 A 以外的自訂控制。
- 拿附錄 A 的 38 項逐一比對：已列入的寫明對應哪些風險或影響評估結論；沒列入的再想一次是不是漏了，確定不需要才寫排除理由。
- 每一列標出實施狀態，已實施的要指得出證據在哪裡，規劃中的要連到處理計畫的負責人與時程。
- 連同處理計畫送指定管理階層核准，核准殘餘風險；之後依 8.3 實施、驗證效果，SoA 跟著更新版本。
標準要求與組織自行決定
選擇處理選項；決定必要控制並與附錄 A 比對；SoA 要有必要控制、納入理由、排除理由與實施狀態；擬定處理計畫並取得管理階層對計畫與殘餘風險的核准；8.3 要實施計畫、驗證效果，無效或出現新風險時回到處理流程，並保存結果。
SoA 的格式（試算表、文件或系統）、處理選項的分類方式、核准層級由誰擔任、處理計畫用什麼工具管理、驗證效果的方法（測試、抽樣、監控指標或覆核推翻率）。和 27001 一起導入時，兩份 SoA 可以放在同一份文件的不同分頁。
常見誤解與稽核常見的不符合
附錄 A 全部適用最保險：全部標「適用、已實施」，稽核員會從中抽幾項要求看證據，拿不出來就是不符合；而且和自己的 AI 角色矛盾的項目一多，整份 SoA 的可信度都會被質疑。
排除只寫「不適用」：理由要連到 AI 角色、風險評鑑結果或外部要求。例如「本組織不訓練或微調模型，訓練資料相關控制由供應商負責，並透過 A.10.3 取得證據」，比「N/A」有說服力得多。
8.3 只確認「有做」：42001 的 8.3 比 27001 多強調了驗證處理是否有效，以及無效時回到處理流程。AI 控制特別容易名實不符，例如有人工覆核，但覆核者一天要看幾千筆。
稽核常見的不符合包括：SoA 缺實施狀態或理由；排除理由和 AI 角色判定互相矛盾；處理計畫沒有負責人和時程；殘餘風險沒有正式的核准紀錄；自訂控制沒有記錄在 SoA；SoA 版本和現場做法對不起來。
✅ 自我檢測
以下 6 題都是原創情境題，選完會立即顯示對錯與解析。目前得分：0 / 6