銀行自架 LLM：資料風險與治理要求的實務考量

我進入銀行參與企業級 LLM 平台建置約三個月後，最常被問的問題之一是：「雲端模型已經很成熟，為什麼銀行還要自己架？」

這個問題沒有單一答案。自架模型可以提高資料流向與系統設定的控制程度，但同時要承擔 GPU、模型更新、資安修補、容量規劃與維運人力。雲端服務則能降低基礎設施負擔，卻需要額外評估資料處理、委外管理、服務所在地與契約責任。

因此，不宜先決定部署位置，再回頭補做風險分析。比較合理的順序是：先確認使用情境與資料等級，再決定哪些工作可以使用外部服務、哪些必須留在受控環境，以及每一種選擇需要哪些補償控制。

金管會指引要求的是風險治理，不是單一部署方式

金管會在 2024 年發布的《金融業運用人工智慧（AI）指引》，採風險基礎原則，並明確說明文件屬行政指導性質、不具拘束力。指引涵蓋治理與問責、公平與以人為本、隱私與客戶權益、穩健與安全、透明與可解釋，以及永續發展六個面向。

這份指引沒有要求金融機構一律自架 AI。對第三方服務，重點是盡職調查、契約、資料保護、責任分工與持續監督；對生成式 AI，則要求機構依資料與使用風險採取適當控制。封閉式部署是可能的控制方式之一，但不是所有情境的唯一答案。

這個差異很重要。若把「自架」本身當成合規完成，很容易忽略模型輸出、權限管理與持續監控；反過來，若只因外部服務方便就直接導入，也可能低估資料外送與第三方依賴。

先做資料分級，再選部署架構

同一個 LLM 平台可能同時處理公開文件、內部作業規範與客戶資料。三者的風險不同，不應共用相同的存取與傳輸規則。

實務上，可以先把使用情境拆成幾類：

公開資料的摘要、翻譯與一般知識問答。
內部文件搜尋與作業流程輔助。
含客戶、交易或員工資訊的分析工作。
會影響授信、投資、客戶權益或法規義務的高風險判斷。

接著逐項確認資料能否離開機構控制的環境、是否允許第三方保留、是否需要人工覆核，以及錯誤輸出會造成什麼影響。公開資料的低風險工作可能適合外部服務；涉及敏感資訊或高影響決策時，內部部署、去識別化、專用端點或其他更嚴格的控制就會更有價值。

自架環境的主要價值是控制資料路徑

在我們的情境中，vLLM、平台與 vector database 都部署在受控網路內。這個選擇的主要目的不是追求技術上的獨立，而是讓 prompt、檢索文件、model output 與 log 的流向都能納入既有權限、稽核與 incident handling 機制。

不過，自架不會自動解決隱私問題。若所有員工都能搜尋全部文件、vector database 沒有權限隔離，或 log 完整保存客戶 input，那麼模型即使沒有連上網際網路，風險仍然存在。

我會把隱私強化的優先順序放在以下幾件事：

以身分與群組控制模型、知識庫及工具權限。
讓檢索結果繼承原始文件的存取規則。
對敏感欄位做 Guardrails、用其他資訊替代或阻擋。
限制 prompt、response 與檢索內容寫進 log 的欄位與 retention period。
對高風險輸出保留人工覆核與追溯紀錄。

相較於一開始就導入更複雜的隱私技術，這些控制通常更直接，也更容易落地。FHE、differential privacy 或 TEE 各有適用情境，但是否優先，仍取決於 threat model、效能需求與現有控制缺口。

向量資料庫也要視為敏感資料層

有些團隊會把 embedding 當成已經去識別化的資料，因為它看起來只是一串數字。這個假設並不安全。研究已顯示，特定模型與攻擊條件下，攻擊者可能從文字 embedding 重建部分原文或敏感資訊。

因此，向量資料庫應套用和原始文件相稱的保護，包括網路隔離、加密、身分驗證、細粒度授權與存取稽核。若文件本身不能由某位使用者讀取，檢索系統也不應只因語意相近就把片段提供給他。

實作上最容易出錯的是「先全庫檢索，再由模型判斷能不能回答」。權限檢查應在檢索之前或檢索過程中生效，而不是交給模型事後決定。

PII masking 需要規則與模型分工

姓名、電話、身分證字號、帳號與地址的格式差異很大。只靠正規表示式容易漏掉自然語言中的個資，只靠 NER 模型又可能誤判或漏判固定格式欄位。

比較穩健的做法，是用規則處理格式明確的資料，再由實體辨識模型補足姓名、組織與地址等語意型資訊。遮罩後仍需保留可稽核的類型標記，例如 [ACCOUNT_ID]，以免完全破壞後續任務所需的結構。

此外，PII detection 不應只放在 user input 端。外部文件、RAG 檢索片段、model output 與 tool parameters 都可能帶有敏感資訊，控制點需要跟著資料生命週期配置。

封閉網路降低部分風險，也增加維運成本

無法直接存取 PyPI、模型站與公共 CDN 時，每次更新都需要額外流程。套件、模型權重與容器映像通常要先在外部環境下載、掃描、建立物料清單，再透過核准程序移入內部環境。

這種做法可以縮小未受控的外部連線，但不能說供應鏈風險因此消失。風險會轉移到套件來源、映像建置、離線搬運流程與更新延遲。若沒有版本鎖定、弱點掃描、簽章驗證與緊急修補流程，封閉網路也可能長期停留在已知有漏洞的版本。

自架平台真正困難的部分，往往不是第一次把模型跑起來，而是持續維持可用性與可控性：GPU 容量、模型版本、權限異動、logging、備援、patching 與 incident recovery，都要有人負責。

聯邦學習不是所有自架 LLM 專案的必要項目

聯邦學習適合資料分散在多個組織或環境、不能集中，但又需要共同訓練模型的情境。若目前目標只是讓單一銀行內部部署推論與 RAG，且資料已能在既有權限下集中處理，聯邦學習通常不是第一階段的優先工作。

但這不代表單一銀行永遠不需要聯邦學習。大型機構內部也可能存在資料孤島，跨機構反詐騙或風險模型更可能涉及資料不能直接共享的限制。是否採用，應從具體合作目標、隱私威脅與模型效益評估，而不是因為它是先進技術就先放進架構。

如何決定是否自架

在做部署決策前，我建議先回答以下問題：

模型會接觸哪些資料？資料可以傳到哪裡？
第三方是否保留輸入、輸出或遙測資料？
誰可以使用模型、知識庫與工具？
模型出錯時，對客戶權益與法規義務有何影響？
機構是否有能力維護 GPU、模型版本與資安更新？
發生事件時，能否取得足夠的日誌並停止服務？

如果風險可以透過契約、專用端點、資料遮罩與權限控制妥善管理，雲端服務可能是合理選擇。如果資料不能離開受控環境、需要整合內部授權，或第三方條件無法滿足要求，自架就會更有理由。

自架與雲端不是一次選定後永遠不變的二選一。金融機構更常需要的是分級架構：讓不同資料與任務走不同路徑，並為每條路徑留下責任、控制與稽核證據。

下次評估 LLM 部署方式時，可以先完成一張「資料類型、允許流向、使用者、影響程度、必要控制」的對照表，再討論模型與基礎設施。這會比先選雲端或自架，更容易形成可執行的決策。

常見問題

銀行使用 LLM 是否一定要自架？

不一定。金管會指引採風險基礎方式，第三方 AI 服務也有相應的盡職調查與管理要求。部署方式應依資料敏感度、使用情境、第三方條件與機構維運能力決定。

embedding 可以當成匿名資料嗎？

不建議。研究顯示文字 embedding 可能洩露原文或敏感屬性，實際風險會隨模型、攻擊能力與資料長度而變化。向量資料庫仍應比照敏感資料層保護。

單一銀行需要聯邦學習嗎？

若目前只是內部推論與 RAG，通常先把權限、資料治理與評測做好更實際。當資料無法集中、但多個環境或機構確實需要共同訓練時，再評估聯邦學習的效益與成本。

資料來源與版本說明

關於作者 KJ Huang

KJ Huang（KJH）是來自台灣的軟體工程師與技術主管，擁有超過八年橫跨 AI、區塊鏈、遊戲化、資安與金融的開發及管理經驗，目前投入企業級自架 LLM 平台、RAG 檢索與 AI 治理的實務工作。更多內容請見 kjhuang.com。

本文屬於《銀行裡的 AI 工程》系列。

系列文章：RAG 優化實戰、RAG 為什麼不適合計數。

English version: Why Banks Self-Host LLMs.

銀行為什麼自架 LLM？從資料風險到治理要求的實務考量