大綱
一、前言
在一家銀行裡，徵信部的 “小李” 用 AI 代理協助分析企金客戶的財報疑點。隔壁桌的 “小明” 也用 AI 代理在做同一件事,但用的是不同的 prompt 模板。樓上稽核部的 “小美”，也建了一個她自己的 AI 代理在追查類似的問題。
三個人,三個代理,做著本質上相同的工作,卻彼此不知道對方的存在。他們的 AI 代理可能對同一份財報給出不同的判讀;當其中一個代理出錯,沒有人知道該由誰負責;三個代理累積的學習,也沒有任何機制讓彼此互通。
這就是 Agent 孤島(Agent Silos)——當組織內的 AI 代理大量出現、卻彼此不互通、不協調、不可見，治理就會失效。
這不是想像中的場景。2026 年 5 月 15 日,華爾街日報以〈企業面臨新的 AI 難題:代理(agent)數量過多〉為標題報導指出，FICO 的資訊長 Mike Trkay 坦言該公司 3,500 名員工每天都在新增「數十個」AI 代理，正在建立治理機制以避免不同代理在處理同一問題時得出相互矛盾的結果。
Magnum 冰淇淋的資訊長 Michael Friedlander 則直言:「因為每個人都能做到這一點,最終很可能會出現許多人使用同類型代理人的情況。」
Gartner 預估,未來兩年內，全球《財富》500 強企業平均將運用超過 150,000 個 AI 代理，但只有 13% 的企業認為自己已建立完善的治理機制。
台灣金融業也正進入同一個轉折點。國泰金控本月剛宣布與 OpenAI、NVIDIA 雙軌合作,要打造「台灣首個金融 AI Agent」；中信銀已建立跨部門的 AI Agent 開發團隊；玉山則在 AI 制度化的耕耘上，於四月獲得台灣人工智慧協會頒發「2026 AI Award 特殊貢獻獎」。三家擴張的節奏不同，但都正面對同一個治理挑戰: 當 AI 代理從個位數成長到數十、數百、上千個,Agent 孤島會不會出現?如果出現了，該怎麼辦?
在 Agent 孤島浮現的同時,現階段有兩條應對路徑正在形成。
第一條，是國際大型銀行(DBS、渣打、JPMorgan)正在建立的「AI Factory」與內部代理治理平台——透過結構化的治理，把已經出現的孤島問題逐步收攏。這條路徑，有一個正在成形的名字:AgentOps。
第二條，是 Shopify 在 2026 年 5 月 9 日揭露的「不准私訊 AI」模式——透過設計性的約束,讓 AI 代理的對話強制公開，從源頭避免孤島形成。短短兩個月內，他們的 AI 代理提交程式碼的合併接受率從 36% 上升到 77%。
解決 Agent 孤島的問題，或許 AgentOps 是個不錯的方案。
【資料來源】
- Belle Lin (2026/5/15), Companies Have a New AI Problem: Too Many Agents, The Wall Street Journal.
- Tobi Lütke (2026/5/9), Learning on the Shop Floor, X.
- 〈國泰金與 OpenAI 攜手 打造金融業多代理協作智能引擎〉,國泰金控新聞稿,2026/4/7。
- 〈國泰金、NVIDIA 攜手打造台灣首個金融 AI Agent〉,國泰金控新聞稿,2026/5。
- 〈玉山銀行科技長張智星獲頒 2026 AI Award 特殊貢獻獎〉,玉山銀行新聞中心,2026/4。
二、Agent Sprawl 與 Agent 孤島:兩個層次的問題
2.1 三個概念,三個層次
本文使用「Agent 孤島」這個詞描述了 小李、小明、小美 在銀行使用AI各自為政的場景。但要把這個問題講透，我們需要先區分一組容易被混用、但其實有層次差異的概念。
第一個概念是 Agent Sprawl(代理蔓生)。它描述的是「規模」這件事——組織內 Agent 數量失控擴張,超出原本的管理能力。它本身是中性的。一家銀行有 2,000 個 AI 模型,如果每一個都被妥善編目、追蹤、退役管理,那只是「規模大」，不必然是「失控」。
第二個概念是 Agent 孤島。它是 Sprawl 沒有被妥善管理之後產生的特定後果——Agent 之間彼此不知道對方存在、結果可能矛盾、知識不互通、責任難追溯。它是治理失效的具體樣態,不是規模本身的問題。
第三個概念是 AgentOps。它是介於前兩者之間的治理紀律——讓 Sprawl 不至於演化為孤島。
簡而言之:Sprawl 是現象,孤島是後果,AgentOps 是紀律。
2.2 從「系統孤島」到「Agent 孤島」
「孤島」這個詞對金融業 IT 部門並不陌生。過去二十年,「系統孤島」是 CIO 的長期戰場——不同部門各自建系統、各自選廠商，結果產生互不相通的資料煙囪。Agent 孤島看起來像是同一個問題的延續,但仔細看,它在七個關鍵維度上都不同。
| 維度 | 系統孤島(傳統 IT 時代) | Agent 孤島(GenAI 時代) |
|---|---|---|
| 出現層級 | BU/應用系統 | 個別員工/個別任務 |
| 規模 | 數十個系統 | 數千到數十萬個 Agent |
| 建造者 | IT 部門 + 外部廠商 | 員工本人(公民開發者) |
| 建造時間 | 數月到數年 | 數分鐘到數小時 |
| 失控成本 | 重複投資-資本支出 | 線性堆疊-營運支出(token) |
| 可見性 | IT 資產清單 | 多數不在任何清單上 |
| 治理工具 | 架構審查委員會 | 萌芽和發展階段 |
七個維度的差異指向同一個結論:Agent 孤島不只是「系統孤島的升級版」，它斷的不只是 IT 系統的連結,更是組織知識傳承的鏈條。當資深授信員的判斷力過去是透過資淺同仁旁觀、共事、提問而傳遞下來時，如果每個人都關起門來和 AI 一對一互動,這個傳統的「教學工坊」就被切斷了。這個現象在金融業部份高度依賴經驗傳承的業務(如授信、徵信等)，殺傷力大於一般科技公司。
[圖一:系統孤島 vs Agent 孤島對比圖]
2.3 從 Sprawl 到孤島的五條過渡路徑
Sprawl 不會自動變成孤島，中間至少有五條過渡路徑。每一條都從一個看似中性的 Sprawl 現象開始，因為缺乏治理，逐步惡化為實質的孤島後果。
路徑一:重複建造 → 結果矛盾。 當員工各自建 Agent 做相同的工作，最初只是浪費 token——這是 Sprawl。但當不同 Agent 對同一個問題給出不同的答案，組織就進入孤島狀態。FICO 的資訊長 Mike Trkay 在華爾街日報的報導中直言，該公司正建立治理機制,「避免不同代理在處理同一問題時得出相互矛盾的結果」。
路徑二:影子代理 → 責任歸屬模糊。 當 Agent 跑在員工筆電上、跑在某個員工自己建的小伺服器上，IT 部門難以追蹤——這是 Sprawl。但當這些影子代理開始產生影響業務決策的輸出時，責任歸屬就變得模糊。風險投資公司 Sapphire Ventures 的總裁 Jai Das 形容:「這些軟體可能運行在員工的筆電、伺服器或公司的其他系統上，資訊科技部門很難全面追蹤它們的狀態。」
路徑三:Token 失控 → 成本失控但無從問責。 當大量 Agent 同時運行,token 帳單會線性堆疊——這是 Sprawl。但當沒有人能說清楚每個 Agent 的成本歸屬時,組織進入「集體買單但無人問責」的孤島狀態。Magnum 冰淇淋的資訊長 Friedlander 在報導中坦言:「我們要如何管理這一切,才能確保其符合財務上的負責任原則呢?」
路徑四:殭屍代理 → 安全漏洞累積。 員工建了一個 Agent，後來不用了，但 Agent 還在跑、還在花 token、還在累積對組織系統的存取權限——這是 Sprawl。但當這些被遺忘的 Agent 變成攻擊面時，就成為實質的安全孤島。AWS 在 2026 年 4 月推出 Agent Registry 時,明確把「退役(retirement)」列為 Agent 生命週期管理的核心環節之一。
路徑五:知識斷層 → 組織學習停滯。 每個員工關起門來和 AI 一對一互動——這是 Sprawl 的副作用。但當資深員工的提問智慧無法被資淺員工觀察學習時，組織進入知識孤島。這是五條路徑中最隱性、也最危險的一條——它不像前四條會立刻被 CIO 察覺，但它會在三五年後體現為人才斷層。
[圖二:從 Sprawl 到孤島的五條過渡路徑]
2.4 規模本身不是問題，規模沒治理才是問題
我們從金融業的具體例子應能感受到此問題的份量。
新加坡星展銀行(DBS)的集團營運長 Derrick Goh,在 2026 年 4 月 16 日發表於 Euromoney 的署名文章中揭露:超過 70% 的 DBS 員工每天使用內部的 DBS-GPT 協助工作，還有許多人建立個人或團隊專屬的 Agent。針對這個大規模部署的現實,Goh 給出一段直白的提醒:
「許多使用者今天大談 Agent 為工作流程帶來的好處，但很少人能清楚說明跨企業治理這些 Agent 的框架。試想一下，多個自主 Agent 執行多步驟工作流程，卻沒有適當的監控、可觀測性與追溯機制——這會是什麼樣的場景?為了管理這個情況，組織應該建立一個『代理控制平面(agentic control plane)』,確保對企業內所有部署的 Agent 進行嚴格監督。但這方面的工具仍屬萌芽和發展階段(nascent and developing),因此需要特別關注。」
Goh 提及「agentic control plane」這個概念的工具仍在萌芽——這正是我們在前面提到的「AgentOps 是一門正在成形的學科」的真實寫照。即便是全球公認 AI 治理相當成熟的銀行之一，在這個議題上也只是剛剛起步。
回到台灣的場景。國泰金控本月剛宣布與 OpenAI、NVIDIA 雙軌合作，要打造涵蓋信貸、貸款、信用卡、保險、財管的多元 AI Agent 矩陣，長期還要做到異業 Agent-to-Agent 協作。這個願景的規模，有機會比 DBS 更大。我們要問的不是「該不該擴張」——擴張本身是趨勢，而是「擴張到這個規模時，治理框架跟得上嗎?」這個問題對於所有正在加速 AI Agent 布局的台灣金融機構，都要一起思考。
【資料來源】
- Belle Lin (2026/5/15), Companies Have a New AI Problem: Too Many Agents, The Wall Street Journal.
- Derrick Goh (2026/4/16), Insights from DBS on being a trusted, AI-enabled bank with a heart, Euromoney (Guest article by DBS Group COO).
- AWS 官方公告:適用於集中式代理程式探索和控管的 AWS Agent Registry 現已推出預覽版,AWS,2026/4/9。
- 〈國泰金、NVIDIA 攜手打造台灣首個金融 AI Agent〉,國泰金控新聞稿,2026/5。
三、台灣三大金控的AI Agent擴張節奏
3.1 三種節奏，同一個議題
在 DBS 集團 COO 提醒「agentic control plane 工具仍在萌芽」的同一段時間,台灣三大金控的 Agent 佈局也進入了新階段——但三家走的路明顯不同。
- 國泰金控走的是「多軌並進的擴張」:2026 年 4 月 7 日宣布與 OpenAI 結盟，5 月宣布與 NVIDIA 合作打造「台灣首個金融 AI Agent」，6 月在 NVIDIA GTC 進一步揭露金融 LLM 微調的技術推進。
- 中信銀走的是「架構先行的長期主義」:從十年前主動發動核心現代化工程開始，把整個底層改造為樂高積木式的微服務 + 混合雲，再以「由上而下、由廣到深」的節奏導入生成式 AI。
- 玉山銀走的是「制度先行的步調」:把 AI 系統做風險分級,參與金管會的金融科技產業聯盟主動制定業界標準。
三種節奏,但都正面對同一個議題:當 AI 代理從個位數成長到數百、數千,Sprawl 之後,孤島會不會出現?
3.2 國泰金控:多軌並進,願景對應的規模
國泰金控的 Agent 策略從 GAIA 框架開始。GAIA(Gen AI Architecture)是國泰世華銀行在 2024 年建立的全集團生成式 AI 框架,內含金融知識庫、嚴格的護欄機制，以及讓員工自建 AI 助手的 GAIA STUDIO 平台。截至 2025 年底,GAIA STUDIO 上已誕生近 50 項業務專屬 AI 助手。
進入 2026 年,國泰的策略明顯加速。4 月與 OpenAI 結盟，全集團導入 ChatGPT Enterprise，目標打造「多代理協作智能引擎」；5 月與 NVIDIA 合作，使用 NeMo 在本地端預訓練、微調開源 LLM,規劃涵蓋信貸、貸款、信用卡、保險、財管的多元 AI Agent 矩陣,並延伸到異業 Agent-to-Agent 協作；6 月在 NVIDIA GTC 上，國泰進一步揭露在金融 LLM 技術深度上的推進。
這個願景的規模有多大?如果國泰的多 Agent 矩陣完整落地，跨子公司加上異業 A2A 協作，Agent 總數會輕易進入「數百到數千」量級。當這些 Agent 之間開始互相呼叫、互相影響業務決策——這就是 DBS Goh 所說的「多個自主 Agent 執行多步驟工作流程」的場景。國泰的 AI CoE 由各子公司總經理擔任召集人,負責優先排序與資源配置；當 Agent 規模真的進入多代理協作階段，治理框架能否對等擴張，將是國泰下一階段最關鍵的考驗。
3.3 中信銀:架構先行,治理嵌入流程
中信銀的故事要從十年前說起。中信金控資訊長賈景光接受採訪時直言:「現行的主機系統運行非常的穩定,其實並沒有立即需要更換的理由⋯⋯我們是積極性先發動這樣的專案。」這個「主動先發動」的判斷，讓中信用十年時間，把傳統單體式架構拆解為樂高積木式的微服務 + 雲端原生設計，並建立私有雲守穩定、公有雲擁抱創新的混合雲策略。當生成式 AI 浪潮在 2023 年襲來,這個架構已經就位。
但更值得 AgentOps 視角注意的，是中信銀法金作業暨資訊處的法規報表案例。中信沒有讓 AI 單獨產出報表,而是建立「人 + RPA + AI」三方比對的機制:3 個 RPA 角色(製表者、查核者、審計師)加上 40 支 AI 同時運作，人員、軟體機器人、AI 各做一次,結果有出入時員工要 AI 解釋為何不同，初步分析後由員工辨別 AI 給出的理由是否合理。處長游惟智揭露了一個關鍵的觀察:「AI 單從主管機關的規範,難以做出精準的判斷和推理，所以還要讓 AI 知道業務邏輯。」
在這個特定的法規報表場景中，Agent 孤島的幾個過渡路徑(重複建造、結果矛盾、責任歸屬)獲得了結構性的回應——當然,這個設計能不能複製到其他業務場景,是另一個值得追蹤的問題。
3.4 玉山銀行:制度先行,風險分級
玉山銀行的路線是「制度先行」。在 2026 年 3 月 27 日與鼎新數智合辦的「智匯轉型」研討會上,科技長張智星揭露玉山多項金融場景的 AI 應用——支票影像識別、自動房屋估價、警示帳戶偵測、徵信報告、聊天機器人——其中即時防詐系統將「警示帳戶」的偵測頻率從每日一次提升至每五分鐘執行一次。
但對 AgentOps 議題真正重要的，是張智星的兩段話。第一段直接點出了 AI 治理的核心張力:「模型門檻設得太嚴，可能誤傷正常客戶；太鬆則失去防詐效果。」第二段給出了玉山的回應方式:建立 AI 系統「風險分級的治理機制」——依不同應用場景與風險程度，設計相對應的審查與控管流程。
這個「風險分級」的設計，本質上就是 SR 26-2 的 Materiality 概念在玉山的具體實踐:不是所有 AI 都需要同等強度的治理，但每一個 AI 都需要被分級、被治理。張智星強調「資料治理、知識管理與 AI 模型維運是 AI 落地金融實務的關鍵」——這幾乎是 DBS Goh 投書中三條原則的玉山版本。同場勤業眾信副總溫紹群提出「Agentic Commerce」概念，並提醒「當 AI 開始涉及金流或決策時，若治理機制不完善,風險將遠高於效益」——這個來自外部第三方的提醒,為玉山的「制度先行」路線提供了業界共識的背書。
3.5 三家共同的提問
三家擴張的節奏不同，但有一個共同的議題:Agent Sprawl 已經是進行式(國泰 50+ AI 助手、中信 40 支報表 AI、玉山多場景 AI 應用)，三家也都從不同角度建立了反孤島的基礎機制——但 Goh 所說的「跨企業治理 Agent 的框架」這個 AgentOps 核心議題,仍是進行式。
還有一個三家共通的結構性事實值得點出。台灣三大金控的 AI 能力,高度建立在雲端大廠的平台之上——中信銀以 Microsoft Azure 為核心雲端平台，導入 M365 Copilot、GitHub Copilot 與 Azure DevOps；國泰與 OpenAI、NVIDIA 雙軌合作，採用 ChatGPT Enterprise 與 NeMo 框架，玉山也在 NVIDIA 的技術生態上推進。這與我們在下一節會看到的國際銀行如出一轍——星展建在 Google Cloud、渣打以 Azure 為首選、JPMorgan 以 AWS 為主。
這不是台灣金融業的弱點，而是全球金融業的共同現實: AI 與 Agent 的底層能力,正在被雲端巨頭平台化、商品化。但它確實帶來一個台灣金融業必須正視的治理課題——當核心 AI 能力依附在少數幾家雲端供應商身上,供應商集中度與轉換成本，本身就是一種需要被納入治理框架的風險。
【資料來源】
- Derrick Goh (2026/4/16), Insights from DBS on being a trusted, AI-enabled bank with a heart, Euromoney.
- 〈國泰金與 OpenAI 攜手 打造金融業多代理協作智能引擎〉,國泰金控新聞稿,2026/4/7。
- 〈國泰金、NVIDIA 攜手打造台灣首個金融 AI Agent〉,國泰金控新聞稿,2026/5。
- NVIDIA GTC 2026 議程:建構與微調訓練客戶意圖判斷與提升客戶體驗的金融 LLM (張睿昇、謝昌宏,國泰金控),2026/6/4。
- 〈IBM 三十年夥伴之力,協助中國信託資訊現代化,迎接 AI 新時代〉,商業周刊,2026/3/31。
- 〈打造亞洲第一個法規報表虛實整合系統 中信銀用 AI 補上推理力,報表產製時間縮短 9 成〉,經理人雜誌。
- 〈從務實上雲到全員 AI:中國信託商業銀行攜手台灣微軟打造金融業 AI 創新文化〉,Microsoft News,2026/4/10。
- 〈玉山銀行攜手鼎新數智 共創企業數位轉型與 AI 驅動成長〉,玉山銀行新聞中心,2026/3/27。
- 〈玉山金控攜手鼎新數智揭示 Agentic AI 正重塑營運流程〉,Yahoo 新聞/台灣好報,2026/3/27。
四、國際銀行的反 Sprawl 設計
4.1 開場:從非金融業的散亂，到金融業的設計
第一節提到的華爾街日報報導，描繪了一幅非金融業的散亂景象:Fair Isaac 的 3,500 名員工每天新增「數十個」AI 代理、DaVita 員工建造了超過 10,000 個 AI 代理、Lyft 與 Magnum 都在思考如何收斂。這是 Agent Sprawl 的典型樣態。
但當我們把鏡頭轉向金融業，景象明顯不同。2025 年起，五家國際大型銀行不約而同採用了一個共同的設計範式:把 AI 治理「平台化」、把重用機制「制度化」、把治理紀律「架構化」。這個範式,有一個共同的名字:AI Factory(AI 工廠)。
下面我們依序走訪五個現場——星展、渣打、Lloyds、JPMorgan、匯豐——看看他們的設計如何在不同層次回應同一個議題:當 Agent Sprawl 不可避免,如何讓孤島不會發生?
4.2 星展銀行(DBS):亞太典範,雙平台 + 治理框架
星展銀行(DBS)集團部署的 AI 模型已超過 2,000 個,跨越 430 多個用例;超過 70% 的員工每天使用內部的 DBS-GPT,還有許多人建立個人或團隊專屬的 Agent。這個規模,讓星展成為亞太金融業 AI 部署最深的代表。
支撐這個規模的,是兩個平台 + 一個治理框架。集團營運長 Derrick Goh 在 2026 年 4 月 16 日的 Euromoney 投書中揭露了一個關鍵的演化:從 2014 年時任 CEO 提出「Digitise or Die」開始,星展發展出一套「Managing through Journeys(透過旅程管理,簡稱 MtJs)」的方法論,用資料驅動方式優化團隊大規模協作——這是機器學習時代的 DBS 範式。進入生成式 AI 時代,星展把焦點升級為「Operating Model Transformation(營運模式轉型,簡稱 OMTs)」,透過人機協作重新設計營運模式,釋放更大的產能與價值。
Goh 在投書中給出三條原則,值得逐字引用:
「第一,我們必須先把治理做對。許多使用者今天大談 Agent 為工作流程帶來的好處,但很少人能清楚說明跨企業治理這些 Agent 的框架。試想一下,多個自主 Agent 執行多步驟工作流程,卻沒有適當的監控、可觀測性與追溯機制——這會是什麼樣的場景?組織應該建立一個『代理控制平面(agentic control plane)』,確保對企業內所有部署的 Agent 進行嚴格監督。但這方面的工具仍屬萌芽和發展階段。」
「第二,我們不能在資料基本功上鬆懈。事實上,AI 與 Agentic 解決方案的使用,要求我們有更高的資料品質與安全。AI 的結果可靠程度,僅取決於 AI 代理使用的資料。」
「第三,以人為本部署 AI——這是我們 CEO Su Shan 持續呼籲的主題:我們拯救的是人,不是工作(we save people, not jobs)。最終,AI 必須是一個為我們的人服務的工具。」
這三條原則,正是 AgentOps 在金融業實踐的縮影:治理優先、資料基本功、以人為本。星展的「agentic control plane」概念,後面我們會看到,和其他四家國際銀行的設計語彙高度相通。
4.3 渣打銀行(Standard Chartered):把 fragmentation 寫進產品定義
渣打銀行在 2025 年 7 月推出 AI Factory 平台時,直接把「治理 AI 專案碎片化(fragmentation)」寫進產品定義。所謂碎片化，是指——各團隊各自開發、互不相通、難以治理的破碎狀態，fragmentation 是國際銀行界對這個現象的慣用統稱。
集團 COO Alvaro Garrido 接受 The Asian Banker 訪談時揭露的數字,描繪了這個設計的規模:全球 80,000 名員工使用 SC GPT，平均生產力提升 6%；每日活躍用戶超過 15,300 人；AI 用例從 2025 年 Q1 的 200 個成長到 2026 年 Q1 的 300+ 個,其中 30+ 是 GenAI 用例。AI Academy 自 2025 年 9 月啟動以來,33,000+ 同仁參與學習；2025 年內部部署率提升至 47.4%，節省 188 萬美元,並透過 Talent Marketplace 創造 175 萬美元的生產力。
但對 Agent 孤島議題真正關鍵的，是渣打的核心設計概念:reusability(可重用性)。AI Factory 提供一個「micro-AI capabilities(微型 AI 能力)」函式庫,讓各業務團隊組合建立自己的 AI 解決方案——這個設計把開發週期「從數月壓縮到數週或數天」。函式庫涵蓋 Agentic AI、檢索增強生成(RAG)、智慧文件處理(IDP)、機器學習模型訓練與部署——核心能力層「建造一次、多次使用」。
更值得注意的,是渣打的 AI inventory(AI 清單)機制:全球涵蓋運行中與開發中所有用例的清單，讓各團隊有一個共同的倉庫，辨識可重用的元件或其他專案的技術。Garrido 直言這是「集中平台與分散自治平衡的關鍵」。
把治理「fragmentation」寫進產品定義、把 reusability 變成設計核心、把 AI inventory 變成治理紀律——這就是渣打的反 Sprawl 設計。
4.4 Lloyds Envoy:Agent Marketplace 模式
「英國勞埃德銀行集團(Lloyds Banking Group)在 2026 年 5 月推出 Envoy 平台,與 Google Cloud 合作,定位是『在規模下安全建造 AI Agent 的內部平台』。Envoy 採用了Agent Marketplace(代理市集)機制——完成並驗證過的 Agent 可發布到內部市集,供其他團隊發現、重用、擴展。這個『讓 Agent 跨團隊重用』的設計,與前面渣打 AI Factory 的可重用性思路指向同一個方向。」
透過將驗證過的 Agent 可發布到內部市集,供其他團隊發現、重用、擴展——這個設計把「重複建造」這個 Sprawl 病徵,從「問題」變成「組織學習的機會」。每個 Agent 都有完整的稽核軌跡、人類監督節點,並接入 Lloyds 既有的 LLM 平台。Lloyds 預期 2026 年從新一代 AI 創造 £100M 的價值,延續 2025 年 GenAI 解決方案約 £50M 的價值基礎。
4.5 JPMorgan LLM Suite:25 萬員工規模的 AgentOps
摩根大通(JPMorgan)的 LLM Suite 提供了另一個觀察視角:當 AgentOps 延伸到 25 萬員工規模,會長什麼樣?
LLM Suite 在 2023 年推出,2024 年夏天正式對全公司開放,目前 250,000 名員工有存取權(除分行與客服外的全集團),其中約半數每日使用。集團首席分析長 Derek Waldron 接受 CNBC 訪談時揭露:LLM Suite 每 8 週更新一次，持續餵入內部資料,接入 OpenAI 與 Anthropic 的多家模型。
Waldron 描述的願景,是 AgentOps 規模化版本:**「未來的 JPMorgan Chase 將是一個完全 AI 連結的企業——每個員工都有自己的個人化 AI 助理,每個流程都由 AI 代理驅動,每次客戶體驗都有 AI 禮賓。」**目前 LLM Suite 已進入下一階段:從「文書工具」演化到「Agentic AI 處理多步驟複雜任務」,能在 30 秒內產出投資銀行簡報。
值得注意的是,LLM Suite 在規模化過程中採取了 opt-in(自願加入)模式,而非強制部署。Waldron 在 VentureBeat 訪談中觀察:「員工的接受程度遠超預期——數個月內從零成長到 25 萬人,而且他們不只是在寫提示詞,還在客製化自己的 Agent、為它設定角色與指令,並在內部分享心得。」這個「員工自建並分享」的文化,我們會在下一節 Shopify 案例中看到更激進的版本。
4.6 匯豐銀行(HSBC):設立首位 CAO 的組織訊號
匯豐銀行在 2026 年 3 月 23 日宣布:任命 David Rice 為集團首位 Chief AI Officer(CAO),自 4 月 1 日生效。這個任命,在金融業是一個值得關注的組織訊號。
第一個值得注意的點,是 Rice 的背景。他在匯豐服務近 20 年,最近的職位是「企業與機構銀行業務」(Corporate and Institutional Banking)的營運長(COO),不是技術出身。產業評論直指:「匯豐沒有任命技術人員當 CAO,而是升任他們的 COO。這告訴你這次任命是什麼:這是一場 operations play(營運佈局),不是 innovation play(創新佈局)。」
第二個值得注意的點,是這個任命的時代意義。匯豐並不是第一個——但走得快:UBS 在 2025 年 10 月任命 CAO,澳洲聯邦銀行(Commonwealth Bank of Australia)在 2025 年 12 月跟進,NatWest 在 2025 年 6 月設立 Chief AI Research Officer(CAIRO)。但匯豐的訊號最強:全球最大的銀行之一,把 AI 治理升級為 C-suite 議題,而且選擇了一個「會看流程、會看治理」的人,而不是「會寫程式」的人。
集團 CEO Georges Elhedery 在公告中明確指出:「我們將賦能員工使用 AI 為每個客戶創造個人化體驗,安全地、即時地、規模化地交付,同時將人類判斷、決策、責任歸屬保留在核心(while keeping human judgement, decision-making and accountability at the core)。」——這幾乎是 Agent 孤島五個病徵中「責任歸屬模糊」的逆向回應。
4.7 共同模式:從 reusability 到 AI Factory
五家國際銀行,五種設計,但有一組共同的設計語彙:
| 概念 | 中文翻譯 | 在不同銀行的呈現 |
|---|---|---|
| AI Factory | AI 工廠 | 渣打 AI Factory、DBS 的 ADA/ALAN 雙平台、JPMorgan LLM Suite |
| Reusability | 可重用性 | 渣打 micro-AI capabilities、Lloyds Agent Marketplace |
| AI Inventory / Agent Marketplace | AI 清單 / 代理市集 | 渣打全球 AI 清單、Lloyds 代理市集 |
| Agentic Control Plane | 代理控制平面 | DBS Goh 提出的核心概念 |
| Chief AI Officer (CAO) | 首席 AI 長 | 匯豐、UBS、CommBank 都已設立 |
五家銀行的雲平台對照
| 銀行 | Agent 平台 | 底層雲端 |
|---|---|---|
| 星展 DBS | ADA + ALAN 雙平台 | Google Cloud（Vertex AI 整合進 ADA） |
| 渣打 Standard Chartered | AI Factory | Microsoft Azure（首選）+ 多雲 |
| Lloyds | Envoy + Agent Marketplace | Google Cloud |
| 摩根大通 JPMorgan | LLM Suite | AWS + 自有私有資料中心（混合架構） |
| 匯豐 HSBC | （多項 AI 工具） | 多雲（AWS + Google Cloud 等） |
前述各家銀行使用的治理工具，如Agent Marketplace、Agent Registry、micro-AI capabilities 函式庫等——有相當部分並非銀行從零打造，而是雲端平台的原生能力。如上表所示，五家銀行用了三家不同的雲:
1. DBS 與 Lloyds 建在 Google Cloud(DBS 的 ADA 直接整合 Google 的 Vertex AI)；
2. 渣打以 Microsoft Azure 為首選,JPMorgan 以 AWS 為主搭配自有資料中心；
3. HSBC 則採多雲。
Google 的 Agent Platform 本身就內建 registry、治理工具與第三方 agent marketplace；Azure 的 AI Foundry 微軟稱為「agent factory」；AWS 也有 Agent Registry。換句話說，2025 至 2026 年間，雲端巨頭把 Agent 治理工具平台化、商品化了——五家銀行用了不同的雲，而主要AI治理工具是直接採用雲端平台的內建功能。
這不會讓銀行的努力失去意義，因為銀行真正的自主性，不在治理工具本身,而在工具之上的客製與紀律——資料治理如何對接、權限模型如何設計、合規如何嵌入、組織如何安排(像 HSBC 設 CAO)、治理框架如何訂立(像 DBS 的 PURE)。工具可以買,紀律必須自己建。
這些不是巧合,而是「結構化治理」這條應對 Agent 孤島的路徑正在成形。每家銀行的具體實現不同,但核心邏輯一致:用平台收斂 Sprawl,用重用機制避免孤島,用治理框架保留問責。
但這條「結構化治理」的路徑，只是應對 Agent 孤島的其中一條路。在 2026 年 5 月,還有另一家公司——不是銀行,而是一家做電商平台的科技公司——用一種截然不同的方式,給出了第二條路的答案。
【資料來源】
- Derrick Goh (2026/4/16), Insights from DBS on being a trusted, AI-enabled bank with a heart, Euromoney (Guest article by DBS Group COO).
- Neeti Aggarwal (2026/5/7), Standard Chartered positions AI Factory and SC GPT as enterprise reuse engines, The Asian Banker.
- Lloyds Banking Group 官方新聞稿:Lloyds Banking Group unveils Envoy – a new platform for building AI agents safely at scale,2026/5。
- JPMorgan Chase 官方部落格:LLM Suite named 2025 “Innovation of the Year” by American Banker,2025/6/3。
- Hugh Son (2025/9/30), Here’s JPMorgan Chase’s blueprint to become the world’s first fully AI-powered megabank, CNBC.
- HSBC 官方新聞稿:HSBC announces David Rice as its first Chief AI Officer,2026/3/23。
- Sean Mitchell (2025/4/17), Exclusive: DBS bets on AI to scale customer-centric banking, IT Brief Asia.
- Standard Chartered 官方新聞稿:We’ve partnered with Microsoft to become a cloud-first bank,2020/8/11。
- Paula Rooney (2024/12/4), JPMorgan Chase builds ambitious AI foundation on AWS, CIO.
- Karl Flinders (2020/7/15), HSBC chooses AWS for public cloud business operations, Computer Weekly.
五、Shopify 的另一條路
5.1 一個違反直覺的決定
在走訪完五家國際銀行的結構化治理現場後，接著介紹另一家完全不同類型的公司:Shopify。它不是銀行,而是全球規模最大的電商平台之一，服務超過 175 個國家的數百萬商家。
Shopify 的 CEO Tobi Lütke 在 2026 年 5 月 9 日於 X 上分享的一個內部決定，意外揭露了 Agent 孤島議題的另一條應對路徑。這個決定,簡單到只有一句話:該公司的 AI 代理「River」被設定為只能在 Slack 公開頻道工作,拒絕回應任何私訊。
路特克自己直言:「最直覺的做法，是讓人們可以私下使用 River。其他許多 AI 助理就是這樣運作——ChatGPT 是一個私人視窗、Claude 是一個私人視窗、Cursor 是你和 IDE 之間的對話。我們做了相反的決定。」
結果讓 Shopify 自己也驚訝:過去 30 天,5,938 名員工和 River 一起工作,跨越 4,450 個 Slack 頻道;River 提交程式碼的合併接受率,在短短兩個月內從 36% 上升到 77%——沒有重新訓練模型,也沒有更換 AI 供應商。
5.2 Lehrwerkstatt:把組織變成「教學工坊」
要理解這個設計,得從路特克自己的故事說起。他 16 歲輟學,進入德國西門子的子公司當學徒。「最有趣的地方是人都坐在地下室裡用 Delphi 寫程式而不是公司規定的 Rosie SQL」路特克回憶，「我透過觀察他們學會寫程式。透過幫他們泡咖啡。透過待得夠久，讓他們的判斷力滲透進我的判斷力裡。」
這個學徒制有一個德文專有名詞:Lehrwerkstatt——直譯就是「教學工坊」。整個工廠車間就是教室,你透過靠近工作來學習，透過觀察熟練的人來學習,透過浸潤(osmosis)來學習。
路特克的核心洞察,直接刺中 Agent 孤島最深層的問題:
「AI 時代最大的危機並非搶走人類的飯碗，而是 AI 為人類代勞後，人類卻沒學到東西。如果每次與 AI 的互動都發生在一個私人視窗裡，那麼唯一學到東西的人，就是螢幕前的那一個人。其他所有人,都被鎖在學徒制的門外。」
這個觀察呼應了我們在第二節描述的 Agent 孤島第五條過渡路徑——「知識斷層 → 組織學習停滯」。當每個員工關起門來和 AI 一對一互動，Sprawl 的副作用會慢慢侵蝕組織的知識傳承機制，最後形成隱性的人才斷層。Shopify 的「不准私訊 AI」，正是這條路徑的釜底抽薪解法。
5.3 為什麼「公開化」會讓 AI 變得更好
但 Lehrwerkstatt 的價值，不只是組織學習。Shopify 的數字證實了一件更反直覺的事:公開化本身,就是讓 AI 變得更好的機制。
路特克描述了這個機制如何運作:「一個 #help_checkout 頻道的支援工程師，會看到另一個頻道裡的後端工程師，如何引導 River 查到正確的日誌查詢，第二天她就能依樣畫葫蘆做同樣的事。一個新進員工會回頭翻 #river 頻道的歷史紀錄,看資深同事在發出第一個請求之前,如何先界定範圍。」
更關鍵的是 Skill 的重用。Shopify 有個機制讓員工為 River 撰寫「skill」(技能,讓 AI 認識特定業務領域的指令包)。路特克舉了一個具體例子:「有人寫了一個 skill 教 River 認識公司結帳資料倉儲，後來被 12 個團隊重複使用。」
這就是 36% → 77% 的真實機制——「沒有重新訓練模型,沒有更換 AI 供應商,純粹靠每個團隊累積的品味流入 Agent,讓 Agent 變得更懂 Shopify。」用路特克的話說:「The agent gets better at being Shopify(代理變得更懂如何當 Shopify)。」
值得注意的是,這個「累積品味」的機制，本質上和第四節渣打銀行的 reusability(可重用性)、Lloyds 的 Agent Marketplace(代理市集)指向同一件事——讓組織的累積能被重用。差別在於,渣打和 Lloyds 用平台機制達成，Shopify 用一條「不准私訊」的硬規定達成。
5.4 設計性約束 vs 結構化治理
走到這裡,讀者應該能感受到兩條應對 Agent 孤島的路徑,在哲學上有根本的差異。
第四節走訪的五家國際銀行,代表的是結構化治理(structural governance)——事後編目錄、加治理層、建平台、設 CAO。它的邏輯是「Sprawl 發生了,我們需要工具來收攏」。星展的 ADA + ALAN + PURE 三層架構、渣打的 AI Factory 與 AI inventory、Lloyds 的 Agent Marketplace、JPMorgan 的 LLM Suite、匯豐的 CAO,都是這條路徑的不同變體。它擅長處理「規模」與「合規」這兩個金融業最棘手的議題。
第五節的 Shopify 代表的是設計性約束(design constraint)——從源頭預防孤島形成,讓 Agent 互動本身變成組織學習機制。它的邏輯是「不要等到孤島發生,從一開始就讓孤島不可能發生」。它擅長處理「學習」與「文化」這兩個結構化治理較難觸及的層面。
兩條路徑不互斥，而是互補。在同一家組織內,規模化的部分需要結構化治理，知識密集的部分可以採用設計性約束。事實上,我們在第四節看到的 JPMorgan LLM Suite，雖然以結構化治理為主軸，但採取 opt-in(自願加入)而非強制部署、鼓勵員工自建 Agent 並分享心得，已經有 Shopify 模式的影子——只是 JPMorgan 不像 Shopify 那麼極端地把「公開化」設為強制。
5.5 一個未解的問題
但所有讀到這裡的金融業讀者,心裡應該都有同一個問題:
Shopify 是科技公司,規模 6,000 人,文化開放,可以毫不猶豫地把 Slack 頻道全面公開化。金融業呢? 銀行業務有結構性的私密性需求，很多 Agent 對話本質上必須私密。
「Shopify 模式對金融業適用嗎?如果適用,該在哪些場景適用?」這個問題,留到第七節討論。
但在進入金融業特別功課之前,我們需要先把前面四節走訪過的現場整合起來——當結構化治理與設計性約束兩條路徑都浮現之後,「AgentOps」這門正在成形的學科,輪廓開始清晰了。下一節,我們梳理這門學科的演化譜系、共識性支柱,以及它目前的成熟度。
【資料來源】
- Tobi Lütke (2026/5/9), Learning on the Shop Floor, X.
六、AgentOps:正在成形的學科
6.1 從 DevOps 到 AgentOps:一條清晰的演化譜系
AgentOps（agent operations,代理營運)是一套用於觀察、評估、治理與最佳化自主 AI 代理的實踐與工具集合。 它把 Agent 視為「有狀態、會演化的實體」來管理——不像傳統軟體那樣寫好就固定,而是需要持續監控、引導、修正,涵蓋 Agent 從設計、部署、運行到退役的完整生命週期。簡單說,DevOps 管程式碼、MLOps 管模型,AgentOps 管的則是「會自己規劃、會互相呼叫、行為無法被預先決定」的 Agent 系統。
這個概念並非單一廠商的術語。IBM、Red Hat、TechTarget 等都已對 AgentOps 提出定義框架,IBM 研究人員更在 ASE 2025 學術會議發表論文,主張應對 agentic 系統的不確定性「需要一門新學科:AgentOps」。不過,各家定義的具體內涵仍在收斂中——這正是「正在成形」的真實樣貌。
在進入 AgentOps 之前，值得先看一下它的演化譜系——這是 IT 治理過去二十年的一條清晰演化軸線。
DevOps(2007 年起) 解決的是「開發團隊與運維團隊各自為政」的協作斷裂。它把軟體交付的整個生命週期(需求→開發→測試→部署→維運)整合進一個共同的紀律。
MLOps(2015 年起) 把 DevOps 的紀律延伸到機器學習模型。它新增的議題是:模型版本管理、訓練資料的可追溯性、模型漂移(model drift)的監控、模型重訓的觸發機制。它的核心洞察是:模型不是程式碼,模型會「變壞」,需要持續監控與重訓。
LLMOps(2023 年起) 在生成式 AI 浪潮下浮現，把 MLOps 的紀律延伸到大型語言模型。它新增的議題是:prompt 工程、檢索增強生成(RAG)的治理、幻覺(hallucination)的偵測、token 成本的管理。
AgentOps(2025 年起) 是當前正在成形的一代。它要回答的問題，LLMOps 已經無法獨自處理:當多個自主 Agent 互相呼叫、執行多步驟工作流程、跨越多個系統時，如何治理一個無法被單點管理的系統? 這就是 DBS Goh 所說的「agentic control plane(代理控制平面)」概念的核心。
[圖三:從 DevOps 到 AgentOps 的演化譜系]
6.2 AgentOps 的四個共識性支柱
雖然 AgentOps 仍在成形,但業界對它的核心支柱已有相當清晰的共識。整合 IBM 等廠商的論述,以及前面四節走訪的銀行與 Shopify 案例,我們可以歸納出四個支柱——按照金融業關注的優先順序排列。
支柱一:治理與安全(Governance & Security)。 這是金融業最敏感的維度,包括權限分級、合規對接、責任歸屬機制。IBM 在 AgentOps 框架中明確指出:「當生成式 AI 受到更嚴格的監管(如歐盟 AI 法案),developers 需要一組護欄與政策來限制 Agent 行為並確保合規。」玉山的 AI 系統「風險分級的治理機制」、JPMorgan 對外部 ChatGPT 的禁用、HSBC 升級 CAO 至 C-suite，都是這個支柱的不同切面。
支柱二:可觀測性(Observability)。 Goh 用最直接的方式表達了這個支柱:「多個自主 Agent 執行多步驟工作流程,卻沒有適當的監控、可觀測性與追溯機制——這會是什麼樣的場景?」Lloyds Envoy 的「完整稽核軌跡」、中信銀法規報表的「人 + RPA + AI 三方比對」，都是這個支柱的具體實踐。
支柱三:成本控制(Cost Governance)。 Token 不是免費的，每個 Agent 都會產生持續的推論成本。WSJ 報導中 Magnum 冰淇淋資訊長的擔憂——「我們要如何管理這一切,才能確保其符合財務上的負責任原則」——正是這個支柱的真實寫照。
支柱四:生命週期管理(Lifecycle Management)。 Agent 不是建造一次就結束的軟體，它有完整的生命週期。IBM 列出五個階段:Development(發展)、Testing(測試)、Monitoring(監控)、Feedback(回饋)、Governance(治理)。AWS 在 2026 年 4 月推出的 Agent Registry,明確把「退役(retirement)」列為生命週期的核心環節之一，正是這條紀律的具體實踐。
[圖四:AgentOps 的四個共識性支柱]
6.3 兩種治理哲學在 AgentOps 框架下的整合
第四節與第五節走訪的兩種治理哲學——結構化治理與設計性約束——在 AgentOps 框架下並不對立。它們是在不同時間點切入同一個 Agent 生命週期。
結構化治理主要在 Agent 生命週期的「事後階段」發揮作用:Agent 建造完成後,如何登錄(渣打的 AI Inventory)、如何共享(Lloyds 的 Agent Marketplace)、如何稽核(DBS 的 ADA + ALAN 雙平台)、如何退役(AWS Agent Registry)。它的優勢是處理「規模」與「合規」這兩個議題。
設計性約束則在 Agent 生命週期的「源頭階段」發揮作用:Agent 還沒建造之前,如何讓互動本身就具備可觀測性(Shopify 的「不准私訊」)、如何讓 Skill 的累積天然可重用(Shopify 的 skill 機制)。它的優勢是處理「學習」與「文化」這兩個結構化治理較難觸及的層面。
一個成熟的 AgentOps 實踐，應該在四個支柱上同時運用這兩條路徑——用結構化治理處理規模化部分,用設計性約束處理知識密集部分。Goh 提出的「agentic control plane」這個概念,本質上就是這個整合視角的代名詞:它不只是一個工具或平台,而是一套讓 Agent 規模化擴張時,治理紀律不被甩開的整合機制。
6.4 為什麼說「正在成形」
走到這裡,讀者應該能感受到 AgentOps 已經有可辨識的輪廓——演化譜系、四個支柱、兩種互補哲學。但同樣重要的是,要誠實標示它的成熟度:AgentOps 是一門正在成形的學科,不是已驗證的解方。
IBM 在官方對 AgentOps 的定義中,直接用了「emerging set of practices」(萌芽中的實踐集合)、「roughly-defined」(定義仍模糊)這兩個形容詞。Goh 在 Euromoney 投書中親口承認:「這方面的工具仍屬萌芽和發展階段(nascent and developing)。」即便是 DBS 這樣全球公認 AI 治理最成熟的銀行之一，在 AgentOps 議題上也只是剛剛起步。
工具仍在競爭:AWS Agent Registry、Microsoft、Boomi、各家雲端廠商都推出各自的方案;IBM 自己也指出,「沒有單一工具能管理 AgentOps,而是一整個生態系——最近一項研究在 GitHub 與其他程式碼倉庫中發現了 17 個相關工具。」最佳實踐也仍在發現:SR 26-2 雖然把生成式 AI 與 Agentic AI 明確排除在範圍之外,但仍要求金融機構自行建立治理機制,等於把這個空白留給了金融業自己。
這就是 AgentOps 目前的真實樣貌:輪廓已現、共識初成、但仍在成形。下一節,我們聚焦於一個關鍵問題:對金融業而言,通用 AgentOps 為什麼必要但不充分?
【資料來源】
- David Zax, What is AgentOps?, IBM Think.
- Derrick Goh (2026/4/16), Insights from DBS on being a trusted, AI-enabled bank with a heart, Euromoney.
- AWS 官方公告:適用於集中式代理程式探索和控管的 AWS Agent Registry 現已推出預覽版,AWS,2026/4/9。
七、金融業的特別功課
7.1 通用 AgentOps 為什麼對金融業必要但不充分
第六節整合出的 AgentOps 框架——四個共識性支柱、兩種互補治理哲學——對金融業而言,是必要的起點,但不充分。
通用 AgentOps 處理的是技術、規模、成本三個維度。但金融業還要疊加三層特殊性:監管層(SR 26-2、金管會 AI 應用指引、歐盟 AI 法案、新加坡 FEAT 原則)、責任歸屬層(當 Agent 給出錯誤建議時責任鏈必須清晰可追溯)、以及 客戶隱私層(銀行業務涉及大量個資、財務、行為資料)。
「不充分」不等於「需要重新發明」。金融業要做的，是在通用 AgentOps 之上加金融業特化層——保留通用框架的紀律,疊加金融業專屬的判斷原則。
而幸運的是,金融業並不需要從零開始建立這個特化層。SR 26-2 在 2026 年 4 月 17 日取代 SR 11-7,提供了一個現成的、經過正式監管驗證的模型風險評估框架——這個框架,可以延伸到 Agent 治理。
7.2 SR 26-2 框架延伸到 Agent 治理
SR 26-2 的核心是一個雙軸結構,評估模型風險的四個因素 × Materiality 合成的整體風險。
第一軸:Model Risk 由四項因素影響:
- Inherent Risk(內在風險):模型本身的複雜度、假設、輸入品質、資料限制——這是模型「天生」帶有的風險
- Exposure(暴險):模型對業務決策的重要性,可量化測量——影響範圍越廣,暴險越高
- Purpose(目的):模型的用途分級——監管報送、財務風險管理為高重要性
- Use(使用方式):模型如何被使用——SR 26-2 特別強化對「誤用」、「超出原始用途」的關注
第二軸:Materiality = Exposure × Purpose
整體模型風險 = Inherent Risk × Materiality × Use
這個框架的精彩之處,在於它讓 MRM(Model Risk Management)的嚴格程度與資源配置有了正式的決策依據:immaterial(非重大)的模型可採輕量管理(識別 + 監測 + 觸發條件),material(重大)的模型則需要完整的驗證與監督。
把這個框架延伸到 Agent 治理,四個因素都有清晰的對應:
| SR 26-2 因素 | Agent 治理的對應 |
|---|---|
| Agent Inherent Risk | Agent 本身的複雜度:單一工具呼叫 vs 多步驟自主規劃、底層 LLM 的品質、RAG 來源的可靠度 |
| Agent Exposure | Agent 對業務決策的影響規模:輔助建議 vs 直接執行、影響多少客戶/交易 |
| Agent Purpose | Agent 的用途分級:監管報送、財務風險管理、客戶溝通、內部生產力等 |
| Agent Use | Agent 的使用方式:被誤用的可能、超出原始設計範圍的風險 |
Agent Materiality = Agent Exposure × Agent Purpose Overall Agent Risk = Agent Inherent Risk × Agent Materiality × Agent Use
這個延伸保留了 SR 26-2 的雙軸結構,只是把四個因素的內涵從「模型」擴大到「Agent」。它的實務意義是:不是所有 Agent 都需要同等強度的治理。
[圖五:SR 26-2 框架延伸到 Agent 治理]
這正是玉山「AI 系統風險分級的治理機制」的具體理論基礎。也是 DBS Goh 所說「agentic control plane」應該具備的內部邏輯——它不只是一個工具或平台，而是一套有正式風險評估框架支撐的治理紀律。
7.3 經驗傳承適用性:另一個正交維度
SR 26-2 框架告訴我們治理「強度」該多高,但沒回答另一個問題:治理「型態」應該採用結構化治理,還是設計性約束?
這就回到第五節最後留下的問題:「Shopify 模式對金融業適用嗎?」
直觀的答案是「不適用」——銀行業務涉及客戶隱私、合規調查、跨境資料,很多 Agent 對話本質上必須私密。但這個直觀答案,把問題簡化過頭了。真正的問題不是「適用 / 不適用」,而是:金融業內部,哪些 Agent 互動的『經驗傳承』價值高到值得採用 Lehrwerkstatt 模式?
「經驗傳承適用性」是一個獨立於 Materiality 的維度。它評估的是:這項工作的判斷力、直覺、提問藝術,是否高度依賴師徒制傳遞?如果是,Agent 互動的公開化能保留這條知識傳承鏈;如果不是,公開化的學習邊際效用較低。
把 Materiality(治理強度)和經驗傳承適用性(治理型態)放在一起,我們得到一個 2×2 矩陣:
| Materiality 高 | Materiality 低 | |
|---|---|---|
| 經驗傳承適用性 高 | 象限 A:高強度治理 + 設計性約束(嚴格追溯 + 公開化加速學習)例:稽核 Agent | 象限 B:輕量治理 + 設計性約束(基本記錄 + 公開化最大化)例:內部知識探索 |
| 經驗傳承適用性 低 | 象限 C:高強度治理 + 結構化治理(嚴格驗證 + 保持私密)例:授信決策 Agent、客戶資料處理 | 象限 D:輕量治理 + 結構化治理(簡單記錄即可)例:行政後勤文書 Agent |
[圖六:Materiality × 經驗傳承適用性 2×2 矩陣]
這個矩陣的意義,在於它讓金融業 AgentOps 不再是「全部結構化治理」或「全部設計性約束」的二選一——而是依據每個場景的雙軸定位,選擇合適的治理組合。
7.4 部門級實施:示例展示
把這個雙軸框架應用到金融業內部,幾乎所有部門都有 AgentOps 的應用空間,只是各自的象限定位不同。
以下用四個示例部門展示——但要強調,這只是示例,不是窮舉。任何部門都可以用同樣的方法自評。
示例一:授信審查部門。 授信判斷本質就是經驗傳承(老 case officer 怎麼追問 Agent 對企金客戶財報的初步分析、怎麼識別產業風險的微妙訊號)——經驗傳承適用性高。但授信涉及客戶資料、影響放貸決策——Materiality 也高。定位:象限 A——高強度治理 + 設計性約束。具體做法:在匿名化處理後的案例討論層,採用 Lehrwerkstatt 模式;在具體客戶決策層,保持完整追溯與審查。
示例二:徵信部門。 徵信最難的是「直覺」——這是典型的師徒制傳承。經驗傳承適用性高。資料敏感度需注意但可分區處理。Materiality 中等到高。定位:象限 A——分區的高強度治理 + 設計性約束。
示例三:稽核部門。 稽核工作本質是「怎麼問對問題」——高度依賴經驗。經驗傳承適用性極高。同時稽核發現直接影響內控評估——Materiality 高。定位:象限 A——而且稽核工作本身就要求留下追蹤軌跡,與公開化精神高度契合。這可能是金融業最容易實施 Lehrwerkstatt 模式的部門。
示例四:信用卡部門。 信用卡業務高度數據驅動,組織通常較大、人員流動較快,資料分析的提問藝術需要持續傳承。經驗傳承適用性高。具體業務決策(發卡、額度調整)Materiality 高;行銷分析、市場研究 Materiality 中等。定位:依場景在 A 與 B 之間。
這四個只是示例。把雙軸框架套用到其他部門——財富管理、營業、人資、法遵、後勤——都能得出各自的象限定位。重要的不是「哪幾個部門」,而是「用什麼框架判斷」。
7.5 三道防線在 AgentOps 上的角色重分配
金融業熟悉的三道防線框架——業務單位、風管/法遵、內稽——在 AgentOps 時代會發生角色重分配。
第一道防線(業務單位):從「使用既有 IT 系統的人」變成「Agent 開發者」。當員工可以自建 Agent,第一道防線必須具備新的能力:Agent 設計、Skill 管理、業務邏輯轉譯成 AI 能理解的指令。SR 26-2 的精神在這裡的延伸是:第一道防線必須自己評估自己建造的 Agent 的 Materiality,並對齊內部治理規範。
第二道防線(風管/法遵):從「審查模型上線」變成「持續監督 Agent 行為」。風管需要新的工具來看 Agent 在跑什麼、結果是否異常、是否偏離業務邏輯。SR 26-2 的「effective challenge」原則——風管要對模型有效質疑——在 Agent 時代意味著:風管必須能對 Agent 的決策邏輯與輸出進行獨立判斷。
第三道防線(內稽):從「事後抽查」變成「Agent 軌跡稽核」。內稽需要可審計的 Agent 互動紀錄、決策追溯能力、跨 Agent 的影響鏈條分析。Lloyds Envoy 的「完整稽核軌跡」設計,本質上就是為第三道防線提供的審計基礎。
中信銀法金作業暨資訊處「人 + RPA + AI 三方比對」的設計,是三道防線在 Agent 時代的具體體現——每一道防線都對 Agent 的輸出有獨立判斷機制,確保責任鏈不斷裂。
7.6 收束:從通用 AgentOps 到金融業 AgentOps
走到這裡,金融業 AgentOps 的輪廓已經完整:
- 通用層:四個共識性支柱(治理與安全、可觀測性、成本控制、生命週期管理)
- 金融業特化層:SR 26-2 框架延伸的雙軸結構(四因素 × Materiality)
- 治理型態判斷:經驗傳承適用性與 Materiality 的 2×2 矩陣
- 責任結構:三道防線在 Agent 時代的角色重分配
它不是把通用 AgentOps 換個名字,而是在通用之上,加入金融業特化的判斷框架。
值得注意的是,SR 26-2 雖然把生成式 AI 與 Agentic AI 明確排除在範圍之外,但仍要求金融機構自行建立治理機制——這正是金融業 AgentOps 的真實處境:監管沒有給出標準答案,但要求你必須有答案。
而 SR 26-2 雖然不直接適用,但它的雙軸風險評估邏輯——這是金融業最熟悉、最被監管驗證、最有實踐基礎的框架——可以成為金融業 AgentOps 的核心方法論。這也是台灣金融業相對國際同業的一個機會點:正在成形的學科,正是參與形塑的時機。
【資料來源】
- SR 26-2 (Supervisory Letter), Federal Reserve / OCC / FDIC, 2026/4/17.
- Derrick Goh (2026/4/16), Insights from DBS on being a trusted, AI-enabled bank with a heart, Euromoney.
- 〈玉山金控攜手鼎新數智揭示 Agentic AI 正重塑營運流程〉,Yahoo 新聞/台灣好報,2026/3/27。
- 〈打造亞洲第一個法規報表虛實整合系統 中信銀用 AI 補上推理力〉,經理人雜誌。
- Lloyds Banking Group 官方新聞稿:Lloyds Banking Group unveils Envoy,2026/5。
八、結語:Sprawl 是常態,孤島是失敗,AgentOps 是紀律
回到開場的問題:當建造 AI 代理的門檻低到「非技術人員也能做」，組織該如何治理這場規模空前的擴張?
走完七節之後，答案的輪廓已清晰:
Agent Sprawl 是必然的現象——無論你選擇加速擴張(像國泰、JPMorgan)還是審慎節奏(像玉山)，只要 AI 代理進入企業日常，規模化都會發生。
Agent 孤島是可避免的後果——它不是規模本身造成的,而是「規模沒治理」造成的。
AgentOps 是介於兩者之間的紀律——它不是工具採購清單，而是一套讓 Sprawl 不至於演化為孤島的整合機制。
在這套紀律下,兩條應對路徑並非二選一:結構化治理(像 DBS 的 ADA + ALAN、渣打的 AI Factory、JPMorgan 的 LLM Suite)擅長處理規模與合規;設計性約束(像 Shopify 的「不准私訊」)擅長處理學習與文化。對金融業而言,真正的功課是學會判斷哪個場景該用哪條路徑——SR 26-2 框架延伸出的雙軸結構(Materiality × 經驗傳承適用性),提供了這個判斷工具。
對台灣金融業而言,AgentOps 還在成形——這既是挑戰,也是機會。國際標竿(DBS、渣打、JPMorgan)已經給出參考答案;本土同業(國泰、中信、玉山)各自走出不同的路徑。剩下的工作,是把這些框架應用到自己的部門——授信、徵信、稽核、信用卡,或任何你負責的場景。
Agent 孤島不會自動發生,也不會自動避免。它的命運,取決於組織是否願意把治理視為紀律,而不是事後補救。
