GembaOS
繁體中文
預約示範

AI AGENT 權限與操作控制台

管住 AI Agent 能看甚麼、做甚麼，以及由誰來擔責。

既能統一管治現有 Agent，亦能從第一天起構建合規受控的 AI 業務流。GembaOS 在一套規則下連接模型、API、業務系統與具體員工，讓資料權限、分級審批、系統執行與經辦責任清清楚楚。

預約示範
當 Agent 提議對業務系統執行變更時
AI Agent

Agent 提出操作申請

已研讀業務記錄並確立變更方案，但自身不持有任何直接寫入系統的權限。

典型範例停用離職同事的帳戶 · 向客戶退款 · 修復失敗的測試 · 處理一宗保險理賠

GembaOS

GembaOS 依據企業授權規則實時校驗

判定該 Agent 是否具備對應權限：交易金額、所涉資料密級及系統當前狀態是否完全符合授權矩陣？

  1. 符合規則

    自動核准並精確執行一次，留存完整審計日誌

    執行前 GembaOS 重新校驗最新記錄，僅精準執行已獲授權的操作，無需人工介入干預。

    典型範例3,000 以下的退款 · 5 個檔案以下、測試通過的修正 · 20,000 以下、文件齊全的理賠

  2. 超出權限

    轉交授權規則指定的負責人審批

    負責人查閱提煉摘要與核驗證據後簽章批准或退回；後續執行同樣經過狀態重核，憑單次放行令嚴格落盤。

    典型範例離職同事的帳戶：IT 管理員簽章，並通知資訊保安同事 · 超過 3,000 的退款：客戶服務主管 · 改動到有負責人的代碼的修正：程式碼負責人 · 超過 20,000 的理賠：理賠審核員

  3. 違反規則

    阻斷違規操作並強制退回

    任何系統狀態均不作修改，阻斷攔截事件與違規原因同樣落盤歸檔。

    典型範例簽章後訂單被改動：退回，一分不付 · 任何對部署設定或密鑰的改動

授權額度內的常規操作自動流轉；唯有超額例外、規則衝突或數據不符的請求，方會呈交專責主管審批。

示例衍生自 GembaOS 隨附的標準作業手冊，金額為展示數值，企業可自主配置授權矩陣。

✓ 部署於貴司環境✓ 遵循企業授權制度✓ 自由選擇模型

實際運作

五段簡短場景，看 GembaOS 如何運作

沒有影片，也沒有聲音：揀一段場景，它會自動播放，也可以自己逐步查看。畫面中的數字與姓名全為示例。

一宗退款，從提出到成為記錄

場景 1 / 5

Agent 研讀個案並提出建議

客戶要求退款。Agent 研讀訂單與退款政策並草擬建議，但它的印記只是意見，沒有付款的權限。

場景 2 / 5

GembaOS 依規則核對

誰可以提出、Agent 能看到甚麼、金額有沒有超出上限。上限以內，由貴公司確認的規則放行；超出上限，則由具名人員決定。

場景 3 / 5

具名人員簽章

客戶服務主管看到的，是 GembaOS 已核對的事實，以及仍需判斷之處。簽章會留下姓名與職位，批准只綁定這一組確切的參數。

場景 4 / 5

只執行一次，再讀回結果

GembaOS 重新讀取訂單。若仍與簽章時相符，便憑單次放行令，把獲批准的退款只執行一次，讀回結果，並封存整個過程。

場景 5 / 5

事實一變，甚麼都不會執行

假設簽章之後訂單被改動。GembaOS 在重新讀取時發現差異，把請求退回，一分不付。這次拒絕同樣留在記錄裏。

用對話交辦工作

場景 1 / 2

用自己的說法講

員工按需要分幾次說明事項。助手會提出這位員工有權交辦的業務中哪一項符合，並附上各項建議所依據的原話；兩項都符合時，助手會追問。

場景 2 / 2

確認後才交辦

交辦內容保留了之前的說明，員工可先修改再交辦。建議經系統核對，在交辦之前不會啟動任何工作；受理回執會列明業務、工單編號、負責人與下一步。

無人當值的時候

場景 1 / 2

告警，以及只讀的雙手

監控告警在無人當值時觸發初步排查。Agent 只能讀取日誌，日誌裏叫它做事的一行，是資料而不是命令。

場景 2 / 2

報告、缺口，以及等待審定的草案

經覆核的報告交給負責人。Agent 缺少的依據，連同應由誰承擔，登記在缺口登記冊，並生成一份等待專人審定的知識草案；在有人批准之前，任何 Agent 都不能引用它。系統沒有任何改變。

示範一次

場景 1 / 3

或者，示範一次

員工在公司宣告的應用程式裏把工作做一遍。記錄工具只觀看，不能點擊或輸入；密碼絕不記錄，離開到其他網站的一段，會標示為缺口而不是猜測。送出之前，員工會逐步檢視每一步。

閱讀「示範一次」如何運作

場景 2 / 3

助手寫下它理解了甚麼

助手把記錄當作資料閱讀，寫出它理解的流程：每一步都有已記錄的步驟作依據；候選規則連同仍未知之處；以及一條問題。規則只有在引用員工自己的回答時，才算「已說明」。

場景 3 / 3

負責人確認，另一人批准發佈

候選規則要由為它負責的人按原文確認，才成為公司的規則。變更會畫成前後路線，並由第二個人批准發佈。

大家一直在簽的

場景 1 / 3

把簽過的決定，按共通點點算

業務檢討每月一次，把規則交給客戶服務主管簽的退款，按個案記錄下的特徵逐一點算。每個特徵旁邊，GembaOS 都註明規則有沒有讀它；這由規則本身讀出，不交給模型判斷。

場景 2 / 3

經 GembaOS 核對的規則候選

檢討依據這一組提出規則候選，並寫明仍不知道的事。GembaOS 核對這一組確實由點算傳回、沒有因宗數太少而隱藏、規則也還沒有讀這個特徵，然後親自把數字抄上。

場景 3 / 3

負責人確認，規則只經發佈改變

客戶服務總監以自己的名義確認候選。這不會改變規則：組織設計助手只是可以把它引作草稿的依據，草稿在過往決定上重判，並由第二個人批准發佈。撤回確認，草稿便不能批准。

閱讀「這條規則管用嗎？」

查看完整導覽

01 / GEMBAOS 核心管控維度

四項核心邊界，均由企業授權規則確定，對所有 Agent 統一執行。

資料存取邊界、跨週期經辦責任、人工審批路徑與單次精確執行，全流程均有可驗證的審計記錄。

01 · 資料權限

嚴格界定每個 Agent 的讀取邊界

Agent 僅能讀取其職責必需的業務記錄與授權欄位。跨租戶數據、保密欄位及未經授權內容嚴格隔離；檢索企業內部文檔時，亦僅返回經審定生效的版本。

資料如何嚴守合規邊界
02 · 持續任務

長週期異步任務的經辦責任人

複雜理賠、突發故障處置或代碼修復可能持續數小時至數日。系統確保每一任務均有具名負責人全程督辦，負責人可向 Agent 下達指令或委託具名同事接手，絕無無人負責的幽靈任務。

長任務交接機制詳解
03 · 人工決策

明確劃分人工審批與自動放行邊界

額度內的常規業務自動放行；超額交易、政策衝突或異常數據則依授權矩陣流轉至專責人員，呈送結構化證據與摘要，無需翻閱繁冗原始案卷。

審批決策路徑配置
04 · 受控執行

只執行獲批准的參數，且只執行一次

Agent 絕不持有底層系統憑證或密碼。操作經審批後，GembaOS 在執行前重新核對簽署人當時看到的事實，憑單次放行令只執行一次，並記錄申請人、審批人及變更細節；若事實已改變，即刻停止並退回。

審批後狀態改變與失效防護

02 / 核心價值

精準解決企業推進 Agent 落地的三大核心難題。

01

無需管理層事無大小逐一審批。

一次性配置金額上限、業務範疇及前置核驗清單。合規額度內的操作自動結案；僅有超限交易或被風險標記的個案，方會攜帶整理完備的事實依據呈送主管桌面。

  1. GembaOS3,000 以下、低風險：由貴司確認的規則放行，毋須簽章
  2. AI Agent超過 3,000：AI 核對並附理由提出建議
  3. 貴公司同事由客戶服務主管決定（AI 的建議只是意見）
檢視審批決策拓撲
02

跨週期任務靈活交接，治理規則始終如一。

長週期任務始終綁定具名責任人。輪班更迭時可向同事發起交接邀請，對方具名確認接收後即刻接管，全流程權限與審批規則維持嚴格一致。

同事控制台收到的任務交接請求
實機運行展示截圖。
閱讀任務交接機制詳解
03

規則調整前，直觀預覽實際業務影響。

企業制度表現為結構化配置而非模糊的 Prompt 提示詞，GembaOS 將其視覺化為管理層易讀的拓撲圖。調整額度時，系統自動標註哪些流程將轉為自動放行、哪些規則將被收緊。

改訂航班示例：票價差額上限
變更前80變更後200

較少簽章可處理的範圍擴大

查看規則變更影響試算

決策路徑與變更示例基於系統標準配置動態生成，詳見產品介紹頁。

03 / 團隊協同全景

真實工作日協同：不同崗位視角的實時掌控。

同一份工單數據在客服專員、客服主管、IT 工程師及業務總監之間流轉。全景呈現典型一日：夜間自動告警、晨會任務梳理、客戶申告流轉、員工自然語言交辦、IT 維運排查、主管電子簽章到輪班工作交接。

各崗位職責分工

  • 客戶服務主管處理例外決定，查看團隊有哪些工作仍在等候。
  • 客戶服務專員跟進自己負責的請求，以及客戶收到的回覆。
  • 資訊科技主任閱讀事故排查報告，接手早會交來的跟進工作。
  • 客戶服務總監查看管轄範圍的情況。一般個案不會因職級較高而多加一次簽署。

客戶服務主管

開工前查看

先讀昨夜告警的排查報告，準備早會。這是唯讀報告，並不表示事故已解決。

Agent 執行動作以唯讀方式排查告警：讀取日誌、寫成這份報告、記下欠缺的資料（沒有處理手冊、沒有聯絡人），並起草一頁待批准的處理手冊。

互動體驗此環節
GembaOS 團隊的一天互動展示 — 08:45 開工前查看
客戶服務主管 · 08:45

截取自展示環境：基於模擬企業數據與電子簽章。

進入互動沙箱閱讀「團隊的一天」完整導覽檢視典型業務實機錄屏

04 / 輕量試點落地

選定單一業務場景，快速驗證成效再行推廣。

  1. 01

    確定試點業務與負責人

    選定具體業務場景、對接系統、業務負責人，並確立量化驗收指標。

  2. 02

    受控接入與影子觀察

    在約定沙箱邊界內核驗數據流、權限判定與操作行為，逐步開放自動放行範疇。

  3. 03

    量化業務價值並評估推廣

    對比人工介入率、審批流轉時效、退回率及異常工單積壓，以實際業務指標決定規模化推廣。

試點範圍、排期及評估費用經由雙方專項確認。

計劃詳情

05 / 技術架構與安全評審

為 IT 與資訊安全團隊提供的完備評審依據。

深入了解私有化部署、模型選型及企業既有架構整合方案，全方位審查底層安全控制機制。

產品架構與運行機制

深入掌握審批路徑、版本比對與執行放行機制。

安全合規與部署方案

審核網絡數據流向與企業級安全管控邊界。

既有系統整合

了解適配器與企業系統的接駁要求。

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

閱讀架構白皮書先由人來做，再逐步交給 Agent示範一次（瀏覽器記錄工具仍是原型）這條規則管用嗎？先查證、再試行，經具名程序擴大

FAQ

常見諮詢問題

查看全部問題
審批流程會否拖慢日常工作？

低風險查詢及額度內操作可自動放行。只有授權表規定須審批的操作，例如超額退款或生產特權變更，才會交由負責人決策。

SOP 和知識庫還未整理好，可以導入嗎？

可以。缺口登記冊會記錄未定義的操作步驟與不清晰的權限邊界。Agent 可草擬規程建議，但必須經業務負責人審閱並批准，才會沉澱為正式業務規程。

資料與模型可以全部留在企業內網嗎？

可採用本地或私有 VPC 部署，配合自託管模型。如選擇雲端模型或外部系統，則會產生對外資料路徑，須按實際需要配置，包括適用的欄位遮蔽措施。

六週試點需要投入多少工程人力？

架構師會全程協作。設定階段需 IT／維運窗口參與，影子模式需指定業務負責人進行審批。實際投入視系統連接而定，會在試點範圍確認時議定。

從貴司的工作流程談起

預約示範

請告知您關注的業務場景（如財務結算、ERP 操作、IT 維運或客戶服務）。我們將透過電郵與您確認時間，並於示範中進行針對性探討。

我們會以電郵回覆。

* 為必填欄位。

輸入資料的處理方式

您輸入的資料會傳送至 Lux Mentis Limited，用作回覆之用。資料儲存於我們自己的伺服器，並以電郵通知團隊，不作其他用途。 閱讀私隱聲明