企業導入 LLM 的資料邊界設計：什麼該上雲、什麼必須留在地端
企業導入 LLM 時，資安部門和推動單位最常上演的對話是這樣的：
推動單位：「我們想用雲端的大模型，效果最好、迭代最快。」 資安部門：「公司資料不能出去，全部地端。」
然後專案就卡住了。要嘛推動單位妥協，買一台 GPU 伺服器跑開源模型，發現效果與維運成本都不如預期，專案不了了之；要嘛資安部門被高層壓下去，資料就這樣上了雲，留下一筆沒人說得清楚的風險。
這兩種結局有同一個病根：把「資料邊界」當成一個是非題，而它其實是一個設計題。「全部地端」和「全部上雲」都是偷懶的答案——前者用最高成本迴避思考，後者用最高風險迴避思考。真正該做的，是把資料與流程拆開來,讓每一種資料流向它該去的地方。
第一步：承認「公司資料」不是一種東西
「公司資料不能外流」這句話的問題在於，它把所有資料當成同一種東西。但實際上，一家企業的資料至少可以分成幾個敏感度等級：
- 公開資料——官網內容、產品型錄、已發布的財報。這些資料本來就在網路上，用雲端模型處理沒有額外風險。
- 內部一般資料——會議記錄、內部文件、流程手冊。外流會尷尬，但不會造成直接損害或法律責任。
- 敏感營運資料——客戶名單、價格策略、未公開財務數字、研發文件。外流有實質商業損害。
- 受法規管制資料——個資（個資法）、病歷（醫療法）、金融交易紀錄（金管會規範）、跨境傳輸受限的資料。外流不只是損害，是法律責任。
做完這個分級，你會發現一件事：大多數企業想用 LLM 處理的場景，七、八成落在前兩級。客服知識庫問答、公開資訊摘要、行銷文案、程式碼輔助——這些場景根本不需要為了最高等級的資料，去背負最高等級的架構成本。
真正需要嚴格管控的，是後兩級。而後兩級的場景，往往也正是價值最高的場景——所以值得為它們設計專門的處理路徑，而不是讓全公司的所有場景都遷就同一條規則。
第二步：把「一次 LLM 呼叫」拆開來看
第二個常見的思考盲點，是把「用 LLM」當成一個不可分割的動作。實際上，一個典型的企業 LLM 應用（例如知識庫問答）至少包含四段資料流，每一段的敏感度都不一樣：
- 知識庫本體——你的文件全文。這是最大宗、最敏感的部分。
- 檢索過程——把文件切塊、做向量索引、根據問題找出相關段落。
- 推論過程——把「問題＋相關段落」送給模型生成回答。真正離開你掌控範圍的，只有這一段送出去的內容。
- 日誌與回饋——問答紀錄、使用者評分。常被遺忘，但裡面累積的資訊量可能比單次呼叫更敏感。
拆開之後，設計空間就出現了。知識庫本體和向量索引可以完全留在地端或私有雲——它們從頭到尾不需要碰外部服務。推論時送出的內容，只是被檢索出來的少數段落，而不是整個知識庫；這些段落可以在送出前做去識別化處理（遮蔽人名、統編、帳號等欄位）。日誌可以規定落地儲存、定期稽核。
換句話說：「用雲端模型」不等於「把資料庫搬上雲」。送出去的東西可以被限縮、被過濾、被記錄——前提是你在架構裡設計了這道關卡。
第三步：設一道 LLM Gateway，讓邊界變成可稽核的程式碼
上面的設計原則，落地時通常收斂成同一個架構元件：LLM Gateway（或稱 AI Gateway）——一個介於內部應用與外部模型服務之間的代理層。所有要呼叫模型的請求，一律經過這道閘門，而閘門負責執行你的資料邊界政策：
- 路由：依場景與資料等級，把請求導向不同的模型——公開資料走雲端旗艦模型，管制資料走地端模型或專屬部署。
- 過濾與去識別化：送出前自動偵測並遮蔽個資欄位；必要時做「假名化—還原」的雙向對應。
- 記錄與稽核：每一筆送出的內容、目的地、時間、呼叫者，全部留痕。資安部門要的「資料到底流去哪裡」，從此有精確答案。
- 額度與成本控管：按部門、按應用計量，避免 API 費用失控。
這個元件的價值,不只是技術上的，更是組織上的：它把「資料能不能出去」從一場部門間的信任攻防，變成一份可以被檢視、被稽核、被逐步放寬或收緊的政策設定。資安部門不必再用「一律禁止」保護自己，因為他們第一次有了「有條件允許、事後可查」的工具。
第四步：地端模型的真實帳單，算給你看再決定
那麼，哪些場景真的該用地端模型？我們的建議是：用「法規要求」和「總持有成本」兩把尺一起量，而不是用直覺。
地端（或私有雲專屬部署）的合理時機：
- 法規明確要求資料不得出境或不得交付第三方處理（部分金融、醫療、政府場景）；
- 資料量大且呼叫頻繁，長期 API 費用確實高於自建（要用正式流量算，不是用 PoC 流量算）；
- 場景對模型能力要求不高，中型開源模型足以勝任。
但同時要誠實面對地端的完整成本：GPU 硬體與機房、模型更新與維護的人力、以及最容易被低估的一項——能力差距的機會成本。地端可部署的開源模型與雲端旗艦模型之間存在能力差距，在複雜推理場景尤其明顯。如果因為模型不夠好導致使用率低落，省下的 API 費用只是把浪費換了一個科目。
實務上最常見的合理解，是混合架構：八成的一般場景走雲端（經過 Gateway 管控），兩成的管制場景走地端或專屬部署。讓例外真正成為例外，而不是讓例外定義整個架構。
結語：邊界是設計出來的，不是宣示出來的
「資料不能外流」是一個立場，不是一個架構。立場宣示完之後，該做的工作才開始：分級你的資料、拆解你的流程、在架構裡放進可執行也可稽核的關卡，然後誠實計算每一種部署方式的總成本。
這樣設計出來的邊界，資安部門敢簽字，因為每一條資料流都有紀錄可查；使用者願意用，因為大多數場景拿到的是最好的模型；財務部門也點頭，因為錢花在刀口上。
先把系統該長什麼樣想清楚，再決定買什麼、建什麼——架構分析的價值，就在於讓這場原本無解的攻防，變成一張所有人都看得懂的設計圖。