📝 本系列為 iThome 鐵人賽學習筆記，屬個人教學與非商業用途；文中法規與標準內容均以自身理解後的話轉述並註明出處，非逐字引用。
階段二｜誰在管、用什麼管：制度與標準
Day 10 把 ISO/IEC 42001 主體條款第 4 到 10 章走了一遍。今天要停在其中最具「AI 特色」、也最容易被低估的一格——第 6 章的規劃，特別是它的風險評鑑，並搭配附錄 C 的「AI 風險來源」一起看。
先問一個問題，這個問題會決定你今天能不能抓到重點：當你在評估一個 AI 系統的「風險」時，你評估的是「這個系統可能對我（組織）造成什麼損害」，還是「這個系統可能對別人（使用者、社會）造成什麼傷害」？
大多數工程師的直覺是前者——這是傳統資訊安全（以下簡稱資安）的思維：保護「我方」的資產。但 42001 要求你同時看後者。這個「向內」與「向外」兩種視角的並存，正是 42001 風險觀最關鍵、也最反直覺的地方。今天就把這個區分講清楚。
依慣例先交代寫法：以下對第 6 章與附錄 C 的說明，都是解讀其用意與架構，僅沿用官方的章節編號與標題；不逐字引用、不翻譯規範條文，也不照抄附錄 C 的清單。想看完整清單與細節，請取得標準正本。
這是今天的核心觀念，值得用一整段講清楚。
第一種：資安風險（向內看）。 這是傳統 ISO 27001（資訊安全管理系統）的主場——評估「什麼事件可能損害『組織自己』的資產」。例如：模型被竊取（智慧財產損失）、服務被攻擊癱瘓（營運中斷）、資料庫外洩（商譽與法律損失）。這裡的受害者是組織，問的是「什麼會傷害到我們」。
第二種：AI 對個人與社會的衝擊（向外看）。 這是 42001 特別加進來、27001 沒有的視角——評估「這個 AI 系統一旦運作，可能對『系統外的人與社會』造成什麼後果」。例如：招聘 AI 對特定族群系統性不利（歧視）、醫療 AI 誤判延誤治療（人身安全）、生成式 AI 大量產出不實內容（資訊環境汙染）。這裡的受害者是使用者與社會，問的是「我們的 AI 會不會傷害到別人」。
上圖把這兩種視角並排在一起：一邊向內看組織資產，一邊向外看個人與社會。為什麼這個區分如此重要？因為一個系統可以「對組織很安全」，卻「對社會很危險」。 一個信用評分 AI，資安做得滴水不漏（沒人駭得進去、資料不外洩），但它系統性地拒絕某個族群的貸款——對組織零風險，對社會卻是嚴重的歧視傷害。傳統資安完全看不到這個問題，因為它只向內看。42001 逼你也向外看，這正呼應了 Day 8 談的基本法七大原則裡的「公平與不歧視」「人類自主」——那些原則保護的都是「系統外的人」。
理解了兩種視角，再來看第 6 章怎麼把它們制度化。第 6 章（規劃）是 PDCA 的第一步（Plan），它要求組織針對 AI 做幾件事。這一章的結構如下圖所示，包含的幾個細項逐一來看：
這裡有一個實務上很重要的分工，值得記住：「風險評鑑」與「衝擊評鑑」的執行，標準把它拆在兩個地方——第 6 章負責「定義方法與規劃」，實際的「執行」則在第 8 章（運作）。也就是說，你在第 6 章決定「要怎麼評」，在第 8 章真正「動手評」。這個「先定方法、再執行」的設計，是為了讓評估可重複、可稽核。
「AI 風險評鑑與處理」聽起來抽象，但它其實就是一套標準的風險管理動作，套用到 AI 上。用白話拆解成四步，如下圖所示（要留意術語：前三步「識別、分析、評估」合起來才叫「風險評鑑」，第四步「處理」是獨立的下一步）：
這四步對做過資安的人並不陌生——它和 27001 的風險管理流程是同一套。42001 的差別不在「流程」，而在「評估的對象要包含 AI 特有的風險，而且要向外看社會衝擊」。這也是為什麼第 6 章需要一份「AI 特有的風險提示」來幫助組織不要漏掉——那就是附錄 C。
附錄 C 屬「參考」（informative）性質——僅供參考、非強制，與附錄 A 的「規定」（normative）性質相對（兩種性質的區分見 Day 9 的文件地圖）。它的作用，是提醒組織「評估 AI 風險時，有哪些 AI 特有的面向容易被忽略」，避免大家只用傳統資安的角度去想。
如上圖所示，它的結構是從兩個角度提示：一是組織可能追求的 AI 目標（例如可歸責性、公平、透明與可解釋、環境衝擊等；其中「可歸責性（accountability）」就是 Day 8、Day 10 說的「問責」——出事時有人負責、且能追溯），二是可能的風險來源。
以下舉幾個代表性的「風險來源」面向，幫助你抓到它在提醒什麼。這不是附錄 C 的完整清單，也不是原文——只是幾個示意，完整內容請見標準正本：
這份清單的價值，在於它把「AI 之所以危險的那些特有原因」列出來，當作評估時的檢查提示。搭配它，組織做風險評鑑時就不會只盯著傳統資安，而會記得問「這個 AI 會不會因為黑箱、因為資料、因為自動化，而傷害到別人」。
42001 是「管理制度」的標準，它告訴你「要做風險評鑑與衝擊評鑑」，但沒有把「怎麼做」講到最細。這時候，兩個姊妹標準就派上用場。三者是設計來搭配使用的，分工如下圖所示：
用一個比喻：42001 是「這棟大樓要有消防系統」的規定，23894 是「消防系統怎麼設計」的手冊，42005 是「怎麼評估火災對周邊社區的影響」的專門指南。導入時，通常以 42001 為主幹，需要方法細節時再參考另外兩者。（這三份同樣受著作權保護，本系列一律只說明它們的定位與分工，不引用內文。）
把今天的觀念，投影到本系列的檢索增強生成（Retrieval-Augmented Generation，以下簡稱 RAG）客服範例，會長出兩份不同的評估：
向內看——資安風險評鑑（這個 RAG 系統可能被怎麼攻擊、傷害到我方）：
向外看——AI 系統衝擊評鑑（這個 RAG 系統可能對使用者與社會造成什麼後果）：
這裡的差別很清楚：同一個 RAG 系統，向內看與向外看，得到的是兩張完全不同的風險清單。第四階段（Day 21–30）我們實作的每一道防禦，其實都在回應這兩張清單的其中幾項——這也是為什麼稍後每一段防禦程式，都能對回 42001 的某一條要求。
今天深入了 42001 第 6 章的風險觀，核心是一個視角的切換：
明天（Day 12）進入 42001 最實務、也最多人關心的部分——附錄 A 的控制措施。 前面談的都是「管理流程」，明天要看「具體要做哪些控制」。我會用「這條控制的目的是什麼、可以落地成什麼樣的政策與技術證據」的方式逐組拆解，並嚴守不照抄控制清單原文的分際，把附錄 A 對映到本系列後面的技術實作。
iThome鐵人賽
看影片追技術