金融服務AI治理框架：SR 11-7、模型風險與監管期望

金融服務AI治理有良好的監管基礎。SR 11-7——美聯儲關於模型風險管理的指導意見——自 2011 年以來一直管理定量模型驗證，並直接適用於用於重要金融決策的AI系統。OCC 公告 2011-12 將等效期望延伸到國家銀行。CFPB 的公平借貸指導適用於用於信貸決策的AI。EU AI Act 的高風險分類涵蓋了大多數影響消費者權利的金融AI。

這不是一個新興的監管領域。金融監管機構有明確的期望。審查員在詢問AI治理。問題不是您的AI是否需要治理框架——而是您的框架是否符合監管標準。

---

SR 11-7：模型風險管理基礎

SR 11-7 將模型定義為「應用統計、經濟、金融或數學理論、技術和假設將輸入數據處理為定量估算的定量方法、系統或方法」。大多數用於信貸、風險、交易和合規職能的AI系統完全符合這個定義。

SR 11-7 的三個要求適用於AI模型：

模型開發和實施：銀行必須了解模型的概念合理性、用於開發的數據質量、執行的測試和限制。對於AI模型，這意味著記錄訓練數據來源、驗證方法論、性能指標和已知失敗模式——而非僅僅是基準測試性能。

模型驗證：對模型的概念合理性、數據質量和性能進行獨立審查。關鍵是，驗證功能必須獨立於模型開發和使用功能。SR 11-7 將此稱為「有效挑戰」——能夠在沒有組織壓力驗證的情況下質疑模型假設、數據選擇和性能聲明。AI模型需要與傳統定量模型相同的獨立性。

治理和控制：組織範圍內的模型風險管理監督。這包括維護模型清單、追蹤模型變更、根據重要性定義風險層級（高/中/低），以及確保模型變更在部署之前通過適當的審查。

---

模型清單要求

用於重要金融決策的每個AI模型必須在您的模型清單中。「重要」意味著輸出影響信貸決策、風險評估、監管資本計算、交易決策或面向客戶的建議。

對於每個模型，清單應記錄：

• 模型名稱和唯一識別符
• 所有者（業務線）和開發者（內部或供應商）
• 模型目的及其影響的決策
• 根據重要性和複雜性的風險層級（高/中/低）
• 模型類型（統計、ML、深度學習、LLM）
• 訓練數據描述和日期
• 最後驗證日期和結果
• 當前狀態（活躍 / 審查中 / 退役）
• 已知限制和批准的使用條件
• 如適用的第三方供應商關係（包括供應商的模型文件義務）

監管機構期望模型清單完整、最新且對審查員可訪問。清單中的空白——生產中未記錄的模型——是重大審查發現。

---

金融服務中特定AI的治理挑戰

SR 11-7 是為統計模型編寫的。AI和機器學習系統呈現了 2011 年指導未完全預見的額外治理挑戰，審查員越來越關注這些挑戰。

可解釋性：傳統統計模型（邏輯回歸、評分卡模型）產生可解釋的輸出——您可以將信貸決策追溯到特定輸入變量及其系數。許多AI模型，特別是深度學習和大型語言模型，本質上不產生這種可解釋性。對於消費者信貸決策，ECOA 和 Regulation B 要求識別拒絕具體原因的不利行動通知。用於信貸決策的AI系統必須產生符合這一標準的解釋，這可能需要在基礎模型之上添加額外工具（SHAP 值、LIME、基於注意力的解釋）。

分佈偏移：在歷史數據上訓練的AI模型在市場條件、客戶人口統計或經濟條件發生變化時可能表現不同。在疫情前數據上訓練的信貸模型在疫情期間表現不佳——但失敗是漸進的，從總體性能指標中不立即可見。金融AI治理必須包括分佈偏移監控：追蹤模型輸入的分佈是否從訓練分佈漂移，作為性能退化的領先指標。

供應商模型不透明：許多金融服務AI產品建立在機構無法完全訪問訓練數據、模型架構或驗證結果的供應商管理模型上。SR 11-7 要求機構對供應商模型進行適當的盡職調查，不能將模型風險管理完全委托給供應商。如果您的AI供應商無法提供足夠的模型文件，您就無法驗證模型以滿足 SR 11-7 標準——您可能無法將其用於重要決策。

模型變更管理：雲端AI API 在沒有相當於 SR 11-7 要求的正式變更控制流程的情況下更新其模型。當 API 提供商更新您端點後面的模型時，您生產中的模型可能與經過驗證的模型不同。這是一個模型風險管理失敗——您在運行未驗證的模型。要求變更通知和測試窗口的合同條款解決了這個問題，或者完全擁有模型消除了這個問題。

---

有效挑戰要求

SR 11-7 的有效挑戰要求是AI部署中最常被違反的治理結構。構建或使用模型的團隊不應是驗證它的團隊。驗證者必須具有：

• 在組織上獨立於模型開發團隊
• 訪問模型文件、訓練數據和性能記錄
• 要求模型變更或撤銷批准的權力
• 執行有意義的獨立測試的資源

對於AI系統，有效挑戰要求驗證者可以在獨立測試數據上重新運行模型，足夠了解訓練管道以識別概念合理性問題，並評估人口統計子組之間的性能，以用於公平借貸目的。

實際實施：清楚地定義驗證功能（內部模型風險組、外部驗證者或組合）。定義開發團隊必須向驗證者提供的文件。按風險層級建立驗證計劃（高風險模型：每年；中等：每兩年）。記錄驗證發現、管理層回應和補救時間表。

---

公平借貸和算法偏差

用於信貸決策的AI受 ECOA（平等信貸機會法）和公平住房法的約束，這些法律禁止基於受保護特徵的信貸歧視。CFPB 和聯邦銀行監管機構期望金融機構監控AI信貸模型的差異影響——當模型產生不成比例地損害受保護群體的結果時，即使沒有歧視意圖。

AI模型的公平借貸治理要求：

差異影響測試：在部署之前和定期間隔，測試受保護類別（種族/民族、性別、國籍、年齡）的模型輸出，以識別不成比例的結果。「差異影響」的閾值遵循公平借貸先例——通常 80% 或更高的差異影響比率觸發審查。

代理變量分析：AI模型可以學習使用與受保護特徵相關的代理變量（郵政編碼、姓名、購物模式）。治理必須包括分析模型是否通過代理有效使用了禁止的特徵。

不利行動解釋：確保模型可以產生不利行動通知，根據 Regulation B 的要求識別信貸拒絕的具體、準確原因。通用解釋（「算法因素」）可能不符合監管標準。

子組性能監控：作為持續監控的一部分，按人口統計子組單獨追蹤模型性能（準確率、假陽性率、假陰性率）。跨群體的性能差異是偏差信號。

---

金融AI的人機協作要求

對於高風險金融決策，人機協作結構既是治理要求，也是風險管理實踐。

信貸決策：邊際信貸決策的自動化（邊緣申請人）應包括人工審查。定義需要人工審查的評分範圍或風險層級。兩端的自動化決策（明確可批准或明確可拒絕）風險較低；邊緣群體是AI錯誤最可能且最重要的地方。

市場風險和交易：AI輔助交易系統應有可以識別和中斷異常行為的人工監督機制。2010 年閃崩是參考案例——在沒有有意義的人工監督的情況下運行的自動化系統可以迅速放大市場波動。

欺詐和反洗錢：AI生成的欺詐警報和反洗錢可疑活動報告在提交可疑活動報告（SAR）之前需要人工審查。BSA 對有意義的審查要求適用，無論警報是如何生成的。

模型輸出監控：將審查AI模型輸出質量的責任分配給特定職能。這與驗證不同——它是在正式驗證周期之間檢測性能退化的持續操作監控。

---

審計跟蹤規格

金融服務AI審計跟蹤必須同時滿足內部模型風險管理和監管審查要求。重要決策的每次AI查詢的最低字段：

保留期：ECOA 要求保留信貸申請記錄 25 個月；BSA 記錄保留 5 年。AI決策記錄應與底層交易保留要求匹配。

---

供應商模型盡職調查

對於其模型用於重要金融決策的AI供應商，SR 11-7 要求您的機構不能從黑盒供應商完全獲取的文件。至少請求：

• 模型開發文件（方法論、訓練數據描述、驗證歷史）
• 公平借貸相關模型的人口統計子組性能指標
• 如有，第三方驗證報告
• 數據處理和安全實踐（SOC 2、ISO 27001）
• 變更通知流程和版本控制實踐
• 為審查目的提供模型文件的合同承諾

如果供應商無法提供足夠的模型風險管理文件，您就無法將該模型用於 SR 11-7 監管的決策。這在審查員面前不可協商。

---

模型所有權的優勢

對於擁有自己微調模型的金融機構，幾個 SR 11-7 治理挑戰大幅簡化：

• 變更管理：模型版本在您的控制之下。您決定何時更新。驗證由您的決定觸發，而非供應商的 API 更新。
• 文件完整性：您可以訪問訓練數據、模型架構和性能指標。驗證文件可以完整。
• 可解釋性：您可以用適合您使用案例的可解釋性工具對模型進行儀器化。
• 審計跟蹤：推論在您的基礎設施上運行，與您現有的審計日誌記錄集成。

自有模型的治理開銷高於使用雲端 API——但這是正確類型的開銷，與 SR 11-7 的要求一致，而非與之矛盾。

預約與 Ertas 的發現電話 →

Ertas Data Suite 為數據主權和模型文件不可商量的金融服務組織提供完整的審計跟蹤、操作員級日誌記錄和本地推論。對於微調管道，Ertas Studio 處理在您的數據上的訓練並導出到部署就緒的 GGUF 格式。