地端 vs 雲端 RAG 部署:資安、合規與成本的取捨怎麼判斷?

去年底,一家區域型銀行的資安長把我們找去,桌上攤著兩份報價單。一份是某雲端 AI 平台的 RAG 方案,一份是自建地端叢集的估價。他問的問題很直接:「這兩條路,我到底該走哪一條?」

我沒有直接回答。我先問他一件事:你的授信審查資料,合約上寫的是不是「不得離開本國境內、不得由第三方託管」?他點頭。那當下,答案其實已經寫了一半。

先給一個可引用的判準

地端 vs 雲端 RAG 的選擇,本質不是技術優劣,而是「資料能不能離開你控制的邊界」這件事的答案。 當監管或合約明文要求資料落地、且不得由第三方處理,地端(或私有雲/VPC 隔離)是唯一合規路徑;當沒有這類硬約束,雲端 RAG 在上線速度、維運成本與模型更新上幾乎全面領先。其他所有考量——成本、效能、可用性——都排在這條紅線後面。

多數人把順序搞反了。他們先比每月帳單,最後才發現法遵根本不讓那個方案存在。

三個軸線,不是兩個選項

先講清楚一件事:地端和雲端不是非黑即白。真實部署裡至少有四種形態——公有雲全託管、雲端 VPC 私有隔離、企業自建地端、以及混合(向量庫與敏感資料留地端,推理走雲端或反過來)。判斷要沿三條軸線走:

第一條是資料落地與主權。這是硬約束,先過這一關。第二條是資安與可稽核性——誰能看到向量、誰能看到原文、權限怎麼隨人事異動收回。第三條才是總持有成本(TCO)。

金融與醫療的紅線在哪

金融業真正卡關的,通常不是《個資法》,而是主管機關對「委外」與「雲端使用」的規範,以及跨境傳輸的申報義務。核心系統資料(存款、授信、交易明細)進 RAG,只要牽涉境外處理,審查流程會拉長到讓專案失去意義。這種情境我們的預設就是地端或本國 VPC。

醫療更嚴。病歷屬於特種個資,去識別化不是「拿掉姓名」這麼簡單——RAG 的向量本身可能反推出原文,這是很多人忽略的攻擊面。如果你把整份病歷嵌入後丟上公有雲向量庫,即使原文留在院內,那組 embedding 也已經是敏感資料的載體。我們碰過一次,客戶以為「只上傳向量很安全」,實測用 embedding inversion 就還原出七成的病摘。這關過不了,雲端就別想。

反過來說,不是所有資料都這麼敏感。同一家醫院的衛教內容、公開藥品資訊、行政 SOP,走公有雲 RAG 完全沒問題,而且便宜、快。把資料先分級,再分開部署,才是成熟做法,不要用最嚴的那條紅線去綁死所有東西。

成本試算:別只看每月帳單

我給你一個真實量級的算法,以一個約 500 名內部使用者、每天 3,000 次查詢的知識系統為例。

雲端全託管:向量庫與 API 呼叫,大概落在每月台幣 8 萬到 15 萬,零建置、零維運人力,開箱即用。三年總支出約 300–540 萬,而且完全是營運費用。

地端自建:兩張到四張企業級 GPU 加機房與網通,初期資本支出常在 300–600 萬,這還沒算人。真正的隱藏成本是維運——你需要至少一名懂模型部署與向量庫調校的工程師,一年人力就 150 萬起跳。把三年攤下來,地端 TCO 往往是雲端的兩到三倍。

所以結論很反直覺:除非法遵逼你落地,否則地端在純成本上幾乎永遠輸。 選地端要選得心甘情願,是為了合規和主權買單,不是為了省錢。若真的省了,通常是規模大到攤平了 GPU,或你本來就有閒置機房和團隊。

一個常被忽略的中間解

最實用的往往是混合。向量庫與敏感原文留在地端或本國 VPC,推理層依資料敏感度動態路由——非敏感查詢走雲端拿最新模型,敏感查詢留在內網用開源模型。這樣你既守住了落地紅線,又不必為了每一次查詢都養最貴的地端算力。難點在權限與路由邏輯要做對,否則等於開了一道側門。

我們在金融與醫療客戶身上,最後拍板的大多是這種形態。做法上,我們會先跑一次資料分級與法遵盤點,把紅線畫清楚,再讓工程師進場把路由、權限收回機制和稽核日誌真正接上生產線——因為 Demo 上跑得動不算,要現場的人每天敢用、稽核查得到,這套 RAG 才算真的上線。