💡 先搞懂問題
組織決定導入 ISO/IEC 42001 時，很常見的第一個動作是翻到附錄 A，把 38 項控制當成待辦清單。做到一半就會卡住：行銷同事自己訂閱的生成式 AI 算不算？金流供應商系統裡內建的詐欺偵測要不要管？我們只是呼叫外部模型的 API，開發相關的控制能不能不做？這些問題附錄 A 回答不了，因為答案取決於更前面的兩件事：組織在每個 AI 系統上扮演什麼角色，以及這次要管到哪裡。
ISO/IEC 42001:2023 是 AI 管理系統（AI management system，AIMS）的要求標準，2023 年 12 月發布，是第一本可以由第三方驗證的 AIMS 標準。本文第 4 到 10 章採用 ISO 管理系統的共同結構（Harmonized Structure，HS），章節順序和 ISO 27001 幾乎一一對得上；附錄 A 列出 38 項參考控制，附錄 B 是這些控制的實作指引，附錄 C、D 則是思考 AI 目標、風險來源與跨產業應用的參考素材。讀這本標準要先抓住骨架：第 4 章定角色與範圍，第 6 章依風險與影響挑控制，第 7 到 10 章讓整套機制真的運作，並持續改善。
生活比喻：老社區成立管委會
想像一棟老社區決定成立管委會。公寓大廈的管理有一套大家熟悉的骨架：要有規約、要開住戶大會、要定期公布財務、每年檢討一次。各社區照這個骨架寫自己的規約，所以你搬到別的社區當委員，很快就能上手。
真正開始管之前，有兩件事一定要先講清楚。第一是身分：同一棟樓裡有屋主、房客、把房子分租出去的二房東，還有每天進出的外送員與訪客。身分不同，要負的責任和能主張的權利也不同，二房東得對自己的房客負責，訪客雖然不繳管理費，門禁設計還是要顧到他們。第二是管轄範圍：走廊和電梯歸管委會，室內裝潢歸住戶，外牆上的冷氣機架介於兩者之間，若沒有事先寫清楚誰管，漏水時就會互相推託。
這個比喻有三個地方容易誤導。社區規約可以由住戶大會投票修改，但 42001 第 4 到 10 章是固定的要求，宣稱符合時一條都不能排除；能依風險評鑑結果或外部要求排除的只有附錄 A 的控制，而且要在適用性聲明（Statement of Applicability，SoA）寫下理由。其次，住戶多半一戶一種身分，組織在 AI 上卻常同時有好幾個角色，而且要以「每個 AI 系統」為單位分開判定。最後，管委會必須管全部公共空間，AIMS 範圍則可以從一條產品線起步，只是排除的部分要說得出理由。
🎮 互動實驗室一：AI 角色判定器
每張卡片是一個原創的虛構情境。請從「卡片上那一方」的角度，判定它對這個 AI 系統扮演哪些 ISO/IEC 22989 角色，可以多選，選好按「送出判定」。有些情境除了必選角色，還有「視實際活動也可接受」的角色，回饋會說明界線在哪裡，以及這些角色在 AIMS 要特別注意什麼。
🎮 互動實驗室二：AI 系統盤點與範圍
下面是一家虛構的 200 人居家用品電商（以下稱 A 公司）第一次盤點出來的清單，其中有自研模型、外部 API、供應商內嵌的 AI 功能、員工自行使用的工具，也有兩項其實不算 AI 系統。點選卡片可以納入或移出 AIMS 範圍，清單旁（手機版在清單下方）會即時做介面與相依性檢查，並產生一段示意的範圍描述。也可以先按上方的預設方案看看差異。
介面與相依性檢查
範圍描述（示意）
📘 原理補完
整本標準怎麼分工
42001 的本文和附錄性質不同，弄錯性質，SoA 和風險處理就會失去依據。下表的「稽核怎麼用」是實務上常見的檢查方式，具體做法以驗證機構的安排為準。
| 部分 | 性質 | 在講什麼 | 導入與稽核時怎麼用 |
|---|---|---|---|
| 第 0–3 章 | 說明與名詞 | 前言、適用範圍、引用標準（只有 ISO/IEC 22989）、名詞與定義 | 本身沒有要組織做的事，但「AI 系統」「AI 角色」等名詞要照 22989 的意思理解 |
| 第 4–10 章 | 要求（shall） | 全景、領導、規劃、支援、運作、績效評估、改善 | 全部都要符合，不能宣告不適用；稽核員會逐條找運作證據 |
| 附錄 A | 規範性 | 控制目標與 38 項參考控制，分在 A.2–A.10 九個主題 | 6.1.3 要求拿必要控制和附錄 A 比對，SoA 逐項交代納入或排除的理由與實施狀態 |
| 附錄 B | 規範性 | 附錄 A 每項控制的實作指引 | 把控制做具體的依據；做法可依規模調整，不必照搬 |
| 附錄 C | 參考性 | 組織可能設定的 AI 目標與可能的風險來源 | 設定 AI 目標、識別風險時的檢核素材，本身不列入 SoA |
| 附錄 D | 參考性 | 不同領域如何使用 AIMS，以及與其他管理系統整合 | 規劃與 27001、27701 等整合時的參考 |
和 27001 對照時有一點特別值得注意：27001 的控制實作指引另外寫在 27002，42001 則把指引放在同一本標準的附錄 B。另外，兩本標準的附錄 A 幾乎不重疊，存取控制、加密這類資安控制仍由 27001 負責，42001 的 38 項著重 AI 生命週期、資料、給利害關係者的資訊、AI 系統的使用以及第三方與客戶。
PDCA 是讀法，不是額外的要求
把第 4 到 7 章看成規劃（Plan）、第 8 章看成執行（Do）、第 9 章看成查核（Check）、第 10 章看成改善（Act），可以很快看出各章怎麼串起來。不過標準本文要求的是持續改善，並沒有強制組織畫出 PDCA 圖或用這四個字命名流程。42001 在共同結構上加進的 AI 專屬內容，集中在 4.1 的 AI 角色與 AI 系統預期用途、6.1.2 到 6.1.4 的 AI 風險評鑑、風險處理與 AI 系統影響評估，以及第 8 章對應的執行條文 8.2 到 8.4；其中影響評估是 27001 完全沒有的。
版本也順帶確認一下：現行版是 ISO/IEC 42001:2023，沒有另出修正（Amendment）。27001 在 2024 年透過 Amd 1 加入「判斷氣候變遷是否為相關議題」，42001 發布時 4.1 就已經內建這項考量，所以文件寫「ISO/IEC 42001:2023」即可，但稽核時一樣會被問到氣候變遷的判斷。未來是否改版，以 ISO 官網公告為準。
盤點、角色、範圍的建議順序
標準沒有規定這幾件事的先後，下面是實務上最不容易重工的排法。標籤說明哪些是標準要求、哪些是常見做法。
- 常見做法 盤點 AI 系統：來源包括專案清單、採購與訂閱紀錄、雲端帳單、軟體資產清冊與員工問卷，記下用途、擁有者、模型來源、資料類型與受影響對象。42001 沒有一條條文直接寫「要有 AI 清冊」，但後面每一步都需要它。
- 標準要求 判定角色：4.1 要求組織決定自己對 AI 系統扮演的角色，並考量系統的預期用途。常見做法 在清冊加一欄「組織角色」，逐系統可複選並寫一句理由。
- 標準要求 整理內外部議題（4.1，含氣候變遷是否相關）與利害關係者的要求（4.2），利害關係者要包含受 AI 結果影響的人。
- 標準要求 決定範圍並以文件化資訊保存（4.3）。常見做法 範圍說明涵蓋的 AI 系統、角色與活動、單位、地點，以及和範圍外單位或供應商的介面。
- 常見做法 做差距分析，排出導入計畫與資源需求，交給管理階層核准。差距分析本身不是標準要求的文件。
角色和 AIMS 的關注重點
| 22989 角色 | 典型例子（虛構） | 在 AIMS 中常特別關注 |
|---|---|---|
| AI 提供者 AI provider | 把模型包成 API 或 SaaS 功能賣給客戶；雲端 AI 平台 | A.8 給使用者與利害關係者的資訊、A.10.4 對客戶的責任，說清楚預期用途與限制 |
| AI 生產者 AI producer | 設計、訓練、微調、測試與部署模型的團隊 | A.6 生命週期控制與 A.7 資料控制；影響評估要在設計階段就開始 |
| AI 客戶 AI customer | 採購外部 AI 服務的部門，實際操作的人是使用者（AI user） | A.9 負責任使用與預期用途、A.10.3 供應商；自己的使用情境仍要做風險評鑑 |
| AI 合作夥伴 AI partner | 系統整合者、資料提供者、AI 評估者與稽核者 | A.10.2 責任分配寫進合約；交付的資料或服務會成為對方 AIMS 的輸入 |
| AI 主體 AI subject | 被 AI 評分的求職者、資料被拿去訓練的會員 | 通常不是導入方，而是組織在 4.2 與影響評估（A.5.4）要考慮的人 |
| 主管機關 Relevant authorities | 政策制定者、監理機關 | 其法規與指引是 4.1 的外部議題、4.2 的要求來源 |
表中「常特別關注」是依角色歸納的閱讀重點，不代表其他控制可以不看；每一項附錄 A 控制最後都要在 SoA 交代。另外，22989 的角色和歐盟 AI 法（EU AI Act）的 provider、deployer 不能一對一換算：歐盟法的 provider 比較接近 22989 生產者加提供者的組合，使用方在該法稱為 deployer。產品若銷往歐盟，法律角色要依該法另外判定。
常見誤解
「我們只呼叫 API，所以只是客戶。」如果把 API 接進對外服務，組織對終端使用者就是提供者；如果做了微調、自建知識庫並自行評測，還可能有一部分生產者的工作。角色要依實際活動判定，不是依採購方式判定。
「附錄 A 的 38 項都要做。」附錄 A 是比對用的參考清單，依風險評鑑與影響評估的結果選用；排除可以，但要有理由，而且第 4 到 10 章的要求不在可排除之列。
「範圍寫全公司比較有誠意。」範圍太大，第一年只有少數團隊拿得出運作證據，第一階段稽核就會被要求修正；範圍太小，客戶又會發現真正賣給他們的 AI 產品不在證書上。合理的做法是從核心產品起步，並寫下其他系統納入的時程。
稽核常見的不符合
最常見的是幾份文件對不起來：範圍寫「本公司所有 AI 服務」，清冊卻只列兩個專案；或範圍文件只寫一句「本公司為 AI 使用者」，實際上有自建模型。其次是範圍外的介面沒交代，例如訓練資料由範圍外的部門提供，卻看不到資料交付規格與品質檢查的安排。也常見清冊建立後從未更新，新採購的 SaaS 已經啟用 AI 功能卻沒有列入，或 4.1 完全沒有交代氣候變遷是否相關。稽核員很喜歡反向抽查：從採購紀錄或訪談中找一個不在清冊上的 AI 工具，看組織怎麼說明。
✅ 自我檢測
以下 6 題都是原創情境題。單選題點選後立即批改；標示「複選」的題目選好後按「送出這題」。目前得分：0 / 6