📝 本系列為 iThome 鐵人賽學習筆記，屬個人教學與非商業用途；文中法規與標準內容均以自身理解後的話轉述並註明出處，非逐字引用。

階段二｜誰在管、用什麼管：制度與標準

昨天給了地圖，今天走一遍

Day 9 為 ISO/IEC 42001 做了導論：它是一套 AI 管理系統（AI Management System，以下簡稱 AIMS）標準，靈魂是 PDCA（Plan-Do-Check-Act）持續改善循環，主體條款落在第 4 到 10 章。今天要做的，就是帶著這張地圖，把第 4 到 10 章實際走一遍——每一章要求組織建立什麼、要產出哪些文件、以及導入時最常見的盲點。

照本系列處理標準的慣例：以下對每一章的說明，都是解讀它的「用意」與「要求的方向」，並使用章節的官方編號與標題（這屬於事實）；不逐字引用、也不翻譯標準的規範條文。條款的官方繁中標題，採台灣國家標準 CNS 42001 的用語。

先建立一個整體印象。第 4 到 10 章其實分成兩個部分：

• 第 4、5 章是「打地基」：在 PDCA 循環正式轉動之前，先把「組織的處境」和「領導的承諾」定下來。
• 第 6 到 10 章才是「PDCA 循環」本體：規劃（6）→ 執行（7、8）→ 查核（9）→ 改善（10），然後周而復始。

（嚴格說，傳統上第 4 到 6 章常一併歸入 Plan；本文把第 4、5 章獨立成「地基」，是為了凸顯它們在循環啟動「之前」的定位，讓層次更清楚。）

上圖把這個「先打地基、再轉循環」的關係畫了出來。以下就依這個順序走；每一章除了說明「要求你建立什麼」與「要產出的文件」，也會點出導入時最容易忽略的「常見盲點」。

打地基：第 4、5 章

第 4 章：組織之全景

• 要你做什麼：先看清楚自己的處境。組織要釐清「內外部有哪些因素會影響 AI 治理」（例如所屬產業的法規、客戶期待、技術能力），盤點「有哪些關注方（interested party，即利害關係人）、他們對你的 AI 有什麼需求與期望」，然後據此決定 AIMS 要涵蓋的範圍——是整間公司、某個部門、還是某一個 AI 產品線。
• 要產出的文件：AIMS 的範圍說明、利害關係人與其需求的盤點。
• 常見盲點：範圍畫得太大（一口氣把全公司納入，導入負擔過重）或太小（把關鍵的 AI 系統排除在外，證書含金量打折）。範圍的拿捏，是導入成敗的第一個關卡。

第 5 章：領導作為

• 要你做什麼：這一章的核心是「高層要真的扛起來」。管理階層必須展現承諾、制定一份明確的 AI 政策（宣示組織治理 AI 的原則與方向），並指派清楚的角色與權責——誰負責風險、誰負責稽核、誰負責核准。
• 要產出的文件：AI 政策、角色與權責的分工。
• 常見盲點：高層「只簽字、不參與」，AI 政策淪為貼在牆上的口號。42001 特別強調領導的實質投入，因為沒有高層授權與資源，底下的流程都推不動。這一點呼應了 Day 8 七大原則裡的「問責」——責任要有人真正承擔。

Plan：第 6 章 規劃

• 要你做什麼：這是 PDCA 的第一步。組織要評估 AI 帶來的風險與機會並規劃因應行動、為 AI 治理設定可衡量的目標、並規劃當系統或需求變更時該怎麼管。這一章裡，42001 開始展現它和一般管理標準不同的地方——它要求你認真面對 AI 特有的風險。
• 要產出的文件：風險評鑑的結果、風險處理計畫、AI 目標與達成計畫。
• 與 RAG 的連結：把本系列的檢索增強生成（Retrieval-Augmented Generation，以下簡稱 RAG）客服當作被治理的 AI 系統，這一章就是要你回答「這個系統可能出什麼錯（提示注入？資料外洩？幻覺？）、我打算怎麼處理、我要達成什麼安全目標」。
• 常見盲點：風險評鑑「做一次、擺著看」，與實際運作的系統脫節。風險是會變的，這也是為什麼它被放進「持續循環」而非「一次性專案」。（第 6 章的 AI 風險評鑑與衝擊評鑑，是明天 Day 11 的主題，會深入談。）

Do：第 7 章 支援、第 8 章 運作

Do（執行）分成兩章：第 7 章準備「資源」，第 8 章進行「實作」。

第 7 章：支援

• 要你做什麼：提供讓制度能運作的後勤——足夠的資源、人員的適任性（能力）與認知（讓大家知道政策與自己的責任）、內外部的溝通，以及登載之資訊的管理。
• 關於「登載之資訊」：這是 42001（乃至所有 ISO 管理系統標準）的專有名詞，白話說就是「制度要求你留存、控管的文件與紀錄」。它涵蓋兩類：一是「該有的文件」（政策、程序），二是「做過的證據」（紀錄、日誌）。第 7 章要求你管好這些文件的建立、更新與存取控制。
• 常見盲點：文件「為稽核而生」——寫了一大疊沒人看、與實際做法對不上的文件。好的登載之資訊應該是團隊真的在用的，而不是稽核前臨時補的。

第 8 章：運作

• 要你做什麼：把第 6 章的規劃，落實到日常營運與 AI 系統的生命週期。這一章包含幾個 AI 特有的重點：AI 風險評鑑與AI 風險處理的實際執行，以及一個很關鍵的新東西——AI 系統衝擊評鑑（評估 AI 對個人與社會可能造成的衝擊，而不只是對組織的資安風險）。
• 要產出的文件：運作流程的文件、AI 生命週期各階段的紀錄、風險評鑑與衝擊評鑑的結果。
• 常見盲點：「規劃」與「運作」兩張皮——文件上寫得很好，實際開發流程卻我行我素。第 8 章要的是把制度真正嵌進開發與維運。

Check：第 9 章 效能評估

• 要你做什麼：檢查制度到底有沒有效。透過監視、量測、分析與評估掌握運作狀況、進行內部稽核（自己先查一遍）、並由管理階層做管理審查（高層定期檢視制度是否仍適當有效）。
• 要產出的文件：監視與量測的結果、內部稽核報告、管理審查的紀錄。
• 與 RAG 的連結：Day 5 做的紅隊測試與攻擊成功率（Attack Success Rate，以下簡稱 ASR）統計，正是這一章「監視、量測」的具體體現——用數據證明防線的有效程度。
• 常見盲點：內部稽核走形式、管理審查變成例行公事。查核若不動真格，PDCA 就轉不出改善。

Act：第 10 章 改善

• 要你做什麼：根據查核的結果採取行動。處理不符合事項與矯正措施（哪裡出錯了、怎麼修、怎麼防止再犯），並推動持續改善——讓下一輪 PDCA 比這一輪更好。
• 要產出的文件：不符合事項與矯正措施的紀錄、持續改善的紀錄。
• 常見盲點：矯正只「治標不治本」——把眼前的錯改掉，卻不追根本原因，結果同樣的問題換個地方再犯。42001 要求的是找出根因、系統性地防堵。

七章走完，把各章的常見盲點放在一起看，會發現它們的共同病灶都是「制度與實作脫節」——範圍畫錯、高層缺席、評鑑擺著看、文件兩張皮、稽核走形式、矯正治標。下圖把這些盲點彙整成一張總覽，導入前值得對照自查：

一套流程，兩張證：與 ISO 27001 的整合

Day 9 提過，42001 與 ISO 27001（資訊安全管理系統，Information Security Management System，以下簡稱 ISMS）共用同一套「調和結構（Harmonized Structure）」——也就是剛剛走過的第 4 到 10 章骨架。這個共通性帶來很實際的整合紅利：風險評鑑、內部稽核、管理審查、文件控制這些流程，兩套標準幾乎共用。如下圖所示，共用的部分可以直接整合，AI 特有的部分才需要另外建立。

因此對已有 27001 的組織，導入 42001 的策略很清楚：共用的管理骨架直接沿用，只需針對「AI 特有的部分」另外建立。這裡要精確一點，因為 AI 特有的三塊，和 27001 的關係並不相同：

• AI 政策、AI 風險評鑑：27001 裡其實有結構完全平行的條款（一樣有政策、一樣有風險評鑑與處理）。42001 的差別不是「多了這個流程」，而是把它們的標的從資訊安全換成 AI（例如風險評鑑要評的是 AI 特有的風險）。所以這兩塊是「沿用同一套框架、換一個評估對象」。
• AI 系統衝擊評鑑：這才是 27001 完全沒有對應、42001 獨有的東西——它評估的是 AI 對個人與社會可能造成的後果，而非組織自身的資安風險。

認清「哪些是換標的、哪些要從零建立」，能讓已有 27001 的團隊用最小成本補齊 42001。

導入時該準備的文件清單

把上面各章「要產出的文件」彙整起來，就是一份導入 42001 時的文件準備清單。下圖可作為實務起點：

要提醒的是，這份清單是幫助理解的整理，不是標準的原文——實際導入時，仍須以 CNS 42001／ISO/IEC 42001 正本所載的要求為準。

對映到技術控制與 RAG 範例

42001 的第 4 到 10 章是「管理層」的循環，但它和本系列的技術實作有一個清楚的介面：這套循環要求的「證據」，很多都由技術層來提供。

• 第 8 章要求 AI 生命週期的運作紀錄 → 由開發流程與版本控制提供。
• 第 9 章要求「監視、量測」 → 由紅隊測試報告、稽核日誌的統計（Day 26、27）提供。
• 第 10 章要求矯正與改善的紀錄 → 由事件處理流程與修補紀錄提供。

換句話說，PDCA 這個管理循環轉動時，每一格都需要下層的技術證據來填。這也預告了第四階段的價值：我們寫的每一段程式（過濾、稽核、測試），最終都會變成某一章要求的「登載之資訊」。

小結與明日預告

今天沿著 PDCA，把 42001 主體條款走了一遍：

• 第 4、5 章打地基：釐清組織全景與範圍、確立領導承諾與 AI 政策；
• 第 6 章（Plan）規劃風險、目標與變更；第 7、8 章（Do）備妥資源並落實運作，含 AI 特有的風險評鑑與衝擊評鑑；第 9 章（Check）以監視、稽核、管理審查查核成效；第 10 章（Act）矯正與持續改善；
• 與 ISO 27001 共用調和結構，已有 27001 者可沿用管理骨架、只補 AI 特有部分；
• 各章要產出的「登載之資訊」，彙整成一份導入文件清單。

明天（Day 11）將聚焦全系列最具 AI 特色的一塊——第 6 章的 AI 風險評鑑，搭配附錄 C 的 AI 風險來源清單，並說明「資安風險」與「AI 對個人／社會的衝擊」有何不同、為什麼需要一個獨立的「AI 系統衝擊評鑑」。今天走的是整條 PDCA 主線，明天要深入其中最關鍵、也最容易被低估的一格。

• 程式碼：本篇為標準條款解讀，無對應程式碼；各章要求的技術證據落點見第四階段。
• 參考條文／出處：ISO/IEC 42001:2023、CNS 42001:2026（章節編號與官方繁中標題屬事實）。本文以自己的話說明各章之用意與要求方向，未逐字引用或翻譯其規範條文，亦未複製子條款清單原文；實際導入請以標準正本所載要求為準。