企業 AI 不一定只放在雲端：香港公司如何判斷 Private、Hybrid 與 On-prem AI 架構？

企業 AI 不一定只放在雲端：香港公司如何判斷 Private、Hybrid 與 On-prem AI 架構？

很多香港公司試用 AI 的第一步都很簡單：把文件交給工具摘要、讓 chatbot 回答內部問題、用 AI agent 草擬電郵或整理報表。Demo 通常很快見效，同事也容易感受到效率提升。

真正困難的，是把這些試驗變成公司日常系統。當 AI 要讀取 CRM、合約、報價、客戶紀錄、倉存或內部知識庫時，管理層很快會遇到幾個實際問題：哪些資料可以放到雲端？哪些資料必須留在受控環境？AI 可以只讀資料，還是可以寫入系統？如果輸出有錯，誰負責審批和追蹤？

所以，2026 年企業 AI 的重點已經不只是「用哪個模型」，而是「AI 應該放在哪個架構」。Cloud、private、hybrid、on-prem 不應被當成技術口號，而是影響資料安全、成本、整合速度和營運責任的商業選擇。

OpenAI 在 2026 年 5 月 18 日公布與 Dell Technologies 合作，探索把 Codex 連接到 hybrid 和 on-premises enterprise environments。這並不代表所有公司都要買大型私有 AI infrastructure；它更像一個清晰訊號：當 AI agent 開始處理真實業務流程，企業會重新關心 data location、system integration、governance 和 operational resilience。

同一週，Cyberport AI Frontier 2026 在 2026 年 5 月 22 日以 enterprise-scale deployment、trust with control、AI delivery model、security and safety by design 為重點。HKPC 亦在 2026 年 5 月 21 日舉辦 AI solutions showcase，涵蓋 smart manufacturing、public services 和 AI for All training。香港企業現在要處理的，不是「要不要用 AI」，而是「AI 怎樣安全地成為營運系統的一部分」。

先分清楚：Cloud AI、Private AI、Hybrid AI、On-prem AI 不是潮流名詞

很多企業討論 AI 架構時，會把幾個詞混在一起。實際決策時，可以先用營運語言拆開。

Cloud AI 通常指使用雲端 AI service 或 SaaS AI 功能，例如文件摘要、客服草稿、電郵分類、會議記錄、內容生成。優點是快、易開始、維護負擔較低；限制是資料流向、權限邊界、客製整合和審計能力要看供應商設計。

Private AI 通常指企業希望 AI 在受控資料、受控權限、受控環境內運作。它未必一定是 on-prem，可以是 private cloud、dedicated cloud、受管理的 VPC 或企業內部平台。重點不是地點，而是控制。

On-prem AI 指模型、資料、運算或關鍵 AI workflow 部署在企業自有或指定機房環境。它適合高度敏感資料、嚴格審計、低延遲或需要與內部 legacy system 緊密連接的場景，但成本、維護和人才要求較高。

Hybrid AI 則是最常見的落地形態：低風險任務用 cloud，高敏感資料留在 private 或 on-prem 環境，中間透過 API gateway、權限控制、資料脫敏、審批流程和 logging 連接。

實務例子：一間物流公司可以用 cloud AI 處理公開貨運資訊、客戶查詢分類和常見問題草稿；但運單、客戶合約價、倉庫出入紀錄和高價值貨物資料，則只在內部系統查詢，AI agent 只能透過受控 API 取得必要欄位，而不能直接讀整個 database。

何時 cloud 已足夠？

如果 AI 任務主要處理非敏感資料、對業務風險低、流程仍然由人決定，cloud AI 通常是合理起點。香港 SME 常見例子包括 marketing draft、FAQ 初稿、內部會議摘要、培訓材料、產品描述、社交內容排程建議。

但「cloud 已足夠」不等於「任何資料都可以貼上去」。企業至少要有三個基本規則：哪些資料可以輸入 AI，哪些資料必須先移除個人或商業敏感內容，哪些輸出必須經人審批。

實務例子：教育培訓中心想用 AI 幫老師整理課程回饋。安全做法不是把完整學生名單和聯絡資料放進 prompt，而是由系統先產生匿名統計，例如出席率、課程滿意度、常見問題分類，再讓 AI 協助整理管理摘要。校務主任仍負責核對結果和決定跟進行動。

何時應考慮 private 或 hybrid？

當 AI 開始接觸客戶資料、員工資料、財務資料、合約、庫存、報價、醫療或教育記錄時，企業就應該考慮 private 或 hybrid 架構。原因不是「雲端一定不安全」，而是企業需要更清楚地控制資料如何被讀取、保留、審計和刪除。

OpenAI 與 Dell 的 2026 年 5 月 18 日合作公告提到，企業希望 AI 在重要 data、systems 和 workflows 所在的環境中運作，並更接近 governed enterprise data。這個方向對香港企業有啟示：AI agent 的價值來自內部 context，但風險也來自內部 context。

實務例子：會計或公司秘書服務公司想用 AI 準備客戶月度文件清單。Hybrid 做法可以是：文件 metadata 和狀態由內部 document management system 提供；AI 只收到文件類型、截止日期、缺漏狀態和已脫敏的備註；草稿 email 產生後，由 account manager 在 CRM 內審批才發送。這樣既能提升效率，又不需要把完整客戶文件交給外部工具自由處理。

何時 on-prem 才值得？

On-prem AI 不應該因為聽起來高級而採用。它適合三類情況。

第一，資料敏感度高或合規要求嚴格。例如金融、保險、醫療、專業服務、受監管外判流程、核心客戶資料庫。

第二，AI 必須與本地 legacy system、內部網絡或特定設備深度整合。例如倉庫控制系統、工廠生產線、物業門禁、內部 ERP、不能暴露到 internet 的舊系統。

第三，企業需要穩定、可預測、可審計的 AI workload。例如大量文件分類、內部知識搜尋、軟件測試、incident response、營運報表生成。

實務例子：一間連鎖診所想用 AI 協助前線接待整理預約、檢查缺漏文件和產生跟進提醒。若 AI 會接觸病人資料，較穩妥的設計可能是把資料保留在內部或受控 private environment，只讓 AI 使用最小必要欄位，例如 appointment status、文件是否齊備、提醒渠道，而不是完整病歷。

AI agent 落地前，要先畫出 data flow

很多 AI project 失敗，不是模型不夠好，而是企業沒有把資料流畫清楚。Agent 要做事，必須知道可以讀甚麼、寫甚麼、改甚麼、何時要人審批。

建議香港企業在正式採用 AI agent 前，先用一頁圖列出：

• 觸發點：由客戶查詢、內部 ticket、定時報表，還是員工手動啟動？

• 資料來源：CRM、booking system、Excel、ERP、email、文件庫、website form？

• AI 可讀欄位：是否只讀摘要、metadata、狀態，還是可讀完整內容？

• AI 可產出內容：摘要、草稿、分類、建議、API action？

• 審批點：誰確認、在哪個系統確認、多久內確認？

• 紀錄：prompt、資料來源、輸出、審批人和最後行動是否可追溯？

實務例子：零售公司想用 AI agent 跟進 WhatsApp 查詢。流程可以是：客服平台收到查詢後，AI 先分類為售前、售後、退換貨或投訴；只讀 product ID、order status 和公開 FAQ；產生回覆草稿；店長或客服主管審批高風險回覆，例如退款、投訴或個人資料更改。這比讓 AI 直接存取所有客戶紀錄安全得多。

Cloud cost 不是唯一成本，治理成本也要計入

很多 SME 比較架構時，只看 monthly subscription 或 server cost。但 AI 成本還包括 integration、data cleaning、permission design、monitoring、backup、incident response、staff training 和 vendor management。

Cloud AI 起步成本低，但若每個部門各自購買工具，長遠會出現 shadow AI、資料分散、權限混亂和難以審計。On-prem 或 private AI 初始成本較高，但對特定高風險流程可能更可控。Hybrid AI 的挑戰則是設計清楚邊界，避免變成兩邊都複雜。

實務例子：一間中型貿易公司想用 AI 做報價前資料整理。若只是整理公開產品資料，cloud AI 已足夠；若要讀取過往成交價、客戶信用條款和供應商折扣，就應改用受控 workflow：AI 從內部系統拿到必要欄位，產生報價建議，sales manager 在 CRM approve，系統再記錄版本和理由。

把 operational resilience 放入 AI 架構

AI 架構不只是 IT 選型，也涉及營運韌性。HKMA 早於 2022 年 5 月 31 日的 operational resilience circular 中，要求相關機構最遲於 2026 年 5 月 31 日前達到 implementation 要求。即使不是銀行，這個思路也值得企業參考：重要流程要知道依賴哪些系統、供應商、資料和人手，並測試中斷時如何維持服務。

套用到 AI，就是要問：如果 AI service 暫停，客服是否仍可回覆？如果模型輸出錯誤，誰能停止自動化？如果供應商功能改變，內部流程會否失效？如果資料同步延遲，agent 會否用舊資料行動？

實務例子：物業管理公司若用 AI 整理維修報告，可以設計 fallback：AI 只負責分類和摘要；緊急維修仍由人手確認；所有工單保留在原有 maintenance system；AI 停止時，前線仍可按原流程派單。這樣 AI 是增強層，不是單點故障。

一個實用決策框架：四個問題

香港企業可以用四個問題快速判斷 AI 架構。

第一，資料敏感嗎？如果包含個人資料、合約、價格、醫療、金融、員工紀錄或商業秘密，至少應考慮 private 或 hybrid。

第二，AI 會不會寫入系統或觸發行動？如果 AI 只寫摘要，風險較低；如果 AI 會改 CRM、發 email、開 ticket、批核申請或調整報價，就必須加入權限和審批。

第三，流程是否關鍵？若 AI 影響收款、客服、合規、交付、庫存或安全，就要設計 monitoring、fallback 和 audit trail。

第四，公司是否有能力維護？On-prem 和 private AI 需要 IT、security、DevOps 和 data governance 能力。若公司未準備好，可以先從 hybrid pilot 開始，把最敏感資料留在原系統，讓 AI 只透過受控接口工作。

結語：AI 架構應跟着工作流走，而不是跟着新聞走

OpenAI x Dell、Cyberport AI Frontier、HKPC AI showcase 和 Google Workspace 更新都指向同一件事：AI 正由單一工具，變成企業營運系統的一部分。對香港企業來說，真正的競爭力不是追逐每一個新模型，而是把 AI 放在適合的架構中，連接正確資料，保留人類審批，並讓系統長期可維護。

如果你的公司正在評估 AI agent、private AI、hybrid cloud 或內部系統整合，可以先從一個流程開始：選一個每日重複、資料來源清楚、風險可控、需要人審批的工作，畫出資料流和權限，再決定 AI 應該放在 cloud、private、hybrid 還是 on-prem。

這張資料流圖畫得清楚，企業才有基礎判斷 AI 應該放在雲端、私有環境、混合架構，還是暫時留在人手流程之中。