金融 AI 的人在迴路：SR 11-7、模型風險，以及美聯儲的實際要求

美聯儲的 SR 11-7 指導於 2011 年 4 月發布，為量化風險模型的世界而編寫——VaR 計算、信用評分算法、壓力測試框架。該指導沒有提到大型語言模型、生成式 AI，甚至沒有將機器學習作為一個獨特類別提及。它不需要。其要求適用於任何「應用統計、經濟、金融或數學理論、技術和假設以將輸入資料處理成定量估計的定量方法、系統或方法」。

用於評估信用價值、摘要借款人文件、標記可疑交易或生成貸款批准理由的 LLM，在 SR 11-7 下是一個模型。指導適用。審查員正在應用它。執法態勢不再是理論性的。

SR 11-7 實際上說了什麼

SR 11-7 建立了建立在三個支柱上的模型風險管理框架。

支柱 1：模型開發和實施

模型必須以明確的目的、適當的方法論和記錄的假設進行設計。對於金融應用程式中的 LLM，這意味著：

• 模型執行的任務必須精確定義
• 訓練資料和微調方法論必須記錄在案
• 模型的已知限制和失效模式必須明確承認
• 在部署之前必須選擇適合金融決策情境的性能指標

「我們使用 GPT-4 進行貸款摘要」不是記錄在案的模型實施。記錄在案的實施指定了哪個模型版本、提示詞如何結構化、對金融文件類型執行了什麼驗證、預期錯誤率是多少，以及當模型出錯時會發生什麼。

支柱 2：模型驗證

獨立驗證是大多數 AI 部署目前未能滿足的要求。SR 11-7 要求模型由獨立於開發團隊的人員進行驗證——沒有建立模型、沒有因其性能而受到激勵，且具有足夠的技術專業知識來評估其方法論。

驗證必須涵蓋：

• 概念合理性：模型的方法對這個金融應用程式有意義嗎？在零售銀行合約上微調的 LLM 可能不適合商業房地產承保文件，即使它產生看起來合理的輸出。
• 持續監控：模型性能必須在生產中被追蹤。準確性、校準和輸出分布必須與驗證基準進行測量。
• 結果分析：在可行的情況下，模型輸出必須與觀察到的結果進行比較。信用風險模型的預測最終必須與實際違約進行測量。

驗證要求是 HITL 連接變得明確的地方。沒有對標記異常的人工審查的持續監控，不是監控——而是指標收集。SR 11-7 期望了解模型的人類查看它在做什麼，並評估它是否正確地做到這一點。

支柱 3：治理、政策和控制

治理支柱要求模型清單、明確的所有權、新模型部署的定義批准流程，以及當模型表現意外時的記錄升級程序。

對於部署 AI 的金融機構，這意味著：

• 每個符合模型定義的 AI 系統必須在模型清單中
• 每個已清點的模型必須有一個對其性能負責的指定所有者
• 必須有一個模型批准流程，包括獨立於業務線的風險官員的簽署
• 必須有定義的觸發器，升級到人工審查——自動模型行為停止且人類決定的閾值

最後一點是嵌入在 SR 11-7 治理框架中的 HITL 要求。在指導文字中它不叫 HITL。在實踐中它就是 HITL。

「有效挑戰」實際上意味著什麼

SR 11-7 最苛刻的概念是「有效挑戰」——要求對模型假設、方法論和輸出進行批判性分析，由不只是接受模型結論的合格人員進行。

指導將有效挑戰定義為：由客觀、知情的各方進行批判性分析，這些各方可以識別模型限制和假設，並建設性地參與改善模型性能。

三個要素很重要：

客觀的：對模型成功沒有投入的審查員。想要信用 AI 被批准和部署的業務線不是客觀的。內部模型風險更接近；外部驗證最好。

知情的：擁有足夠技術和領域專業知識來實際評估模型的審查員。不理解 LLM 如何生成文字的信用官員，無法有效挑戰基於 LLM 的信用分析工具。

建設性的：目標是改進，而非僅僅批准。有效挑戰識別具體的弱點，並要求在部署或繼續運作之前解決這些問題。

風險官員閱讀由建立模型的團隊準備的摘要並簽署批准表的審查流程，不是有效挑戰。那是勾選複選框的版本。審查員知道其中的差別。

金融 AI 部署的真實案例

信用決策 AI：幾家地區性銀行收到了與在沒有獨立驗證的情況下部署的基於 LLM 的信用決策工具相關的 MRA（需要關注的事項）調查結果。常見發現：機構無法提供文件表明該模型已在其特定貸款群體的代表性樣本上進行了測試、不利行動通知準確反映了 AI 的推理，或者當 AI 的置信度低於定義閾值時存在人工覆蓋的機制。

AML 交易監控：標記可疑交易以進行 SAR 報告的反洗錢 AI，必須滿足模型驗證的 SR 11-7 要求。2024 年和 2025 年在三家大型機構的審查員發現，SAR 報告的 LLM 輔助敘述生成被視為工作流程工具而非模型——完全繞過了模型清單和驗證要求。

欺詐檢測：地區支付處理商的欺詐評分 AI 在審查期間被發現沒有定義的重新訓練時間表，也沒有對標記邊緣案例的人工審查。該模型已上線 18 個月。由於分布偏移，其在有卡詐欺上的準確率從 94% 下降到 78%，但沒有監控系統發現這一點，因為監控僅限於掩蓋下降的匯總統計數據。

黑箱問題

SR 11-7 的概念合理性要求為 LLM 創造了一個特定問題：可解釋性要求。

對於人類審查員對 LLM 輸出提供有效挑戰，他們需要理解為什麼模型產生了那個輸出——輸入的哪些特徵驅動了決定、考慮了哪些替代方案、模型的置信度反映了什麼。產生信用建議而不解釋其推理的黑箱，未能達到有效挑戰標準。人類審查員無法挑戰他們看不到的東西。

這不是「AI 有高準確率」可以解決的問題。SR 11-7 不接受高整體準確率作為可解釋性的替代品。要求是合格的人類能夠評估個別決定——這意味著模型必須產生人類可以評估的推理。

被提示解釋其推理的 LLM，或被微調以在建議旁邊產生結構化理由的 LLM，比在沒有可見推理的情況下產生評分或建議的模型，在 SR 11-7 合規方面處於更好的位置。這是為金融應用程式微調的、有目的建構的模型，相對於通過 API 訪問的通用模型，具有真正的監管優勢的領域之一。

2026 年的監管方向

OCC 在 2025 年底發布了專門針對銀行操作中 LLM 風險的補充指導。該指導在 SR 11-7 推斷的地方是明確的：

• 用於信用、AML、欺詐和客戶通信功能的 LLM，在 SR 11-7 下是模型
• 模型清單要求適用於第三方 AI 服務，而非只是內部開發的模型
• 對高風險 AI 輸出需要人工審查檢查點——信用拒絕、SAR 報告、制裁篩查結果
• 需要模型版本固定：機構不能使用在沒有定義的重新驗證流程的情況下自動更新的 API 端點

最後一點對於每個使用基於雲端的 AI API 的機構都是重要的。靜默接收模型更新的「gpt-4-turbo」端點不是固定的模型版本。SR 11-7 要求你知道你在運行什麼模型，並已驗證該版本。你無法驗證一個移動目標。

Ertas 如何支持金融 AI 合規

對於建立必須滿足 SR 11-7 要求的 AI 系統的金融機構，在資料準備階段兩件事很重要：稽核追蹤和模型所有權。

Ertas Data Suite 提供帶完整稽核追蹤的本地資料準備——每次標注、每次操作員操作，帶時間戳並記錄。在 Ertas 中準備的金融訓練資料可以記錄、審查並包含在模型驗證包中，因為準備過程本身是可稽核的。

Ertas 微調讓金融團隊能夠直接擁有模型權重。當你在本地運行自己的微調模型時，你控制版本。你驗證一次並運行到你選擇更新為止。供應商靜默更改模型行為的失敗模式——雲端 AI 部署中最重要的 SR 11-7 合規風險之一——不適用於你擁有和控制的模型。

有關基礎 HITL 框架，請參閱什麼是人在迴路 AI？。有關微調 LLM 情境中的模型風險管理，請參閱我們關於模型風險和微調 LLM 以及為何銀行謹慎對待通用 AI 的文章。

預約與 Ertas 的探索通話 →

SR 11-7 在 LLM 存在之前就已編寫。它精確描述了它們的治理要求。那些將其解讀為適用於其 AI 部署的機構——並相應地建立 HITL 流程——已經領先一步。那些將 AI 視為在模型風險框架之外的機構，正在積累他們尚未收到的審查發現。

查看早鳥定價 → 用於 Ertas 微調——你版本化、驗證和控制的有目的、本地運行的模型。