💡 先搞懂問題
生成式 AI 的使用門檻低到不需要 IT 部門幫忙：打開瀏覽器、登入個人帳號，就能把一份合約貼進去請它摘要。很多組織第一次意識到這件事，是在發現客戶名單、原始碼或未公告的財務數字已經被貼進外部服務之後。
常見的第一反應是發公告「全面禁止」。問題是禁令很難執行，員工會改用個人手機與個人帳號，組織從此完全看不到誰在用、用在哪裡。反過來完全放任，資料外流與 AI 產出錯誤以公司名義寄出的風險都沒人管。比較可行的路，是把規則講清楚：哪些用途可以、哪些資料能放進哪種工具、產出要由誰檢查、出事找誰。實務上這套規則常叫做可接受使用規範（acceptable use policy），搭配資料分級（data classification）與核准工具清單（approved tools list）一起運作。
生活比喻：公司的公務車
公司不會因為怕員工出車禍就禁止開車，因為業務總要拜訪客戶。比較常見的做法是訂一套公務車規則：要有駕照才能借，只能用在公務，車上不能載危險物品，用完要登記里程。想開自己的車去跑公務，得先申請並確認保險有涵蓋。萬一擦撞，不管多小都要回報總務，讓公司判斷要不要通知保險公司與對方。
這套規則的好處是大家都知道界線在哪：公務車隊是公司點名過、保過險的車；能載什麼有清楚的規定；發生狀況有固定的窗口。員工不必每次都去問主管「這樣可以嗎」，主管也能在出事時說清楚當初的規則是什麼。
比喻有兩個地方容易誤導。第一，公務車停在停車場、鑰匙在總務手上，看得見也管得住；AI 工具卻是在瀏覽器裡一開就能用，所以光有規則不夠，還需要教育訓練與技術措施（例如單一登入、資料外洩防護 DLP）配合，也要接受不可能百分之百攔住。第二，車禍通常一眼就看得出來，AI 出錯卻常常不明顯：它會用流暢又肯定的語氣講出錯誤的法條或數字，這種現象叫幻覺（hallucination）。因此規範裡的「人類審查」不是形式，而是唯一能接住這類錯誤的關卡。
🎮 互動實驗室一：這樣用可以嗎
每張卡片是一個原創的虛構情境。請參考旁邊的示意資料分級對照表（手機版在卡片下方），加上用途與產出怎麼處理，判斷這個用法是「允許」「有條件允許」還是「禁止」。答完會亮出對應的資料等級、工具類型、規範條款與相關控制。對照表是一家虛構組織的示意規則，實際分幾級、怎麼對應，由組織依風險自行決定。
示意資料分級對照表
🎮 互動實驗室二：AI 政策起草器
你是一家 200 人線上家居電商（虛構）的 AIMS 負責人，要起草「員工使用生成式 AI 規範」。勾選規範要涵蓋的要素，部分要素可以選擇寫法。旁邊的面板會即時檢查它和公司既有政策是否對齊（A.2.3，手機版在清單下方），最下面產生示意的規範大綱。清單裡混了兩個不建議放進去的選項，試著找出來。
與既有政策的對齊檢查（A.2.3）
🎮 互動實驗室三：AI 事故通報演練
同一家虛構電商的官網 AI 客服串接了外部大型語言模型 API。週五晚上，客服組長發現 AI 客服對幾位詢問延遲到貨的客戶回覆「我們將全額退款並加贈 500 元購物金」，這不是公司的補償政策。請從通報走到改善，每一步選出最合適的做法。每步只能選一次，選完會說明原因。
📘 原理補完
標準要求什麼，哪些是組織自己決定
ISO/IEC 42001:2023 沒有一條專門講「生成式 AI」的條文。員工使用生成式 AI，是用同一套 AI 政策、風險評鑑與附錄 A 控制來處理。下表把這頁用到的條文與控制整理在一起：中間一欄是標準期待的結果（用白話說明，不是條文原文），右邊兩欄是常見做法與 ISO 27001 的對照。常見做法都不是標準規定，組織可以依規模與風險調整。
| 主題 | 42001 依據 | 標準期待的結果（白話） | 常見做法（組織自行決定） | ISO 27001 對照 |
|---|---|---|---|---|
| AI 政策 | 條文 5.2、A.2.2 | 有一份經最高管理階層核定、對內傳達的 AI 政策，內容能真的指引 AI 的開發與使用 | 上位 AI 政策，下面再掛一份員工使用生成式 AI 的主題規範 | 條文 5.2、控制 5.1 |
| 和其他政策對齊 | A.2.3 | 找出會被 AI 影響的既有政策，讓說法一致、不互相矛盾 | 政策對照表；在 AI 規範中直接引用資安政策的資料分級 | 控制 5.1 的主題政策 |
| 政策審查 | A.2.4 | 依規劃的時間間隔，以及有需要時，檢視政策是否仍合適有效 | 每年一次並和管理審查同步，新法規或重大事故時另外審 | 控制 5.1 |
| 角色與責任 | 條文 5.3、A.3.2 | AI 相關工作有人負責，分派清楚 | 指定規範擁有者、工具清單擁有者、例外核准者、事故窗口 | 條文 5.3、控制 5.2 |
| 疑慮通報 | A.3.3 | 有一套流程讓人能對組織的 AI 用法提出疑慮，並有人處理 | 擴充既有申訴或事件通報管道，加 AI 類別、匿名選項與不報復承諾 | 控制 6.8（只涵蓋資安事件，範圍較窄） |
| 負責任使用 | A.9.2、A.9.3、A.9.4 | 定義負責任使用 AI 的過程與目標，並讓 AI 照預期用途使用 | 可接受使用規範、核准工具清單、人類審查、使用揭露 | 控制 5.10 可接受使用 |
| 供應商 | A.10.3 | 外部 AI 服務與模型的提供者，要符合組織負責任 AI 的做法 | 工具上清單前審查服務條款：輸入是否拿去訓練、存放地點、保留期間 | 控制 5.19～5.23 |
| 事故溝通 | A.8.4 | 事先決定並記錄 AI 事故發生時如何告知使用者 | 擴充事件管理程序、準備通知範本、做桌上演練 | 控制 5.24～5.28 |
資料分級本身多半沿用 ISMS 已有的分類（27001 控制 5.12）。42001 的 A.7 系列管的是 AI 系統開發與強化用的資料，只有當員工輸入的內容會被拿去訓練或改善組織自己的模型時，才會直接牽涉到 A.7；單純使用外部工具時，資料能不能輸入，主要是資訊分級、資訊傳遞（27001 控制 5.14）、個資保護與供應商管理的問題。
從零開始的做法
- 先盤點現況：員工實際在用哪些 AI 工具、用在哪些工作、輸入了哪些資料。匿名問卷加上網路與 SaaS 使用紀錄，通常比只問主管準確。
- 在條文 4.1 判定組織的 AI 角色。只使用外部工具的組織，角色主要是 AI 的使用方（客戶）；若把模型串進產品對外提供，角色就多了提供者，適用的控制也會變多。
- 把生成式 AI 的情境放進 AI 風險評鑑：資料外洩、幻覺造成的錯誤決策、提示注入（prompt injection，把指令藏在模型會讀取的內容裡操控它）、智慧財產爭議、過度依賴。
- 起草規範：用途界線、資料分級對應、核准工具清單、人類審查、智慧財產、通報與事故、例外申請、角色、審查週期，並逐份對照既有政策（A.2.3）。
- 評估工具並建立清單：審查服務條款與資料處理方式，每個工具標註可處理的資料等級，指定清單擁有者。
- 讓規範被執行：全員訓練與簽署、單一登入、資料外洩防護、瀏覽器或網路管控，並把 AI 類別加進疑慮通報與事件管理流程。
- 持續運作：定期檢視工具清單與通報案件，把事故與稽核發現帶進政策審查（A.2.4）與管理審查（條文 9.3）。
常見誤解
「42001 要求我們禁止或允許生成式 AI」：標準沒有規定要禁止或允許，它要的是組織依風險做出決定、寫下來、讓人知道並確實執行。全面禁止在條文上並不違規，但若禁令擋不住、組織又沒有發現，風險評鑑與控制就和現實脫節，稽核時一樣會被追問。
「用企業版就安全了」：企業版通常在合約中承諾不拿輸入訓練模型，也有帳號管理與紀錄，風險確實比較低，但它解決不了幻覺、智慧財產與個資目的外利用的問題。所以示意對照表裡，個人資料即使用企業版也不行，機密資料也只限指定工具。
「AI 事故就是資安事件」：資安事件是機密性、完整性、可用性受損；AI 事故還包括系統沒被入侵、照常運作，卻產生錯誤、有害或不公平結果的情況，例如實驗室三的錯誤補償承諾。兩者可以共用一套事件管理程序，但事故定義、分級與使用者通知要擴充。
稽核常見的不符合
第一類是規範和實際對不上：政策寫「僅能使用核准工具」，但清單沒有擁有者、半年沒更新，網路紀錄顯示大量使用清單外的服務。第二類是只有公告、沒有措施：一紙「禁止輸入機密」，沒有訓練紀錄、沒有技術控制，訪談時員工說不出哪些資料不能貼。第三類是政策互相打架：AI 規範和個資政策對資料用途的說法矛盾，或 AI 規範另訂一套分級，和資安政策對不起來（A.2.3）。第四類是事故流程沒涵蓋 AI：模型輸出錯誤造成客戶損失，卻被當成一般客訴處理，沒有原因分析，也沒有通知使用者的計畫（A.8.4）。第五類是審查流於形式：政策版本頁只改了日期，看不出審查時考慮了哪些輸入（A.2.4）。
對照 ISO 27001 的經驗會發現很多地方似曾相識：可接受使用（控制 5.10）、資訊分級（5.12）、事件管理（5.24 起）都是現成的骨架。差別在 AI 的錯誤不一定來自攻擊，而且結果的對錯不容易被肉眼看出，所以人類審查與疑慮通報的分量比一般資安規範重。
✅ 自我檢測
以下 6 題都是原創題目，單選題點選後立即顯示解析，複選題選好後按「送出」。目前得分：0 / 6