AI 系統清冊怎麼做？盤點模型、資料、Owner、風險與退場
組織若不知道有哪些 AI 系統，就無法管理權限、供應商、成本、事件與停用。AI 清冊不應只列工具名稱；一項可用的紀錄至少要回答用途、owner、使用者、資料、模型與供應商、權限、測試、事件、複查與退場。
清冊範圍怎麼定
包含正式上線、PoC、部門試用、嵌入既有 SaaS 的 AI 功能、外部 API、自架模型與已停用但仍保存資料的系統。不要只盤 IT 採購：員工用個人帳號或部門信用卡購買的工具也可能形成 Shadow AI。
NIST AI RMF Playbook 的 Govern 1.6 將 AI system inventory 描述為與系統或模型相關的有組織資料，可包含文件、事件計畫、資料字典、程式連結與相關人員。NIST 也建議依風險安排資源，但 Playbook 是自願性建議，不是官方登錄或認證。
每筆清冊的核心欄位
身分與用途
內部 ID、系統名稱、狀態、版本、部門、使用者、受影響者、允許與禁止用途。名稱不能只寫「客服 AI」，要能區分測試與正式環境。
Owner 與聯絡
業務、技術、資料、供應商與事件窗口。每個關鍵責任指定最終 owner，不把所有問題都填同一個工程師。
技術與依賴
模型、平台、部署、提示、RAG、外部工具、資料庫與上下游系統。記錄版本和可替換性，才能在供應商事故或價格變更時判斷影響。
資料與權限
輸入、輸出、知識來源、資料分級、保存、刪除、區域、角色與服務帳號。個資與機密的實際義務由適任人員依法律、契約與情境判斷。
影響、測試與營運
最壞可合理預見後果、人工關卡、測試門檻、監控、事件、近失事件、最近測試與下次複查。若清冊只有風險顏色沒有證據與處置，就很難支持決策。
退場
匯出、刪除、回到人工、替代系統與停用責任。停用不等於刪掉入口，還要處理帳號、金鑰、日誌、備份與衍生資料。
從零開始的盤點流程
先發出不究責的部門問卷，搭配採購、費用、身分、SaaS 與技術資料交叉核對。把未知標成未知，不因沒有完整答案就排除。初次可使用AI 系統清冊模板統一欄位，再依組織增加特定法規或產業欄位。
接著用AI 風險初篩工具做工作分流：低影響項安排週期複查，涉及敏感資料、高影響決策或外部動作的系統進入加強審查。初篩不是法律或官方分類。
清冊如何保持有效
指定清冊 owner，設定定期複查，也讓模型、提示、資料、供應商、權限、用途與事件變更能觸發更新。將清冊 ID 帶入採購、變更、日誌與事件文件，避免每個系統在不同表格用不同名稱。
ISO/IEC 42001 的官方說明以 Plan-Do-Check-Act 表達 AI 管理系統持續改善。清冊也應支援「現況、控制、檢查、改善」循環，不是一次性資產盤點。
若初次盤點發現大量未核准工具，依Shadow AI 治理指南設申報與替代路徑；發生事件時，用AI 事件紀錄模板連回同一清冊 ID。