GembaOS
繁體中文
預約示範

技術札記

這個 AI 究竟獲准做甚麼？上個月又改過甚麼？

寫給負責變更管理委員會（CAB）、內部審計人員，以及當初點頭同意這條審批路線、日後要向管理層與監管機構交代的業務部門主管。

GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。

這篇文章探討企業在 AI 試點結束後一定會面臨的合規追問，且通常由當初未參與項目立項的審計人員提出：「這個 AI 究竟獲准執行哪些操作？這項權限是誰在何時批准的？上個月又改動了甚麼？」

靜默漂移：文檔與代碼永遠在分家

大部分企業在面對審計時，習慣用一張 Visio 或 PPT 流程圖來回答問題。項目啟動時架構師畫了架構圖，業務主管簽字歸檔。然而在隨後的九個月裡：

那張歸檔的架構圖卻從未更新過。

九個月後，那張圖能證明的僅僅是「第一個月時大家打算怎麼做」，而無法證明系統當前到底如何運行。

這不是文檔紀律的問題。在系統旁邊人工維護的圖示，是系統的第二份正本；而在企業 IT 演進中，第二份正本永遠是失效的那一份。

代碼即正本：直接由運行時配置輸出圖示

在 GembaOS 體系中，審批路線既不是散落在代碼中的 if-else，也不是人工繪製的靜態圖片，而是業務規約（Playbook）中嚴格宣告的元數據：哪些業務條件命中哪一個審批檔位、該檔位需要哪位具名責任人簽署、AI 在何種情況下必須申報自身無法決策、執行前需要重讀哪些底層欄位。

這份宣告正是 GembaOS 治理內核在生產環境中實際執行的依據。 因此，系統可以直接將其導出為可視化圖示。

以下是參考用的航班改期業務規約，由 GembaOS 命令行工具直接讀取生產配置生成：

決裁之前: 受理 (客戶) → 讀取記錄 (AI) → 規則選定決裁級別 (GembaOS)

條件簽章人數
已填寫差價，且差價 = 0，且風險評分低於 0.2，且無風險提示0
已填寫差價，且差價 ≤ 200AI 審查（專員角色） → 客戶服務主管1
其餘一律AI 審查（專員角色） → 客戶服務主管 → 收益管理2

若 AI 申報自己拿不準: 附於審批單之上，由主管該論點的決裁者在本檔簽章人之前作答 — 運價規則讀不清 → 收益管理 · 航段未必等效 → 收益管理.

簽章之後: 執行前重新讀取 (GembaOS) → 憑放行令執行 (GembaOS)

同一項改動，交給工具比對:

$ gemba playbook diff <previous> flight_rebooking
LOOSER   rebook_route band 1: threshold 80 -> 200
STRICTER approvalRoutes.rebook_route: now forces a person: agent_recommends_otherwise
DATA     capabilities.knowledge__search: granted to SPECIALIST (ALLOW)
DATA     capabilities.knowledge__get: granted to SPECIALIST (ALLOW)

這張圖示清晰展現了三個核心治理原則：

  1. 執行主體是路線的一等公民：每一步由誰執行（大模型、具名責任人還是治理內核）由規約嚴格宣告。特別是最後兩步：重新核對現狀並在單次放行令下真正調用 API 寫入的，是 GembaOS 治理內核。模型只負責提出方案，絕不持有底層寫入權限。
  2. AI 主動申報不確定性：在大模型評估過程中，若遇到模糊邊界，只能從預先定義的枚舉清單中申報「此處無法決策」，並由規約路由給指定的專業主管。一旦申報，該模型即刻喪失在該檔位的自動放行資格——聲明自身無法裁決的，絕不能回頭自行蓋章放行。
  3. 消除模糊的文字描述：條件表達式在業務視圖與審計視圖中嚴格保持一致。工具無法自動翻譯的複雜條件會原樣展示，絕不進行模棱兩可的意譯。

變更審批真正需要的能力：自動算清風險走向

靜態圖示回答的是「系統現在是甚麼狀態」；而變更管理委員會（CAB）與審計人員追問的是「這次改動究竟讓規則變鬆了還是變緊了」。

GembaOS 支持對同一個業務規約的兩個版本進行自動化 Diff 比對（例如現行版本對比 Git 歷史版本），並自動為每處差異打上風險方向標籤：

這種方向推導不是依靠人工手動填寫的變更說明，而是由算法對審批檔位的覆蓋範圍進行數學推導。這徹底消除了「人工閱讀複雜代碼運算式、在腦海中比對哪個版本會放過更多漏洞」的認知負擔與出錯隱患。

系統做不到的事（權限與責任邊界）

GembaOS 的工具鏈負責忠實解析與校驗宣告。

但這項變更在商業上是否合規、是否合理——例如 200 元差價是否只需一名客服主管簽批、航線問題交給收益管理主管是否恰當——屬於企業的商業判斷，其責任永遠落在呈批單上具名簽字的管理人員身上。

GembaOS 所做的，是讓管理人員在點擊簽批時以最低的認知成本看清自己正在同意甚麼，並讓審計人員在事後能一清二楚地覆盤上個月到底改動了甚麼。

這貫徹了 GembaOS 的核心哲學：為每一個系統動作繫上具名責任人；AI 負責主動探測與計算影響，人類負責確認風險並最終拍板。

本文回答的問題

這張審批路線圖是自動生成的，還是另外人工維護的？

完全由代碼生成。它讀取的是 GembaOS 治理內核在運行時執行的同一份業務規約配置，每次構建都會重新生成；圖示一旦與配置產生漂移，會直接導致構建中斷，絕不允許發布過時的圖示。

「變鬆了」這個風險判定，是系統如何推導出來的？

由審批授權檔位的邏輯結構直接推出。檔位按宣告次序逐一比對、命中即生效。放寬某一檔位的條件，等於把原本落入後續高權限檔位的個案提前放行；若後續檔位需要更多人員簽批，這項改動就自動標記為 LOOSER（變鬆），反之標記為 TIGHTER（變緊）。無法解析方向的改動則留空，交由人工審查。

業務主管不熟悉技術運算式，能看懂這張圖嗎？

同一張架構圖提供兩種視圖：面向架構師與合規審計的一版包含嚴格的變數識別碼與內核邏輯；面向業務簽批人的一版使用管理控制台的業務語言。兩者源自同一份配置正本，絕不會各說各話。

資料來源

截至 2026 年 9 月，GembaOS 未取得任何第三方認證；本站的控制對應表為自評，未經審計。GembaOS 處於 Design Partner 階段。 了解 Design Partner 計劃。

最後更新: · GembaOS v0.2