銀行本地端 AI：滿足監管機構稽核要求

銀行監管機構並不反對 AI。他們反對的是他們無法稽核的 AI。

當 OCC 或 FINRA 檢查員審查您的 AI 系統時，他們要求的文件與您的雲端 AI 供應商的隱私政策或服務條款截然不同。他們想要訓練資料的來源。他們想要模型版本歷史記錄。他們想要推理日誌，顯示哪個模型版本為特定決策提供服務，使用了哪些輸入資料，以及何時作出決策。他們想要顯示誰批准了部署的變更管理記錄。

大多數雲端 AI 部署無法提供這些文件——不是因為技術上不可能，而是因為底層系統不是為此設計的。這就是為什麼本地端 AI 不僅僅是銀行的偏好，而是監管現實的原因。

監管框架

聯邦銀行監管機構並未發布單一的「AI 法規」，但他們發布了幾份重要指引，共同定義了稽核標準：

OCC 公告 2011-12（模型風險管理）要求銀行建立正式的模型風險管理框架，涵蓋概念聲音性驗證、持續監控和有記錄的覆蓋流程。該指引明確適用於使用統計或機器學習方法的 AI 系統。

SR 11-7（聯準會/FDIC 等效指引）建立了類似的模型開發、驗證和治理標準。它要求「有效挑戰」——獨立驗證模型的假設和方法論。

FINRA 規則 3110（監督）和相關 AI 指引要求經紀商在使用 AI 進行合規相關功能（交易監控、KYC、欺詐偵測）時保留足夠的人工監督。

CFPB 公平貸款指引要求貸款決策的可解釋性，這直接影響機器學習信用承保模型的架構。

這些框架共同建立了一套要求，使得符合規範的銀行 AI 架構看起來非常具體。

審查時稽核員實際要求的內容

讓我們具體說明。當監管稽核員審查您的 AI 系統時，他們通常要求：

訓練資料文件

• 每個訓練資料集的來源清單
• 刻意排除的資料說明（例如，為何某些歷史時期被排除）
• 個人識別資訊和受保護特徵的處理（受保護特徵的代理排除）
• 合成或增強資料的生成方法論

模型開發記錄

• 版本化的訓練配置（超參數、架構選擇）
• 訓練/驗證/測試分割方法論
• 替代模型的比較評估
• 選擇此模型的說明

驗證文件

• 由獨立驗證團隊完成（不是建立模型的同一團隊）
• 公平性和偏差測試結果
• 壓力測試和假設情境分析
• 已知局限性和應用範圍的文件

生產推理日誌

• 每個決策：模型版本、輸入資料、輸出結果、時間戳記、服務實例
• 輸入資料的不變性驗證（日誌不能被修改）
• 最低保留期限（依功能不同，通常為 3 到 7 年）

變更管理記錄

• 部署批准工作流程，帶有指定批准者
• 重新訓練事件的記錄（為什麼，什麼時候，誰批准了）
• 品質下降的回滾記錄

正在進行的監控記錄

• 概念漂移偵測方法論
• 公平性指標的定期重新驗證
• 模型性能警報的事件記錄

為什麼雲端 AI 無法提供這些文件

當銀行使用 OpenAI、Google 或 Anthropic 等雲端 AI API 時，他們根本無法訪問此清單上的大多數項目。

訓練資料文件？提供商的模型在專有資料集上訓練——您無法訪問。模型版本？您可以在 API 請求中指定一個版本，但您無法控制何時停用版本，也無法訪問版本之間的差異。推理日誌？您可以記錄您的 API 請求和回應，但日誌駐留在您的基礎設施中，而不是提供商的基礎設施中——這實際上使可操控性成為一個問題。

即使您解決了技術問題，仍然存在一個監管問題：您使用的是第三方模型，您無法完全記錄其行為。監管稽核員越來越多地提出這個問題——特別是對於影響信用決策、欺詐標記或合規警報的 AI 系統。

符合規範的銀行 AI 架構

滿足這些要求的架構在本地端運行整個 AI 生命周期——不僅僅是推理，而是從資料準備到訓練到部署到監控的全部。

第一層：訓練環境

訓練在您自己的基礎設施上進行，完全控制資料訪問。每次訓練運行都使用版本化記錄，捕獲：

{
  "run_id": "train-2026-03-07-001",
  "base_model": "llama-3.1-8b-instruct",
  "dataset_version": "fraud-training-v4.2",
  "dataset_hash": "sha256:a1b2c3...",
  "hyperparameters": {...},
  "training_duration_hours": 6.4,
  "final_eval_metrics": {"accuracy": 0.943, "f1": 0.921},
  "approved_by": "model_review_board",
  "approved_at": "2026-03-07T14:23:00Z"
}

這個記錄是不可變的，存儲在版本控制的模型倉庫中，稽核員可以直接訪問。

第二層：驗證環境

在部署到生產環境之前，每個模型都經過獨立驗證團隊的評估。驗證環境與訓練環境隔離——驗證工程師無法修改正在評估的模型。

驗證報告生成為結構化文件，捕獲公平性指標（按保護屬性的人口統計相同性）、性能基準與之前版本的比較，以及部署建議（帶有批准/否決記錄）。

第三層：生產推理

每個推理請求在本地端記錄，格式適合稽核：

{
  "inference_id": "inf-20260307-847291",
  "model_version": "fraud-detector-v4.2.1",
  "request_timestamp": "2026-03-07T09:15:32.441Z",
  "input_hash": "sha256:d4e5f6...",
  "output": {"risk_score": 0.73, "flag": true},
  "latency_ms": 47,
  "serving_instance": "gpu-node-03"
}

輸入以雜湊形式存儲（而非原始形式）以保護客戶隱私，同時仍允許驗證特定交易使用了哪些輸入。完整的輸入資料存儲在單獨的加密存儲中，通過雜湊連接。

第四層：稽核日誌存儲

推理日誌、訓練記錄、驗證報告和變更管理記錄都存儲在防篡改的稽核日誌系統中。

「防篡改」在這裡具有特定技術含義：

• 每條記錄都包含前一條記錄的雜湊值（形成鏈條）
• 記錄只能追加——不能修改或刪除
• 定期雜湊驗證偵測任何竄改

這種架構直接回應了監管對可操控記錄的關注。

訪問控制和職責分離

OCC 的模型風險管理框架要求「有效挑戰」——驗證者必須與開發者分開，具有足夠的獨立性以有意義地挑戰設計選擇。

這轉化為具體的訪問控制要求：

每次訪問都記錄日誌。任何跨越這些邊界的嘗試都會產生警報。

變更管理工作流程

監管稽核員特別檢查模型何時以及為何更改的記錄。您需要記錄的是：

1. 觸發器：為什麼要重新訓練或更新模型？（概念漂移、新資料可用、偏差問題被識別）
2. 批准流程：誰提議了更改，誰審查了更改，誰批准了部署
3. 驗證結果：新版本的評估結果與前一版本的比較
4. 部署記錄：新版本何時上線，哪個舊版本被替換
5. 回滾程序：如果新版本表現更差，採取了什麼行動

這個工作流程必須在所有生產模型更改中系統性地應用——不能跳過，不能事後補記。稽核員可以透過查看變更管理記錄和推理日誌之間的差異來檢測後補記。

災難恢復和業務連續性

銀行監管機構還要求 AI 系統的災難恢復計劃，與其在關鍵業務流程中的角色相稱。

對於影響貸款決策或欺詐偵測等關鍵功能的 AI 系統，您通常需要：

• RTO（恢復時間目標）：通常為 4 小時以內的關鍵系統
• RPO（恢復點目標）：推理日誌通常為 24 小時以內（某些情況下更嚴格）
• 故障轉移程序：如何在不丟失審計追蹤的情況下切換到備份系統的文件
• 測試記錄：DR 演練已執行且通過的證據

大多數雲端 AI 部署將這種責任轉移給提供商——但監管稽核員通常要求您，而非您的供應商，有責任滿足這些目標。

Ertas 為銀行 AI 合規構建的內容

Ertas Data Suite 圍繞著本指南中描述的稽核要求設計。

資料準備：攝入 → 清理 → 個人識別資訊編輯 → 標記管道完全在本地端運行，帶有每個步驟的完整來源記錄。每次轉換都使用時間戳記和操作員 ID 記錄。稽核報告可以直接為 OCC 的模型風險管理框架導出。

訓練記錄：每次訓練運行自動生成記錄：資料集雜湊值、超參數、評估指標，以及到稽核員可以讀取的簽名批准記錄的連接。

合規導出：直接為 OCC 公告 2011-12、SR 11-7 和 CFPB 公平貸款要求生成合規文件套件。

本地端架構確保沒有任何資料或日誌離開您的大樓——這是其他任何架構都無法提供的保障。

預約稽核準備評估，評估您目前的 AI 基礎設施與 OCC/FINRA 要求的差距。