企業 AI 落地
AI 如何真正進入一家公司:先把制度寫下來。
AI 試點在公司裡卡住,原因往往不在模型,而在模型周圍的組織:制度在人腦子裡,存著資料的系統 AI 夠不著,AI 動了手卻沒有誰能查的痕跡。在一個流程裡補上這三個缺口,AI 就能在那裡接手真正的工作,並且不超出你授予的權限。下面是:一條普通的報銷制度的三種寫法、一個三步試點,以及這種做法解決不了什麼。
- 制度在人腦裡
- 制度存在於經驗和例外裡,而不是寫成系統能檢查的條文。
- 系統夠不著
- 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——都照辦,並留下記錄。
檔案裡的四句話
票據、差旅預算、超額審批、審計只讀。AI 助手可以引用這四句話,但沒有任何東西能阻止它,或任何人,提交一張違反制度的報銷單。
助手就是那位員工,不是超級使用者
提交報銷單的助手以登入員工的身份行事,不超出該員工的權限。審計人員的修改也同樣被拒絕。助手讀取和改動的記錄與人的操作出現在同一份審計日誌裡;在 Enterprise 版中,AI 治理還會審計介面內 AI 的每一次工具呼叫。
AI 接到哪裡
從你已經在用的系統開始
AI 的用處取決於它能讀到哪些記錄。風險更低的路徑通常是先讀取現有系統裡已有的資料,而不是先替換它們。
先連線,再考慮遷移
現有的 ERP 或 CRM 資料庫可以不搬一條記錄,就掛載為受治理的物件,AI 通過和其他一切相同的權限讀取它。遺留系統現代化指南有完整的步驟。
預設只讀,尚在早期
聯邦接入預設只讀;寫回源系統要按物件有意開啟。它也尚在早期:讀路徑是成熟的那一條,第一個試點請圍繞讀取來規劃。
Agent 通過受治理的工具行事
無論是你自己經 MCP 接入的 Agent,還是 ObjectOS 的產品內 AI,都以登入使用者身份通過受治理的工具行事,而不是直接訪問資料庫。信任中心寫明瞭每一個 AI 動作要經過什麼。
三步試點
選一個流程,把它寫下來,量三個數
第一個試點要小到能做完,具體到能評判。下面三步與行業無關。
它解決不了什麼
把制度寫下來也解決不了的三件事
這種做法把成文的制度搬進一個會強制執行它的系統,對工作中沒有成文的部分無能為力——這一點在試點之前說清楚,好過試點之後。
沒人寫下來的制度
如果制度只存在於某位經理的判斷裡,就還沒有東西可以建模。把它寫下來是組織自己的工作,而且常常比搭建本身更費時間。
沒人說得清的判斷
有些決定依賴從未被說出來的經驗:和某家供應商的關係、某位客戶的歷史。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 執行環境上執行,目前尚在計劃中。
下一步