💡 先搞懂問題
一般軟體寫好、測過、上線之後，只要程式碼沒改，同樣的輸入就會得到同樣的結果。AI 系統不一樣：它的行為是從資料學來的，上線後面對的資料卻一直在變。客戶換了付款習慣、詐騙手法進化、外部模型供應商悄悄更新版本，模型的表現就會一點一點走樣，而且不會像伺服器當機那樣跳出明顯的錯誤訊息。
很多組織的 AI 管理停在「上線前開一次審查會」。審查會之後，沒有人看模型品質、沒有記錄每次決策用的是哪個版本、重新訓練被當成小改直接換上去。等到客訴上門，團隊才發現連「那一次到底發生了什麼」都答不出來。
生命週期（life cycle）的想法，就是把 AI 系統當成有一生的東西來管：從決定要做什麼、設計開發、驗證、上線、運作，到最後下線，每一段都有該做的檢查與該留的紀錄。ISO/IEC 42001 附錄 A 的 A.6 這一組控制正是沿著這條線排列。
生活比喻：一台車從研發到報廢
車廠開發新車，會先訂規格：油耗多少、安全等級多高、給誰開。工程部畫設計圖、留零件清單，記下為什麼選這款引擎。出廠前做碰撞測試與道路測試，交車前做出廠檢查。車子上路後有定期保養，發現瑕疵要召回，車上還裝著行車紀錄器。等車子老舊到不符合新的排放標準，就要辦報廢，而不是丟在路邊。
少了任何一段都會出事。規格沒寫清楚，測試就不知道要測什麼；沒有行車紀錄器，事故發生後只能各說各話；只顧出廠、不管保養，車子遲早在路上拋錨。
這個比喻有兩處要小心。第一，車子的磨損看得見、有儀表板提醒，AI 模型變差卻沒有聲音：準確率慢慢下滑時，系統照樣回應、照樣打分數，所以監控要主動去量模型品質，不能只看系統有沒有在跑。第二，車子出廠後設計就固定了，AI 系統卻常在上線後重新訓練或更換外部模型版本，等於每隔一段時間就換了一台新車，每次都要回到驗證與部署的關卡重走一遍。
🎮 互動實驗室一：生命週期關卡
一家約 200 人的虛構電商要開發「訂單風險評分模型」，替每張訂單打分數，分數高的先暫停出貨、由客服確認。請帶著這個專案走過六個關卡，在每一關點選這個階段應該留下的證據（可複選），再按「交出這一關」。每關會立即說明哪些選對、哪些多做、哪些漏掉；漏掉的證據會記進稽核清單，走完六關後由稽核員一次開出示意不符合。
🎮 互動實驗室二：模型漂移監控模擬
同一個訂單風險評分模型上線了。示意每週約 20,000 張訂單，其中約 80 張是詐欺。請先選一個情境，再調整監控設定：輸入資料分布的警戒值、召回率（抓到詐欺的比例）的警戒值、多久檢查一次，以及觸發後要做的處置。圖表會即時顯示什麼時候發現問題、什麼時候恢復，以及期間多漏抓了多少示意詐欺交易。注意：詐欺要等客戶申訴退款才確定，召回率要大約 4 週後才算得出來（示意）。
📘 原理補完
A.6 的兩層結構：先定方向，再走生命週期
附錄 A 的 A.6 分成兩個部分。A.6.1 只有兩項控制，是整條生命週期的方向盤：A.6.1.2 要組織找出並寫下引導 AI 開發的負責任目標，例如公平性、透明度、穩健性、隱私；A.6.1.3 要把這些目標落實成有階段、有放行條件、有人核准的設計與開發流程。A.6.2 的七項控制則沿著生命週期逐段展開，前五項依序對應需求、設計開發、驗證確認、部署、運作監控，最後兩項技術文件與事件日誌貫穿全程。
生命週期該切成哪些階段，42001 本文沒有指定。ISO/IEC 22989 描述了發想、設計與開發、驗證與確認、部署、運作與監控、持續確認、重新評估、退役等階段；ISO/IEC 5338:2023 則以系統與軟體工程的 ISO/IEC/IEEE 15288、12207 為基礎，補上 AI 特有的流程。組織可以用瀑布式、敏捷或 MLOps（機器學習維運）的方式對應這些階段，重點是每一段有人負責、有檢查點、有紀錄。
| 控制 | 生命週期位置 | 要回答的問題 | 稽核常抽的證據 | ISO 27001:2022 相近主題 |
|---|---|---|---|---|
| A.6.1.2 | 全程的方向 | 我們做 AI 要守住什麼？怎麼變成可檢查的門檻？ | 負責任開發目標、目標對需求與測試的對照 | 無直接對應，接近政策與目標 |
| A.6.1.3 | 全程的流程骨架 | 每個階段交什麼、誰放行、例外誰核准？ | 開發流程文件、階段審查紀錄、例外核准 | 8.25 安全開發生命週期 |
| A.6.2.2 | 需求與規格 | 要做什麼、不做什麼、做到多好才算數？ | 需求文件與核准、需求到測試的追溯 | 8.26 應用系統安全要求 |
| A.6.2.3 | 設計開發 | 為什麼這樣設計、用了哪一版資料？ | 設計紀錄、實驗追蹤、模型登錄 | 8.27 安全系統架構與工程原則 |
| A.6.2.4 | 驗證確認 | 有沒有照規格做對？是不是適合真實用途？ | 測試計畫與報告、分群結果、核准人 | 8.29 開發與驗收中的安全測試 |
| A.6.2.5 | 部署 | 怎麼安全上線、出事怎麼退回去？ | 部署計畫、上線核准、回復演練紀錄 | 8.32 變更管理 |
| A.6.2.6 | 運作監控 | 上線後誰在顧、看哪些指標、超標怎麼辦？ | 監控儀表板、告警處理、重訓與更新紀錄 | 8.16 監視活動 |
| A.6.2.7 | 全程，依對象提供 | 使用者、客戶、主管機關各需要看什麼？ | 文件對象清單、模型卡、文件與正式版本是否一致 | 5.37 文件化運作程序（部分相近） |
| A.6.2.8 | 至少涵蓋使用期間 | 能不能重建某一次決策？ | 日誌規格、實際調出一筆歷史紀錄、存取與保存期限 | 8.15 日誌記錄 |
ISO 沒有發布 42001 與 27001 附錄 A 的官方對照表，最右欄是依主題整理的參考，方便已有 ISMS 的組織找到可以擴充的既有程序。
標準要求與組織自行決定的部分
附錄 A 是一份參考控制清單。組織要依 AI 風險評鑑與處理的結果，在適用性聲明（SoA，Statement of Applicability）中說明哪些控制納入、哪些排除及理由，這一點和 ISO 27001 的做法相同。納入的控制就要落實並能拿出證據。只採購外部 AI 服務、完全不做開發的組織，A.6 的部分控制可能較少適用，但只要有微調模型、撰寫提示詞樣板或串接 RAG（Retrieval-Augmented Generation，檢索增強生成）知識庫，通常仍算在開發活動裡，上線後的監控與使用紀錄也還是要自己做。
標準沒有規定的事情很多，都由組織依風險決定：要用哪一種生命週期模型、用什麼工具、監控哪些指標與多久看一次、警戒值訂多少、部署要不要先跑影子模式（shadow mode，新模型在背景打分數但不影響實際決策）、日誌要記哪些欄位與保存多久。A.6.2.8 只明確要求至少在系統使用期間記錄事件日誌，其他階段要不要記由組織判斷。下線（退役）也沒有獨立的一項控制，但組織依 A.6.1.3 定義的流程若涵蓋退場，就要照著做並留下紀錄；22989 與 5338 都把退役列為生命週期的一段，實務上建議納入。
把生命週期控制落地的步驟
- 盤點範圍內的 AI 系統，在 SoA 中確認 A.6 各項的適用性與理由。
- 畫出現行的開發與維運流程，對照 22989 或 5338 的階段，標出缺口；最常見的缺口是上線後監控、重新訓練的核准與退場。
- 為每個關卡訂出產出物與放行條件，盡量內建在既有工具裡，例如工單的核准欄位、CI/CD 管線裡的模型評測、模型登錄（model registry）的版本紀錄。
- 為每個上線系統訂監控計畫與日誌規格：指標、警戒值、負責人、檢視頻率、觸發後的處置、保存期限與遮罩方式。
- 寫清楚哪些變更要回到驗證與部署關卡，例如重新訓練、更換外部模型版本、修改系統提示詞、擴大使用族群或用途。
- 用內部稽核抽一個系統，從需求一路追到監控與日誌，確認這條鏈沒有斷。
常見誤解
「重新訓練只是小改。」架構沒變不代表行為沒變。換了資料，模型對某些族群的表現可能變好也可能變差，所以重訓後的模型要當成新版本，重跑驗證、走部署核准，技術文件也要跟著更新。
「監控就是看系統有沒有掛。」CPU、記憶體、回應時間只能告訴你服務還在，不能告訴你模型還準不準。A.6.2.6 期待的是連模型層面一起看：輸入資料分布是否改變（資料漂移，data drift）、輸入和正確答案的關係是否改變（概念漂移，concept drift）、誤判率趨勢、不同族群的表現差距、人工覆核推翻 AI 決定的比例。
「驗證和確認是同一件事。」驗證（verification）問的是有沒有照規格把東西做對，確認（validation）問的是做出來的東西在真實用途下是否適用。實驗室一的模型在測試集上達到規格，但如果客服實際使用後發現被擋的多是老客戶大量採購，那就是確認沒過。兩者都在 A.6.2.4，缺一不可。
「日誌記越多越好。」AI 的事件日誌常包含輸入內容、客戶資料甚至完整對話，本身就是需要保護的資訊。記錄前要決定哪些欄位要遮罩、誰可以查、保存多久，並和個資保護的要求一起檢視。
稽核常見的不符合
稽核員最常用的手法是抽一個最近上線或改版的 AI 系統走完一遍。常見的斷點包括：需求只寫「準確率 90% 以上」，沒有界定在哪些資料、哪些族群上量；設計文件停在第一版，之後幾次重訓都沒更新；只測整體準確率，沒有分群比較；模型由個人手動複製到正式環境，沒有核准紀錄，回復方案從沒演練；監控只有基礎設施指標；日誌沒記模型版本，事故時無法判斷是哪一版造成；對外文件寫的效能數字還是兩年前的版本。這些斷點有一個共同點：控制在文件上存在，但沒有長進團隊每天使用的工具與流程裡。
✅ 自我檢測
以下 6 題都是原創情境題，選完會立即顯示對錯與解析。目前得分：0 / 6