玉山金智能徵信的啟示：高風險 AI 流程如何保留人類判斷

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-06

玉山金控將生成式 AI 導入企業授信徵信，目標是處理最花時間的資料蒐集與報告起草工作。iThome 報道指出，該行自行開發多項工具後，可在約 5 分鐘匯集企業外部資訊，並在資料備妥後約 7 分鐘生成徵信報告初稿；公司估計，相關工具每年可節省約 8.4 萬人時。對銀行及其他受高度監管企業而言，這個案例較值得留意的地方，不是「幾分鐘寫好報告」，而是如何把 AI 放進原有審批流程，同時保留可追溯的人類覆核。

這項安排也有明確限制。徵信報告涉及企業營運、財務變化、負面新聞、訴訟及潛在風險，AI 即使能整理資料和提出分析框架，仍未必掌握客戶實況或異常數字背後的原因。iThome 指出，當報告未能解釋財務數據突變時，客戶關係經理（RM）仍須向客戶查證，並根據實際訪查結果修訂。因此，這不是以 AI 取代授信人員或審批，而是把人員由重複尋找資料和填寫初稿，調配到查核例外、補足脈絡及作出風險判斷。

先拆解工作，才談得上自動化

傳統企業徵信的難處，往往不在單一資料庫或單一報表，而在資料分散於公開資料、新聞、年報、法說會資料、招聘網站及銀行內部紀錄，且不同 RM 的撰寫方式和判斷深度不一。iThome 報道形容，玉山銀行的法金團隊每年要產出數千份報告，RM 每月約四成工時用於蒐集資料；資深人員完成一份報告可花十多小時，新手則可能超過 20 小時。若只在流程末端加上一個文字生成工具，未必能解決資料來源、格式與判斷標準不一的問題。

玉山採取的做法，是把徵信工作劃分為外部資料蒐集、內部歷史資料整理、數據分析、生成初稿、人手調整及深化分析等六個階段，再配合四項 AI 工具。當中，iCatcher 用於連接外部資料及整理企業背景；OCR 財務報表自動引入減少人手輸入；「智捷通」按授信 5P 原則撰寫初稿；「AI提示家」則在完稿後提出可能被審查單位追問的風險與不足。這種分工比把全部任務交給一個聊天介面更可控，因為每一環都可界定輸入、輸出和負責人。

從流程設計看，資料蒐集工具亦不限於案件撰寫。iThome 指出，RM 在拜訪新客戶前亦會以 iCatcher 了解客戶背景及負面消息。這反映企業導入 AI 時，應先識別同一份結構化資料可在哪些既有工序重用，而非只計算一份文件節省了多少分鐘。不過，資料匯集得愈快，前線人員更要確認來源的時效、相關性與上下文；負面消息的出現本身，不能直接等同信用風險結論。

把專家經驗變成可檢查的 prompt 與框架

高風險知識工作的一大障礙，是關鍵判斷通常存在於資深人員的經驗中。iThome 報道指出，玉山法金團隊花約三個月，將原本隱含在專家腦中的撰寫重點梳理成結構化 prompt，並按授信需求、客戶群和行業特性建立不同報告範本。換言之，AI 導入前的主要工作之一，是先回答「一份合格報告必須涵蓋甚麼」、「何種特徵需要甚麼紀錄」及「哪些情況須升級處理」。

這個步驟帶來的效益不只在生成內容。當審查要求、必要欄目和風險描述被明確化，新手 RM 可以把 AI 初稿視為學習參考，較容易掌握過去依賴師傅帶領才能累積的注意點；審查部門與前線之間亦有較一致的共同語言。這是根據案例可作出的流程分析，並不代表 AI 已具備資深審查員的判斷力。標準化可以減少遺漏和格式落差，但也可能令使用者過度依賴既有框架，忽略未被設計進 prompt 的新型風險。

因此，較穩妥的實踐是把 AI 產出定位為「需被驗證的工作底稿」。玉山的安排中，RM 要審閱初稿，再加入客戶訪查和財務資料的深度分析；分行案件亦會交總行審查單位複審。若其他金融或企業團隊參考此模式，應把人工覆核、例外升級和最終責任清楚寫進流程，而非把人工介入當成系統表現不足的臨時補救。人手應集中在 AI 最難自行取得或判斷的資訊，例如客戶解釋、商業關係及異常成因。

LLM 評測不能只看文字是否流暢

生成報告的另一個難題，是「寫得像報告」不等於內容可靠。iThome 指出，玉山會先列出報告應有的元素，再由另一個大型語言模型（LLM）按清單檢查完整度，例如企業成立時間及負責人資料是否齊備；團隊亦會核對三年財務分析有否按正確年份比較，並使用 Faithfulness（忠實度）等品質指標，檢查生成內容是否偏離所匯入的參考資料。這類評測把模糊的好壞，轉化為可重複檢查的項目。

但「以 AI 檢查 AI」不能構成唯一防線。iThome 報道提到，玉山會把 LLM 的檢查結果交給法金專家判斷，確認檢查本身是否正確，並為每份生成報告計算品質分數、蒐集使用者回饋。這是一個重要的治理原則：評測器同樣有盲點，尤其當資料不完整、行業背景複雜或問題涉及隱性知識時，必須由理解業務責任的人員校正。對高風險流程來說，完整度、資料忠實度與人類專家覆核，應是互相補足的三層控制。

迭代速度取決於協作機制

iThome 指出，玉山由去年 3 月至今年 7 月已釋出 14 個版本，平均約三星期一次迭代，並由法金專家在共同編輯的 Excel 檔標註個別報告意見，開發人員再據此修改系統 prompt 或服務端 prompt。第一線 RM 亦可直接回報錯誤或幻覺內容。案例顯示，AI workflow 的改良重點不只是選擇哪一個模型，而是能否把使用現場的具體錯誤，快速變成下一輪規則、範本與測試案例。

不過，iThome 亦引述玉山人員提醒，這種小步快跑的共創模式未必適合所有場景，特別是在成效尚未明顯的初期，管理層支持仍然關鍵。企業若要複製，宜先選擇資料範圍較清楚、可由專家頻繁檢驗、且保留人類最終決定權的工序，逐步建立評測基準和回饋循環。下一步值得觀察的，是這套人機協作能否在持續迭代後，維持資料可信度、審查一致性與責任界線，而非只追求報告生成速度或節省工時。