關於本地 LLM 與公共 AI API 的爭論往往過於簡化。
一派認為每家公司都應該在本地運行模型；另一派則認為企業級 AI API 已經足夠安全，且操作起來簡便得多。
針對敏感的 Excel 數據，更好的答案其實更具務實性：應根據試算表的敏感度、安全流程的成熟度以及用戶實際需要的工作流來匹配架構。
公共 API、企業級 AI 服務、本地模型、私有 VPC 部署以及混合脫敏工作流，在不同的場景下都可能是正確的選擇。
為什麼 Excel 數據需要特殊照護
試算表很容易被低估。
它們通常包含那些從未進入受控 BI 系統的數據：
- 客戶層級的營收
- 薪資與佣金
- 預測數據
- 預算
- 董事會報告數據
- 供應商條款
- 客服導出資料
- 稅務記錄
- 營運異常情況
- 個人識別資訊 (PII)
當員工將這些文件上傳到聊天機器人時，公司可能會失去對數據去向、保留時間、訪問權限以及該行為是否符合政策的控制。
風險不僅在於技術層面，更在於流程。大多數試算表的上傳行為都發生在正常的數據治理路徑之外。
五大主要選項
1. 公共聊天機器人 (Public chatbot)
這是最簡單的路徑。用戶打開聊天機器人，上傳文件並要求分析。
這對於公開數據或合成數據來說沒問題。但對於機密文件則充滿風險，除非組織已明確批准該工具及其用途。
主要優點是速度快；主要風險是數據洩露失控。
2. 公共 API (Public API)
公共 API 比消費級聊天機器人給予開發者更多控制權。他們可以構建內部應用、限制發送內容，並更仔細地管理提示詞（Prompts）。
但數據仍然會離開公司的環境。供應商的數據使用、保留、日誌記錄和合規條款至關重要。
對許多公司來說，這在經過供應商審查並簽署正確合約後是可行的，但不應將其視為自動安全。
3. 企業級 AI 服務 (Enterprise AI service)
企業級 AI 平台通常提供更強的隱私承諾、管理控制、加密、不訓練承諾、保留選項和合規文件。
範例包括 OpenAI、Microsoft Azure OpenAI、AWS Bedrock、Google Vertex AI、Anthropic 等提供的企業方案。
對於希望獲得強大模型質量而不想自行維護 GPU 基礎設施的公司來說，這通常是最佳的折衷方案。
權衡之處在於，即使在更強的企業控制下，處理過程仍發生在公司自有伺服器之外。
4. 本地 LLM (Local LLM)
本地 LLM 運行在筆記型電腦、工作站、伺服器或內部 GPU 設備上。
主要優勢是控制權。數據可以留在機器或網絡內部。這對於原型開發、隱私敏感的實驗或離線場景非常有用。
但權衡也是現實的：
- 模型質量可能低於頂尖的 API
- 設置可能不穩定
- GPU 成本昂貴
- 除非自行構建，否則監控手段有限
- 訪問控制和審計日誌需自行負責
- 「本地」並不自動代表「合規」
5. 私有 VPC 或地端部署 (Private VPC or on-prem)
這是本地 AI 的企業版本。
模型運行在受控環境中，通常圍繞著身份驗證、網絡、日誌、存儲和安全政策。團隊可以開放內部 API 並將其連接到經批准的應用程序。
對於高度敏感的試算表工作流，這是最強大的路徑，但它需要較高的營運成熟度。
務實的決策框架
將數據敏感度作為第一道過濾器。
| 試算表類型 | 合理的 AI 路徑 |
|---|---|
| 公開數據或範例 | 公共聊天機器人或 API |
| 內部但低風險數據 | 經批准的企業級 AI 服務 |
| 機密業務數據 | 具備合約控制的企業級 API、私有 VPC 或經批准的內部應用 |
| 受監管或高度敏感數據 | 私有 VPC、地端部署、實體隔離 (Air-gapped) 或脫敏工作流 |
| 敏感度未知 | 在分類前禁止上傳 |
接著詢問營運問題：誰來維護系統？
如果公司沒有能力維護 GPU、修補模型伺服器漏洞、監控日誌並評估輸出，那麼完全本地部署可能會產生新風險。在這種情況下，具備強大控制能力的企業級 AI 服務可能比無人管理的本地模型更安全。
本地部署並不自動等同於安全
如果周邊系統薄弱，本地模型仍然可能洩露或處理不當。
常見錯誤包括：
- 將上傳的文件存儲在未加密的資料夾中
- 記錄包含敏感值的提示詞日誌
- 讓每個用戶都能訪問每個文件
- 允許生成的代碼訪問網絡
- 未能修補主機系統漏洞
- 將輸出結果複製到不受管理的工具中
- 使用來自不可信來源的模型或套件
隱私是架構屬性，而不僅僅是模型位置屬性。
公共 API 也不自動等同於不安全
反之亦然。
企業級 AI API 可以提供強大的控制。一些供應商聲明，默認情況下不會使用企業或 API 客戶的數據來訓練模型。雲端供應商可能提供私有網絡、IAM、加密、審計日誌和數據保留控制。
正確的問題應該非常具體：
- 哪種產品方案？
- 哪份合約？
- 哪種保留設置？
- 哪個區域？
- 哪些日誌？
- 哪些用戶？
- 哪些試算表數據？
具備企業控制能力的公共 API 對於許多工作流來說是可以接受的，而隨意的聊天機器人上傳則不然。
理想的敏感 Excel 工作流應具備的特徵
對於敏感的試算表分析，良好的工作流應該：
- 在分析前對數據進行分類
- 將文件保存在經批准的存儲空間中
- 強制執行用戶權限
- 使用確定性工具進行計算
- 僅向模型發送必要的上下文
- 防止工具產生的外向洩漏
- 引用來源行、工作表、公式或查詢
- 記錄提示詞、工具、數據訪問和輸出
- 允許管理員控制保留政策
- 支持私有或企業批准的模型端點
這為團隊提供了務實的平衡：既能發揮 AI 的效用，又不會產生失控的複製貼上行為。
RowSpeak 的定位
RowSpeak 是一個試算表分析的工作流層。這意味著它可以架構在不同的模型選擇之上。
對於風險承受度較低的團隊，模型端點可以是經批准的企業級 API。對於敏感部署，它可以是在客戶基礎設施中運行的私有 LLM。在這兩種情況下，用戶體驗都應專注於試算表任務：上傳數據、提問、生成圖表、審查證據，並透過 Excel 轉儀表板工作流 將 Excel 文件轉化為可視化看板。
模型是可以替換的，受控的工作流才是持久的部分。這就是為什麼這個決策通常屬於更廣泛的 AI 商業智慧規劃，而不僅僅是模型選擇。
最終檢查清單
在為 Excel 分析選擇本地 LLM 或公共 API 之前，請回答以下問題：
- 活頁簿中最敏感的欄位是什麼？
- 該工具是否獲准處理該類別的數據？
- 供應商是否會針對提示詞、文件或輸出進行訓練？
- 數據在哪裡處理和保留？
- 您是否可以使用脫敏後的樣本代替？
- 用戶是否需要行級或文件級的權限？
- 計算是否以確定性方式執行？
- 答案是否可審計？
- 誰負責維護模型和基礎設施？
- 當模型出錯時會發生什麼？
最好的架構很少是最極端的那一個，而是能在提供用戶實質分析幫助的同時，匹配試算表風險等級的架構。如果核心問題在於供應商適配性，將熟悉的選項（如 Copilot in Excel）與私有工作流工具進行比較也會有所幫助。
來源與延伸閱讀
- OpenAI 企業隱私政策：https://openai.com/enterprise-privacy/
- AWS Bedrock 常見問題：https://aws.amazon.com/bedrock/faqs/
- Google Vertex AI 數據治理 / 零數據保留：https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention
- vLLM OpenAI 兼容伺服器：https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- Ollama 庫：https://ollama.com/library
