💡 先搞懂問題
現在很少有組織從頭到尾自己做 AI。常見的樣子是：文字生成呼叫外部的大型語言模型 API，自家的小模型在雲端機器學習平台上訓練，訓練資料的標註外包給專門的公司，最後把整個功能包成產品賣給企業客戶。每一段都有人負責「一部分」，但如果沒有事先說好，出事時每一方都能找到理由說「那不是我的範圍」。
更麻煩的是，外部模型的變化你常常看不到。供應商可能更新模型、修改服務條款、改變輸入資料的使用方式，同樣的提示突然得到不同結果；而面對客戶的是你，客戶與主管機關只會來找你。
ISO/IEC 42001 附錄 A.10 第三方與客戶關係（Third-party and customer relationships）用三項控制處理這件事：A.10.2 責任分配（Allocating responsibilities），在組織、合作夥伴、供應商、客戶之間把 AI 生命週期的責任分清楚；A.10.3 供應商（Suppliers），確保買來的模型、服務與資料符合組織負責任 AI 的做法；A.10.4 客戶（Customers），在提供 AI 產品或服務時考慮客戶的期待與需求。另外，A.4.4 工具資源（Tooling resources）要求記錄 AI 系統用到的工具，外部模型的提供者、名稱、版本與使用條款也包含在內，供應商改版時才知道哪些系統受影響。
生活比喻：團膳便當公司
一家團膳公司每天替科技園區的企業供應 3,000 個便當。醬料向中央廚房採購，烹調在租來的共享廚房進行，洗菜切菜外包給前處理工廠，做好的便當送到企業客戶的員工餐廳。某天有員工吃完腹痛送醫，各方開始互推：中央廚房說醬料出廠檢驗合格，共享廚房說冰箱溫度是租戶自己設定的，前處理工廠說照規格洗過了，企業客戶說便當放在室溫兩小時，是因為那天午休延後。
如果事前講清楚，就不會變成這樣：醬料配方變更由中央廚房提前通知；共享廚房負責設備正常運作，租戶負責自己的溫度設定；前處理工廠照衛生規格作業並留下紀錄；團膳公司負責整體品質、標示過敏原，並告訴客戶「送達後兩小時內食用」；客戶負責按時發放。合約裡也寫明，任何一方發現問題要在多久內通知誰。
這個比喻有三處和 AI 不同。第一，食品的責任有很大一部分由食品安全法規明定；AI 價值鏈的責任目前多數仍靠合約與組織自己的決定，法規只在特定情境下明確規定，例如歐盟 AI 法對高風險 AI 系統與通用目的 AI 模型的義務。第二，醬料配方改了，吃得出來；外部模型改版卻可能無聲無息，只有固定的測試題組才抓得到差異。第三，「共同負責」不代表各管一半、模糊帶過，而是每一方負責清楚的一段，交界處也要寫明。
🎮 互動實驗室一：責任分配表
把每一項責任放進最適合的格子。桌機可以直接拖曳；手機或平板請先點一下責任卡，再點要放的格子。「共同」代表雙方各負責清楚的一段，不是「大家一起想辦法」。放錯會說明原因，可以再試一次。
我方
供應商
客戶
共同
🎮 互動實驗室二：供應商評估問卷
同一家公司打算再引進另一家外部模型供應商。下面是同事提出的 18 個候選問題，但問卷最多只能放 10 題，否則供應商不會認真回答。點一下把問題加入問卷，再點一次移除，每點一題都會說明它是不是關鍵。選好後按「完成問卷」，看看還漏了哪些面向。
📘 原理補完
A.10 三項控制與相關做法
三項控制處理的是同一條價值鏈的不同位置。下表用白話整理，條文原文請以 ISO 正式出版品為準；與 ISO 27001 的對照是依主題整理的參考，ISO 沒有發布兩份附錄 A 之間的官方對照表。
| 控制 | 處理的問題 | 常見做法 | 稽核常看的證據 | ISO 27001 對照 |
|---|---|---|---|---|
| A.10.2 責任分配 | AI 生命週期各段工作由組織、夥伴、供應商、客戶中的誰負責 | 價值鏈圖、責任分配矩陣（RACI）、把關鍵責任寫進合約 | 責任矩陣、對應的合約條款；抽一項活動追問「誰負責、怎麼證明」 | 5.19、5.20 供應商關係與協議中的資安 |
| A.10.3 供應商 | 買來的模型、API、資料與服務是否符合組織負責任 AI 的做法 | AI 供應商分級、評估問卷、合約條款、版本變更後回歸測試、定期重新評估 | AI 供應商清單、評估紀錄、合約、最近一次供應商變更時的處理紀錄 | 5.19 到 5.22 供應商關係，5.23 雲端服務 |
| A.10.4 客戶 | 提供 AI 產品或服務時，是否考慮客戶的期待、法規環境與治理需求 | 售前需求訪談、客戶 AI 資訊包（用途、限制、資料處理、責任分工）、變更通知 | 需求紀錄、提供給客戶的文件、合約條款、客戶回饋處理紀錄 | 沒有直接對應，27001 多從採購方角度看供應鏈 |
| A.4.4 工具資源 | AI 系統用了哪些演算法、框架、外部模型，版本為何 | 模型卡、軟體物料清單（SBOM）、記錄外部模型的提供者、名稱、版本與使用條款 | 抽一個上線模型，請團隊說明所用的外部模型版本與授權條件 | 部分對應 5.9 資產清冊 |
標準要求的是：責任要被分配、要有供應商管理的流程、提供 AI 產品或服務時要考慮客戶需求。至於責任矩陣用什麼格式、評估問卷問哪些題、供應商多久重新評估一次、合約要談到多細，標準都沒有規定，由組織依供應商的重要性、資料敏感度與議價能力自行決定。這和 ISO 27001 的供應商管理精神一致，已經有供應商評鑑制度的組織，通常在既有流程上加入 AI 專屬題目即可，不必另起一套。
把價值鏈責任落地的步驟
- 畫出價值鏈：列出每個重要 AI 系統用到的外部模型、API、平台、資料與外包服務，以及下游的客戶與使用者。
- 判定角色：組織在每個系統中是提供者、使用者，還是兩者皆是。角色概念可參考 ISO/IEC 22989；若產品會進入歐盟市場，也要對照歐盟 AI 法的提供者（provider）與部署者（deployer）定義，兩套名詞不能一對一換算。
- 建立責任矩陣：把資料、訓練、驗證、部署、監控、人類監督、日誌、事故通報、使用者告知、法規遵循等活動分配出去，「共同」的項目要寫出各自負責的那一段。
- 評估供應商：依風險分級決定評估深度，問 AI 特有的問題，記錄評估結果與接受理由。
- 寫進合約：資料使用、變更通知、事故通報、配合稽核、轉包限制、終止時資料返還等條款；大型供應商的標準條款改不了時，評估能否接受，把剩餘風險記入風險評鑑並設計補償措施。
- 持續監督與回饋客戶：追蹤供應商的版本與條款變更、跑回歸測試；我方因此改變行為時，依 A.10.4 通知受影響的客戶，並更新 A.4.4 的工具資源紀錄。
法規提醒
歐盟 AI 法對價值鏈有明確安排：通用目的 AI 模型的提供者要向下游提供者提供必要的資訊與文件，這部分義務自 2025 年 8 月 2 日起適用；部署者若以自己的名義推出、實質修改高風險 AI 系統，或改變其預期用途使其成為高風險，可能被視為提供者而承擔對應義務。高風險相關義務的適用時程經 2026 年的數位綜合法案調整延後，實際適用以歐盟官方公告與專業法律意見為準。台灣方面，金管會的金融業運用 AI 指引也提到對第三方 AI 業者的監督與責任分工；人工智慧基本法把「問責」列為基本原則，具體義務要看後續子法與各主管機關規範。
常見誤解
用大廠的 API，風險就轉給大廠了：供應商只對它承諾的部分負責，面對客戶、決定怎麼用模型的是你。模型輸出被你的產品拿去做什麼、使用者有沒有被告知、出錯時怎麼通知客戶，都是你的責任。
供應商有 42001 或 27001 證書，就不用評估：證書可以降低評估成本，但要看驗證範圍是否涵蓋你採購的那項服務，也要看驗證機構是否經認證。證書代表供應商有一套管理系統，不代表它的模型適合你的用途，也不會回答「我的資料會不會被拿去訓練」這類具體問題。
共同負責就是大家一起負責：責任矩陣上只寫「共同」而沒有拆開，等於沒有分配。內容過濾、雲端環境安全、事故調查這類跨界的工作，最需要寫清楚各自那一段。
開源模型沒有供應商：從公開模型庫下載的模型也是外部來源，要檢查授權條款、模型來源是否可信、已知限制與版本，並記錄在工具資源裡。
稽核常見的不符合
工程師用個人帳號或公司信用卡訂閱外部 LLM API，沒有經過採購與供應商評估；沿用舊的資安供應商問卷，完全沒問資料會不會被用來訓練；供應商更新服務條款後允許使用客戶資料改善模型，組織沒有察覺；責任矩陣寫得很完整，合約裡卻沒有對應條款；組織以為供應商負責內容過濾，供應商認為那是應用端的事；底層模型換了版本，沒有回歸測試，也沒有通知依賴原有行為的客戶。
✅ 自我檢測
以下 6 題都是原創情境題，選完會立即顯示對錯與解析。目前得分：0 / 6