02 / 典型場景
保險理賠跨越數星期,審批只需一屏
GembaOS 是企業 AI Agent 的治理執行平台:以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批,部署於企業本地機房或私有 VPC。此場景是保險理賠:文件由模型閱讀,讀到的數值由 GembaOS 與記錄核對,所以小額而沒有問題的索償幾分鐘就完成。一宗個案即使歷時數星期、分幾輪補交文件,經過理賠審核、醫療審查和法務,到理賠經理面前仍然只是一張一屏看得完的審批單。
模型在理賠中做甚麼、不能做甚麼?
理賠的 Playbook 宣告一名調查員:一個只有理賠和保單讀取權限、以及一張固定格式表單的模型。它閱讀陳述、所有附件和已回覆的補件,向簽署人交出要點。
| 調查員會做 | 調查員不能做 |
|---|---|
| 從收據、發票和證明書讀出金額和日期 | 提議金額:準備金就是記錄上的索償金額 |
| 寫下經過和摘要,事實與推斷分開 | 選結論:在保障範圍內等結論由簽署人選 |
| 以封閉清單提出問題(金額不符、已存在病症、可能適用除外條款等),引用保單條款並照抄條文原句 | 引用保單沒有的條款,或替條文加上它沒說的話:GembaOS 標明「保單中沒有此條款」,並把引文逐字與條文核對 |
| 把每個檔案歸類:病歷、收據、發票、相片 | 判定文件已齊:所需文件由 GembaOS 對照個案實際的檔案計算 |
| 列出欠缺的文件和值得諮詢的角色 | 聯絡申請人、簽章,或把路線改得更寬鬆 |
在人閱讀之前,GembaOS 先核對要點。凡在理賠記錄中有對應欄位的數值,都逐一比對並標示一致或不符。不符、有問題,或根本沒有要點(模型停了),都會成為審批單上的風險標記;標記只會為路線加人。簽署人讀的是不符的那一行,不必逐頁重看。
怎知道條文真的這樣寫?
因為條文就擺在那裏,而引文會與條文核對。
引用條款的問題,必須附上該條文的原句。調查員以自己的讀取權看保單條文,把所依據的一句照抄進要點。GembaOS 接着做兩件模型講不過去的事:把條款編號與保單記錄上的條款核對,再把引文與該條款的正文逐字核對(空白與大小寫除外)。表單上會顯示其中一項:
| 表單顯示 | 意思 |
|---|---|
| 這段話確在條文內 | 引文確實出自所引的條款 |
| 這段話不在條文內 | 條文讀過了,但沒有這樣寫(改寫,甚至更嚴重) |
| 沒有摘錄原文 | 這個引用沒有條文佐證 |
| 保單中沒有此條款 | 保單記錄上沒有這一條 |
除第一項外都是風險標記:快速通道關閉,由人查看。
這裏能證明的範圍很窄,我們寧可說清楚:能證明的只是「這些字出自條文」。條款是否支持要點的說法,是判斷,仍然屬於簽署的人。所以條文全文就印在引文旁邊,引用的那一句還會標示出來。讀的人不必去翻,低頭就看到條文。
小額索償會怎樣?
小額索償可以走快速通道。申請人在工單頁確認陳述;索償同時在 Playbook 的自動簽批範圍和租戶權限表之內;至少有一份文件;包括要點在內沒有任何標記。這時由規程規則簽批,在單次放行令下計提準備金並回讀,申請人幾秒內就收到回覆。兩個上限都由貴公司決定;取消自動簽批範圍,所有索償都交審核員。
小額但有任何標記的索償,會交給審核員。下面的示範中,診所收據合計 HK$980.00,索償金額是 HK$650。該行標示「不符」,不走快速通道,由審核員一鍵打開收據後決定。
欠缺的文件由誰跟進?
GembaOS 把個案放在工單上,而不是放在審批單上。每類理賠必須具備哪些文件,由 Playbook 列明:意外理賠要病歷和收據,財物損失要維修發票。調查員把每個檔案歸類,GembaOS 逐一核對檔案是否確實在案,並計算欠缺甚麼。計算的是 GembaOS,而非模型:只有指向個案中確實存在的檔案,該種類才計入;哪個檔案被歸為哪一類,簽署人都看得到。
所需文件由 GembaOS 自行以補件請求索取:種類、截止日期,並在截止前 3 個工作日提醒一次。申請人只看到文件種類,看不到模型寫的任何字;他們在工單頁上載檔案並附一句說明,或直接回覆電郵。每次回覆,調查員都再讀一次,仍欠的由 GembaOS 繼續索取,直至 Playbook 的輪數上限。其他文件審核員仍可另行索取。審批單要等文件齊全才起草,而且只起草一次。
文件始終未到會怎樣?
截止日期已過,或輪數用完仍欠所需文件時怎樣處理,Playbook 以一項設定決定:
| 設定 | 結果 |
|---|---|
| 由經辦人決定 | 記錄在案,個案留在審核員的待辦,由審核員決定 |
| 轉交 | 個案轉到指定角色(例如理賠經理)的待辦 |
| 以資料不齊結案 | 通知申請人文件未到;這並非對理賠本身的決定,申請人可以重新申請 |
| 拒賠 | 起草拒賠審批單,交路線上的人簽署;簽署才拒賠,不同意則個案退回審核員 |
單憑逾期,拒賠永遠不會被執行。Playbook 也可以讓規程規則簽批拒賠,但 gemba config check 會警告「理賠可能在無人簽署下被拒」。
| 以往 | 使用 GembaOS | |
|---|---|---|
| 閱讀文件 | 審核員逐頁閱讀,再把金額抄一次 | 調查員閱讀,每個數值標示與記錄一致或不符 |
| 小額索償 | 與大額索償排同一條隊 | 申請人確認後,在貴公司的上限內、沒有標記即走快速通道 |
| 文件不齊 | 經辦人記在日程裏,一換人就斷 | 所需文件由 GembaOS 索取並提醒一次;始終未到,按 Playbook 的設定處理 |
| 申請人說了甚麼 | 被重新抄進理賠備註 | 原話與檔案原樣呈現給申請人確認,以雜湊值鎖定 |
| 醫療或法務意見 | 檔案裏的一段評語 | 從封閉清單選取的會簽結論,進入簽署鏈 |
| 經理覆核 | 從頭讀整份檔案 | 自上次查看以來的變化,然後是唯一剩餘決策 |
| 計提準備金 | 收到批核電郵後人手輸入 | 重讀理賠記錄後,在單次放行令下只執行一次 |
步驟是怎樣的?
| 步驟 | 由誰 | 記錄甚麼 |
|---|---|---|
| 1. 受理 | 申請人以理賠編號申報;系統記錄陳述與檔案並簽發工單 | 陳述、檔案、所指的理賠(只限申請人本人的) |
| 2. 要點 | 調查員閱讀;GembaOS 把數值與記錄核對 | 要點、每個數值的一致或不符、標記 |
| 3. 補件 | GembaOS 索取檔案中欠缺的所需文件;申請人上載;調查員再讀 | 每一輪的種類、截止日期、提醒、收到甚麼、何時收到,以及新的要點和重新計算 |
| 4. 確認 | 申請人確認已記錄的內容,或指出錯處 | 申請人確認,或附在原件旁的更正 |
| 5. 快速通道 | 收到確認後由 GembaOS 判斷 | 走(由規則簽批)或不走;不走時記錄由誰簽批、原因為何 |
| 6. 進入評估 | 文件齊全後由審核員啟動 | 一張以要點置頂的審批單:理賠的現狀,加上出險天數、補件輪數、檔案數量 |
| 7. 簽署 | 審核員,其後理賠經理,各自附結論 | 附結論與理由的簽署鏈 |
| 8. 執行 | 系統在放行令下執行 | 先與審批人看過的內容比對,再計提準備金一次 |
AI 建議拒賠時,由誰簽?
在這裏,模型不會建議拒賠:它只以清單提出問題,決定由人做。路線上的人按 Playbook 設定的結論簽署:審核員是「在保障範圍內/不在保障範圍內/需要調查」,醫療審查是「治療必要/治療不必要/病歷不足」,法務是「適用免責條款/不適用免責條款/有歧義」。
結論亦決定下一步。「需要調查」會令醫療審查緊接審核員簽署;「病歷不足」會退回審批單,並向申請人索取病歷。結論由人選,下一步由 Playbook 決定。
香港保險業監管局已推出人工智能促進計劃,理賠與詐騙偵測都是業界探索的應用範疇。無論貴公司採用哪一種做法,這裏的記錄都寫明由誰、根據哪些事實、以哪個結論作出決定,以及模型讀過甚麼。
實機畫面






同一個櫃位的兩宗小額索償:一宗被要點攔下,一宗經快速通道完成。




開始需要甚麼?
- 現行的理賠審批權限:誰可批核多少金額,何時交醫療審查或法務,小額索償可否由規則簽批。
- 讀取理賠與保單的權限,以及計提準備金的一個操作(經 REST 或 SQL Adapter)。
- 要調查員從文件讀出的數值、可以提出的問題,用貴公司自己的用語。
- 每類理賠必須具備的文件,以及文件未到時的處理方式。
- 調查員使用的模型:自行託管或 SaaS 均可,在資料出境上限之內。
- 各角色簽署時選用的結論,用貴公司自己的用語。
- 與申請人的渠道:工單頁、電郵,或兩者並用。
本文回答的問題
AI Agent 可以決定是否賠付嗎?
在 GembaOS 不可以。調查員(模型)閱讀文件並向簽署人交出要點,但不提議金額、不選結論。理賠以一張審批單結束,由具名的人簽署,每人簽署前從封閉清單中選一個結論;只有已確認、無任何標記的小額索償,才由規程規則在租戶權限表之內簽批。
AI 在理賠中做甚麼?
它閱讀陳述、所有附件、已回覆的補件,以及理賠和保單記錄,然後交出固定格式的要點:文件上的金額和日期、經過、封閉清單內的問題(條款按保單記錄原文引用)、欠缺的文件、值得諮詢的角色。GembaOS 把每個數值與理賠記錄核對,標示「一致」或「不符」。
怎知道 AI 沒有憑空捏造保單條款?
因為條文就印在表單上,引文會與條文核對。引用條款的問題必須附上該條文的原句;GembaOS 把條款編號與保單記錄上的條款核對,再把引文與該條款正文逐字核對。「不在條文內」「沒有摘錄原文」「保單中沒有此條款」都是風險標記,而條文全文會列在引文旁邊。這項核對只證明這些字出自條文,條款是否支持該說法仍由簽署的人判斷。
欠缺的理賠文件由誰跟進?
Playbook 列明的所需文件由 GembaOS 跟進。調查員把檔案歸類,GembaOS 計算欠缺的種類,自行向申請人索取,附截止日期並提醒一次;其他文件審核員仍可另行索取。文件始終未到,就按 Playbook 的設定處理:由審核員決定、轉交理賠經理、以資料不齊結案,或把拒賠交由審核員簽署。
經理休假兩星期回來,要看甚麼?
先看「自上次查看以來」的變化:等了多少天、新增的簽署與結論、新文件、補件輪數、申請人確認;其下是「唯一剩餘決策」:待簽角色、為該角色設定的問題,以及仍未決的結論。
最後更新: · GembaOS v0.2