自託管 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；
• 使用私有云模型服務；
• 使用本地部署模型；
• 針對不同場景混合使用不同模型。

關鍵是模型不應該直接連線資料庫，也不應該直接擁有業務系統賬號。它應該通過開源的 ObjectStack Runtime 拿到“完成當前任務所需的最小上下文”。ObjectOS 是同一 ObjectStack 應用可選的商業生產平臺與運營體驗，並不取代這條執行時邊界。

例如使用者問：

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

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

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

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

自託管不是沒有代價。

企業需要負責：

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

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

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

什麼時候自託管尤其重要

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

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

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

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

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

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

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

ObjectStack Runtime 與可選的 ObjectOS 運營層

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

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

ObjectOS 是同一 ObjectStack 應用可選的商業生產平臺與運營體驗，增加瀏覽器 AI 構建、部署、支援和運營能力，但不改變底層開放定義或 ObjectStack Runtime。

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

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

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

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