AI 模型清單範本：追蹤您的組織在生產環境中運行的每個模型

監管機構不接受「我們使用 AI」作為治理立場。他們想要一份清單——每個模型、其版本、其負責人、其風險等級、誰驗證了它，以及上次審查是什麼時候。如果您無法按需提供該清單，您就存在合規差距。

本文為您提供完整範本。複製它，將欄位名稱調整為您的工具，然後今天就開始填寫。

為什麼監管機構要求模型清單

三個主要框架都匯聚到同一個要求：您必須維護您操作的每個 AI 系統的正式登記冊。

SR 11-7（美聯儲 / 美國貨幣監理署） 要求銀行及其控股公司維護業務決策中使用的所有模型的全面文件。「模型」被廣泛定義——任何產生估計或決策的定量方法。這包括信用評分、欺詐偵測、用於貸款發起的聊天機器人，以及任何觸及受監管結果的 LLM 輔助工作流。

歐盟 AI 法案第 11 條 要求高風險 AI 系統在投放市場或投入使用之前提供技術文件。該文件必須在系統整個生命週期內保持最新。對於部署者（使用高風險系統的組織），第 26 條要求維護日誌並實施人工監督——只有在您知道您在運行什麼系統的情況下才有可能。

ISO/IEC 42001（AI 管理體系標準）要求組織建立 AI 系統登記冊作為其 AI 管理體系的一部分。第 6.1.2 條明確要求識別 AI 系統及其相關風險。

對於受上述任何框架約束的組織，清單不是可選的。它是其他一切建立在其上的基礎。

模型清單是什麼（以及它不是什麼）

模型清單是您的組織在生產環境中操作的每個 AI/ML 系統的結構化登記冊。它包括：

• 您內部構建的模型
• 供應商的模型（包括 API 存取的模型，如 GPT-4、Claude、Gemini）
• 微調模型，即使基礎是供應商的
• 在本地和雲端上運行的模型
• 嵌入在您部署的第三方軟體中的模型

它不僅僅是您調用的 API 清單。如果供應商的模型做出或影響業務決策，它就屬於您的清單——包括固定的版本、上次更改的日期，以及如果失敗誰擁有結果。

影子 AI——由個別團隊在正式採購流程之外部署的模型——是最常見的差距。您的清單只有在誠實反映實際運行情況時才有用。

模型清單範本

每個模型部署使用一行。如果同一個模型版本部署在兩個不同的生產環境中（例如，一個用於客戶服務，一個用於內部運營），請創建兩行。

填寫範例行

模型變更日誌範本

對生產中模型的每次變更——版本更新、重新訓練、閾值調整——都必須記錄在案。這與您的主清單表格是分開的；清單顯示當前狀態，變更日誌顯示歷史記錄。

變更類型選項：版本更新 / 閾值調整 / 輸入特徵變更 / 訓練資料更新 / 基礎設施遷移 / 緊急回滾

如何填寫每個欄位

風險等級是大多數組織出錯的欄位。不要根據技術複雜性分配它。根據失敗的後果分配它。影響信用決策的簡單邏輯回歸是高風險的。建議內部會議摘要的複雜 transformer 模型是低風險的。問題是：如果這個模型輸出了錯誤的東西，誰會受到傷害，傷害有多嚴重？

人工監督級別需要與現實相符，而不是理想。如果您的政策說 HITL，但審查員在不到 10 秒內橡皮圖章 98% 的輸出，請誠實記錄——政策與實踐之間的差距本身就是一個發現。

第三方 API 模型的版本要求您固定模型版本，而不是使用「最新」別名。如果您在調用 gpt-4 而不是 gpt-4-0613，您不知道您實際上在運行什麼模型。固定版本，記錄它們。

監管範圍應由您的法律或合規團隊填寫，而不是工程師。工程師知道模型做什麼；法律知道哪些法規附加到該活動。

維護清單

未維護的模型清單比沒有清單更糟糕——它創造了虛假的信心，並會積極誤導稽核員。

最低審查節奏：

• 高風險系統：每季度
• 中等風險系統：每半年
• 低風險系統：每年
• 任何生產事件後：5 個工作日內

新清單條目的觸發因素（不僅僅是對現有行的更新）：

• 新模型部署到生產環境
• 現有模型應用於新的業務目的或新的資料類型
• 模型從一個部署環境移至另一個（預演 → 生產）

更新現有行的觸發因素：

• 版本變更
• 負責人變更
• 驗證狀態變更
• 退役

常見錯誤

將清單視為一次性項目。 組織為了稽核建立清單，然後讓它過時。監管機構會檢查最近的更新。18 個月前最後一次更新的清單是治理差距的證據，而不是治理。

低報影子 AI。 個別團隊啟動 AI 工具——Copilot 整合、供應商特定的 AI 功能、自定義 API 整合——而不經過正式採購。直接調查業務部門，而不僅僅是 IT。問：「您的團隊使用的任何 AI 工具不是由中央 IT 管理的嗎？」答案幾乎總是肯定的。

將模型與使用案例混為一談。 在兩個不同環境中部署的相同模型版本（例如 GPT-4o）——面向客戶的支援聊天與內部法律文件摘要——代表兩個不同的清單條目，具有潛在不同的風險等級、監督要求和監管範圍。

不按版本追蹤 API 存取的模型。 「我們使用 OpenAI」不是清單條目。具體的模型 ID、固定的日期以及任何後續更新都是所需信息。

連接到您的資料管線

模型變更日誌列——特別是變更類型、更改者和驗證完成——直接映射到良好儀器化資料處理管線的輸出。如果您的訓練資料管線追蹤每個帶有操作員歸因和時間戳的轉換，您已經擁有了變更日誌的原材料。差距通常是將該操作日誌連接到治理登記冊。

Ertas Data Suite 生成每個資料轉換步驟的完整、不可變稽核追蹤——誰運行了它，什麼時候，什麼改變了——直接輸入模型變更日誌，無需手動輸入。

預約 Ertas 探索通話 →

後續步驟

1. 匯出您環境中當前運行的所有模型列表（與 ML Ops 和 IT 合作）
2. 使用您的分類政策為每個模型分配風險等級（或採用上述三層框架）
3. 為每個模型識別負責人——如果沒有人負責，那就是您的第一個治理發現
4. 在 90 天內安排所有高風險系統的第一次正式審查
5. 實施變更通知流程，使清單保持最新

清單是基礎。模型卡片、驗證文件、稽核追蹤和事件響應都引用它。做好它，您的其餘治理計劃就有了依靠的基礎。