AI 治理的真相：內部稽核如何揭開黑盒子的秘密
AI 治理的真相：內部稽核如何揭開黑盒子的秘密— 從五個觀念，到一條可以走的生命週期稽核路線
撰稿：ARKO AI 主編；責任編輯：Peter Pan
■ 1. 引言：AI 浪潮下的透明度危機
在當前的商業環境中，企業正面臨一個巨大的挑戰：我們正以前所未有的速度擁抱人工智慧以驅動創新，但同時，對這些系統的控制感卻在急劇流失。當 AI 滲透到自動化決策、信用評分甚至招聘流程時，管理層往往躲在「技術太複雜」的屏障背後。然而，AI 不應是一個無法被質疑的黑盒子。目前的透明度危機不僅是技術挑戰，更是企業治理的崩潰。AI 稽核不再是工程師的專利，而是企業確保生存與信任的核心。隨著全球監管力度加大，稽核人員必須從幕後走向前線。
說真的，這幾年教授ISO/IEC 42001:2023的經驗，我發現最大的卡點不是「不知道 AI 有風險」，而是「知道有風險，但不知道該在什麼時候查、查什麼、要什麼證據」。市面上的 AI 治理討論多半停在原則層次：要公平、要可解釋、要有人類監督。這些沒有錯，但稽核人員需要的是查核點與底稿，不是形容詞。
所以這篇文章分成兩段。前半部是五個重新定義 AI 治理的核心觀點，協助閱讀者瞭解如何將不可控的技術轉化為受控的商業資產；後半部則補上那條缺失的軸線 —用 ISO/IEC 5338:2023 的 AI 系統生命週期過程，把這五個觀點釘到具體的時間點與證據上。順便釐清一個在AI圈流傳很廣的誤解：AI 生命週期到底是七個階段還是八個階段。
■ 2. 重點：你不需要成為 AI 工程師也能進行稽核
許多稽核專業人士對 AI 感到恐懼，認為必須精通機器學習才能介入。這是一個嚴重的誤區。根據 GIAS 2024（全球內部稽核準則，2025 年 1 月 9 日正式生效）的精神，稽核的核心始於風險導向（risk-based auditing）。稽核人員的職責不是逐行檢查程式碼，而是評估由第一道防線（營運與開發）與第二道防線（風險、合規、資安）所建立的治理框架是否真的在運作。
老實講，這個舉例我用過很多次：稽核人員不需要成為造紙工程師也能稽核財務報表；同樣地，稽核人員不需要精通神經網路也能稽核 AI。重點在於查證控制點與問責制度。透過三道防線模型（Three Lines Model），內部稽核應聚焦於資料治理的有效性、模型確效的程序透明度，以及決策的問責體系。
「內部稽核不需具備 AI 工程專業知識即可執行測試；但在涉及對抗性測試或模型健壯性等高度技術性課題時，應依據準則尋求外部專家支援。」
值得注意的是，這句話有兩個方向要同時成立。一方面，稽核不能因為技術門檻而缺席；另一方面，稽核也不該假裝自己有能力做紅隊測試。實務上比較健康的做法是：稽核設計查核問題與證據要求，技術測試外包或委由第二道防線執行，但稽核保留對「測試範圍是否足夠」與「發現是否被追蹤結案」的判斷權。這才是真正的獨立性。
■ 3. 重點：影子 AI 是隱藏在視線之外的最大風險
在 AI 治理中，最大的風險往往不是已知的系統，而是那些未經授權的工具。員工為了提高效率，可能無意中將受保護的客戶個資或企業機密輸入公共 AI 模型中。僅依靠採購記錄或財務報表已無法發現這些風險，因為大多數影子 AI 工具是免費的，或是隱藏在既有軟體中。稽核人員必須從單純的財務稽核思維（看帳單）轉向營運技術稽核思維（看流量）。
偵測影子 AI 的關鍵技術手段：
▸ 雲端與 SaaS 訂閱比對：交叉核對 IT 支出與雲端服務存取日誌。
▸ 網路出口監控：透過資料外洩防護（DLP）系統監測指向已知 AI 端點的流量。
▸ 瀏覽器擴充功能檢閱：檢查員工設備上安裝的 AI 助手外掛。
▸ 供應商發佈說明：審閱 ERP 或辦公軟體是否自動啟用了未經核准的 AI 功能。
▸ 身分供應商日誌：檢視 SSO／OAuth 授權紀錄，找出以公司帳號登入的第三方 AI 服務。
▸ API 金鑰盤點：搜尋程式碼倉庫與 CI/CD 設定中的模型供應商金鑰。
有趣的是，最後兩項往往比 DLP 更有效。DLP 看得到的是「已知端點」，但真正麻煩的影子 AI 常常是開發團隊自己串的 API，它不會出現在瀏覽器流量裡，只會出現在某個 repo 的環境變數中。從趨勢來看，隨著各家 SaaS 把 AI 功能直接內建進既有訂閱，影子 AI 的定義本身也在改變 —— 未來的問題不是「員工偷用了什麼」，而是「我們付錢買的軟體，什麼時候悄悄變成了 AI 系統」。NIST 於 2026 年 3 月發布的 AI 800-4 報告也點出同一個方向：瀏覽器型代理工具、個人 API 金鑰串接的自動化流程，正在成為下一代的影子 AI。
■ 4. 重點：你的身分決定了你的稽核深度 — 部署者 vs. 提供者
有效的 AI 治理拒絕一刀切。我們必須透過範疇門檻（scoping gateway）來優化稽核資源的分配。根據歐盟 AI 法案（EU AI Act），企業的角色主要分為兩類：
▸ 部署者（Deployer）：若您僅是使用第三方工具（如 Microsoft Copilot 或企業版 ChatGPT），稽核應聚焦於供應商合約管理、資料輸入控制及輸出查核。
▸ 提供者（Provider／Developer）：若您自行開發或對模型進行實質性修改（如微調），則需承擔最高級別的治理責任，包括全生命週期管理與技術健壯性測試。
這種分類法能確保稽核工作精準打擊風險。對於部署者，我們可以減輕對模型內部的技術測試，轉而強化對供應商服務保證（如 SOC 2 報告、模型卡、DPA 條款）的核查，避免無謂的資源浪費。不過這裡有個實務上的陷阱值得提醒。歐盟 AI 法案第 25 條規定，部署者在特定情況下會「升格」為提供者 —— 例如以自己的名稱或商標推出高風險 AI 系統、對高風險 AI 系統進行實質修改，或改變原本非高風險系統的預期用途使其成為高風險。換句話說，「我們只是買來用」這句話，並不是一張永久有效的免責聲明。稽核在做範疇界定時，應該同時問兩個問題：現在我們是什麼角色？以及，有沒有任何一條產品或專案路線，正在悄悄把我們推向提供者？微調、RAG 知識庫外掛、把模型輸出重新包裝成自有品牌服務，這三件事是最常見的角色升格觸發點。
■ 5. 重點：董事會的 AI 識讀能力已成為法律義務
問責制的轉移：高層不再享有「技術無知」的豁免權。
AI 治理的成敗取決於頂層監督。這不僅是道德建議，更是法律義務。歐盟 AI 法案第 4 條明文要求提升相關人員的 AI 識讀能力（AI literacy）。更重要的是，在瑞士等司法管轄區，瑞士《債法典》（Swiss Code of Obligations）第 716a 條規定了董事會不可委任的核心職責，這意味著 AI 監督責任不能被簡單地外包給 IT 部門。
為何缺乏 AI 素養會導致治理失敗？
▸ 自動化偏見：管理層可能對模型輸出產生過度依賴，忽略必要的人類監督。
▸ 控制措施誤用：董事會若不具備 AI 知識，將無法識別 AI 生成內容中的潛在偏見或合規破口。
▸ 風險胃納錯配：不理解模型不確定性的董事會，無法為 AI 決策設定有意義的容忍度門檻。
內部稽核必須檢查董事會技能矩陣，確保高層決策者具備足夠的 AI 素養，以評估技術對組織風險偏好的影響。說真的，AI 識讀能力這件事很容易被做成一場合規表演 — 辦一場 90 分鐘的線上課程，簽個到，證據就有了。稽核如果只查「有沒有辦訓練」，等於幫組織背書了一個空殼。比較有意義的查核點是：董事會在過去四個季度中，是否曾經因為 AI 相關風險資訊而「改變過一項決定」？如果答案是從來沒有，那不是因為沒有風險，而是因為風險資訊根本沒有被有效傳遞到那一層。
■ 6. 重點：生成式 AI 的特有風險 —幻覺與資料洩漏
生成式 AI（GenAI）打破了傳統 IT 控制的一項核心假設：系統輸出應該是可預測的。GenAI 的幻覺（hallucination）特性要求我們必須擴展內部控制框架（如 COSO GenAI）。
核心預警：如果內控框架未隨之進化，組織將在以下五個 COSO 組件中面臨控制真空。
- 控制環境：缺乏對 AI 倫理的指導方針。
- 風險評估：未納入幻覺與資料洩漏的特定風險。
- 控制活動：傳統存取控制不足以應對動態模型。
- 資訊與溝通：缺乏對 AI 生成內容的標記。
- 監督活動：未針對模型漂移建立監測機制。
稽核人員應特別關注揭露與標記（disclosure and marking）。依據歐盟 AI 法案第 50 條，企業必須確保 AI 生成內容能被識別，防止過度依賴並降低對品牌聲譽的潛在威脅。第 50 條第 2 項進一步要求生成式系統的輸出應以機器可讀格式標記為人工生成或操作，這代表水印與來源標註（provenance）不再只是技術選項，而是可稽核的合規要求。
從趨勢來看，GenAI 帶來的真正稽核挑戰是「不可重現性」。傳統系統稽核可以重跑一次交易，比對結果是否一致；但同一個提示詞在同一個模型上跑兩次，答案可能不同。這意味著稽核證據的形態必須改變 —— 從「結果正確性」轉向「過程可追溯性」：提示詞紀錄、模型版本、參數設定、檢索來源、人工覆核紀錄，這五樣東西缺一不可。
■ 7. 重點：沒有生命週期地圖，稽核就只是抽樣 —— ISO/IEC 5338:2023 補上的那條軸線
前面五個觀點都成立，但把它們攤開來看，會發現一個結構性問題：它們是五個「主題」，不是一條「流程」。稽核人員拿著這五點去現場，很容易變成隨機抽查 —— 這次查影子 AI，下次查董事會訓練，看起來都有做，但永遠說不清楚覆蓋率是多少。
這正是 ISO/IEC 5338:2023 的價值所在。
◆ 7.1 ISO/IEC 5338:2023 是什麼，以及它「不是」什麼
ISO/IEC 5338:2023《Information technology — Artificial intelligence — AI system life cycle processes》於 2023 年 12 月發布，由 ISO/IEC JTC 1/SC 42 制定，定義一組描述 AI 系統生命週期的過程與相關概念，適用範圍涵蓋機器學習系統與啟發式（heuristic）系統。它的技術基礎是既有的兩份系統工程標準 —— ISO/IEC/IEEE 15288:2023（系統生命週期過程）與 ISO/IEC/IEEE 12207:2017（軟體生命週期過程）——再加上取自 ISO/IEC 22989:2022（AI 概念與術語）與 ISO/IEC 23053:2022（機器學習系統框架）的 AI 特有過程，經修改與擴充而成。老實講，ISO/IEC 5338:2023 的引言寫得比很多標準誠實：它的出發點就是「與其重新發明一套 AI 專用生命週期，不如把傳統軟體系統的生命週期過程延伸，補進 AI 特有的特性」。
這個定位帶來兩個直接後果。
第一，如果 AI 系統中的某個元件其實是傳統軟體或傳統系統，那就直接沿用 ISO/IEC/IEEE 12207:2017 與 ISO/IEC/IEEE 15288:2023 的過程來實作，不必另立門戶。稽核不需要為 AI 專案設計一整套稽核流程，只需要在既有的 SDLC 稽核流程上「加掛」AI 特有的查核點。
第二，這點特別重要 —— ISO/IEC 5338:2023 明白聲明它不規定特定的生命週期模型。它關注的是「AI 特有的過程有哪些」，而不是「這些過程該排成什麼順序」。這句話後面會決定我們怎麼看待階段數量的爭議。
至於它跟其他標準的分工，我目前是這樣理解的：ISO/IEC 42001:2023 告訴你「誰該負責」，ISO/IEC 5338:2023 告訴你「該做哪些事」，ISO/IEC 23894:2023 告訴你「怎麼判斷該不該做」。ISO/IEC 5338:2023 本身也明說，它是在為 ISO/IEC 42001:2023 所討論的生命週期過程提供進一步細節。
對稽核而言，這個分工很實際：ISO/IEC 42001:2023 給你組織層的查核清單，ISO/IEC 5338:2023 給你系統層的查核清單 —— 而後者恰恰是多數 AI 稽核方案缺的那一半。更完整的六份標準對照，整理在下圖。
◆ 7.2 三種過程類型：稽核程序該從哪裡改起
多數介紹文章會直接把 ISO/IEC 5338:2023 講成「四大過程群組」，但那其實是沿用 ISO/IEC/IEEE 15288:2023 的結構分類。ISO/IEC 5338:2023 自己更強調的是另一組分類 。
依照與傳統標準的差異程度，把過程分成三型：
▸ 通用過程（Generic）：與 ISO/IEC/IEEE 15288:2023 及 12207:2017 完全相同的過程，AI 沒有帶來任何改變。
▸ 修改過程（Modified）：在既有過程上增刪或調整元素。ISO/IEC 5338:2023 在這類過程的條文中會另設一節，專門說明 AI 情境下的特殊考量。
▸ AI 特有過程（AI-specific）：完全不對應 ISO/IEC/IEEE 15288:2023 及 12207:2017 任何既有過程的新增過程。
說真的，這個三分法對稽核的價值遠高於四大群組。它直接回答了「我現有的 SDLC 稽核程序要改多少」這個問題：通用過程原封不動沿用；修改過程只需要補上 AI 特殊考量的查核問題；AI 特有過程則必須全新設計。
至於結構上的四大群組，仍然沿用 ISO/IEC/IEEE 15288:2023 的分類：
▸ 協議過程（Agreement）：取得、供應。AI 情境下是供應商評估、模型採購條款、資料使用權利。
▸ 組織賦能過程（Organizational Project-Enabling）：生命週期模型管理、基礎設施管理、專案組合管理、人力資源管理、品質管理、知識管理。算力資源與資料平台治理落在這裡。
▸ 技術管理過程（Technical Management）：專案規劃、專案評估與控制、決策管理、風險管理、組態管理、資訊管理、量測、品質保證。模型版本控制與實驗追蹤屬於此群組。
▸ 技術過程（Technical）：從業務或任務分析、利害關係人需求定義、系統需求定義、架構定義、設計定義、系統分析、知識獲取、AI 資料工程、實作、整合、驗證、轉移、確效、持續確效、運作、維護，到處置。AI 特有的過程主要就加在這一層。
◆ 7.3 三個 AI 特有過程：稽核真正的新戰場
ISO/IEC 5338:2023 相對於 ISO/IEC/IEEE 12207:2017 與 15288:2023 最重要的增補，集中在三個 AI 特有的技術過程上。這三個過程在傳統系統稽核流程裡找不到對應項目，也是稽核最容易漏掉的地方。
【一】知識獲取過程（Knowledge Acquisition，ISO/IEC 5338:2023 § 6.4.7）
ISO/IEC 5338:2023 引用 ISO/IEC 2382:2015 的定義：知識獲取是定位、蒐集、精煉知識，並將其轉換為知識型系統可進一步處理之形式的過程。它通常涉及知識工程師的介入，但同時也是機器學習的重要組成。簡單講：AI 系統的行為不完全來自程式碼，而是來自「知識」—— 可能是訓練資料中的統計模式，也可能是專家規則、標註準則、領域本體。ISO/IEC 5338:2023 特別指出，對啟發式模型而言知識獲取的重要性更高，因為知識是被明確編碼進模型的，直接決定模型的正確性。
稽核關注點：標註準則文件是否存在且版本化；標註人員的訓練與一致性檢核（inter-annotator agreement）；領域專家的參與紀錄；知識來源的授權與合法性。
【二】AI 資料工程過程（AI Data Engineering，ISO/IEC 5338:2023 § 6.4.8）
資料的取得、標註、清理、切分、增強、版本控制。這個過程在 ISO/IEC 5338:2023 中被獨立出來，正是因為在傳統軟體生命週期裡，資料只是「輸入」，但在機器學習系統裡，模型行為不是被寫出來的，而是從資料中學出來的 —— 資料本身就是「實作」的一部分。
稽核關注點：訓練／驗證／測試集的切分是否防止資料洩漏（data leakage）；資料血緣（lineage）是否可追溯；個資與敏感屬性的處理是否符合法規；資料集是否有版本識別碼可對應到特定模型版本。這一段可以延伸參考 ISO/IEC 8183:2023《AI 資料生命週期框架》，它把資料這一塊拆得更細。
【三】持續確效過程（Continuous Validation，ISO/IEC 5338:2023 § 6.4.14）
這是三者之中對稽核衝擊最大的一個，也是下一節整節要談的主角。傳統系統上線後進入「維護」狀態，假設功能不會自己改變；但 AI 系統上線後會因為資料漂移、概念漂移、上游模型更新而持續變化。ISO/IEC 5338:2023 把這件事講得很直接：AI 系統的一項關鍵差異特性是「可量測的潛在衰退」—— 模型試圖捕捉的目標行為本身會隨時間改變，而這種偏移可以透過確效的輸入與輸出被量測出來。行為會變不是 AI 獨有，但「可被量測」是。
稽核關注點：是否定義了效能衰退的觸發門檻；漂移偵測是否有告警機制與責任人；再訓練決策是否有審批紀錄；重新確效的結果是否回饋到風險評估。
◆ 7.4 反直覺重點：七個階段還是八個階段？一個被廣泛誤傳的差異，以及它真正的治理意涵
這是我最近被問到最多次的問題，也可能是AI圈流傳最混亂的一段。您大概看過兩種說法。一種說 ISO/IEC 22989:2022 定義了「七個」AI 生命週期階段 —— 這個版本流傳極廣，連 AWS 官方部落格談 ISO/IEC 42001:2023 治理時用的都是七階段圖。另一種說 ISO/IEC 5338:2023 有「八個」階段。於是很多人得出結論：這是兩份標準的差異。老實講，這個結論不對。實際情況比較有趣。
【事實一】ISO/IEC 5338:2023 沒有自己的階段清單
前面 7.1 提過，ISO/IEC 5338:2023 第 5.3 條明白聲明它不規定特定的生命週期模型。它的生命週期示意圖是以 ISO/IEC 22989:2022 的圖為基礎繪製的，並在圖說中明確標註出處。所以「ISO/IEC 5338:2023 的八階段」這種講法，嚴格說是不成立的 —— 階段清單的源頭在 ISO/IEC 22989:2022 身上。
【事實二】ISO/IEC 22989:2022 的條文其實列了八個階段
翻開 ISO/IEC 22989:2022 第 6.2 節，底下的子條款依序是：
6.2.2 構想（Inception）
6.2.3 設計與開發（Design and development）
6.2.4 驗證與確效（Verification and validation）
6.2.5 部署（Deployment）
6.2.6 運作與監測（Operation and monitoring）
6.2.7 持續確效（Continuous validation）
6.2.8 重新評估（Re-evaluation）
6.2.9 除役（Retirement）
八個，清清楚楚。所以「ISO/IEC 22989:2022 是七階段」的說法，也不是來自條文。
【事實三】差異的真正來源是「圖」，不是「條文」
那七階段是從哪來的？來自 ISO/IEC 22989:2022 的範例生命週期模型圖。在那張圖上，「持續確效」被加了一個條件標註 —— 大意是「在持續學習的情況下」。也就是說，它在圖上被畫成一個條件性階段，而不是每個 AI 系統都會經歷的常態階段。於是二手轉述時，很自然地就被省略了。七個常態階段加上一個條件階段，講久了就變成「七個階段」。
【事實四】ISO/IEC 5338:2023 做的事，是把那個條件標註拿掉
這才是關鍵。ISO/IEC 5338:2023 在繪製自己的生命週期圖時，沿用了 ISO/IEC 22989:2022 的階段，但刻意移除了「在持續學習的情況下」這個限定，並且在圖說中明白說明理由：持續確效在沒有持續學習的情境下同樣適用，例如用來偵測資料漂移、概念漂移，或發現技術性故障。所以正確的說法應該是這樣：階段清單來自 ISO/IEC 22989:2022，共八個；ISO/IEC 22989:2022 的範例圖把「持續確效」標為條件性（僅限持續學習）；ISO/IEC 5338:2023 移除該條件，將持續確效視為常態階段。差異不在「幾個階段」，而在「持續確效是不是必要的」。
【為什麼這個差異對稽核是實質的】
ISO/IEC 22989:2022 提供的是概念層的 AI 系統生命週期 —— 它的任務是讓大家對「階段」這個詞有共同定義。既然已經有了一套生命週期，為什麼還需要 ISO/IEC 5338:2023？
答案就在這個條件標註上。當你越了解 AI 系統實際的運作方式，越會發現有些當初看起來合理的設定，在實務上會導出完全相反的稽核結論。採七階段讀法，推論是：我們的模型不做持續學習，權重是凍結的，所以持續確效這個階段不適用於我們 —— 上線通過驗收之後，就進入維護狀態。這個推論非常有說服力，我猜測 ISO/IEC 5338:2023 正是為堵住這個推論才移除條件標註的。
模型凍結，不代表世界凍結。輸入資料的分佈會變（資料漂移），目標變數與特徵之間的真實關係會變（概念漂移），上游的基礎模型可能被供應商靜默更新，資料管線可能因為某個欄位格式調整而悄悄劣化。這些全都與模型是否持續學習無關。一個兩年沒改過一行程式碼的信用評分模型，可能已經在完全不同的族群結構上運作了。
對稽核而言，這一條差異直接決定一個具體的查核判斷：
▸ 若採七階段觀點 → 靜態模型上線後不需週期性重新確效 → 沒有相關證據也不算缺失。
▸ 若採 ISO/IEC 5338:2023 立場 → 所有生產中的 AI 系統，無論是否持續學習，都應有持續確效機制 → 缺乏漂移監測即為控制缺失。
值得注意的是，這個立場與整體監理趨勢是一致的。NIST 於 2026 年 3 月發布的 AI 800-4《Challenges to the Monitoring of Deployed AI Systems》，是美國聯邦層級第一份系統性盤點上線後監測缺口的報告，其核心論點正是：上線前的評估不足以支撐風險決策，監測必須是持續的實務而非一次性關卡。換句話說，ISO/IEC 5338:2023 的這個小改動不是標準委員會的個人偏好，而是整個監理趨勢的縮影。
【給稽核人員的一句話總結】
引用階段模型時，請註明出處為 ISO/IEC 22989:2022；引用「持續確效為常態階段」這個立場時，請註明 ISO/IEC 5338:2023。把兩者混為一談，在正式稽核報告裡是會被挑戰的。
◆ 7.5 八個階段：把過程放到時間軸上
釐清了爭議之後，我們就可以放心使用這組階段作為稽核的時間軸：
① 構想（Inception）
② 設計與開發（Design and Development）
③ 驗證與確效（Verification and Validation）
④ 部署（Deployment）
⑤ 運作與監測（Operation and Monitoring）
⑥ 持續確效（Continuous Validation）
⑦ 重新評估（Re-evaluation）
⑧ 除役（Retirement）
譯名說明：本文採國內慣用譯法，verification 譯為「驗證」、validation 譯為「確效」，因此 verification and validation 為「驗證與確效」、continuous validation 為「持續確效」。國內文獻另有「確認」「驗效」等譯法，引用時建議一併附上英文原文，避免譯名差異造成誤讀。
不過 ISO/IEC 5338:2023 另外提醒了一件稽核人員很容易忽略的事：階段的概念只是為了把有時序關係的活動分組，用來呈現依賴性，並不代表這些活動在時間上或組織上完全分離。以敏捷開發為例，開發與運作是兩個不同階段，卻是同時進行的。一項功能仍然必須先實作、才能驗證、才能部署 —— 依賴關係存在，但階段邊界是模糊的。這對稽核的意義是：不要拿「階段閘門是否依序通過」當作唯一的查核標準。在 DevOps 或 MLOps 環境下，找不到一份標示「第三階段完成」的簽核文件，並不必然代表控制失效；真正該查的是依賴關係有沒有被跳過 —— 有沒有未經驗證與確效就部署的模型版本。另外，ISO/IEC 5338:2023 也指出生命週期的各個階段可以由不同組織擁有與管理（例如資料的取得與提供、機器學習模型、或其他元件的程式碼可能分屬不同實體），而組織也可能依賴其他組織來建置基礎設施或提供生命週期所需的能力。這正是供應鏈稽核的切入點：您的稽核範圍，可能只涵蓋這八個階段中的三個。
從趨勢來看，部署者最被低估的風險就在 ⑥ 這一格。您沒有改任何東西，但供應商改了 —— 而合規責任仍然在您身上。這也是 7.4 那個「靜態模型不需持續確效」推論最危險的應用場景：您以為模型是靜態的，但它其實不是，只是變動發生在您看不見的地方。所以稽核程序裡應該要有一條：供應商模型版本異動的偵測與影響評估機制是否存在。
◆ 7.6 每個階段查什麼、要什麼證據
把八個階段展開成稽核流程，就是下面這張表。用法是：先用第 4 節的範疇門檻決定自己是部署者還是提供者，再決定每一列要查到多深。表格分成三欄。查核點與證據是多數 AI 稽核指引都會提到的部分；真正值得細看的是紅旗那一欄 —— 那些是實務上反覆出現、但在文件審閱階段不容易被發現的樣態。它們的共同特徵是「形式上齊備、實質上失效」，而不是「什麼都沒有」。完全空白的組織其實好查，難的是這一類。
◆ 7.7 角色決定稽核深度：兩套角色語彙要分開用
很多人會問，為什麼 ISO/IEC 42001:2023 這類管理系統標準要特別凸顯角色（role）？因為同樣一張生命週期表，不同角色的稽核重心完全不同 —— 提供者要自證全生命週期的技術查核，部署者則主要證明自己選對了供應商、用對了方法。但這裡有個容易踩到的坑：AI 治理其實存在兩套角色語彙，而它們互不相容。
第一套來自歐盟 AI 法案，是二分法：提供者（Provider）與部署者（Deployer）。這套語彙的目的是分配法律責任，所以它問的是「出事時誰要負責」。第二套來自 ISO/IEC 22989:2022，是六分法：AI 生產者、AI 提供者、AI 客戶、AI 夥伴、AI 主體、相關主管機關。這套語彙的目的是描述生態系，所以它問的是「這個系統牽涉到哪些人」。
老實講，不少稽核報告把兩套混著用 — 前半段引歐盟 AI 法案談提供者義務，後半段引 ISO/IEC 22989:2022 談 AI Provider 的角色，讀起來很順，但論述其實已經斷裂了。因為這兩個「Provider」不是同一件事。歐盟 AI 法案的 Provider 指的是開發並將系統投放市場的一方，比較接近 ISO/IEC 22989:2022 的 AI Producer；而 ISO/IEC 22989:2022 的 AI Provider 指的是供應平臺或服務的一方。至於歐盟 AI 法案的 Deployer，對應到的是 ISO/IEC 22989:2022 的 AI Customer。名稱相同、指涉不同，這在正式稽核報告裡是會被挑戰的。值得注意的是，這兩套語彙並沒有官方對照表，上面的對應是實務上的理解而非標準明文。所以引用時務必註明依據哪一份文件，不要寫成等號。
【實務上怎麼搭配使用】
我的做法是分兩步。
第一步用歐盟 AI 法案界定自己的法律角色，決定稽核要查到多深。部署者可以減輕對模型內部的技術測試，轉而強化供應商服務保證的核查；提供者則必須承擔全生命週期的技術查核責任。這一層決定的是「深度」。
第二步用 ISO/IEC 22989:2022 盤點供應鏈上還有誰，決定證據要向哪個對象索取。稽核人員實際面對的往往不是自己組織的角色，而是上下游的其他角色 —— 資料從哪個夥伴來、模型由誰訓練、決策影響到哪些人。這一層決定的是「廣度」。
【六個角色，各查什麼】
AI 生產者（AI Producer）：設計、開發、訓練模型的一方。稽核聚焦在資料來源的授權鏈、標註準則與一致性檢核、訓練與測試集切分是否防止洩漏，以及模型卡與設計決策紀錄是不是開發過程的產物。最常見的紅旗是模型卡在交付後才補寫 —— 下游拿到的其實是行銷文件，不是技術文件。
AI 提供者（AI Provider）： 供應平臺或服務的一方。稽核聚焦在服務條款與 SLA 是否涵蓋模型版本異動的通知義務、是否提供客戶稽核權、事故通報的管道與時限。紅旗是底層模型靜默更新卻提不出版本對照表。
AI 客戶（AI Customer）： 買來用的一方，也就是歐盟 AI 法案下的部署者。稽核聚焦在實際用途是否與供應商聲明的 intended purpose 一致、輸入資料控制、人類監督者是否具備實質否決權，以及影子 AI 的盤點。紅旗是把「我們只是買來用」當成免責聲明，卻沒察覺已經符合第 25 條的升格條件。
AI 夥伴（AI Partner）：提供資料、系統整合、評估或基礎設施的協力單位。這個角色最容易被稽核跳過，因為他們通常不是合約的直接對手方。但資料轉手兩三層之後，最上游的同意書涵蓋範圍往往查不到，而責任會回到使用資料的人身上。稽核聚焦在授權鏈能不能追溯到最上游、整合商的變更管理、第三方評估者的獨立性。
AI 主體（AI Subject）： 權益受決策影響的個人或群體。這是六個角色裡唯一與組織沒有合約關係的一方，也因此最常被漏掉。稽核聚焦在是否被告知正在與 AI 互動、申訴與人工複核管道是否可及且有人負責結案、決策紀錄保存期是否足以涵蓋申訴期。這裡有個很典型的交叉失效：申訴期照法規訂、銷毀期照保存政策訂，兩個政策各自合規，湊在一起卻讓組織無法回應申訴。
相關監管機關（Relevant Authorities）： 制定法規並監督邊界的一方。這個角色不是被稽核的對象，所以查的是組織如何回應它：法規追蹤機制由誰負責、更新頻率為何、風險分級是否隨法規變動重新評估、通報義務的時限與窗口是否明確指派。紅旗是法規變動已逾半年，風險分級表仍是舊版，且無人被指派追蹤。
從趨勢來看，隨著 AI 供應鏈越拉越長 —— 基礎模型供應商、微調服務商、系統整合商、資料標註外包 —— 單一組織能直接稽核的範圍只會越來越小。這正是 ISO/IEC 22989:2022 這套六分法的價值：它提醒稽核人員，您的稽核範圍可能只涵蓋整條鏈的一小段，而剩下的部分必須靠合約條款與供應商證明來覆蓋。合約裡沒寫稽核權和變更通知義務，後面就查不到東西。
■ 8. 把標準堆起來看：ISO/IEC 5338:2023 在整張地圖上的位置
單獨導入 ISO/IEC 5338:2023 意義有限，它需要與其他標準搭配。這是我目前使用的堆疊視角：
▸ ISO/IEC 42001:2023 — AI 管理系統（可驗證取證，組織層）
▸ ISO/IEC 5338:2023 — AI 系統生命週期過程（系統層，本文重點）
▸ ISO/IEC 23894:2023 — AI 風險管理指引（對應 ISO 31000:2018）
▸ ISO/IEC 22989:2022 — AI 概念與術語（生命週期階段的真正來源）
▸ ISO/IEC 23053:2022 — 機器學習系統框架
▸ ISO/IEC 8183:2023 — AI 資料生命週期框架（把 ②③ 拆得更細）
▸ ISO/IEC 42005:2025 — AI 系統影響評估（對應歐盟的 FRIA 思路）
▸ ISO/IEC TR 5469:2024 — 功能安全與 AI 系統（ISO/IEC 5338:2023 明確指向）
▸ NIST AI RMF 1.0（NIST AI 100-1）— Govern／Map／Measure／Manage 四大功能
有趣的是，NIST AI RMF 與 ISO/IEC 5338:2023 的關係常被誤解為競爭。實際上它們的抽象層次不同：AI RMF 是風險管理功能的組織方式，ISO/IEC 5338:2023 是工程過程的組織方式。稽核可以用 AI RMF 的四大功能當作風險論述的骨架，用 ISO/IEC 22989:2022 與 ISO/IEC 5338:2023 的八個階段當作查核的時間軸 —— 兩者交叉起來就是一張相當完整的稽核矩陣。另外值得一提的是，若您所在的產業有專屬的生命週期標準（例如醫療器材的 IEC 62304:2006），ISO/IEC 5338:2023 建議的做法是把 AI 特有考量與該領域標準並行實施，而不是二選一。這對受高度監理的產業是很重要的一句話 —— 它意味著導入 ISO/IEC 5338:2023 不需要推翻既有的法規遵循架構。
■ 9. 結語：通往負責任 AI 的未來路徑
AI 治理絕非創新的絆腳石，而是建立長期信任的基石。隨著全球監管（如歐盟 AI 法案、瑞士 FINMA 08/2024 規範）日趨嚴謹，企業必須意識到：唯有受控的 AI，才是可持續的 AI。內部稽核應扮演企業的指南針，引導組織在變動的法律框架與技術浪潮中穩健前行。而要做到這件事，光有原則不夠 —— 需要一條可以逐階段對照的生命週期軸線，這正是 ISO/IEC 5338:2023 的貢獻。
從趨勢來看，未來三年 AI 稽核會走向兩個方向。
一是證據自動化 —— 監測日誌、模型版本、確效報告會直接從 MLOps 平台流入 GRC 系統，稽核從「索取底稿」變成「查詢底稿」。
二是持續稽核 —— 既然模型是持續變化的，年度稽核的節奏本身就已經失效，稽核頻率必須跟上模型的重訓頻率。
說穿了，這正是 ISO/IEC 5338:2023 把持續確效從條件階段提升為常態階段的同一個邏輯，只是把它從系統層搬到了稽核層。最後思考：您的組織是否已經準備好，在下一次監管審查前，證明您的 AI 決策是可回溯、可解釋且具備法律問責性的？現在就開始盤點您的 AI 清冊與問責矩陣，別讓治理的真空成為創新的致命傷。
■ 參考來源
▸ISO/IEC 5338:2023, Information technology — Artificial intelligence — AI system life cycle processes
▸ISO/IEC 22989:2022, Information technology — Artificial intelligence — Artificial intelligence concepts and terminology
▸ISO/IEC 23053:2022, Framework for Artificial Intelligence (AI) Systems Using Machine Learning (ML)
▸ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management
▸ISO/IEC 8183:2023, Information technology — Artificial intelligence — Data life cycle framework
▸ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system
▸ISO/IEC 42005:2025, Information technology — Artificial intelligence — AI system impact assessment
▸ISO/IEC TR 5469:2024, Artificial intelligence — Functional safety and AI systems
▸ISO/IEC 2382:2015, Information technology — Vocabulary
▸ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes
▸ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes
▸ISO 31000:2018, Risk management — Guidelines
▸IEC 62304:2006, Medical device software — Software life cycle processes
▸Regulation (EU) 2024/1689 (EU AI Act), Articles 4, 25, 50
▸NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
▸NIST AI 800-4, Challenges to the Monitoring of Deployed AI Systems (2026)
▸FINMA Guidance 08/2024, Governance and risk management in the use of artificial intelligence
▸Global Internal Audit Standards (GIAS 2024), The IIA
▸COSO, Internal Control — Integrated Framework: Generative AI considerations