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

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

從「管理流程」到「具體要做的事」

前兩天走完了 ISO/IEC 42001 的管理主體：Day 10 走過主體條款第 4 到 10 章的 PDCA 循環，Day 11 深入第 6 章的風險與衝擊評估。但你可能會有一個疑問：這些都是「流程」與「制度」，那具體到底要做哪些事，才算把 AI 治理好？

回答這個問題的，就是今天的主角——附錄 A。它是一份「控制措施」的清單，把抽象的管理要求，具體化成一組組「該有的控制」。如果說主體條款是「你要建立一套會運轉的管理制度」，那附錄 A 就是「這套制度裡，具體該裝上哪些零件」。

進入內容之前，先交代本篇的寫法。附錄 A 是整份標準中著作權保護最嚴格的部分，控制清單的原文——包括翻譯——都不適合在公開文章中轉載。因此本篇不逐條列出控制條目，而是沿用附錄 A 的大分類主題（章節架構屬公開資訊）作為骨架，逐組解讀這組控制要達成什麼目的，並示範它可以落地成什麼樣的政策、流程與技術證據。想查閱完整而精確的控制清單，請取得標準正本；本篇的價值在於讀懂與落地，而非取代標準。

先理解附錄 A 的定位

附錄 A 在 Day 9 介紹文件地圖時提過：它是「規定（normative）」性質，內含一組控制目標與控制措施。這裡把幾個關鍵觀念釐清：

• 控制目標與控制措施的差別：控制目標是「要達成什麼」（例如：確保用於 AI 的資料品質可被信任），控制措施則是「用什麼手段達成」。
• 不是每一條都強制：Day 9 強調過，附錄 A 是「參考控制」——組織要依風險評鑑的結果，透過**適用性聲明（Statement of Applicability，以下簡稱 SoA）**決定納入或排除哪些控制、並說明理由。這與上一點的「規定」性質並不矛盾：附錄 A「規定」的是「必須逐條表態」這個程序（經 SoA 說明納入或排除），而不是「每一條控制都必須採用」。SoA 怎麼寫，是明天 Day 13 的主題。
• 附錄 A 配附錄 B：附錄 A 給「控制是什麼」，附錄 B 則給「這些控制怎麼實作」的指引。兩者搭配著讀，配合的方式如下圖所示。

本篇的方法：把一條控制拆成三層

抽象的「控制措施」對工程師常常很難落地——讀完一條控制，還是不知道「那我到底要做什麼、要拿什麼給稽核看」。所以本系列用一個固定的框架來拆解每一組控制。這個框架是本篇的核心工具，如下圖所示，共分三層：

• 政策層：組織在這個主題上「宣示的原則與規定」是什麼。（文件：政策、辦法）
• 流程層：把政策落實的「具體做法與步驟」。（文件：程序書、作業流程、紀錄）
• 技術證據層：系統實際運作時「留下的、可被稽核檢查的證據」。（產物：設定、日誌、測試報告、程式）

一條控制，只有政策沒有流程，是空談；只有流程沒有技術證據，稽核時拿不出東西。三層都到位，才算真正落地。 這個三層法，也正好把「管理制度」和本系列第四階段的「技術實作」接了起來——技術證據層，就是我們之後要寫的程式與日誌。

舉一個具體例子（此為筆者自行設計的示範，非附錄 A 原文）。假設有一組控制的目的是「確保用於 AI 系統的資料是被治理的」，用三層拆解會長這樣：

• 政策層：訂一份《AI 資料治理政策》，規定資料來源要合法、要記錄來歷、敏感資料要去識別化。
• 流程層：建立「資料進入向量資料庫前的檢查程序」——來源審查、去識別化、標記，並留下處理紀錄。
• 技術證據層：去識別化的程式、資料來源與處理的日誌、向量資料庫的存取設定。（這正是第四階段 Day 22 要實作的東西。）

看懂這個拆法，附錄 A 的每一組控制就都能「落地」了。以下逐組導讀。

附錄 A 的九組控制：逐組看目的與落地

附錄 A 把控制依主題分成九個群組，分別涵蓋：與 AI 相關的政策、內部組織與權責、AI 系統的資源、AI 系統的衝擊評鑑、AI 系統生命週期、AI 系統的資料、提供給各關注方的資訊、AI 系統的使用，以及第三方與顧客關係。九組的全貌如下圖所示，以下逐組說明其目的與落地方向（完整而精確的控制條目請見標準正本）：

與 AI 相關的政策

• 目的：組織要有一份（或一套）明確的 AI 政策，作為所有治理活動的最高指導。
• 落地方向：政策層——制定 AI 政策文件，並定期審視更新；對應主體條款第 5 章的領導承諾。

內部組織與權責

• 目的：把 AI 治理的角色、責任與回報路線定清楚，不讓「大家都以為別人會處理」。
• 落地方向：政策＋流程——角色與權責矩陣、決策與升級流程、跨部門的協作機制。

AI 系統的資源

• 目的：確保投入 AI 的各種資源（例如資料、算力、人力、工具等）都被盤點與管理——你要知道自己的 AI 是「用什麼做出來的」。
• 落地方向：流程＋技術證據——資源盤點清單、模型與資料集的登錄。這一組直接呼應第四階段 Day 28 的供應鏈與模型治理。

AI 系統的衝擊評鑑

• 目的：把 Day 11 講的「向外看」制度化——重點在跳出資安、把 AI 對外部的影響評估變成組織的常規動作。
• 落地方向：流程＋證據——衝擊評鑑的程序與紀錄（呼應第 6、8 章的衝擊評鑑要求與姊妹標準 ISO/IEC 42005）。

AI 系統生命週期

• 目的：從需求、設計、開發、測試、部署到退役，AI 系統的每一個階段都要有負責任的管理，而不是「上線就不管了」。
• 落地方向：三層俱全——開發規範（政策）、各階段的檢核與審查（流程）、版本控制與測試報告（技術證據）。這一組是與第四階段技術實作連結最密的一組。

AI 系統的資料

• 目的：確保餵給 AI 的資料，在來源、品質、治理上都可被信任——因為 AI 的行為是資料教出來的。
• 落地方向：三層俱全——資料治理政策、資料處理與去識別化流程、處理日誌與資料血緣（Day 22 實作）。

提供給各關注方的資訊

• 目的：讓受 AI 影響的關注方（利害關係人），能得到適當的資訊——呼應基本法的「透明與可解釋」原則。
• 落地方向：政策＋技術證據——揭露政策、AI 生成內容標示、來源可查證的設計（Day 24 實作）。

AI 系統的使用

• 目的：確保 AI 系統被負責任地、依組織政策使用。
• 落地方向：流程＋技術證據——使用規範（政策）、存取與權限控制，以及防止濫用、保留人類監督與確認關卡等做法（Day 25 實作）。

第三方與顧客關係

• 目的：當你的 AI 牽涉到第三方（供應商、外部模型、客戶）時，責任與義務要在關係中界定清楚。
• 落地方向：政策＋流程——第三方管理規範、合約中的 AI 條款、供應鏈風險追蹤（呼應 Day 28）。

附錄 A 與第四階段的對映

把九組控制與本系列後半的技術實作對起來，就會看到附錄 A 不是紙上談兵——它的很多控制，最後都要靠程式與日誌來提供「技術證據」。下圖呈現各控制組與第四階段實作的主要落點：

這張圖就是「從法條到程式碼」在附錄 A 這一層的具體樣貌：每一組管理控制，最後都會在第四階段找到一段對應的程式或一份對應的紀錄來當證據。

對映到 RAG 範例

把附錄 A 投影到本系列的檢索增強生成（Retrieval-Augmented Generation，以下簡稱 RAG）客服範例，會得到一份「這個系統該有哪些控制」的清單雛形——這其實就是一份迷你的、針對 RAG 系統的適用性聲明前身：

• 資料：RAG 的知識庫資料有沒有做來源審查與去識別化？
• 對關注方的資訊：回答有沒有標示「AI 生成」、有沒有附來源？
• 使用：不同使用者的檢索範圍有沒有做權限隔離？
• 生命週期：模型與知識庫的更新有沒有版本控制與測試？

第四階段我們每加一道防禦，其實都在為這份清單的某一項「補上技術證據」。到了 Day 29 收斂白皮書時，這份清單就會長成一份完整、可勾選的檢核表。

小結與明日預告

本文將 42001 附錄 A 拆解為可落地的三層，重點是「怎麼落地」而非「清單有什麼」：

• 附錄 A 是一份控制目標與控制措施的清單，透過 SoA 依風險選用，並配附錄 B 的實作指引一起讀；
• 本系列用**「政策＋流程＋技術證據」三層法**拆解每一組控制，讓抽象的控制變得可落地、可稽核；
• 附錄 A 分九組（政策、內部組織、資源、衝擊評鑑、生命週期、資料、對關注方資訊、使用、第三方關係），每組都能對映到第四階段的技術實作；
• 全篇嚴守著作權：只講目的與落地方向，不照抄控制清單原文。

明天（Day 13）將把第二階段的 42001 段落收尾——談「認證之路」：從適用性聲明（SoA）怎麼寫，一路走到取得證書的完整流程（差距分析、內部稽核、管理審查、第一階段與第二階段稽核）。 今天知道了「要裝哪些控制」，明天就看「怎麼證明你真的裝好了、並拿到一張證書」。

• 程式碼：本篇為標準附錄解讀，無對應程式碼；各控制的技術證據落點見前述對映圖所列日次。
• 參考條文／出處：ISO/IEC 42001:2023、CNS 42001:2026 之附錄 A（控制）與附錄 B（實作指引）（分組編號與大分類名稱屬事實）。本文以自己的話說明各組控制之目的與落地方向，示範用「政策／流程／技術證據」三層改寫，未逐字引用、未翻譯、也未複製附錄 A 之控制清單原文；完整且精確的控制內容請以標準正本為準。