💡 先搞懂問題
有 ISO 27001 經驗的人做風險評鑑，習慣問「這件事發生了，對公司有多糟」：營收掉多少、會不會被罰、商譽受不受損。這套問法用在 AI 系統上會漏掉一大塊。一個履歷篩選模型對公司來說只是「偶爾淘汰錯幾個人」，對被淘汰的求職者卻是整個工作機會；一個貸款評分模型的誤判率在報表上很低，卻可能集中落在沒有信用紀錄的年輕人身上。這些傷害不會出現在公司的損益表上，用組織的角度評分，很容易被打成低風險，甚至根本沒被列出來。
ISO/IEC 42001 因此多了一條 27001 沒有的條文：6.1.4 AI 系統影響評估（AI system impact assessment）。組織要建立一套過程，評估 AI 系統在開發、提供或使用時，可能對個人、群體與社會造成的後果，把結果寫下來，並且拿回去作為 6.1.2 AI 風險評鑑的輸入。條文 8.4 再要求依規劃的時機、以及有重大變更被提出時，真的去執行並保存結果。
生活比喻：蓋一座大型購物中心
想像一家開發商要在住宅區旁邊蓋大型購物中心。開發商自己一定會算帳：工期會不會拖、成本會不會超支、開幕後能不能回本。這些是開發商的風險。可是住在旁邊的人在乎的完全是另一回事：週末會不會塞到出不了巷口、小孩上學的路會不會變危險、巷口那幾家小吃店會不會撐不下去。所以這類開發案通常還要做交通影響評估，把「誰會受影響、影響多大、怎麼減輕」寫成報告，評估結果常常回頭改變設計，例如多開一個停車場出口、加設行人號誌。開幕後車流跟預估差很多，還得再檢討一次。
這個比喻有兩個地方要小心。第一，交通影響評估多半要送主管機關審查，42001 的影響評估則是組織依自己的 AIMS 執行，標準本身沒有要求送審；但如果你的系統受法規規範（例如歐盟 AI 法對特定高風險系統部署者的基本權利影響評估），法規另有規定。第二，購物中心蓋好之後很少大改，AI 系統卻可能每個月換一次模型、擴大一次使用對象，所以重新評估的觸發條件比固定週期更重要。另外，42001 的風險評鑑本來就要考慮對個人與社會的後果，影響評估不是另起爐灶，而是把這部分專門、深入地做一遍，再交回風險評鑑。
🎮 互動實驗室一：影響評估工作坊
先選一個虛構的 AI 系統，接著依序走過五個步驟：初篩是否需要完整評估、找出受影響的對象、評估正負面影響、決定緩解措施與人類監督、核准與重新評估時機。每一步選完都會說明理由，走完後會產生一份示意的影響評估摘要。選項的位置每次都會打亂。
🎮 互動實驗室二：風險評鑑 vs 影響評估分診
每張卡片是一個在導入現場會被提出的問題或任務。請判斷它主要該放進哪一項活動：6.1.2 風險評鑑（站在組織角度：對組織、對達成 AI 目標有什麼後果）、6.1.4 影響評估（站在受影響者角度：對個人、群體、社會有什麼後果），還是兩者都要（同一件事兩邊都有明顯後果，或屬於重大變更，兩種評估都要更新）。
📘 原理補完
條文與附錄 A 怎麼分工
影響評估在 42001 裡出現在三個地方，讀的時候要放在一起看。條文 6.1.4 屬於規劃，要求組織定義影響評估的過程：評估 AI 系統的開發、提供或使用，可能對個人或群體、以及社會造成的潛在後果；評估時要考慮系統部署所處的技術與社會情境，以及適用的司法管轄區；結果要文件化，組織可以視情況提供給相關的利害關係者，並且要在 6.1.2 的風險評鑑中考慮。條文 8.4 屬於運作，要求依規劃的間隔、以及有重大變更被提出時實際執行，並保存結果。附錄 A 的 A.5 有四項控制：A.5.2 建立評估流程（何時做、誰做、結果怎麼用）、A.5.3 把評估結果文件化並保存一段由組織定義的期間、A.5.4 評估對個人或群體的影響、A.5.5 評估對社會的影響。
| 比較項目 | 6.1.2 AI 風險評鑑 | 6.1.4／8.4 AI 系統影響評估 |
|---|---|---|
| 主要問題 | 哪些風險會幫助或妨礙達成 AI 目標？發生時後果多大、可能性多高？ | 這個系統會影響誰？可能造成什麼正面與負面的後果？ |
| 站的位置 | 以組織為中心，後果分析也要涵蓋對個人與社會的後果 | 以受影響者為中心，專門而深入地看個人、群體與社會 |
| 典型輸出 | 風險清單、風險等級、處理優先順序 | 受影響對象清單、影響描述、緩解建議、核准與重評時機 |
| 兩者關係 | 要把影響評估結果當成輸入 | 結果回到風險評鑑與風險處理，變成控制與 SoA 的依據 |
| 和 27001 的對照 | 結構類似 27001 的 6.1.2，但風險類型要擴充到偏差、可解釋性、誤用等 | 27001 沒有對應條文，是 42001 最有特色的要求之一 |
| 方法參考 | ISO/IEC 23894（AI 風險管理指引） | ISO/IEC 42005:2025（AI 系統影響評估指引） |
一次完整影響評估的執行步驟
下面是常見做法的順序，和工作坊的五步驟相同，只是多了前後兩端。標準沒有規定一定要這樣排，也沒有規定表格格式、評分方式或要評多深，這些由組織在 A.5.2 的流程裡自行決定。
- 從 AI 系統清冊出發，用初篩問卷（例如是否影響個人權益、是否自動化決定、是否涉及弱勢族群、受影響者能否申訴）判斷要做完整評估還是簡式檢核，並把初篩結果留下來。
- 描述系統：預期用途、可合理預見的誤用、使用的資料與模型、部署情境、適用的法規與地區。
- 列出受影響的對象：直接使用者、被系統判斷的人、間接受影響的人（例如被 AI 監看工作表現的員工），以及可能被放大影響的社會面向。
- 評估正面與負面影響，必要時把模型表現按群體拆開來看，不只看整體平均。
- 提出緩解措施與人類監督安排，送進風險評鑑與風險處理，決定要採用哪些控制。
- 由跨部門審查、指定的管理階層核准，文件化並依 A.5.3 保存；決定要不要、以及如何告知相關利害關係者。
- 訂出重新評估的觸發條件：更換模型或資料來源、用途或使用對象改變、部署到新地區、法規改變、發生影響個人的事故或收到申訴，再加上規劃的定期檢視。
標準要求與常見做法要分清楚
要有定義好的影響評估過程；要考慮個人或群體與社會的後果、技術與社會情境、司法管轄區；結果要文件化並納入風險評鑑；依規劃與重大變更時執行並保存結果。附錄 A.5 的控制則依 SoA 決定是否適用。
初篩問卷的題目與門檻、評估範本、評分方式、參與角色、核准層級、文件保存多久、多久定期重評、是否對外公開評估摘要。ISO/IEC 42005:2025 提供這些面向的指引，但它是指引，不能拿來驗證，採用與否由組織決定。
常見誤解與稽核常見的不符合
把資安風險評鑑當成影響評估：資安風險評鑑以資訊的機密性、完整性、可用性為核心，不會自動涵蓋公平、歧視、自主或取得服務的機會，拿它充數，稽核員一問「哪些群體可能受到不利影響」就答不出來。
把 DPIA 當成影響評估：個資保護影響評估（DPIA，Data Protection Impact Assessment）聚焦個人資料處理對隱私的風險；AI 系統影響評估範圍更廣，包含公平、安全、透明與社會影響。兩者可以共用範本與資料，但不能互相取代。歐盟 AI 法第 27 條的基本權利影響評估（FRIA）是特定高風險系統部署者的法定義務，同樣可以共用資料，適用範圍與時程以歐盟官方公告為準。
只評估自己開發的系統：採購來、直接面對客戶的 AI 服務，影響一樣落在你的客戶身上。供應商的評估可以當輸入，但用在你的情境、你的使用者身上，評估責任還在你。
稽核常見的不符合包括：只有程序但沒有任何一份實際評估紀錄；評估只寫「本系統不涉及歧視」卻沒有資料或分析支撐；評估沒有日期與版本，對不到目前上線的系統；更換底層模型或擴大使用對象後沒有重評；評估結論和風險清單、SoA 對不起來；所有系統的社會影響欄位都寫「無」。
✅ 自我檢測
以下 6 題都是原創情境題，選完會立即顯示對錯與解析。目前得分：0 / 6