銀行的智能體 AI 現在表面上是 AI 議題,本質上卻是工程議題。模型可以替換,控制平面不能。2026 年的挑戰不是採用率 —— 劍橋 CCAF 統計已達 52% —— 而是你的銀行今天正在跑的那些自主系統,下一季能不能通過 SR 11-7 檢查。大多數通不過。
執行摘要 / 關鍵要點
- 別再叫它聊天機器人。 生產端的基本單位是一條工具呼叫權限受嚴格控管的有界工作流程。真正的工作發生在工作流程之內,而不是在 LLM 之內。
- OSWorld 66.3% 就是可靠度天花板。 史丹佛 HAI 最貼近企業工具呼叫的基準測試,在結構化任務上仍有三分之一失敗。這個數字足以支持積極導入人在迴路;但無法支持對任何沾到客戶資金的系統進行非監督執行。
- 依權限分類,而非依智力分類。 自主性階梯從 Level 0(唯讀的 ISDA 條款擷取)走到 Level 4(具強制檢查點的多工具支付修補)。Level 5 —— 沒有檢查點的自我編排 —— 在 2026 年的生產級銀行業務中不應該存在。
- 智能體控制平面是五項工程化元件,不是一份政策文件。 OAuth 範圍化的服務帳戶、確定性語意路由、Open Policy Agent 策略閘、WORM 稽核日誌,以及經過演練的緊急關閉開關。少一個就是稽核缺失。
- SR 11-7 與 PRA SS1/23 早已適用。 聯準會已多次澄清,任何輸入到輸出的決策系統都在規範範圍內。主張「LLM 不算模型」的銀行,在開口爭辯之前就已經輸掉這場監理辯論。
為什麼 2026 年正是這份指數重要的時間點 #
今年銀行業在智能體 AI 上唯一重要的事,就是從聊天介面轉向有界工作流程。一個替客戶起草信件的聊天機器人,可以人工審閱;一個對著生產卡片平台呼叫 POST /accounts/{id}/freeze 的智能體,則是會被稽核留存的證據。生產實況已經跟上這個框架:劍橋 CCAF 的 2026 年調查顯示,52% 的機構已積極採用智能體,23% 已進入規模化或轉型成熟度(Cambridge CCAF ⧉)。「孤立試點」的門檻大約在 2025 年下半年就已跨過。
採用率攀升的同時,有兩件事一併發生變化。
第一,監理機關不再把 LLM 當作新鮮玩意。聯準會已澄清:SR 11-7 ⧉適用於以 LLM 為基礎的決策流程,無論該 LLM 在機構內部是否被歸類為「模型」。PRA 的 SS1/23 ⧉ 從一開始的範圍就足以納入。歐盟 AI Act 的「高風險」分類涵蓋金融服務業大多數 LLM 用例。「我們不確定這算不算」這種說法,已經沒有立足之地。
第二,基準測試的現實追了上來。史丹佛 HAI 的 2026 年 AI 指數報告指出,OSWorld —— 目前最接近真實企業工具呼叫場景的基準 —— 準確率為 66.3%(Stanford HAI ⧉)。結構化任務仍有三分之一會失敗。這個數字定義了 2026 年自主性的技術天花板。它高到足以支持在 HITL 監督下進行有界的 Level-3 佈署;但不足以支持對任何沾到客戶資金的 API 進行非監督執行。
銀行業需要的智能體 AI 指數,要為 LLM 決策系統做巴塞爾框架對資本所做的事:把「我們有控制」這種口頭主張,逐一工作流程地轉換成可量測、可稽核的證據。
2026 年指數架構 #
| 指數層次 | 「就緒」的樣貌 | 就緒度指標 | 失敗模式 |
|---|---|---|---|
| 自主性等級 | 每條生產工作流程都標註 Level 0–4;生產環境沒有任何 Level 5 | 各等級工作流程比例;Level 3+ 占比 | 生產智能體因為在送往 SWIFTNet 之前沒有靜態允許清單把關,把 pacs.008 發送給一個被幻想出來的受款人 BIC |
| API 權限管理 | 每個智能體對應一個採用最小權限 OAuth 範圍的服務帳戶(例如 card-freeze:write:lt-5000usd);與舊核心之間採用 MTLS |
達到最小權限的智能體比例;孤兒權限數量 | 智能體沿用一個權限過大的服務帳戶,逐筆讀取它本來無權閱讀的帳戶;72 小時內提交 GDPR 第 33 條事件通報 |
| 確定性護欄機制 | 每次工具呼叫在抵達 API 之前,都先經過語意路由器(NeMo Guardrails / LangChain Guardrails)加上 JSON-schema 驗證器 | 被攔截的工具呼叫比例;依類別劃分的拒絕率 | LLM 發出一筆 amount: 0 的 transfer 呼叫;下游 API 沒有驗證;18 小時後總帳對帳警示在另一個時區才響起 |
| 人在迴路覆蓋率 | 每次 Level-3 執行都會推出帶有強制逾時的審核介面;政策上禁止自動核可 | 審核產能;橡皮圖章率(2 秒內核可的比例) | 操作人員在 4 分鐘內按下 200 個警示的「核可」;對一位合法客戶提交 SAR;一週內收到監理機關投訴 |
| 稽核完整性 | 不可變的 WORM 日誌完整捕捉系統提示詞 + 取回的上下文 + LLM 輸出 + 工具呼叫 + 工具結果 + 核可人員 UID;寫入時即以密碼學簽章 | 具備完整軌跡的呼叫比例 | SR 11-7 檢查員詢問為何 #4421 智能體核可了一筆 480 萬美元電匯;銀行只拿得出電匯收據與模型卡,沒有提示詞層級的證據;遭到開立稽核缺失 |
| 單位經濟性 | 每筆完成決策的成本經追蹤,包含逆轉與修補成本;與人工基線比對為正 | 每筆決策淨成本;逆轉率 | 邊緣案例智能體的每 token 花費,高於它取代的人工調查員成本;CFO 在第三季關掉這個專案 |
應追蹤的當前訊號 #
| 訊號 | 對銀行的意涵 | 來源 |
|---|---|---|
| 52% 積極採用 | 智能體 AI 已脫離試點階段;機構層級的治理早該到位 | Cambridge CCAF ⧉ |
| 23% 進入規模化或轉型 | 已有一群有意義的少數機構走過了概念驗證的舞台秀 | Cambridge CCAF ⧉ |
| OSWorld 66.3% | 結構化工具呼叫存在三分之一的失敗率。在這種可靠度水準下,對客戶資金 API 的非監督執行無法成立 | Stanford HAI ⧉ |
| 55% 把人類監督流失列為首要風險 | 控制設計才是首要的工程議題,而非事後補上的合規議題 | Cambridge CCAF ⧉ |
| 76% 大型金融機構難以衡量價值 | 籠統的「生產力提升」說法撐不過一場 CFO 對話。請逐條工作流程衡量,別逐項專案衡量 | Cambridge CCAF ⧉ |
自主性階梯 #
請依照智能體「被允許做什麼」分類,而不是依底層模型「有多聰明」分類。同一個 GPT-5 / Claude 4 / Gemini 3 實例可以同時待在每一個等級;真正的差別在外包覆的那層工程。
- Level 0 — 觀察。 對日誌、軌跡或交易具備唯讀存取。智能體呈現樣態或異常,不寫入任何地方。範例:偵測各走廊
pacs.008拒絕率的漂移,並警示營運團隊。 - Level 1 — 唯讀檢索。 從營運系統讀取,輸出結構化內容供人類消費。範例:從交易對手的 ISDA 主協議中擷取 CSA 條款變體,標示出與銀行標準範本的偏離。智能體不會回寫合約倉儲。
- Level 2 — 起草供人類提交。 產生由人類審閱後送出的內容。範例:根據詐欺系統警示加上 KYC 紀錄加上交易軌跡,起草可疑活動報告;BSA 官員閱讀後視情況修改、再提交。記錄系統只看到經人類核可的版本。
- Level 3 — 有界工作流程內的執行。 在外包覆強制執行確定性硬上限的前提下,呼叫生產 API。範例:卡片凍結 API 呼叫,由允許清單政策強制執行
max-amount-at-risk: 5000 USD;智能體不能在未經 Level-2 升級的情況下,凍結餘額高於該門檻的關聯卡片。這個上限是寫在策略即程式碼裡,不是寫在提示詞裡 —— 提示詞不是安全邊界。 - Level 4 — 帶強制檢查點的多工具編排。 跨系統執行一連串動作;每一次狀態轉換都被記錄;在下一次工具呼叫之前,檢查點需要人類核可。範例:支付修補工作流程 —— 從死信佇列取出失敗的
pacs.008→ 透過 SWIFT KYC Registry 查出正確受款人 → 產生修正後的訊息 → 寫入出向佇列 → 由人類核可再送。任一步通不過 schema 驗證,工作流程便停下並建立例外案件。 - Level 5 — 自我編排。 智能體在沒有檢查點核可的情況下自行規劃並執行。2026 年的生產級銀行工作流程都不應該停在 Level 5。 這不是成熟度的陳述,而是可靠度的陳述。OSWorld 66.3% 會沿著串接的 API 呼叫複合下去。三次工具呼叫各 66%,端到端成功率剩 29%。五次只剩 13%。別這麼做。
智能體控制平面 #
控制平面是 LLM 與你的生產系統之間那層工程。五項元件,全都跑在執行期,沒有一項是寫在政策文件裡的。
1. 身分與權限 #
每個智能體精確對應一個服務帳戶。該帳戶持有的 OAuth client_credentials 權杖,範圍縮到最小所需的 API 表面。卡片凍結智能體的權杖可以以 amount-at-risk: 0..5000 usd 呼叫 POST /accounts/{id}/freeze;但不能對其他客戶呼叫 GET /accounts/{id}/balance;也不能呼叫保管、財務或交易相關的任何端點。服務帳戶的密鑰每週輪替;長期不換的憑證,是生產佈署中最常見的控制平面破口。
2. 工具呼叫上的確定性護欄機制 #
每一次 LLM 工具呼叫,在抵達生產 API 之前,都必須穿過一個確定性語意路由器(NeMo Guardrails、LangChain Guardrails,或同等品)。路由器把意圖比對到一份有限的允許清單;清單以外的呼叫被拒絕並記錄。接著由 JSON-schema 驗證器檢查 payload —— 必填欄位齊全、金額落在區間內、ISO 國別碼合法、受款人 BIC 落在銀行預先核可的交易對手名單上。驗證器要假設最壞情況:pacs.008 帶著 amount: 0 是模型故障,不是合法交易;送往一個你的制裁過濾尚未為發起客戶分群預先核可的國家的電匯,也一樣。
3. 策略即程式碼 #
Open Policy Agent(或同等品)坐在驗證器與 API 之間。策略以 Git 版本控管;拒絕決策一律留存日誌;在你既有平台上把微服務與微服務之間呼叫管起來的那同一個策略引擎,也用來管智能體的工具呼叫。把智能體視為需要客製閘控的特殊類別,正是為什麼六個月後,平台團隊裡沒有人弄得清楚那個影子控制平面。
4. 稽核日誌 #
不可變的 WORM 儲存 —— S3 Object Lock、Azure Blob 不可變性,或一個帳本式資料庫。每一次呼叫都要捕捉:時間戳、智能體 ID、服務帳戶 ID、系統提示詞雜湊、取回的上下文、LLM 供應商加上模型加上版本、原始 LLM 輸出、解析後的工具呼叫、OPA 裁決、API 回應、下游影響,以及適用情況下的核可人員 UID。紀錄在寫入時即以密碼學簽章。SR 11-7 與 SS1/23 檢查員要的,就是這份日誌。如果你拿不出任一筆決策的完整軌跡,你就沒有一個經模型風險管理的智能體。
5. 緊急關閉開關 #
一個紅按鈕 API,可以在 60 秒內取消同一個權限類別中所有飛行中的智能體呼叫。每季以桌上演練測試。緊急關閉開關是唯一能把你從以下情境救出來的東西:供應商悄悄退化的模型版本、你沒預想到的提示詞注入向量,或是把偽陽率推過營運門檻的漂移事件。沒測過的緊急關閉開關就是不會運作;請把演練時間列入預算。
模型風險管理 #
主張「在 SR 11-7 之下 LLM 不算模型」的銀行,已經輸了。聯準會多次澄清:任何在決策工作流程中使用的輸入到輸出系統,都在規範範圍內。PRA 的 SS1/23 範圍還更廣。正確的姿態:從第一天起,就把每個生產智能體當作 SR 11-7 / SS1/23 模型。事後追溯把已部署智能體框成模型的成本,是一開始就設計成模型的成本的好幾倍。
三道防線,套用到智能體:
- 第一道(模型擁有者)。 記錄智能體的預期用途、訓練與評估資料血緣、系統提示詞架構、工具呼叫允許清單、緊急關閉開關測試結果。負責生產環境的漂移監控。
- 第二道(MRM 模型風險管理團隊)。 在生產佈署前驗證智能體。驗證報告涵蓋:供應商釋出的評測分數(MMLU、HumanEval、HellaSwag 有用但不充分)、銀行自有評測分數(從真實營運案例構建的留出評測集 —— 大多數銀行最該補強卻投入不足的就是這塊)、提示詞注入紅隊測試結果、對有客戶影響的工作流程進行偏見與公平性分析,以及一份量化的剩餘風險陳述。
- 第三道(內部稽核)。 針對抽樣的生產決策,測試控制平面閘控與稽核日誌的完整性。2027 年的稽核循環會跟 2025 年完全不一樣;現在就把預算編出來。
持續監控比單一時點驗證更重要。每週重跑的銀行自有評測組合,會抓到供應商基準測試浮不出來的模型更新退化。OpenAI、Anthropic 與 Google 的釋出節奏比你的驗證節奏快;要嘛你跑持續評估把這個落差關上,要嘛由檢查員開個缺失替你關上。
量測業務影響 #
籠統的「生產力提升」說法撐不過一場 CFO 對話。請用衡量其他營運變動的方式衡量智能體:
- 每筆完成決策的成本,含失敗決策的逆轉與修補成本。一個讓 BSA 官員時間減少 40%、卻產生 12% 偽陽性提報的 SAR 起草智能體,是在毀滅價值,不是在創造價值。
- 被省下的人工接觸次數,要扣掉控制平面監督與例外處理所新增的人工接觸。重點不是把人類注意力極小化,而是把它重新導向更高槓桿的決策。
- 逆轉率 —— 智能體執行的動作在 24 小時內被回滾的比例。在 Level-3 工作流程上逆轉率超過 2% 是可靠度問題;超過 5% 是控制平面問題。
- 稽核軌跡完整性 —— 可從 WORM 日誌完整重建血緣的決策比例。Level-3 與 Level-4 工作流程應該維持在 100%。少一點就是政策層級的失敗,而且會在稽核中浮出來。
如果一條工作流程變快了、卻變得更難解釋,指數就應該扣它分。要在監理檢查中失敗,最便宜的方法,就是只衝吞吐量、把軌跡丟掉。
對各類銀行的意涵 #
全球系統性重要銀行 #
難題在於規模化的治理:數百個跨業務線的智能體,每個都有自己的模型擁有者,每一個都是潛在的稽核缺失。所需的投資不是再做一個試點,而是中央控制平面、統一的稽核日誌基礎建設,以及一支每季有能力驗證 50 個以上智能體的 MRM 板凳人力。沒有這個產能,智能體上線的速度會比能被治理的速度還快,機構就會在不知不覺中累積 SR 11-7 曝險。
交易銀行與企業金融銀行 #
投資報酬最高的工作流程是支付修補、KYC 文件擷取、財務服務 FAQ 分流,以及對帳差異處理。全部屬於 Level-2 或有界 Level-3。企業客戶不在乎工作是不是智能體做的;他們在乎的是 SLA 是否改善、爭議率有沒有走平。請以指標領頭,別以技術領頭。
區域銀行 #
買,別自建。挑一家供應商,其智能體平台已經具備控制平面的基本元件 —— OAuth 範圍化、OPA 整合、WORM 稽核日誌、經過演練的緊急關閉開關 —— 然後依你自己的 MRM 框架去驗證該平台。打造一個客製化的控制平面是多年期的投資,在區域型規模下並不會產生差異化。把工程產能花在工作流程設計與操作員 UX 上才划算。
金融科技、PSP 與基礎建設供應商 #
對供應商而言,產品問題不是「你的 AI 智能體表現有沒有比人類好」,而是「你的平台是不是開箱即用就能產生符合 SR 11-7 的稽核軌跡」。能對這題答「是」的供應商,會拿下企業案;答不出的供應商,會卡在概念驗證迴圈裡,而銀行的 MRM 團隊會不斷找到理由讓你的驗證不過。
結論 #
2026 年銀行的智能體 AI 是工程問題。有意思的工作在控制平面,不在模型。模型可以替換;OAuth 範圍化、確定性語意路由器、OPA 策略閘、不可變的稽核日誌與緊急關閉開關,則不行。
未來 18 個月在監理機關眼中仍稱得上可信的機構,是那些從第一天就把每個生產智能體當作 SR 11-7 / SS1/23 模型治理、銀行自有評測組合持續運轉、控制平面被設計成失效時也安全的機構。沒做到的機構,將親自驗證自己的 MRM 板凳能不能撐過每季 50 個以上的補救缺失。
請用衡量任何營運變動的方式衡量智能體:成本、可靠度、可逆性、證據。OSWorld 66.3% 就是你的可靠度天花板,規劃時請據此調整。
常見問題 #
什麼是銀行業的智能體 AI?
一條把 LLM、對生產系統的工具呼叫、執行期護欄機制與人在迴路檢查點組合起來的有界工作流程。真正的工作發生在工作流程之內,而不是在模型之內。如果你聽到的字眼是「聊天機器人」,你就站錯類別了。
銀行應該從哪裡起跑?
從價值可量測、下檔可控的 Level 1 與 Level 2 工作流程起跑:ISDA 條款擷取、SAR 起草、支付修補分流、內部知識檢索、程式碼審查輔助、KYC 文件分類。在你的控制平面還搞不定 OAuth 範圍化、語意路由、OPA 閘控、WORM 日誌與經過演練的緊急關閉開關之前,先別碰 Level 3。
最大的風險是什麼?
讓智能體在 LLM 輸出與 API 之間沒有確定性護欄機制的情況下,直接對生產 API 執行動作。OSWorld 66.3% 就是警訊。以這個失敗率對 SWIFT MT103 或客戶資金 API 進行未包覆的工具呼叫,寫的就是下一輪監理週期最糟糕的頭條。
SR 11-7 適用於以 LLM 為基礎的智能體嗎?
是。聯準會已澄清,任何在決策工作流程中使用的輸入到輸出系統,都落在 SR 11-7 範圍內。在英國,PRA 的 SS1/23 涵蓋同一塊地。歐盟 AI Act 的高風險分類涵蓋金融服務業大多數用例。「這算不算模型」的辯論已經結束;請據此行動。
智能體 AI 應該怎麼向董事會報告?
每條工作流程四個數字:自主性等級、稽核軌跡完整性、逆轉率、每筆決策淨成本。再加上一份前五大剩餘風險清單。模型卡的投影片秀就免了。
參考資料 #
- Stanford HAI, (2026). 2026 年 AI 指數報告 ⧉.
- Stanford HAI, (2026). 技術效能章節 ⧉.
- Cambridge Centre for Alternative Finance, (2026). 2026 全球金融服務業 AI 報告 ⧉.
- Federal Reserve, (2011). SR 11-7:模型風險管理指引 ⧉.
- Prudential Regulation Authority, (2023). 監理聲明 SS1/23:銀行模型風險管理原則 ⧉.
- European Commission, (2024). 規則 (EU) 2024/1689 —— AI Act ⧉.
- NVIDIA, (2024). NeMo Guardrails 框架 ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
最後審閱 。
最近審閱 .