企業 AI 落地

AI 如何真正進入一家公司:先把制度寫下來。

AI 試點在公司裡卡住,原因往往不在模型,而在模型周圍的組織:制度在人腦子裡,存著資料的系統 AI 夠不著,AI 動了手卻沒有誰能查的痕跡。在一個流程裡補上這三個缺口,AI 就能在那裡接手真正的工作,並且不超出你授予的權限。下面是:一條普通的報銷制度的三種寫法、一個三步試點,以及這種做法解決不了什麼。

ObjectOS product surface connecting business data, applications, and AI agents
AI 編寫中繼資料 物件、權限、流程、工具
人 審閱 diff 業務權限、資料訪問、審批
執行環境 執行策略 UI、API、審計、MCP、動作
制度在人腦裡
制度存在於經驗和例外裡,而不是寫成系統能檢查的條文。
系統夠不著
AI 需要的記錄在 ERP、CRM 和表格裡,它沒法安全地讀取。
沒有痕跡
AI 動了手,沒人說得清是誰允許的、改了什麼、憑的是誰的權限。

核心觀點

制度寫得越清楚,AI 越能放手幹。

AI 只能守住它讀得懂、執行環境又查得了的制度。拿一條普通的差旅報銷制度來說:寫在制度檔案裡的一段話,助手可以引用,卻沒人能讓它照辦;寫進本體——一個物件、幾個欄位、一條校驗、一個審批步驟——同一條制度就會在每一次寫入時強制執行,對人和 Agent 一視同仁,每一次請求和決定都留下記錄。這條制度是通用示例,不來自任何客戶。

// (a) 現在的制度文本:差旅制度第 4 條
//   4.1 每筆差旅報銷必須附票據。
//   4.2 報銷金額不得超過已批准的差旅預算。
//   4.3 超過 5,000 的報銷需部門負責人審批。
//   4.4 審計人員可檢視報銷單,但不能修改。

// (b) 同一條制度,寫進本體
export const TravelClaim = ObjectSchema.create({
  name: 'travel_claim',
  label: '差旅報銷',
  fields: {
    amount: Field.currency({ label: '金額', required: true }),
    trip_budget: Field.currency({ label: '差旅預算' }),
    receipt: Field.file({ label: '票據', required: true }), // 4.1
  },
  validations: [{                                         // 4.2
    name: 'within_trip_budget',
    type: 'script',
    condition: 'record.amount > record.trip_budget',
    message: '制度 4.2:報銷金額超出差旅預算。',
  }],
});

// 4.3:報銷流程裡的一個審批步驟(見 /approvals/),
// 在 'amount > 5000' 時啟動
{ id: 'head_review', type: 'approval', config: {
    approvers: [{ type: 'role', value: 'department_head' }],
    lockRecord: true,
} }

// 4.4:審計人員的權限集(見 /permissions/)
travel_claim: { allowRead: true, allowCreate: false,
                allowEdit: false, allowDelete: false }

// (c) 執行環境強制執行
// 報銷 6,200,預算 5,000 → 拒絕:制度 4.2
// 報銷 6,200,預算 8,000 → 儲存;記錄鎖定,等部門負責人決定
// 審計人員修改報銷單 → 拒絕:只讀(4.4)
// 審計日誌:AI 助手以登入員工身份建立報銷單;
// 審計日誌:head_review 由部門負責人批准

一條制度,三種狀態

同一條報銷制度:一段文字、一份本體、一個執行中的系統

三種狀態各管一件事:文字告訴人制度是什麼,本體告訴系統,執行環境讓所有人——人和 Agent——都照辦,並留下記錄。

(a) 制度文本

檔案裡的四句話

票據、差旅預算、超額審批、審計只讀。AI 助手可以引用這四句話,但沒有任何東西能阻止它,或任何人,提交一張違反制度的報銷單。

(b) 本體

一個評審者讀得懂的物件 

同樣的四句話,變成一個帶型別欄位的報銷物件、一條緊挨著所保護欄位的校驗、一個審批步驟和一個只讀權限集——一份小小的定義,而不是散落在各個介面裡的邏輯。

(c) 執行環境

拒絕、流轉、留痕 

超預算的報銷在每一條寫入路徑上都會被拒絕:表單、API、匯入或 AI 工具呼叫。超過額度的報銷等待部門負責人審批,期間記錄鎖定。每次請求與決定都被審計。

同一條制度下的 AI

助手就是那位員工,不是超級使用者 

提交報銷單的助手以登入員工的身份行事,不超出該員工的權限。審計人員的修改也同樣被拒絕。助手讀取和改動的記錄與人的操作出現在同一份審計日誌裡;在 Enterprise 版中,AI 治理還會審計介面內 AI 的每一次工具呼叫。

AI 接到哪裡

從你已經在用的系統開始

AI 的用處取決於它能讀到哪些記錄。風險更低的路徑通常是先讀取現有系統裡已有的資料,而不是先替換它們。

先連線,再考慮遷移 

現有的 ERP 或 CRM 資料庫可以不搬一條記錄,就掛載為受治理的物件,AI 通過和其他一切相同的權限讀取它。遺留系統現代化指南有完整的步驟。

預設只讀,尚在早期 

聯邦接入預設只讀;寫回源系統要按物件有意開啟。它也尚在早期:讀路徑是成熟的那一條,第一個試點請圍繞讀取來規劃。

Agent 通過受治理的工具行事 

無論是你自己經 MCP 接入的 Agent,還是 ObjectOS 的產品內 AI,都以登入使用者身份通過受治理的工具行事,而不是直接訪問資料庫。信任中心寫明瞭每一個 AI 動作要經過什麼。

三步試點

選一個流程,把它寫下來,量三個數

第一個試點要小到能做完,具體到能評判。下面三步與行業無關。

第 1 步

選一個制度已成文的流程

選一個制度已經寫在紙面上、有明確業務負責人的流程:費用報銷、採購申請、服務工單。如果沒人寫得出這條制度,它還不適合做試點。

第 2 步

把它寫進本體 

把制度變成物件、欄位、校驗、審批步驟和權限。你的編碼 Agent 可以起草這份定義;流程負責人把它當作一個小 diff 來評審,逐條對照制度。

第 3 步

量三個數 

節省的工時、從申請到決定的週期、差錯率,都與試點開始前測得的基線對比。參考案例頁列出了受治理試點還應衡量的其他指標。

它解決不了什麼

把制度寫下來也解決不了的三件事

這種做法把成文的制度搬進一個會強制執行它的系統,對工作中沒有成文的部分無能為力——這一點在試點之前說清楚,好過試點之後。

沒人寫下來的制度

如果制度只存在於某位經理的判斷裡,就還沒有東西可以建模。把它寫下來是組織自己的工作,而且常常比搭建本身更費時間。

沒人說得清的判斷

有些決定依賴從未被說出來的經驗:和某家供應商的關係、某位客戶的歷史。AI 可以把這些情況準備好,決定仍應由人來做。

還不存在的整合

一個沒有可訪問的資料庫或 API 的系統,AI 依然夠不著。聯邦接入尚在早期,寫回源系統是一個有意的步驟,不是預設行為。

評審清單

試點開始前,請確認

  • 這個流程有成文的制度和明確的業務負責人。
  • 它需要的記錄讀得到,來自你在執行的系統或通過匯入。
  • AI 可以執行的每個動作都已列出,需要人審批的已標明。
  • 工時、週期和差錯率都有基線。
  • 大家對試點不覆蓋什麼已有共識。

FAQ

常見問題

一句話說,ObjectStack 是什麼?

一份可執行的業務本體。AI 編寫它,執行環境執行它,Agent 操作它,你擁有它。

AI 會自作主張嗎?

只在你授予的權限之內行事。Agent 以登入使用者身份執行,不超出該使用者的權限;需要審批的業務決定由流程中的審批節點交給人;它讀取和改動的記錄與人的操作寫進同一份審計日誌。介面內 AI 每次工具呼叫的審計屬於 Enterprise 版的 AI 治理。

我們能把本體帶走嗎?

ObjectOS 有三個版本:ObjectOS Community,開源、可免費自託管;ObjectOS Cloud,託管在瀏覽器中、無需安裝;ObjectOS Enterprise,自管部署在你自己的基礎設施上。你的本體是普通的 ObjectStack 中繼資料。從 ObjectOS Cloud 或 ObjectOS Enterprise 匯出本體、在開源的 ObjectStack 執行環境上執行,目前尚在計劃中。

下一步

繼續完善你的評估材料。