企業團隊AI治理政策範本
涵蓋模型清單、風險層級、人工監督要求、供應商管理和事件響應的完整AI治理政策範本。根據您的組織進行調整。
書面AI治理政策對企業組織來說不再是可選的。EU AI Act 要求高風險系統有記錄的治理過程。網絡保險承保機構開始將其作為承保條件。董事會在同行組織發生高知名度AI失敗後要求提供。法律部門要求提供，因為監管風險現在是董事會級別的關注，而非僅僅是IT關注。
本範本涵蓋每個基本部分。以下政策文本旨在被調整——用您組織的具體信息填入括號字段，調整風險閾值以符合您的行業和監管背景，並在內部發布之前讓法律進行審查。
如何使用本範本
不要試圖同時實施每個部分。從第 3 節和第 4 節開始——風險分類和模型清單。這兩個部分為其他所有內容所引用的基礎提供了基礎。然後構建治理結構（第 2 節）和人工監督要求（第 5 節）。第 6 至 10 節可以隨著您的計劃成熟而跟進。
組織AI治理政策
文件 ID：[POLICY-AI-001] 版本：[1.0] 生效日期：[日期] 下次審查日期：[日期 + 1 年] 政策負責人：[AI風險官 / CTO / CISO] 批准者：[董事會 / 執行委員會]
第 1 節：範圍和定義
1.1 範圍
本政策適用於[組織名稱]運營的所有AI系統，包括：
- 內部開發的AI系統
- 從第三方供應商採購或通過 API 訪問的AI系統
- 組織使用的第三方軟件產品中嵌入的AI功能
- 承包商或合作夥伴代表組織運營的AI系統
本政策涵蓋任何使用機器學習、大型語言模型或影響業務成果、客戶交互、員工決策或合規義務的自動化決策邏輯的系統。
1.2 定義
| 術語 | 定義 |
|---|---|
| AI系統 | 任何使用機器學習、統計建模或基於規則的自動化來產生影響組織決策或客戶結果的輸出（預測、分類、生成內容、決策）的軟件系統 |
| 高風險AI | 在錯誤可能對個人造成重大損害、創造法律責任或觸發監管執行的背景下運行的AI系統。分類標準見第 3 節 。 |
| 模型 | AI系統核心的訓練工件——從輸入產生輸出的權重和參數。與圍繞它構建的應用程序不同。 |
| 人機協作（HITL） | 人工在採取任何重要行動之前審查和批准每個AI輸出的監督配置 |
| 人工監控（HOTL） | AI自主操作但人工監控輸出並具有定義的覆蓋權力的監督配置 |
| 無人監督（HOOTL） | 沒有對個別輸出進行人工審查的自動化配置；人工僅審查總體性能指標 |
| 審計跟蹤 | AI系統輸入、輸出、處理步驟、人工審查決策和系統變更的不可變、帶時間戳的記錄 |
| 模型清單 | 組織在運營中所有AI系統的正式登記冊，如第 4 節所定義 |
第 2 節：治理結構
2.1 AI治理委員會
AI治理委員會（AGC）是AI政策、風險容忍度和升級決策的主要決策機構。
- 組成：首席技術官、首席風險官、首席法律官、首席信息安全官和輪換的業務部門代表
- 會議頻率：季度常規會議；P0/P1 事件或重大政策決策時臨時召開
- 決策權力：批准高風險AI系統部署；設置風險容忍度閾值；批准政策變更；審查 P0 和 P1 事件的事件報告
2.2 AI系統負責人
模型清單中的每個AI系統都必須有一個命名的AI系統負責人。
- 職責：維護準確的清單條目；確保驗證按計劃完成；在定義的 SLA 內響應事件；確保按規定實施人工監督；當風險層級或範圍更改時向 AGC 升級
- 分配：AI系統負責人在模型清單注冊時分配，必須由相關業務部門負責人批准
2.3 AI風險官
AI風險官對AI治理計劃有效性承擔企業級問責。
- 職責：維護AI治理政策；監督模型清單；每季度向 AGC 報告計劃狀態；與外部審計師和監管機構協調；監控監管變化並在重大變化後 30 天內更新政策
第 3 節：AI風險分類
所有AI系統在模型清單注冊時必須被分類到三個風險層級之一。AI系統負責人提議層級；AI風險官確認或調整。
第一層——高風險
影響個人訪問服務、就業機會、醫療保健結果、法律地位、金融產品或教育機會的系統。還包括根據 EU AI Act 附件三分類為高風險的任何系統，或在受監管金融背景下根據 SR 11-7 作為模型的任何系統。
示例：貸款資格篩選、員工績效評分、醫療分診支持、具有個人級別建議的合同審查、具有賬戶級別後果的欺詐檢測。
必需的控制：
- 人機協作監督（HITL）——在採取任何重要行動之前進行人工批准
- 完整的審計跟蹤（不可變、帶時間戳，最低 [X] 年保留）
- 季度驗證
- 記錄的模型卡
- 在部署之前在模型清單中注冊
第二層——中等風險
內部生產力工具、內部使用的內容生成、沒有個人級別後果的分析儀表板，以及產生建議而非決策的面向客戶的工具。
示例：內部文件摘要、銷售預測儀表板、客戶支持聊天機器人（帶有人工升級路徑）、會議轉錄和摘要。
必需的控制：
- 帶有定義覆蓋過程的人工監控（HOTL）監督
- 事件日誌記錄
- 半年驗證審查
- 在部署後 [X] 天內在模型清單中注冊
第三層——低風險
對個人沒有直接影響、容錯率高且沒有監管範圍的系統。
示例：垃圾郵件過濾器、自動完成建議、內容標籤建議、內部搜索排名。
必需的控制：
- 基本輸入/輸出日誌記錄
- 年度審查
- 在部署後 [X] 天內在模型清單中注冊
層級升級：如果第二層或第三層系統被修改為影響個人級別的結果，或者如果其輸出被用於為第一層決策提供信息，它必須重新分類。AI系統負責人負責識別和報告層級升級觸發因素。
第 4 節：模型清單要求
4.1 注冊要求
所有AI系統必須在[組織名稱]模型清單中注冊：
- 第一層系統：在部署到生產之前
- 第二層系統：在部署後 [10] 個工作日內
- 第三層系統：在部署後 [30] 個工作日內
影子AI（在正式 IT 採購流程之外部署的系統）必須在發現後 [30] 天內報告並注冊。AI系統負責人和業務部門負責人共同負責識別和報告影子AI。
4.2 必需的清單字段
完整字段規格和填充示例請參見AI模型清單範本。至少，每個清單條目必須包括：模型 ID、模型名稱、版本、類型、供應商/來源、部署環境、業務目的、風險層級、負責人、驗證狀態、最後驗證日期、下次審查日期、監管範圍、人工監督級別和事件日誌鏈接。
4.3 審查節奏
| 風險層級 | 最低審查節奏 |
|---|---|
| 第一層（高風險） | 季度 |
| 第二層（中等風險） | 半年 |
| 第三層（低風險） | 每年 |
| 任何層級（事件後） | 在事件關閉後 5 個工作日內 |
第 5 節：人工監督要求
人工監督要求由風險層級確定，並在部署之前使用 HITL 工作流程設計工作表 實施 。
第一層系統：在採取任何影響個人的行動之前，需要人工批准。審查者必須有訪問：AI輸出、產生它的輸入、模型版本和相關政策背景。必須定義和監控審查 SLA。必須追蹤覆蓋率。
第二層系統：需要帶有定義覆蓋過程的人工監控。監控包括：定期輸出抽樣、異常輸出模式的自動警報，以及審查者識別的關注問題的記錄升級路徑。
第三層系統：帶有輸出日誌記錄和總體性能監控的自動化操作是允許的。如果第三層輸出被用作第一層或第二層系統的輸入，完整管道在監督目的上被視為第一層。
自動化偏差預防：所有具有人工審查的系統必須實施自動批准決策的隨機回顧性審查。最低回顧性審查率：[5]%。偏離基線超過 [20]% 的覆蓋率偏差觸發閾值設置的審查。
第 6 節：供應商管理
6.1 部署前評估
在使用其技術部署任何AI系統之前，必須使用 AI供應商評估記分卡 對所有AI供應商進行評估。這包括：商業 API 提供商、SaaS 產品中嵌入的AI和存在供應商關係的開源基礎模型。
最低可接受的記分卡總分：3.0 總體。沒有任務關鍵的第一層系統可以依賴在維度 2（審計和日誌記錄）或維度 4（數據治理）中得分低於 3.0 的供應商。
6.2 持續評估
所有活躍供應商需要年度重新評估。以下事件在年度周期之外觸發即時重新評估：
- 供應商收購或控制權變更
- 供應商數據治理條款的重大變更
- 影響第一層系統的供應商模型更新
- 涉及供應商的任何監管行動
6.3 合同要求
在使用供應商模型部署任何第一層AI系統之前，以下內容必須以書面形式確認：
- 確認數據處理條款的數據處理協議或等效文件
- 確認組織的數據不用於模型訓練（或明確退出）
- 版本鎖定可用性和變更通知承諾
- 符合組織保留要求的日誌導出功能
第 7 節：數據治理
與AI系統一起使用的訓練數據和推論時數據必須遵守組織的數據分類政策。
- PHI（受保護的健康信息）和PII（個人身份信息）：在任何AI系統（訓練或推論）中使用之前，需要隱私官的明確AI處理批准
- 特權數據（法律、財務、商業機密）：在任何AI系統中使用之前，需要相關職能負責人和法律部門的批准
- 第三方數據：在包含在訓練數據集或推論管道之前，必須審查許可條款，確認允許AI使用
在沒有確認供應商處理義務的批准數據處理協議的情況下，不得將任何個人數據發送給第三方AI供應商。
第 8 節：審計跟蹤和日誌記錄
第一層系統：每次推論的所有輸入、輸出、模型版本、時間戳和人工審查決策必須記錄。日誌必須不可變（防篡改）、UTC 時間戳，並存儲最少 [X 年按適用法規]。
第二層系統： 所有輸入、輸出、模型版本和時間戳必須記錄。收到人工審查的任何案例的人工審查決策必須記錄。最低保留期：[X 年]。
第三層系統：必須記錄總體性能指標。最低保留期：[1 年]。
日誌訪問限於授權人員。日誌必須根據請求對AI風險官、內部審計和授權監管機構可用。日誌基礎設施必須包括防止意外丟失的保護。
第 9 節：事件響應
AI事件是AI系統產生導致或造成對個人的意外傷害、監管違規、重大財務損失或重大聲譽風險的輸出的任何事件。
9.1 嚴重性級別
| 嚴重性 | 定義 | 初始響應 SLA |
|---|---|---|
| P0——關鍵 | 物理傷害；財務損失超過 $[10萬]；監管 違規；1,000 人以上受到影響 | 在 1 小時內通知AI風險官 |
| P1——高 | 特定群體的系統性錯誤；發現的合規差距；如果公開則存在聲譽風險 | 在 4 小時內通知AI風險官 |
| P2——中 | 輸入子集的錯誤輸出；沒有立即傷害 | 在 24 小時內通知AI系統負責人 |
| P3——低 | 質量退化；沒有個人傷害；沒有合規影響 | 在 [5] 個工作日內記錄和審查 |
9.2 響應過程
對所有 P0 和 P1 事件遵循 AI事件響應操作手冊。關鍵步驟：在補救之前保留證據；在遏制之前確認範圍；P0/P1 通知法律和合規；在 [10] 個工作日內進行事後審查。
9.3 通知要求
- 董事會/執行通知：P0 在 24 小時內
- 監管通知：按適用法規（EU AI Act、GDPR 第 33 條、HIPAA 違規通知規則）
- 個人通知：如果個人受到錯誤AI決策的影響，法律將就通知義務提供建議
第 10 節：政策審查和更新
本政策由AI風險官每年審查，並由AI治理委員會批准。
AI風險官將在以下任何情況發生後 30 天 內更新本政策：
- 適用法規的重大變更（EU AI Act 實施行為、SR 11-7 指導更新、NIST AI RMF 修訂）
- 需要政策級別響應的 P0 事件及其發現
- 董事會或執行指示
- 組織AI使用配置文件的重大變更（新的高風險使用案例、新的受監管市場）
所有政策更新都進行版本控制。以前版本保留 [5] 年。
實施指南
最常見的實施失敗是試圖一次性構建整個治理計劃。從這裡開始：
第 1 個月：實施第 3 節（風險分類）。對目前生產 中的每個AI系統進行分類。這揭示了您的第一層系統，並告訴您最緊迫的差距在哪裡。
第 2 個月：實施第 4 節（模型清單）。注冊每個系統。接受您的第一個清單將是不完整的——構建它的過程將揭示您不知道存在的影子AI。
第 3 個月：實施第 2 節（治理結構）。為每個注冊系統分配AI系統負責人。首次召集AI治理委員會。審查第一層系統並確認監督控制已到位。
第 4-6 個月：實施第 5-8 節（監督、供應商管理、數據治理、日誌記錄）。這些建立在前三個月建立的基礎上。
Ertas Data Suite 的內置審計跟蹤和操作員日誌記錄直接滿足第 4 節和第 8 節的要求——每個數據轉換都記錄了時間戳和操作員 ID，無需額外工具即可生成本政策所要求的不可變審計記錄。
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
AI Model Governance in Production: The Complete Enterprise Guide
Model governance isn't a compliance checkbox — it's the operational framework that determines whether your AI is accountable, auditable, and correctable. Here's what it actually requires.
AI in High-Stakes Environments: What Responsible Deployment Actually Requires
High-stakes AI isn't just about better models — it's about accountability, oversight, and the infrastructure to catch and correct failures before they cause harm.
The EU AI Act's High-Risk System Requirements: What They Demand and What They Don't Tell You
The EU AI Act's Annex III defines high-risk AI categories. If you're deploying in healthcare, legal, finance, or HR, you're almost certainly in scope. Here's what compliance actually requires.