內容大綱
一、引言：同一天、三張人才訂單、三條路徑
2026 年 2 月 14 日，台灣三大金控同時在人力銀行上刊登 AI 職缺。
玉山銀行在找「AI 模型評測主管」——從零打造企業級評測架構，主導 AI 紅隊演練，建立黃金測試集的全生命週期管理。國泰金控在找「AI 科技治理專業人員」——將 Responsible AI 框架嵌入模型開發與產品規劃流程，理解 AI 模型運作而非純法遵背景。中國信託在找「AI 互動設計師」與「分行 AI 助理訓練師」——前者要設計 Agent 的長短期記憶模組與多輪對話決策邏輯，後者甚至註明：「歡迎櫃員應徵，三年分行經驗即可。」
同一個產業、同一個時間點，三張截然不同的人才訂單。一家在造尺、一家在建制度、一家在擴產線。
這不是偶然的招募差異。打開三家金控的完整職缺清單，會發現一個更深層的結構：玉山的 14 個 AI 職缺集中在 SRE、雲端工程和模型評測；國泰的 17 個職缺橫跨人壽、世華、產險、證券四家子公司，從 GenAI 工程師到 AI 文化大使一應俱全；中信的 22 個職缺幾乎全圍繞 AI Agent 展開，法金端甚至形成了從流程規劃師到知識管理師到互動設計師到應用建構師的完整產線。
招募即架構宣言——職缺設計本身就是技術路線的鏡像。
過去兩年，台灣金融業的 AI 討論多半圍繞「該選哪朵雲」、「要不要買 NVIDIA 的晶片」。但從三家金控的實際佈局來看，真正的賽局不在雲端平台的選擇，而在選擇之後的架構決策：用雲端的 MLOps 還是自建？Agent 由工程團隊兼做還是獨立設職？治理靠組織委員會、靠工程評測、還是靠外包認證？
本文從雲端平台競爭格局、NVIDIA 晶片端的角色、三家金控的實際架構選擇出發，結合公開招募職缺的交叉驗證，拆解台灣金融業在 Agentic AI 時代的架構賽局。目標不是評判哪條路最好——三條路各有優劣——而是為金融業決策者提供一個評估框架，看清楚每條路徑背後的組織基因、技術取捨與治理風險。
二、三朵雲：Google、AWS、Azure 的企業級 Agentic AI 平台競爭
三足鼎立的平台差異
2025 年下半年起，三大雲端平台不約而同地將產品重心從「LLM 推論服務」轉向「Agentic AI 全生命週期平台」。這個轉向對金融業的意義重大——它意味著雲端平台不再只是模型的「水龍頭」，而試圖成為 Agent 從開發、部署到治理的一站式工廠。
Google Cloud
以 Vertex AI Agent Builder 為核心，打造了從模型到 Agent 的垂直整合平台。其 Agent Development Kit（ADK）自開源以來已被下載超過 700 萬次，支援 Python 與 Java 開發。
2025 年底推出的 Agent Engine 提供全託管運行環境，包含 Sessions（會話管理）、Memory Bank（長期記憶）、Code Execution（程式執行）等服務，並透過 OpenTelemetry 整合 Cloud Trace 實現 Agent 行為追蹤。
2025 年 12 月更推出 Agent Designer——一個低程式碼視覺化介面，讓開發者在畫布上設計多 Agent 協作流程後匯出為 ADK 程式碼。Google 的策略核心是模型原生優勢：Gemini 系列模型與平台深度整合，Vertex AI Search 提供開箱即用的 RAG 方案，Model Garden 涵蓋超過 150 個基礎模型。
對金融業而言，Google 的差異化在於其資料分析生態（BigQuery + Dataplex + Dataflow）能與 Agent 無縫銜接，適合已深度使用 GCP 數據服務的機構。最新的 Cloud API Registry 整合更讓管理者可在 Agent Builder 控制台中統一管理組織內可用的 MCP 工具，為 Agent 治理提供集中管控入口。
AWS
以 Amazon Bedrock 為基座，走多模型市集路線。Bedrock 的核心差異在於模型中立——同一個 API 可存取 Anthropic Claude、Meta Llama、Mistral、Cohere 等多家模型，金融機構不必綁定單一模型供應商。
2025 年 3 月，Bedrock 的多 Agent 協作功能正式 GA，採用 Supervisor-Collaborator 架構：由一個監督 Agent 協調多個專業 Agent，支援動態角色調整（Inline Agents）和關聯資料引用（Payload Referencing）以降低資料傳輸成本。
2026 年初更推出 AgentCore——一個獨立的 Agent 運營平台，涵蓋全託管運行環境、持久記憶、身份管理、可觀測性儀表板，以及透過 Amazon CloudWatch 進行的即時效能監控，支援長達 8 小時的複雜多步驟任務。
Bedrock 同時新增 Responses API 的伺服器端工具執行（Server-side Tools），讓 Agent 在 AWS 安全邊界內執行網頁搜尋、程式碼運行和資料庫更新。
對金融業而言，AWS 的優勢在於企業級整合深度——IAM 權限體系、VPC 網路隔離、CloudFormation/CDK 基礎設施即程式碼——以及 SageMaker 生態系提供的完整 MLOps 工具鏈。
Microsoft Azure
在 2025 年底將原先的 Azure AI Studio 全面升級為 Microsoft Foundry——一個整合模型、工具與治理的統一平台。Foundry Agent Service 於 2025 年 5 月 GA，至今已有超過一萬家客戶使用，支援 Connected Agents（點對點 Agent 互呼叫）與 Workflow（多 Agent 工作流編排）兩種協作模式。
Foundry 最大的差異化在於 Microsoft 生態系整合：與 Microsoft 365、SharePoint、Dynamics 365、Azure Logic Apps 深度銜接，開發者可一鍵將 Agent 發布到 Teams 和 Copilot 頻道，IT 管理員透過 Admin Center 統一治理。
Foundry 的模型目錄涵蓋超過 11,000 個模型，包含 OpenAI GPT 系列與 Anthropic Claude 系列——Azure 是目前唯一同時提供 OpenAI 和 Anthropic 前沿模型的雲端平台。Model Router（已 GA）可動態為每個提示選擇最適合的模型，平衡成本、效能與品質。
Foundry Control Plane 提供集中式的 Agent 治理，涵蓋護欄（Guardrails）、OpenTelemetry 追蹤、持續紅隊測試與 Azure Monitor 洞察。
對金融業而言，Azure 的吸引力在於既有 IT 資產的延續性——大量金融機構已使用 Active Directory、Office 365 和 .NET 技術棧，Foundry 的 Semantic Kernel + AutoGen 整合讓這些既有投資可以自然延伸至 Agentic AI。
金融業選擇平台的關鍵考量
對金融業而言，選擇雲端平台不只是技術偏好，更涉及監管合規、資料主權與長期供應商策略。幾個關鍵維度值得決策者關注。
首先是資料在地化。
台灣金管會《金融機構作業委託他人處理內部作業應注意事項》對資料出境有明確規範。三大平台在台灣的區域可用性不同：Google Cloud 和 AWS 在台灣設有可用區，Azure 同樣有本地部署選項。但更關鍵的問題是——Agent 呼叫外部 LLM API 進行推論時，資料是否算「出境」？這個灰色地帶目前尚無定論。
其次是廠商鎖定風險。
三大平台都在建構自己的 Agent 生態系，但鎖定程度不同。Google 的 ADK 雖開源，但 Agent Engine 的託管服務與 GCP 深度綁定；AWS Bedrock 的多模型策略降低了模型層的鎖定，但 AgentCore 的運營服務同樣依賴 AWS 基礎設施；Azure Foundry 透過支援 MCP、A2A 等開放標準嘗試降低框架鎖定，但 Microsoft 365 整合的便利性本身就是一種生態鎖定。金融業需要的不是「零鎖定」——那不現實——而是在可接受的鎖定範圍內最大化投資回報。
第三是可解釋性工具。
金管會「金融業運用 AI 之核心原則」將「可解釋性與公平性」列為六大核心原則之一。三大平台各有對應工具：Google 的 Vertex AI Explainable AI 提供特徵歸因分析；AWS 的 SageMaker Clarify 加上新的 Automated Reasoning 功能，可進行偏差檢測與自動推理驗證；Azure 的 Responsible AI Dashboard 整合公平性評估、模型解釋與錯誤分析。
但值得注意的是，這些工具多半針對「單一模型預測」的可解釋性——當多個 Agent 協作做出一個貸款決策時，現有工具尚無法解釋整條決策鏈的邏輯，這是三大平台共同的治理空白。
平台菜單 vs 實際點餐
三大平台都提供完整的 MLOps 工具鏈——Vertex AI Pipelines、SageMaker Pipelines、Azure ML Pipelines——以及從資料準備、模型訓練、部署監控到 A/B 測試的全流程支援。從產品頁面看，任何一家平台都足以滿足金融業的全部 AI 生命週期管理需求。
然而，當我們把視線從產品頁面移到台灣三大金控的實際做法，會發現一個有趣的落差：沒有任何一家「照單全收」雲端平台的 MLOps 工具鏈。
玉山銀行與 Google Cloud 合作密切，卻自建了整套 MLaaS 平台（Airflow + FastAPI + Prometheus + K8s）。
國泰金控以 AWS 為主要雲端夥伴，卻自行開發 Data Pipeline 生成器、自建 GAIA 護欄框架和 Model Hub。
中信銀的核心模型訓練圍繞地端的 CTBC Brain 自主建構，AI 治理選擇 SAS 平台而非三大雲端的管理服務——雖然推論層使用了 AWS Bedrock 和 GCP Vertex AI，但模型生命週期的關鍵環節並未交給雲端平台的 MLOps 工具鏈。
這個落差不是偶然。金融業對模型生命週期控制權的堅持——特別是在模型驗證、版本管理和審計追蹤方面——讓雲端平台的 MLOps 更像是「菜單上的選項」而非「預設套餐」。這意味著，對金融業而言，選擇雲端平台只是第一步；真正的架構決策發生在選擇之後——用什麼、不用什麼、自建什麼。
這個「平台菜單 vs 實際點餐」的落差，正是理解三家金控架構差異的關鍵線索。在展開三條路徑之前，我們先看另一個不可忽略的玩家——NVIDIA。
三、一張晶片：NVIDIA NeMo 在金融業的角色
造模型 vs 用模型
如果三朵雲的競爭是「誰來提供 Agent 的運行平台」，那 NVIDIA 的角色則是更上游的一環——「誰來造出金融業需要的模型」。
NVIDIA NeMo 是一套模型訓練與客製化框架，提供 Fine-tuning、RLHF（人類回饋強化學習）、NeMo Guardrails（護欄機制）等能力。它不是部署平台，不直接面對終端用戶，而是讓金融機構在自己的 GPU 基礎設施上訓練和客製化大型語言模型。與雲端平台的關係是互補而非競爭：NeMo 負責「造模型」，雲端平台負責「用模型」。
這個分工之所以重要，是因為台灣金融業面對一個獨特的挑戰：通用 LLM 對在地金融場景的不足。
台灣金融業為何需要地端訓練
GPT-4、Claude、Gemini 等通用模型在英文金融場景表現優異，但面對台灣金融業的實際需求，存在幾個明確的缺口。台灣金融法規體系（銀行法、保險法、證交法）有大量在地化條文和函釋，通用模型難以精準掌握。台語（閩南語）客服場景——許多銀行分行仍有大量台語溝通需求——更是通用模型幾乎無法處理的領域。此外，台灣金融產品的命名邏輯、利率結構、稅務規則與歐美差異顯著，「直接用通用模型」在許多專業場景的準確率無法滿足金融業對錯誤零容忍的要求。
監管層面也推動了地端訓練的必要性。金管會《金融機構作業委託他人處理內部作業應注意事項》對涉及客戶個資的資料處理有出境限制，敏感資料（信用評分、KYC 資料、交易紀錄）的模型訓練若送上公有雲，可能觸及合規紅線。這讓「在自己的 GPU 上、用自己的資料、訓練自己的模型」成為部分金融機構的剛需，而非技術偏好。
中信銀的 CTBC Brain 就是這條路徑的代表。中信資料研發中心下設電腦視覺、NLP、機器思考三大實驗室，搭配 NVIDIA GPU 地端基礎設施，從人臉辨識（通過 NIST 國際認證）到自然語言理解都堅持自主研發。從最新的招募訊號來看，其 NLP 科學家已被要求具備「微服務與 Agent 開發能力」，顯示 CTBC Brain 正從傳統機器學習模型轉型為 Agent-based 架構——地端訓練的模型不再只是單點預測工具，而是 Agent 系統的推論核心。
微服務（Microservices）是一種軟體架構風格，將一個大型應用程式拆解為多個小型、獨立運作的服務，每個服務負責一個特定的業務功能，彼此透過 API 溝通。
用金融業的場景來說明：傳統的核心銀行系統可能是一個巨大的單體應用（Monolith），存款、放款、外匯、風控全部寫在同一個程式裡，改一個功能就要整包重新部署。微服務架構則是把這些功能各自拆成獨立的服務——存款服務、放款服務、外匯服務各自運行、各自部署、各自更新，彼此透過標準化的 API 介面互相呼叫。
分層架構：地端造模型、雲端用模型、RAG 銜接兩者
從三家金控的實踐來看，NVIDIA 晶片端的角色可以用一個三層架構來理解：
Layer 1（地端）負責敏感資料的模型訓練與客製化。這一層使用 NeMo 框架 + NVIDIA GPU，處理不能出境的資料，訓練金融專業模型。目前主要是中信在走這條路，玉山和國泰的重心在雲端。
Layer 2（雲端）負責通用 LLM 推論與 Agent 應用。這一層透過三大雲端平台（Bedrock、Vertex AI、Azure Foundry）存取各家 LLM，處理不涉及敏感資料的 Agent 任務，如客服問答、文件摘要、產品推薦。三家金控都在用，只是選擇的平台和模型不同。
Layer 3（銜接層）是 RAG（Retrieval-Augmented Generation），作為地端知識與雲端模型的橋樑。金融機構的內部法規、產品手冊、客戶案例存在地端知識庫，透過 RAG 餵給雲端 LLM 進行推論，既保護了資料主權，又利用了雲端模型的推理能力。這也解釋了為什麼中信要專門設立「AI 知識管理師」——RAG 的品質取決於知識源的整理品質，而這需要懂業務的人來做。
這個三層架構不是哪家金控的官方說法，而是從三家的實際佈局歸納出的共同模式。它意味著：台灣金融業的 Agentic AI 架構不是「選雲端或選晶片」的二選一，而是「兩者在不同層次各司其職」的分層設計。
四、三條路徑：台灣三大金控的架構抉擇
以下的分析，從雲端選擇、MLOps 實踐、Agentic AI 佈局、人才招募四個維度交叉驗證每家金控的真實架構。招募即架構宣言——職缺設計本身就是技術路線的鏡像。
4.1 玉山銀行 × Google Cloud：工程師自建、品質先行
雲端架構：GCP 單雲深綁
在三家金控中，玉山對單一雲端平台的指向最為明確。資料庫管理工程師的職缺寫明「雲端以 BigQuery 為核心」，並使用 GCP Dataplex 管理元數據與資料血緣；資料工程師的必要條件直接列出「Airflow 或 GCP Composer、Dataflow 等 ETL 工具」；雲端工程師的職缺更直接寫到「配合供應商 GCP 或 SI，引進新技術及最佳實踐」，加分條件是 GCP 相關證照，而「具備 GCP 以外之雲端平台（如 AWS、Azure）開發維運經驗」被列為額外加分——言下之意，GCP 是必要，其他是加分。
玉山同時是三家中唯一在職缺中明確寫出「雲地混合」架構定位的金控。地端資料庫以 PostgreSQL/EDB 為主要平台，雲端以 BigQuery 為核心，兩者並行運作。這個架構設計反映的是務實的資料分級策略：敏感資料留地端、分析資料上雲端。
MLOps：全開源自建 MLaaS
玉山的 MLOps 平台 MLaaS 已從 1.0 演進到 2.0，全部採用開源工具鏈自行建構。工作流編排用 Airflow；API 服務層用 FastAPI、Django 或 Flask；監控用 Prometheus + Grafana；日誌用 EFK（Elasticsearch + Fluentd + Kibana）；容器編排用 Kubernetes + Docker；基礎設施即程式碼（IaC）用 Terraform + Ansible + Helm Chart。
這套工具鏈的特色是完全不依賴任何雲端管理服務。雖然 Google Cloud 提供 Vertex AI Pipelines 等現成的 MLOps 方案，玉山選擇在 GCP 基礎設施上自行搭建開源工具鏈。背後的邏輯是控制權——每一個組件都可被替換、可被審計、可被在地維運，不受單一供應商的功能更新或定價變動影響。
SRE 文化是玉山 MLOps 的另一個鮮明特徵。從招募要求來看，SRE 工程師需熟悉 Postmortem 實踐，API 可用性目標為 99.9%，Day2Ops（上線後持續維運）被視為與開發同等重要的職能。這種工程師文化直接影響了玉山對 AI 品質的態度——不只要能做出模型，更要能穩定運行、持續監控、出問題時快速定位根因。
SRE（Site Reliability Engineering，網站可靠性工程）是 Google 在 2003 年創立的一套方法論，核心理念是用軟體工程的方式來解決 IT 維運問題。
傳統的 IT 維運（Ops）靠人工監控、手動處理故障、被動救火。SRE 則把這些工作自動化——用程式碼來監控系統、自動偵測異常、自動擴縮容量，並透過 Postmortem（事後檢討）制度化地從每次故障中學習，防止同樣的問題再次發生。
從 MLOps 成熟度來看，玉山已達到 Level 2 水準：自動化 CI/CD 管線、持續模型監控、自動觸發重訓練機制。這在台灣金融業中屬於前段班。(分級標準主要參考 Google 在其 MLOps 實踐指南中提出的分級框架)
需要說明的是，本文對三家金控 MLOps 成熟度的判斷，是基於公開招募資料和媒體報導的外部推估，而非三家金控的自我評估或第三方稽核結果。職缺中揭露的技術細節多寡不代表實際能力高低——特別是國泰和中信在職缺中揭露的工具鏈細節較少，不代表內部的 MLOps 實踐不及玉山。
Agentic AI：策略已宣示、落地內部消化
玉山對 Agentic AI 的態度可以用「高層已亮旗、基層穩步走」來形容。總工程師黃仕鎮在 2025 年生成式 AI 年會上公開宣示三層 AI 架構願景：嵌入式 AI（AI Embedded）→ AI 助手（AI Copilot）→ AI 代理人（AI Agent），並明確表態「把 AI 變成 Agentic AI 並整合起來，是未來方向」。
然而在招募端，玉山不設 Agent 專職角色。Agentic AI 的落地由 AI PM 統籌評估——其職缺內容寫明「洞察金融科技趨勢，評估生成式 AI（GenAI）及 Agentic 框架在業務端的應用潛力」——然後交由現有工程團隊內部承接開發。
這種策略背後的邏輯是：先把評測品質做到位，再規模化 Agent 落地。玉山是三家中唯一設立完整 AI 評測體系的金控，這不是巧合。
人才招募佐證：獨步三家的評測工程
玉山約 14 個 AI 職缺全部集中在智能金融處，招募重心是基礎建設（SRE、雲端工程、資料工程）與評測體系。
最值得關注的是 AI Evaluation Lead 和 Senior AI Evaluation Engineer 這兩個角色——在國泰和中信的職缺中完全不存在。AI Evaluation Lead 的職責包括：從零打造企業級 AI 評測架構，定義 LLM/RAG 和傳統 ML 的評測標準（Accuracy、Relevance、Faithfulness、Consistency）；結合 Responsible AI 原則建立公平性、偏差與可解釋性的驗收標準；主導評測自動化策略，推動評測流程與 MLOps/DevOps CI/CD 深度整合；管理黃金測試集（Golden Datasets）的全生命週期，包含邊緣案例與對抗樣本；建立 AI 紅隊演練機制（Red Teaming），針對 Prompt Injection、Jailbreaking 和 PII 洩露定期執行安全測試。
Senior AI Evaluation Engineer 則負責具體的評測工程實作，追蹤的工具包括 RAGAS、DeepEval、TruLens、Promptfoo、Arize Phoenix，並以 OWASP Top 10 for LLM 作為安全標準。評測整合至 Jenkins/GitLab CI，每次模型版本更新自動觸發回歸測試。
這個評測體系的深度在台灣金融業中獨樹一幟。它反映的不只是技術能力，而是一種組織性格：玉山寧可慢半步確保品質，也不要快半步承擔風險。
業務端 AI 角色相對少——只有一個私銀財管 AI 應用企劃。整體而言，玉山的人才策略是「少而精、內部轉型」，一個 Lead AI PM 同時負責 Agentic 框架評估、AI Governance & LLMOps、跨職能協作，以少量精銳協調整個 AI 體系。
4.2 國泰金控 × AWS：組織驅動、制度先行
雲端架構：AWS 組織級合作
國泰金控與 AWS 的合作不只是技術採購，而是組織級的戰略關係。2025 年國泰金控啟動 AWS 種子員工培訓計畫，首批培訓 200 餘人，目標是取得 350 張以上 AWS 認證，其中 70% 與 AI 相關。這個規模在台灣金融業中數一數二，反映國泰將 AWS 視為長期基礎設施夥伴而非短期供應商。
更關鍵的是組織架構：國泰金控層級的 AI Center of Excellence（AI CoE）統一決定雲端資訊架構，子公司不能自行選擇雲端平台。這意味著無論是人壽、世華銀行、產險還是證券，雲端基礎設施的技術標準由金控統一制定。國泰證券的職缺具體列出了 AWS Redshift、Glue、EKS 等服務名稱，但這不代表證券自主選擇了 AWS——而是金控層級的架構決策向下落實。
在此基礎上，國泰自建了兩套關鍵框架：GAIA（複合級護欄技術）和 Model Hub（企業級 AI 模型中心）。GAIA 是國泰自研的生成式 AI 護欄系統，在 LLM 輸入端和輸出端各設一道防線，防止有害內容、資訊洩漏和偏差回應。Model Hub 則是跨子公司的模型管理中心，統一管理模型版本、部署狀態和使用權限。兩者搭配雲端 Data Lakehouse（整合 Data Warehouse 與 Data Lake），形成國泰的 AI 基礎設施三支柱。
MLOps：雲端管理服務 + 自建框架並行
國泰金控的 MLOps 路線介於玉山的「全開源自建」和中信的「地端為主」之間，走的是雲端管理服務與自建框架並行的混合路線。
一方面，國泰金控自行開發了 Data Pipeline 生成器，職缺中也明確要求應徵者至少熟悉一種 MLOps 平台——MLflow、Kubeflow 或 SageMaker——但不指定必須使用哪一個。這種「至少熟悉一種」的寫法暗示國泰金控可能在不同場景使用不同工具，而非全面押注單一平台。
另一方面，國泰在 LLM 推論優化方面的技術要求相當具體：vLLM、TensorRT-LLM、Ollama、模型量化——這些都是當前 LLM 部署的主流開源工具，反映國泰已進入 LLM 生產環境的成本優化階段，而非還在 PoC 階段。
AI 數據平台架構師的職缺特別值得關注。這個角色明確提到「AI 中台與 AI Middleware」的架構概念，涵蓋 Data Lakehouse + MLOps + AI Gateway + Vector Database + Search Engine。其中 GenAI Gateway 負責 Token 用量追蹤與權限控制——當一個組織開始管理 LLM 的 Token 消耗時，代表 LLM 已經從實驗工具變成了生產成本項目。
Agentic AI：GenAI 工程師兼 Agent，四階段路線圖
國泰的 Agentic AI 佈局特色是「不另設 Agent 專職，而將 Agent 能力內嵌於 GenAI 工程師角色」。GenAI 工程師的職缺明確要求具備 Multi-Agent System、Agent Orchestration、MCP/ADK/A2A 等能力。
AI 數據平台架構師的加分條件包含 Agentic Architecture 設計原則——Tool Orchestration 和 Memory Management。AI 維運工程師的加分條件則是 Agent Orchestration Engine 和 Prompt Gateway。
國泰金控的 Agent 發展路線圖最為清晰：GenAI Tools → AI Assistant → AI Agent → AI Native，四階段循序漸進。當前的招募佈局顯示國泰正處於第二到第三階段的過渡期——已有 AI Assistant 的生產應用，正在為 AI Agent 階段儲備人才。
國泰證券的職缺更進一步，要求 Agent-to-Agent 通訊設計和 Multi-Agent 協作，並提供 Java（Spring AI / LangChain4j）與 .NET（Semantic Kernel）雙軌選擇——這在台灣金融業中相當罕見，反映國泰證券的開發團隊有 Java 和 .NET 兩種技術背景，與其券商核心系統的歷史架構一致。
人才招募佐證：全職能光譜最完整的 AI 組織
國泰金控約 17 個 AI 職缺橫跨人壽、銀行、產險、證券、金控 DDT 五個實體，是三家中職能光譜最完整的 AI 組織：AI PM、GenAI 工程師、AI 維運工程師、AI 資料科學家、AI 治理專業人員、AI 推廣專業人員、AI Scientist Tech Lead，從規劃到開發到治理到推廣一應俱全。
兩個獨特角色值得特別關注。
第一是「AI 數據推廣專業人員」——國泰內部定位為「AI 文化大使」，負責全公司 AI 能力養成與文化轉型。這個角色在玉山和中信都不存在，反映國泰將 AI 不僅視為技術專案，更視為組織文化工程。
第二是「Problem Framing」方法論的制度化——這個詞彙在多個職缺中反覆出現，被提升為 AI 團隊的核心方法。Problem Framing 不是「把業務問題轉為技術需求」那麼簡單，而是在技術介入之前，先用結構化方法定義「這到底是不是一個值得用 AI 解決的問題、以及 AI 解決方案的成功標準是什麼」。將這個能力制度化為團隊方法論，在台灣金融業 AI 團隊中並不常見。
AI 治理方面，國泰人壽和國泰世華銀行各設 AI 科技治理專業人員，且明確要求「理解 AI 模型運作」——不是純法遵背景，而是能在技術與法規之間搭建橋樑的角色。這種「治理人員需懂技術」的要求，與國泰金控三層治理制度（金控政策層→子公司管理層→實施細則層）相呼應，形成制度設計者與執行者之間的銜接。
整體而言，國泰金控的人才策略是「系統性擴編、跨子公司佈局」。不是靠一個天才團隊打天下，而是透過組織制度確保每家子公司都有對應的 AI 人才配置。
4.3 中國信託 × NVIDIA：自研核心、Agent 工廠
雲端架構：雙雲 + 地端三層混合
中信的雲端策略是三家中最複雜的——不是因為規模最大，而是刻意追求分散。
最直接的證據來自職缺描述。AI/數據應用工程師（個金）的職缺同時列出 AWS Bedrock 和 GCP Vertex AI 兩個具體的 AI 服務名稱。這不是人力銀行常見的「熟悉 AWS/GCP/Azure」通用寫法——此種寫法是為了擴大人才池；而是在同一個職缺中並列兩家平台的特定 AI 服務，反映這個角色實際上需要在兩個平台之間切換工作。另一個職缺（AI 流程設計師）則提到 AWS Bedrock 和 Microsoft AI Foundry，顯示中信銀在不同業務場景使用不同的雲端 AI 服務。
這種雙雲策略背後有明確的戰略考量。AWS Bedrock 可接入 Anthropic Claude 和 Meta Llama 模型，GCP Vertex AI 可接入 Google Gemini 模型——中信透過雙雲確保不被任何單一模型供應商鎖定。當某家模型供應商調價、停止支援特定功能或出現安全事件時，中信可以快速切換到另一條路徑。
加上地端的 NVIDIA GPU 基礎設施（CTBC Brain），中信形成了三層混合架構：
Layer 1 地端自研（CTBC Brain + NVIDIA GPU，處理敏感資料模型訓練）→
Layer 2 雲端雙雲推論（AWS Bedrock + GCP Vertex AI，處理通用 LLM 推論與 Agent 應用）→
Layer 3 治理外包（SAS AI治理平台，處理 AI 模型風險管理與合規）。這是三家中架構最分散、最強調「不被單一供應商鎖定」的設計。
MLOps：自研核心 + 開源監控
中信銀的 MLOps 策略圍繞「CTBC Brain」自研學習平台展開，並與工業技術研究院合作建構 AI 深度學習系統。CTBC Brain 不只是一個品牌名稱——中信資料研發中心下設電腦視覺、NLP、機器思考三大實驗室，累計部署超過 20 個 AI 專案、取得 20 餘項發明專利，人臉辨識技術通過 NIST 國際認證。
從招募訊號來看，中信銀的 AI 中台已進入生產運作階段——軟體設計工程師的職缺明確寫到「負責 AI 中台環境監控及維運管理」。監控工具鏈為 Prometheus + Grafana + ELK，與玉山高度重合，印證了金融業 SRE 實踐的自然趨同。數據基礎設施方面，中信銀建構了 Spark/Hive 生態系、Hadoop/Cloudera/Kafka 等大數據處理管線，並已導入 Data Lakehouse 架構和知識圖譜技術。
值得注意的是，中信的 NLP 科學家職缺要求「微服務與 Agent 開發能力」——這不是傳統 NLP 研究職位的要求。它證實了 CTBC Brain 正從傳統的機器學習模型工廠轉型為 Agent-based 架構，地端自研的核心能力正在與 Agentic AI 的發展方向接軌。
Agentic AI：三家中最激進，Agent 工廠模式
中信的 Agentic AI 佈局是三家中最激進的——不只是因為投入最多資源，更因為它直接改變了組織的人才結構和業務流程。
法金端形成了一條完整的 Agent 產線：流程規劃師負責訪談業務單位，將企金授信、貿易融資、客服等業務流程拆解為 Agent 可執行的子任務，設計狀態機邏輯；知識管理師負責將企業內規、法令函釋、產品手冊轉為 AI 可讀格式，設計文本 Chunking 策略，建立 QA-Pair 規範和向量化標準；互動設計師負責設計 Agent 的長短期記憶模組、多輪對話決策邏輯和 Self-Correction 機制；應用建構師則負責工程實作，並將現有的 RPA（機器人流程自動化）整合為 Agent 的外部工具——透過 Function Calling 介面，Agent 可以呼叫 RPA 執行結構化的系統操作。
這條產線的技術要求極為具體：Function Calling、Tool Use、State Machine、長短期記憶模組、Self-Correction 邏輯、Agent-to-Agent 溝通。這些不是概念性的未來規劃，而是寫在現職招募要求中的具體技能，意味著中信已在建構或即將建構這些能力。
人才招募佐證：非技術背景 AI 角色大量湧現
中信約 22 個 AI 職缺全部集中在中信銀，是三家中數量最多的。但最引人注目的不是數量，而是角色的多元性——中信銀是三家中唯一大量招募非技術背景 AI 角色的金控。
AI 知識管理師（法金和個金各設一位）的背景要求不是工程師，而是有企金或個金實務經驗的業務人員。他們的工作是將內部法規和業務知識轉為 AI 可讀格式——這意味著中信已認識到，RAG 的品質瓶頸不在向量資料庫的技術實作，而在知識源本身的整理品質。Chunking 策略怎麼切、QA-Pair 怎麼配、知識分級怎麼標——這些決策需要的是業務領域知識，不是工程技能。
AI 流程規劃/設計師需要企金授信、貿易融資或客服經驗，負責將業務流程拆解為 Agent 可執行的子任務。AI 互動設計師需要對話設計或 UX 背景，負責設計 Agent 的記憶模組和對話邏輯。產品 AI 助理規劃師甚至不要求金融經驗，專注 AI 智能銷售推廣和知識庫營運調校。
最具象徵意義的是「分行 AI 助理訓練師」——職缺描述註明「歡迎櫃員應徵！三年分行經驗即可」，工作內容是 AI 平台操作、知識庫調校和 AI 實務場景設計。這是三家金控中唯一將前線人員直接納入 AI 人才體系的案例，意味著中信的 Agent 落地已推到分行端點——不只是總行的科技團隊在做 AI，分行的櫃員也被納入 AI 化的進程。
SAS 工具在中信銀的招募中仍有一席之地。信用風險模型驗證人員仍將 SAS 列為必要工具，與中信選擇 SAS 作為 AI 治理平台的策略一致——治理層的工具選擇與核心 AI 開發工具形成互補而非替代關係。
整體而言，中信銀的人才策略是「大量外招、Agent 工廠化、前線轉型」。它不像玉山靠少數精銳工程師驅動一切，也不像國泰透過組織制度跨子公司複製；中信的路徑是把 Agent 開發拆成標準化的產線工序，每個工序招募對應的專業人才，形成可規模化的 Agent 工廠。
4.4 三條路徑對照
| 維度 | 玉山 | 國泰 | 中信 |
|---|---|---|---|
| 主要雲端 | GCP（單雲深綁） | AWS（組織級合作） | AWS Bedrock + GCP Vertex AI（雙雲） |
| MLOps 路線 | 全開源自建 MLaaS | 雲端管理服務 + 自建框架 | 自研核心 + 開源監控 |
| Agent 落地策略 | AI PM 統籌，現有團隊內部消化 | GenAI 工程師兼 Agent，四階段路線圖 | 完整 Agent 產線，前線人員轉型 |
| AI 職缺數 | ~14 | ~17 | ~22 |
| 最特色角色 | AI 模型評測主管 | AI 文化大使 | 分行 AI 助理訓練師 |
| 組織 DNA | 工程師文化 | 制度治理文化 | 業務驅動文化 |
| 擴張策略 | 少而精，內部轉型 | 系統擴編，跨子公司佈局 | 大量外招，Agent 工廠化 |
三條路徑各自反映了不同的組織基因。玉山的工程師文化讓它自然走向「自建一切、品質把關」；國泰的制度治理文化讓它傾向「組織先行、制度複製」；中信的業務驅動文化讓它選擇「快速落地、專業分工」。沒有哪條路絕對正確，但每條路都有各自的風險盲點——這正是下兩節要探討的。
五、分層混合才是現實：三條路徑的共同啟示
三家金控走出三條截然不同的路徑，但當我們將視線從差異移到共性，會發現幾個被忽略的結構性現象。
選雲 ≠ 用雲的 MLOps
第二節曾提到一個觀察：三大雲端平台都提供完整的 MLOps 工具鏈，但沒有任何一家金控照單全收。現在我們可以把證據攤開來看。
玉山與 Google Cloud 合作最深，GCP 是其明確的主要雲端夥伴。但玉山的 MLaaS 平台完全自建——Airflow 做工作流編排、FastAPI 做 API 服務、Prometheus + Grafana 做監控、EFK 做日誌——全套開源工具鏈跑在 GCP 的 Kubernetes 上，但沒有使用 Vertex AI Pipelines 或 Cloud Monitoring 等 Google 的原生 MLOps 服務。
國泰以 AWS 為主要雲端夥伴，組織級投入超過 200 人取得 AWS 認證。但國泰自行開發了 Data Pipeline 生成器、自建 GAIA 護欄框架、自建 Model Hub——這三個核心組件都不是 AWS 的管理服務，而是國泰在 AWS 基礎設施上自行建構的。職缺要求應徵者「至少熟悉一種 MLOps 平台（MLflow / Kubeflow / SageMaker）」，但不指定必須用哪一個，暗示國泰保留了工具選擇的彈性。
中信走得更遠。它的 AI 核心——CTBC Brain——建構在地端 NVIDIA GPU 基礎設施上，MLOps 根本不在雲上。雲端（AWS Bedrock + GCP Vertex AI）主要用於 LLM 推論層，而非模型生命週期管理。治理則交給 SAS 平台，也不是三大雲端的管理服務。
三家的共同訊息很清楚：金融業對模型生命週期控制權的堅持——特別是在模型驗證、版本管理、審計追蹤和上線審批方面——讓雲端平台的 MLOps 淪為「可選組件」而非「預設方案」。對決策者而言，這意味著選擇雲端平台只是架構決策的起點，不是終點。真正的架構複雜度在於：用雲端平台的什麼、不用什麼、自建什麼。
監控工具鏈的趨同
一個有趣的細節是：玉山和中信——一家深綁 GCP、一家以地端為主——的監控工具鏈高度重合。兩家都使用 Prometheus + Grafana 做效能監控，都使用 EFK（Elasticsearch + Fluentd/Filebeat + Kibana）做日誌管理，都要求 SRE 工程師熟悉 Kubernetes 和 CI/CD 管線。
這不是巧合，而是金融業 SRE 實踐的自然收斂。Prometheus 和 Grafana 是開源監控領域的事實標準；EFK 在日誌處理方面同樣如此。金融業選擇這些工具的共同考量是：開源（不受商用授權限制）、可控（可在地端或雲端靈活部署）、可審計（原始碼可查、監控邏輯可追溯）、社群活躍（問題排除有大量參考資料）。
國泰在職缺中揭露的監控工具鏈最少，但 MLOps 平台要求最明確（至少熟悉 MLflow / Kubeflow / SageMaker 其一）。這暗示國泰走的是「管理服務優先」路線——不自建監控底層，而是在雲端管理服務的基礎上做上層應用。三種路線（全開源自建 / 管理服務優先 / 地端核心 + 開源監控），對應的是三種不同的基礎設施維運哲學，但監控層的技術選擇卻趨同——這反映了金融業在可觀測性（Observability）這件事上的共識比想像中更強。
知識工程：被低估的 Agent 品質瓶頸
三家金控的 Agentic AI 佈局各有特色，但中信銀的一個獨特做法值得所有金融機構關注——它將 RAG 知識管理獨立為專職。
中信的法金和個金各設一位 AI 知識管理師，背景要求不是工程師，而是有業務實務經驗的人員。他們的工作內容極為具體：設計文本 Chunking 策略（一份法規文件該怎麼切段才能讓 AI 正確理解上下文）、建立 QA-Pair 規範（問答對怎麼配對才能覆蓋業務場景）、制定向量化標準格式、進行知識分級標註。這些工作需要的是對業務邏輯的深度理解，而非向量資料庫的技術實作能力。
玉山和國泰目前都沒有設立類似的專職角色。這可能有兩個原因：一是知識管理由工程團隊兼任，二是 Agent 落地尚未深入到需要獨立處理知識品質的階段。無論哪個原因，中信的做法都指向一個重要的產業趨勢：Agent 的品質天花板不在模型能力，而在知識源品質。
這個判斷有直覺上的道理。當前的 LLM——無論是 GPT-4、Claude 還是 Gemini——在推理能力上的差距已經快速縮小。但 RAG 系統的品質取決於檢索到的知識片段是否準確、完整、具有足夠的上下文。一個切段不當的法規文件、一對配對錯誤的 QA、一個分級標註有誤的知識條目，都可能導致 Agent 給出看似合理但實質錯誤的回答——在金融業，這種錯誤的代價極高。
當 Agent 從 PoC 進入生產環境、從個位數增長到數十個，「知識工程」將成為金融業必須正視的新職能。中信目前是唯一認知到這一點並付諸行動的金控。
Agent Sprawl 的隱憂
隨著 Agentic AI 的加速落地，一個新的風險正在浮現：Agent Sprawl——Agent 數量的失控擴張。
中信的 Agent 產線化策略雖然加速了落地，但也可能加速 Sprawl 風險。當法金有自己的 Agent 產線、個金也有自己的、分行又有自己的 AI 助理，如何確保跨 Agent 的一致性？不同 Agent 的知識庫版本是否同步？Agent A 呼叫 Agent B 時的權限邊界如何定義？Agent 出錯時的責任歸屬如何釐清？
三家金控目前的分層防線設計——敏感資料訓練在地端、通用 Agent 應用在雲端、RAG 銜接兩者——可以處理資料安全面向的風險，但不足以應對 Agent 治理面向的挑戰。
這正是下一節要探討的核心問題。
Agent Sprawl 借用了 IT 領域既有的「Sprawl」概念——VM Sprawl（虛擬機蔓生）、Cloud Sprawl（雲端資源蔓生）——指的是組織內 Agent 數量失控擴張，導致管理困難的現象。
具體來說：當各部門各自建立自己的 Agent（法金有法金的、個金有個金的、分行又有分行的），短期內每個 Agent 都解決了局部問題，但長期會出現幾個麻煩。不同 Agent 的知識庫版本可能不同步，導致同一個客戶問同一個問題，從不同管道得到不同答案。Agent 之間的權限邊界不清楚，Agent A 呼叫 Agent B 時該有什麼存取限制，沒有統一規範。出了問題要追責時，決策經過了哪些 Agent、每個 Agent 貢獻了什麼判斷，追溯鏈斷裂。加上每個 Agent 都需要維護、更新、監控，維運成本隨數量線性甚至指數增長。
六、三種治理範式：同一道題，三種解法
金管會 2024 年發布「金融業運用人工智慧（AI）之核心原則及相關推動政策」，明確要求金融機構在可靠性與安全性、公平性與非歧視性、隱私保護與資料治理、透明性與可解釋性、問責機制、永續發展六大核心原則下推動 AI 應用。
面對同一份監管要求，三家金控走出了三條完全不同的治理路徑。
玉山——造尺的人：工程 + 學術雙軌
玉山的 AI 治理架構由三條線交織而成。
學術線：玉山與陽明交通大學科技法律學院合作，共同研擬 AI 治理框架與風險管理機制。這不是形式上的產學合作——目標是「建立安全、穩定、負責任且值得信賴的 AI 應用」，由法律學者從法規面提供治理框架的理論基礎和國際趨勢研究。
工程線：AI Evaluation 團隊是玉山治理體系的技術核心。紅隊演練（Red Teaming）定期模擬 Prompt Injection、Jailbreaking 等攻擊場景，測試 AI 系統的安全防線。自動化評測 CI/CD 將模型品質檢查整合進持續部署管線，每次模型更新自動觸發回歸測試。黃金測試集（Golden Datasets）涵蓋邊緣案例和對抗樣本，確保模型在極端場景下仍能維持品質。OWASP Top 10 for LLM 作為安全基準線。
管理線：AI PM 在每個專案中兼管 AI Governance & LLMOps，確保治理原則在專案層級落地。董事會下設「科技諮詢委員會」由董事長黃男州親自召集，延攬前 Google 台灣董事總經理簡立峰等外部委員，從最高層級為 AI 策略把關。
玉山的治理能力長在工程團隊和學術合作上。優勢是治理深度——紅隊演練和自動化評測的技術含量在三家中最高。風險盲點則在於：治理依賴工程師的自覺紀律和學術合作的研究節奏，缺乏組織層級的強制力。如果關鍵 AI PM 離職，治理知識可能出現斷層。此外，學術研究的產出速度未必能跟上 Agent 落地的迭代節奏。
國泰——建制度的人：組織制度驅動
國泰的 AI 治理架構是三家中組織層級最高、制度設計最完整的。
頂層是金控級的「資料暨 AI 治理委員會」——由原本的資料治理委員會升格而來，控股及各子公司 CEO 主持。這個升格動作本身就有象徵意義：AI 治理被拉到與資料治理同等的組織層級，而非附屬於資訊部門。
執行層是 AI Center of Excellence（AI CoE），統一管理跨子公司的 AI 開發、技術框架選擇和資源配置。AI CoE 的權限範圍涵蓋雲端架構決策——子公司不能自行選擇雲端平台——反映國泰將 AI 治理視為金控層級的統一事務，而非各子公司的自主判斷。
制度層是三層治理結構：金控政策層制定原則與方向、子公司管理層落實執行標準、實施細則層規範具體操作流程。高風險 AI 應用需要 CEO 或委員會升級審批。
技術層是自建的 Responsible AI（RAI）技術框架和 GAIA 雙護欄設計（輸入端過濾有害提示、輸出端過濾偏差回應），為制度層提供技術支撐。
人才層則是在國泰人壽和國泰世華銀行各設 AI 科技治理專業人員，且明確要求理解 AI 模型運作——不是純法遵背景的合規人員，而是能在技術和法規之間搭橋的複合型人才。
國泰的治理能力長在組織架構和制度流程上。優勢是覆蓋面廣、制度可複製——同一套治理框架可以在人壽、銀行、產險、證券之間統一執行。風險盲點則在於：制度可能過重。當 Agent 的迭代週期從月縮短到週甚至天，治理委員會的決策頻率能否跟上？三層審批機制是否會成為 Agent 快速落地的瓶頸？制度設計得再完善，如果執行速度跟不上技術演進，就可能從「護欄」變成「牢籠」。
中信——買保險的人：外包專業認證
中信的 AI 治理架構走了一條與前兩家截然不同的路——核心 AI 自研，治理外包。
2025 年 8 月，中信與 SAS 合作，成為台灣首家完成 AI 治理系統驗證的金融機構。SAS 的解決方案對齊了 NIST AI Risk Management Framework、GDPR 和 ISO 42001 等國際標準，提供 HMS（全託管服務）99% SLA 和 24/7 技術支援。
這個選擇的策略邏輯很清晰：中信將核心 AI 能力（電腦視覺、NLP、模型訓練）視為必須自建的競爭優勢，但將 AI 治理視為可以借助外部專業平台快速達標的合規需求。SAS 在全球金融監管圈的品牌認可度——被數千家金融機構使用、被主要金融監管機構認可——為中信提供了一種「認證背書」效果：當監管機構來查的時候，「我們使用全球金融業標準的 SAS 治理平台」比「我們自建了一套治理框架」更容易獲得信任。
從招募訊號來看，這個策略是一致的。中信的 22 個 AI 職缺中沒有 AI 治理專職角色——治理工作由 SAS 平台承擔，不需要專人維護。信用風險模型驗證人員仍將 SAS 列為必要工具，顯示 SAS 在中信的模型風險管理流程中已深度嵌入。
中信的治理能力長在外部認證和專業平台上。優勢是落地速度快——不需要從零建構治理框架，也不需要培養治理專職人才，買下 SAS 的解決方案就能快速合規。而且必須肯定的是，SAS 在傳統統計模型的治理領域——信用評分卡、風險評等模型、反洗錢偵測模型——確實是全球金融監管圈的事實標準，經營數十年，美國聯準會 SR 11-7 模型風險管理要求幾乎就是照著這類平台的能力來設計的。中信選擇 SAS 處理既有模型的治理需求，是務實且合理的決定。
但風險盲點在 Agentic AI 這一層浮現。傳統統計模型的治理之所以成熟，是因為這類模型的特性適合審計：輸入輸出明確、特徵可列舉、邏輯迴歸的每個係數都有統計意義、驗證回測有標準方法。LLM 和 Agent 的特性則完全不同——LLM 是黑盒子（特徵歸因無法像邏輯迴歸那樣直接解讀）、Agent 的行為具有隨機性（同一個輸入可能產生不同的決策路徑）、多 Agent 協作的決策鏈是動態生成而非預先定義的工作流程。這些特性讓傳統 MRM 的方法論——模型文件、驗證回測、壓力測試——很難直接套用。
SAS 宣稱對齊 NIST AI RMF 和 ISO 42001，但這些框架本身也還在演進中，尚未針對多 Agent 協作有成熟的治理規範。當中信的 Agent 產線開始量產，Agent 之間的互動、決策鏈的追蹤、權限邊界的管理，都超出了現有 SAS 平台的能力邊界——不只是 SAS，三大雲端平台的治理工具同樣還停留在單一模型層級，這是整個產業的共同空白。
三家共同的治理真空：AgentOps
無論哪種治理範式，三家金控都面對同一個尚未解決的問題——當多個 Agent 開始協作決策時，誰來治理它們？
現有的 MLOps——無論是玉山的自建 MLaaS、國泰的混合框架還是中信的 SAS 平台——都是為「單一模型的生命週期管理」設計的：模型開發 → 訓練 → 驗證 → 部署 → 監控 → 重訓練 → 退役。這套流程可以管好一個模型，但管不了十個 Agent 的協作。
多 Agent 協作帶來的治理挑戰至少包含三個層面。
第一是可解釋性的維度爆炸
當一個 Agent 獨立做出貸款審核建議時，我們可以追溯它參考了哪些資料、使用了什麼模型、輸出了什麼推論。但當一個信用評估 Agent 呼叫了反洗錢 Agent 和客戶分群 Agent，三者的結論彼此影響後做出最終建議時，決策鏈的可解釋性就變成了指數級的複雜問題。目前三大雲端平台的可解釋性工具都只針對單一模型預測，尚無法處理這種多 Agent 決策鏈的解釋需求。
第二是自主決策權限的邊界
AI Agent 的「A」代表 Autonomous——自主。但在金融業，「自主」到什麼程度是可接受的？Agent 可以自動回覆客戶的產品諮詢，但可以自動核准一筆百萬元的貸款嗎？可以自動調整客戶的投資組合嗎？Human-in-the-loop（人類介入）機制的設計需要在效率和安全之間取得平衡，而這個平衡點會隨著業務場景、風險等級和監管要求而不同。目前三家金控都沒有公開揭露其 Agent 自主決策權限的分級框架。
第三是審計追蹤的粒度
當多個 Agent 之間透過 Function Calling、Tool Use、A2A 通訊等機制互動時，每一次互動都需要被記錄、可回溯、可審計。這不只是技術問題，更是合規問題——當監管機構要求金融機構解釋某個 AI 決策的完整路徑時，Agent 間的通訊紀錄必須像交易紀錄一樣完整保存。
三家金控的 AgentOps 準備度各不相同。中信的 Agent 產線最完整，但其 SAS 治理平台尚未覆蓋多 Agent 協作的治理需求，形成「Agent 跑最快、治理追不上」的潛在風險。國泰的三層治理制度在設計上可以容納 AgentOps——只要在實施細則層增加 Agent 協作的治理規範——但目前尚未明確定義。玉山的評測體系最可能自然延伸至 AgentOps，因為它已經有 CI/CD 整合的自動化評測管線和紅隊演練機制，技術架構上最容易從「單模型評測」擴展到「多 Agent 評測」。
監管灰色地帶
AgentOps 的治理真空之外，還有幾個監管灰色地帶值得關注。
公平放貸場景
當 AI Agent 參與貸款條件的決定——利率定價、額度核定、擔保要求——如何確保不違反公平放貸原則？特別是當 Agent 使用的特徵工程涉及間接關聯的敏感屬性（例如郵遞區號可能間接反映族群分布）時，偏差可能以不易察覺的方式滲入。
投資適合度場景
金管會對投資型保單和理財商品有 KYC（認識客戶）和 KYP（認識產品）的要求。當 AI Agent 推薦投資組合時，其決策邏輯能否通過金管會的檢查？特別是當 Agent 整合了客戶分群模型、市場預測模型和產品配對模型時，推薦邏輯的可追溯性面臨挑戰。
跨境合規
Agent 使用雲端 LLM 進行推論時，客戶資料（即便只是問句中包含的個資片段）是否算「出境」？三大雲端平台在台灣都有部署，但 LLM 推論的實際運算位置可能不在台灣——這個灰色地帶目前缺乏明確的監管指引。
國際趨勢方面
歐盟 AI Act 已於 2024 年正式通過，將信用評分、保險定價等金融場景列為「高風險 AI」，要求嚴格的合規審查和人類監督。新加坡金融管理局（MAS）的 FEAT 原則（Fairness, Ethics, Accountability, Transparency）則提供了另一套更貼近亞洲金融市場的治理框架。台灣金管會的 AI 應用指引目前以原則性規範為主，尚未進入細則立法階段——這既是機會（金融機構有空間探索最適合自己的治理路徑），也是風險（缺乏明確標準可能導致各家做法參差不齊，或在未來法規明確化時面臨整改成本）。
七、結語：架構選擇的背後是治理能力的競賽
三條路徑各有優劣
| 維度 | 玉山 | 國泰 | 中信 |
|---|---|---|---|
| 架構哲學 | 工程師自建一切 | 組織制度先行 | 業務驅動快速落地 |
| Agent 落地速度 | 最穩（先評測再上線） | 中等（先治理再落地） | 最快（先落地再完善） |
| 治理深度 | 技術性最強 | 組織性最強 | 認證性最強 |
| 供應商鎖定風險 | 最高（GCP 深綁） | 中等（AWS 為主） | 最低（刻意分散） |
| 擴展彈性 | 依賴內部人才培養 | 可跨子公司制度複製 | 可大量外招快速擴編 |
三條路徑沒有絕對的優劣。玉山的「先評測再上線」可能錯過市場先機，但也可能因此避開一場 AI 事故。國泰的「先治理再落地」可能減慢速度，但當監管趨嚴時已有完備的制度基礎。中信的「先落地再完善」可能累積技術債，但也可能因為搶先佈局 Agent 而建立先行者優勢。
對決策者的四個提醒
第一，人才策略即架構策略
你招什麼人，決定了你能走哪條路。玉山招評測工程師是因為自建一切需要人把關，國泰招治理專員和文化大使是因為組織驅動需要制度人才與文化推動者，中信招 Agent 設計師和知識管理師是因為 Agent 工廠化需要新工種。在決定技術架構之前，先問自己的組織基因適合哪條路——工程師文化的組織很難走制度驅動路線，業務導向的組織也未必適合全自建模式。
第二，知識工程是被低估的瓶頸
Agent 的品質取決於知識管理，而非模型能力。中信已將知識管理獨立為專職，法金和個金各設知識管理師。當你的 Agent 給客戶的回答不準確時，問題很可能不在模型，而在餵給模型的知識——Chunking 切得不對、QA-Pair 配得不準、知識版本沒有即時更新。這是一個需要業務人員而非工程師來解決的問題。
第三，選雲不等於選 MLOps
三家金控的實踐已經證明，雲端平台提供的 MLOps 工具鏈幾乎都沒有被照單全收。金融業對模型生命週期控制權的堅持，讓自建或混合路線成為必然。在評估雲端平台時，與其關注平台的 MLOps 功能有多完整，不如關注平台在被「部分採用」時的彈性——能不能只用它的運算資源和模型服務，而不被綁定在它的 MLOps 管線上。
第四，多雲、多模型、多代理時代，治理能力才是護城河
三家金控的技術能力差距不大——都有百人以上的 AI 團隊、都有成熟的模型開發經驗、都在積極佈局 Agentic AI。但治理路線的差異巨大——工程評測型、組織制度型、外包認證型。當 Agentic AI 從 PoC 進入大規模生產，AgentOps 層的治理能力——多 Agent 決策鏈的可解釋性、自主決策權限的分級管理、Agent 間通訊的審計追蹤——將決定誰能走得更快、更穩。技術可以追趕，治理卻需要時間沉澱。
側欄 Box：從職缺看架構——三家金控 AI 招募解碼
2026/2/14 同日查詢，三家金控的 AI 公開職缺一覽：
| 維度 | 玉山 | 國泰 | 中信 |
|---|---|---|---|
| AI 職缺數 | ~14 | ~17 | ~22 |
| 最特色角色 | AI 模型評測主管 | AI 文化大使 | 分行 AI 助理訓練師 |
| Agent 專職 | 無（AI PM 兼管） | 有（GenAI 工程師含 Agent） | 大量（完整 Agent 產線） |
| 治理專職 | 無（AI PM + 評測工程化） | 有（子公司各設專職） | 無（SAS 平台外包） |
| 知識管理專職 | 無 | 無 | 有（法金+個金各設） |
| 評測專職 | 有（獨步三家） | 無 | 無 |
| 業務端 AI 角色 | 少 | 中 | 多 |
| 雲端平台 | GCP 單雲 | AWS 主力 | AWS+GCP 雙雲 |
| 組織 DNA | 工程師文化 | 制度治理文化 | 業務驅動文化 |
| 擴張策略 | 內部轉型 | 系統擴編 | 大量外招 |
附錄：研究資料來源
公開招募資料：三家金控公開招募職缺（104 人力銀行 + 各公司官網，查詢日 2026/2/14）——玉山銀行約 14 個 AI 相關職缺、國泰金控約 17 個 AI 相關職缺（跨人壽、世華、產險、證券、金控 DDT）、中國信託約 22 個 AI 相關職缺。
技術報導：iThome 系列報導（玉山 MLaaS 平台演進、國泰 GAIA 框架、中信 CTBC Brain）；商益（BusinessYee）玉山 GENIE 首年實戰紀錄（2025 生成式 AI 年會）；數位時代（BNext）玉山銀行 AI 四大構面（制度、人才、資訊、服務）；聯合新聞網玉山總工程師黃仕鎮談三層 AI 架構。
治理與合作：SAS 官方新聞稿——中國信託 AI 治理系統驗證（2025/8）；數位時代——玉山與陽明交通大學科技法律學院 AI 治理合作；國泰金控公開資料——資料暨 AI 治理委員會、AI CoE 組織架構。
雲端平台與產業：AWS、Google Cloud、NVIDIA 台灣金融客戶案例與合作發布；金管會「金融業運用人工智慧(AI)之核心原則及相關推動政策」。
