雲端還是本地？企業AI走向「按需分配」

AI導入受阻，原因不只是模型選擇

起草提案、檢索內部規程、摘要合約——企業中想要使用生成式AI的場景不勝枚舉。然而，僅僅提供便捷的服務並不足以讓業務使用習慣化。每當員工疑惑「能輸入客戶名稱嗎」「這份資料是否屬於內部機密」時，工作就會停下來。

另一方面，全面禁止使用則會讓第一線員工得不到所需支援，甚至可能流向公司無法掌握的個人帳戶。在規劃導入時，與AI的回答性能同等重要的，是建立員工能夠放心使用的規則和路由機制。

本系列將從構想到運營，逐步解說將雲端AI與企業自管AI基礎設施相結合的「混合私有AI」。其中也會介紹使用IMMERSIA的配置方案，但所有配置和用途均為參考示例。僅部署特定設備，並不能自動實現本文所述的全部功能。

雲端與本地各有其角色

雲端AI是以外部服務形式使用AI的方式；本地部署則是在自有設施等自主管理的環境中運行系統。所需設備、使用條件和運營負擔因模型和用途而異。

對於整理公開資訊或處理已獲批准外發的資料，雲端AI是候選方案。但企業合約與個人服務不能等同對待，需逐一確認資料儲存、用於訓練、處理地區、刪除及管理功能等條款。

對於不得外發的資訊或需要與內部系統緊密整合的處理，本地AI是候選方案。但同時需要設計由誰負責更新、監控、備份和漏洞回應。「雲端危險、本地安全」的簡單劃分會遺漏實際風險。

同一介面，根據資訊類型選擇處理目標

混合配置的目標是：員工透過同一入口使用AI，系統在後台根據公司政策切換處理目標。例如，整理已公開產品資訊的請求與包含未公開價格表的提案起草，允許的處理目標不同。

示例配置中，在統一的AI工作區後方設置一個驗證資訊分類和使用權限的層級。已批准外發的資訊路由至已審批的雲端連接，內部處理的資訊路由至本地AI，無法判斷的內容則暫時擱置，並設置向負責人確認的路徑。

重要的是，不能僅憑AI的分類結果作為唯一判斷依據，還需結合文件管理分類、使用者所屬部門、合約約束和收件人白名單等條件。即便看起來是「普通問題」，如果附件或對話歷史中混有機密資訊，也需要整體重新審視。

首先梳理資訊類型與業務的對應關係

與其從一開始就覆蓋整個公司，不如選擇一項具體業務，這樣更容易進行設計。以銷售部門為例，可將公開資料摘要、內部價格表查詢和客戶提案起草分別作為獨立任務進行梳理。

在此基礎上確認：「誰來使用」「參考什麼內容」「回答交給誰」「可以外發的範圍是什麼」。即使是同一份文件，負責人自己閱讀與傳遞給外部服務是不同的判斷。「能查看」不等於「可以發送」。

容易被忽視的是回答的使用去向。即便是僅在內部生成的摘要，如果直接發送給客戶，資訊就會流出。不僅要控制輸入，還要將回答的確認和共享方式納入業務流程。從資訊入口到使用後全程把握，才能讓AI導入從單純的工具添加升級為運營設計。

液浸冷卻是部署本地AI的設備側選項

在本地運行AI時，除計算設備外，還需確認電源、散熱、安裝空間、噪音和維護動線。IMMERSIA的液浸冷卻是將電子設備浸入適配冷卻液以散熱的方式，是規劃此類計算基礎設施部署的選項之一。

但液浸冷卻本身不具備資訊分類或防止外發的功能。資訊保護需透過網路、認證、軟體、權限管理和運營的組合來實現。此外，設備散熱處理和安裝條件因機型、配置和現場情況而異，需逐一確認。

明確這一區別，也有助於釐清應諮詢的對象：業務側梳理所需資訊和任務，資訊系統側設計存取和路由，設備側確認電源、冷卻和維護。三方共享同一構想推進，才能實現無壓力的導入。

混合資訊：將任務分開處理

假設銷售人員需要結合公開目錄和內部折扣條件起草提案。兩份資料能否一起發送給外部AI，取決於最敏感資訊的處理方式。不能因為大部分是公開資訊，就將剩餘的機密資訊也透過同一路徑發送。

一種方法是將僅使用公開資訊撰寫說明文字的任務與反映個別條件的任務分開。但分開後生成的文字中仍可能殘留機密內容。不要認為經過處理就可以自由使用，需確認最終輸出將交給誰。

即便使用本地AI，也不一定完全沒有外部連接。某些配置需要用於更新、監控或授權驗證的通訊。區分業務資料的傳輸路徑和管理通訊路徑，可以明確「在內部處理」這一說法的範圍。

在規劃初期，將資訊類型、使用部門、參考系統、是否可外發和確認負責人整理成一張表格非常有效。模糊的欄位不要強行填寫，保留為待確認事項。這樣可以看清實施前需要先行判斷的內容，也能縮小PoC驗證的範圍。

另外，將處理保留在本地與複製所有資料是兩回事。可以直接參考原有業務系統，也可以只整備必要範圍用於檢索。如需複製，需確定更新和刪除何時生效，避免過時文件持續作為回答依據。

導入的起點：「什麼留在本地」