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 決定。

香港保險業監管局已推出人工智能促進計劃,理賠與詐騙偵測都是業界探索的應用範疇。無論貴公司採用哪一種做法,這裏的記錄都寫明由誰、根據哪些事實、以哪個結論作出決定,以及模型讀過甚麼。

實機畫面

受理時的 GembaOS 個案面板:要點把相片歸類為相片,所需的病歷和收據未到,第 1 輪由規程自動索取
受理時的 GembaOS 個案面板:要點把相片歸類為相片,所需的病歷和收據未到,第 1 輪由規程自動索取

GembaOS 工單頁(手機):待確認的申請內容,以及補交病歷和收據的請求
GembaOS 工單頁(手機):待確認的申請內容,以及補交病歷和收據的請求

文件到齊後的 GembaOS 個案面板:要點標示金額和受傷日期與記錄一致;不走快速通道,由審核員和經理簽批
文件到齊後的 GembaOS 個案面板:要點標示金額和受傷日期與記錄一致;不走快速通道,由審核員和經理簽批

以調查要點開頭的準備金審批單:文件與記錄核對、附件,然後是批准後會發生甚麼
以調查要點開頭的準備金審批單:文件與記錄核對、附件,然後是批准後會發生甚麼

審核員簽署後理賠經理打開的審批單:自上次查看以來新增一個簽署,結論為在保障範圍內
審核員簽署後理賠經理打開的審批單:自上次查看以來新增一個簽署,結論為在保障範圍內

執行後的工單時間線:兩個簽署、執行前重讀理賠記錄、在放行令下計提並回讀、正式回覆
執行後的工單時間線:兩個簽署、執行前重讀理賠記錄、在放行令下計提並回讀、正式回覆

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

小額索償的 GembaOS 個案面板:文件與記錄不符,不走快速通道;要點把收據合計標示為不符
小額索償的 GembaOS 個案面板:文件與記錄不符,不走快速通道;要點把收據合計標示為不符

以要點開頭的小額索償審批單:收據 HK$980.00、記錄 HK$650,標示不符,附上收據
以要點開頭的小額索償審批單:收據 HK$980.00、記錄 HK$650,標示不符,附上收據

颱風小額索償的工單時間線:要點與記錄一致、走快速通道、按規程規則簽批、計提準備金並回讀
颱風小額索償的工單時間線:要點與記錄一致、走快速通道、按規程規則簽批、計提準備金並回讀

快速通道完成後的工單頁(手機):已確認的申請內容和正式回覆
快速通道完成後的工單頁(手機):已確認的申請內容和正式回覆

開始需要甚麼?

相關:採購例外申請、退款審批、詞彙表。

本文回答的問題

AI Agent 可以決定是否賠付嗎?

在 GembaOS 不可以。調查員(模型)閱讀文件並向簽署人交出要點,但不提議金額、不選結論。理賠以一張審批單結束,由具名的人簽署,每人簽署前從封閉清單中選一個結論;只有已確認、無任何標記的小額索償,才由規程規則在租戶權限表之內簽批。

AI 在理賠中做甚麼?

它閱讀陳述、所有附件、已回覆的補件,以及理賠和保單記錄,然後交出固定格式的要點:文件上的金額和日期、經過、封閉清單內的問題(條款按保單記錄原文引用)、欠缺的文件、值得諮詢的角色。GembaOS 把每個數值與理賠記錄核對,標示「一致」或「不符」。

怎知道 AI 沒有憑空捏造保單條款?

因為條文就印在表單上,引文會與條文核對。引用條款的問題必須附上該條文的原句;GembaOS 把條款編號與保單記錄上的條款核對,再把引文與該條款正文逐字核對。「不在條文內」「沒有摘錄原文」「保單中沒有此條款」都是風險標記,而條文全文會列在引文旁邊。這項核對只證明這些字出自條文,條款是否支持該說法仍由簽署的人判斷。

欠缺的理賠文件由誰跟進?

Playbook 列明的所需文件由 GembaOS 跟進。調查員把檔案歸類,GembaOS 計算欠缺的種類,自行向申請人索取,附截止日期並提醒一次;其他文件審核員仍可另行索取。文件始終未到,就按 Playbook 的設定處理:由審核員決定、轉交理賠經理、以資料不齊結案,或把拒賠交由審核員簽署。

經理休假兩星期回來,要看甚麼?

先看「自上次查看以來」的變化:等了多少天、新增的簽署與結論、新文件、補件輪數、申請人確認;其下是「唯一剩餘決策」:待簽角色、為該角色設定的問題,以及仍未決的結論。

最後更新: · GembaOS v0.2