為什麼企業 AI 應用平臺應該優先自託管

企業引入 AI 時，最容易被模型能力吸引：上下文視窗多大、推理多強、生成速度多快。

但當 AI 不再只是聊天，而是開始讀取客戶、訂單、合同、工單、審批和內部檔案時，更重要的問題會變成：

這些資料在哪裡執行？誰能訪問？日誌在哪裡？金鑰誰管？出了問題誰能停下來？

這就是自託管 AI 應用平臺變得重要的原因。

先給結論：真正應該優先自託管的，不一定是模型，而是 AI 應用執行時。

模型可以來自外部，也可以部署在本地；但承載業務物件、許可權、流程、Agent 工具和審計證據的執行時，應該儘可能部署在企業自己控制的基礎設施中。因為模型負責推理，執行時負責決定哪些資料能被讀取、哪些動作能被執行、哪些步驟需要審批、哪些證據必須留下。

自託管不是“把軟體裝到伺服器上”這麼簡單

很多人把自託管理解成安裝包或私有化部署。那只是第一層。

真正重要的是責任邊界：

• 業務記錄留在你的資料庫裡；
• 檔案留在你的物件儲存或檔案系統裡；
• 身份和許可權來自你的 SSO、組織結構和角色體系；
• 審計日誌留在你的日誌和合規系統裡；
• 金鑰、網路、備份和訪問策略由你控制；
• 是否連線外部模型服務，由你配置和批准。

如果一個平臺號稱“企業 AI”，但所有業務上下文都必須先上傳到供應商雲端，IT 團隊就很難回答合規、資料駐留、審計和退出成本這些問題。

自託管的價值，不是讓企業拒絕雲或拒絕外部模型，而是讓企業保留最後的控制權。

不要把自託管執行時、本地模型和私有云 SaaS 混為一談

很多討論會把三件事混在一起：

自託管執行時：業務物件、許可權、流程、Agent 工具、審批和審計執行在企業控制的基礎設施中。

本地模型：模型權重或推理服務執行在企業內部，用於滿足隔離、成本、延遲或合規要求。

私有云 SaaS：供應商為客戶開一個獨立環境，但平臺執行、日誌、升級和資料處理仍由供應商主導。

這三者可以組合，但不是一回事。企業最應該優先確認的是執行時邊界：業務資料是否先進入自己的物件層，Agent 是否繼承自己的許可權系統，審計證據是否落在自己的日誌體系中。

如果執行時不在企業控制內，即使接了本地模型，Agent 仍可能繞過業務許可權；如果執行時在企業控制內，即使某些場景使用外部模型 API，也可以只發送授權後的最小上下文。

為什麼 AI 應用比普通 SaaS 更需要部署邊界

普通 SaaS 通常處理的是一個應用自己的資料。AI 應用平臺不一樣，它天然會連線多個系統：

• CRM 裡的客戶和商機；
• ERP 裡的訂單和庫存；
• 工單系統裡的服務記錄；
• 合同系統裡的金額、條款和審批；
• 檔案系統裡的附件、報告和內部文件；
• 身份系統裡的使用者、角色和組織關係。

一旦 Agent 可以跨這些系統查詢和行動，它就不再是一個孤立工具，而是一個業務執行層。

這個執行層如果完全在外部，風險會放大：

• 很難解釋哪些業務資料被髮送到哪裡；
• 很難統一繼承企業原有許可權；
• 很難把 Agent 行為寫入內部審計系統；
• 很難在網路隔離、行業監管或客戶合同要求下落地；
• 很難在供應商切換時保持業務連續性。

所以企業真正要評估的不是“AI 能不能接業務系統”，而是“AI 接入業務系統以後，執行邊界是否仍然歸企業控制”。

自託管執行時應該承擔什麼

一個適合企業的自託管 AI 應用平臺，至少應該把這些能力放在企業基礎設施內。

能力	為什麼必須在執行時內
業務物件層	把客戶、訂單、工單、合同、裝置等概念建模成統一物件，而不是讓 Agent 直接猜資料庫表。
許可權層	繼承使用者身份、角色、記錄許可權和欄位許可權，讓 Agent 在使用者已有許可權內工作。
工具層	把查詢、動作和流程暴露成受控工具，限制輸入輸出和可執行範圍。
審批層	高風險動作進入人機協作審批佇列，而不是由模型直接落庫。
審計層	記錄 Agent 讀取了什麼、建議了什麼、呼叫了什麼、誰批准了什麼、最終改了什麼。
連線層	連線現有資料庫、ERP、CRM、身份系統和檔案儲存，同時保留網路與金鑰控制。

這些能力放在自託管執行時裡，AI 才能接近業務系統而不繞過治理。

外部模型服務仍然可以使用，但不能越過執行時

自託管並不等於只能使用本地模型。

企業可以選擇：

• 使用外部模型 API；
• 使用私有云模型服務；
• 使用本地部署模型；
• 針對不同場景混合使用不同模型。

關鍵是模型不應該直接連線資料庫，也不應該直接擁有業務系統賬號。它應該通過 ObjectOS 這樣的執行時拿到“完成當前任務所需的最小上下文”。

例如使用者問：

總結這個客戶過去 90 天的未關閉工單，並建議下一步處理動作。

執行時應該先檢查使用者是否能訪問這個客戶，再按物件許可權和欄位許可權查詢相關工單，隱藏敏感欄位，只把必要上下文交給模型。模型返回建議後，真正執行動作仍然要回到執行時，由許可權、審批和審計決定能不能落地。

這樣外部模型可以提供智慧能力，但不會成為業務資料的任意入口。

自託管也意味著企業要承擔執行責任

自託管不是沒有代價。

企業需要負責：

• 部署和升級；
• 網路隔離和訪問控制；
• 資料庫、檔案和日誌備份；
• 身份系統整合；
• 金鑰管理；
• 可用性和容量規劃；
• 安全基線和漏洞響應；
• 合規配置和內部審計。

這也是為什麼自託管平臺必須足夠清晰：它不能只是把複雜度轉嫁給客戶，而應該把物件、許可權、流程、日誌和整合邊界講清楚，讓 IT 團隊知道自己要控制什麼、運維什麼、審計什麼。

企業選擇自託管，換來的不是“省心”，而是“可控”。

什麼時候自託管尤其重要

以下場景裡，自託管通常不是加分項，而是必要條件：

• 資料不能離開指定地區、VPC 或本地網路；
• 客戶合同要求業務資料不得進入第三方訓練或託管環境；
• 系統要連線內部 ERP、資料庫或檔案服務；
• 行業監管要求完整審計鏈路；
• 需要接入內部身份系統和許可權模型；
• 希望使用本地模型或隔離網路；
• AI 會觸發真實業務動作，而不僅是生成文本。

越接近真實業務，越需要清楚的部署邊界。

評估供應商時可以直接問這 8 個問題

如果你正在評估 AI 應用平臺，可以先問供應商：

1. 業務資料預設存在哪裡，是否必須上傳到供應商雲端？
2. Agent 是否繼承企業已有使用者身份和許可權？
3. 是否支援物件級、記錄級、欄位級和動作級許可權？
4. 模型能否直接訪問資料庫，還是隻能通過受控工具訪問？
5. 外部模型 API 會收到哪些上下文，是否可以配置最小化傳送？
6. 高風險動作是否支援審批、回滾和自動剎車？
7. Agent 的讀取、建議、工具呼叫和寫入是否都能進入企業審計系統？
8. 在斷網、隔離網路或供應商服務不可用時，核心業務應用是否還能執行？

如果這些問題回答不清，說明平臺可能還停留在 AI 演示層，而不是企業生產層。

ObjectOS 的設計取向

ObjectOS 不是把企業資料搬到一個新的雲端系統裡，再讓 AI 在上面工作。

它更像一個部署在企業基礎設施中的業務執行層：連線現有資料和系統，把它們建模成物件，統一許可權、流程、API、審計和 Agent 工具。

資料、身份、檔案和審計證據仍然由企業控制。AI 可以通過受控工具查詢和行動，但不能繞過執行時邊界。

這讓企業可以用比較穩的方式推進 AI：

1. 先連線一個現有系統；
2. 建模關鍵業務物件；
3. 開放只讀查詢；
4. 增加建議和審批；
5. 最後把成熟、低風險的動作交給 Agent 自動執行。

真正的企業 AI，不只是模型能力更強，而是它能進入業務系統，同時仍然被企業治理。