Agentic Research

This article is not yet available in English. You are reading the Traditional Chinese original. The English edition will appear here once it is translated.

Browse articles that do have an English edition

合約條款提取與風險標記系統:從逐頁閱讀到結構化風險導航

2026/10/0114 min readBryan Chan閱讀中文原文
Topics應用場景AI Agent法務

LawGeex 在 2018 年的一項研究中讓 AI 與 20 位資深律師比賽審查保密協議(NDA)。結果令人震驚:AI 的準確率達到 94%,而律師的平均準確率只有 85%;更重要的是,AI 平均每份合約只需 26 秒,律師則需要 92 分鐘。這不是說 AI 能取代律師,而是說明了一個事實:當任務被明確定義為「定位條款、比對標準、標記偏差」時,AI 的穩定性與速度遠超人工。關鍵在於,LawGeex 的 AI 不是憑空判斷,而是基數百份已標註的 NDA 訓練出來的——它知道「責任上限」通常長什麼樣子、「保密期間」有哪些變體寫法。

Starling Elevate 的法務團隊每年審查超過 500 份銷售與採購合約。引入結構化的條款提取系統後,他們將初審時間從平均每份 3 小時縮短到 45 分鐘,同時將遺漏關鍵條款的機率從 12% 降到 2%。做法很簡單:定義七類必須檢查的條款,每份合約都產出一張「條款對照表」,標記出與公司標準範本的偏差,法務只需覆核標記為「重大偏差」或「未找到」的項目。這不是魔法,這是把模糊的「讀完整份合約」變成具體的「檢查這七件事」。

為什麼這個場景值得自動化

三個核心痛點:位置不固定(同類條款在不同合約裡的位置、名稱、寫法都不一樣,每次都要重新找);表述變體多(同一種限責安排有很多種寫法,讀到第十份時注意力已經撐不住);遺漏無感(漏掉一條不會有任何提示,你根本不知道自己漏了)。

照這個配方做完,你會得到四樣東西:一份版本化、經法務確認的標準範本與底線清單;每份合約一張「七類條款對照表」,每筆結論附原文頁碼與條號;一個標記偏差等級的風險地圖;以及全程的審計軌跡。

同樣明確它不做什麼:不解釋法律效果,不判斷「能不能簽」,不替代法務。AI 在這個流程裡的「理解」止步於「這條款表面約定了什麼」;「這樣約定對你方意味著什麼」是法律判斷,屬於人。

工具組合與前置準備

工具在流程裡做什麼
Ironclad / DocuSign合約生命週期管理(CLM):模板庫、版本控制、電子簽名、審批流程;作為最終審查報告的匯入目標
Claude長文字的條款定位與轉錄,輸出結構化的對照表行
NotebookLM把你方標準範本與底線清單上傳為依據來源,偏差比對能同時引用兩邊原文
PaddleOCR掃描檔與圖片型合約轉文字;可本地部署,敏感合約不出內網
Dify(可選)把流程編排成團隊可重複使用的形式:上傳合約 → OCR(如需)→ 抽取 → 比對 → 輸出報告

PaddleOCR 的環境搭建與端到端實作見PaddleOCR 抽取港股年報;三個工具的定價與部署方式以官網為準。

資料前置:合約在公司裡通常屬於高敏感資料。動工前確認三件事:這份合約能不能用雲端工具處理(問法務與資訊安全);要不要去識別化(當事方名稱、金額等欄位先遮蔽再進流程);要不要本地路線(OCR 本地跑,模型端依資料分級結果決定)。分級方法見企業資料安全基本盤。

材料準備:你方標準合約範本(最新版本);不可讓步的底線清單(例如「責任上限必須存在」「保密期間不得短於合作期間」);兩三份歷史合約當測試樣本。底線清單由法務預先確認——它是對照表的尺,尺不能在覆核時才現場發明。

一、檔案分流——文字層 PDF 與掃描檔走不同路

判斷方法:打開 PDF,嘗試選取並複製一段文字。能選取、能複製,是文字層 PDF;選不中、整頁本質上是一張圖片,是掃描檔。不少合約是混合型(簽字頁掃描、內文文字層),要逐頁確認。

檔案類型處理路徑關鍵動作
文字層 PDF直接抽取文字必須保留頁碼:每段文字記錄它來自第幾頁——頁碼是之後覆核回溯原文的根
掃描檔PaddleOCR 做文字識別OCR 輸出必須校對;數字、日期、金額、否定詞所在段落全部對照原圖核過
混合型按頁拆分,分別走上面兩條路頁碼以原文件統一編號;合併後檢查頁碼序列連續

掃描路為什麼要更保守:合約場景會放大 OCR 錯誤。一個數字辨識錯,金額就變了;一個形近字錯,義務主體就換了;漏掉一個「不」「無」「得」,條款意義整個反轉。機器讀文件的錯誤模式與校對策略,機器怎麼讀懂財報有完整說明。

Ironclad 整合:如果公司使用 Ironclad 作為 CLM,可以直接從 Ironclad 匯出合約的文字版本(多數情況下 Ironclad 已儲存結構化數據),跳過 OCR 步驟。Ironclad 的 API 也支援上傳合約後自動觸發審查流程,這讓整個鏈路可以完全自動化。

二、定義條款對照表的欄位

固定抽七類條款,每類都要有結果(找不到也是結果,見下文):

  1. 期限與終止:合作期限、續約機制、提前終止的條件與通知期
  2. 付款與價格:金額與幣別、付款節點與條件、遲延付款的處理
  3. 違約與救濟:什麼構成違約、救濟方式、補正期間
  4. 智慧財產:成果歸屬、授權範圍、背景智財的處理
  5. 責任限制:有沒有責任上限、除外情形、上限的計算基礎
  6. 保密:保密資訊範圍、保密期間、例外情形
  7. 管轄與爭議解決:準據法、管轄法院或仲裁安排、前置協商程序

對照表每一行的欄位設計:

欄位填什麼
條款類別上述七類之一
合約原文摘錄節錄關鍵原句,不改寫
原文位置頁碼+條號
你方標準立場來自標準範本與底線清單,由法務預填
偏差描述與標準的具體差異(哪句、差在哪)
偏差等級與標準一致/可接受偏差/重大偏差/合約未找到
覆核狀態待覆核/已覆核/有爭議
覆核者與日期人工覆核後填寫

兩個設計要點。「未找到」是一等公民:缺少責任上限條款的合約,可能比責任上限異常的更危險——空白本身就是風險信號,絕不能留白或用範本內容補上。偏差等級只標事實(與標準差多少),風險的最終定性由覆核的法務填,AI 給的等級只是初篩建議。

三、抽取提示詞——只定位與轉錄,不解釋

提示詞骨架:

任務:從以下合約文字中,定位七類條款:期限與終止、付款與價格、
違約與救濟、智慧財產、責任限制、保密、管轄與爭議解決。

每一類輸出:
- 原文摘錄:節錄關鍵原句,禁止改寫或以摘要代替
- 原文位置:頁碼與條號(輸入文字中已帶頁碼標記)
- 內容要旨:一句話描述這條款約定了什麼表面內容;
  不分析對任何一方的利弊,不預測法律效果
- 找不到時:輸出「未找到」,禁止以通用條款或其他合約的
  內容補充

紀律:只使用給定文字中出現的內容;不引用「行業慣例」;
不憑記憶補全;輸出按固定欄位的表格。

兩條設計理由。「未找到」必須顯式要求:模型在找不到條款時,傾向於編一條「應該存在」的標準條款填進去,而且填得格式完整、語氣正常——這是合約場景最致命的錯誤形態,比抽錯更難被發現。禁止解釋效果:解釋是法律判斷,模型會給出看似專業的說法,但沒有任何東西為它的說法負責。

長合約的處理:不要一次把幾十頁塞進一個對話。按章節切段,每段帶同一個抽取任務,最後合併成一張表。合併後必做兩個檢查:頁碼序列是否連續;七類條款是否每一類都有結果(含「未找到」)。切段有一個隱性風險——中間某段被漏掉,而輸出依然「看起來完整」,所以合併檢查不可省。

NotebookLM 的價值:當你方標準範本與底線清單上傳到 NotebookLM 後,可以在比對階段要求 AI 引用兩邊的原文。例如:

標準範本第 5.2 條:「乙方之損害賠償責任總額不得超過本合同總金額。」
合約第 8.3 條:「乙方之責任上限為新台幣 100 萬元。」
偏差描述:合約設定了固定金額上限,而非按比例計算。若合約總金額高於 100 萬,此條款對我方較不利。

這種雙向引用的能力,讓覆核的法務能一眼看出差異在哪,而不需要在兩個文件之間來回切換。

四、風險分級與覆核優先序

偏差等級的定義必須由法務預先確認,以下是常見的分級邏輯:

等級定義覆核優先序
與標準一致條款內容與標準範本實質相同,僅措辭微調低(可抽樣覆核)
可接受偏差與標準有差異,但在商業上可接受,不涉及核心風險中(建議覆核)
重大偏差違反底線清單,或顯著增加我方風險高(必須覆核)
合約未找到標準範本中存在的條款,在合約中完全缺失高(必須覆核)

風險地圖:將所有合約的偏差等級匯總成一張儀表板,法務負責人可以一眼看出哪些合約需要優先處理。例如:

合約 A:2 項重大偏差(責任限制、管轄)、1 項未找到(保密)
合約 B:1 項可接受偏差(付款節點)
合約 C:全部與標準一致

覆核順序:先處理合約 A,再處理合約 B,合約 C 可以抽樣或跳過。這不是偷懶,這是資源配置——法務的時間應該花在真正有風險的地方。

Ironclad 整合:在 Ironclad 中,你可以為每個偏差等級設定不同的審批流程。例如,「重大偏差」必須經過資深法務與業務負責人雙重批准;「可接受偏差」只需資深法務批准;「與標準一致」自動通過。這樣,AI 的輸出直接驅動工作流程,而不只是產生一份報告。

五、人工覆核節點與 CLM 整合

  • 誰覆核:資深法務,責任到人。 junior 法務可以做初步篩選,但最終決定權在 senior。
  • 覆核什麼:啟用初期全量人工覆核——自己先人工跑一批,與 AI 對照表逐條對照,把每一個不一致標出來(是抽取錯、標準理解分歧,還是 AI 真的漏了)。穩定之後改為「兩類必看+抽樣」:重大偏差必看,未找到的必看,其餘抽樣。
  • 抽樣比例與鬆緊條件自己定,並寫下來:方法是把「不一致率」定義為人工判斷與 AI 比對不同的條目佔比;每批固定抽樣計算;不一致率低於你對遺漏代價的容忍度時放寬抽樣,回升就收緊到全量。容忍度取決於你遺漏一條關鍵條款的實際代價——這是你的參數,不要抄任何文章裡的現成數字。
  • 留紀錄:每份合約的最終審查意見、審查人、日期、使用的標準版本,全部保存在 CLM 系統中。這是稽核紀錄,是日後修訂標準的原料,也是出現爭議時唯一能還原過程的東西。

CLM 整合:將 AI 生成的對照表以結構化格式(JSON 或 CSV)匯入 Ironclad 或 DocuSign CLM。大多數現代 CLM 支援自訂欄位,你可以建立「偏差等級」「原文證據鏈接」「覆核狀態」等欄位,讓法務團隊在 CLM 內直接查看與審批。這樣做的價值在於:所有決策都在同一個系統內留下軌跡,方便後續分析與合規審計。

再說一次那條底線:能不能簽由法務決定、由法務記錄、由法務負責。AI 的輸出永遠不直接等於決定。

六、持續校準與標準迭代

每一季做一次複盤,三個檢查:

  • 遺漏率檢查:有多少關鍵條款被 AI 標記為「未找到」,但實際上存在?如果是 OCR 錯誤,改進 OCR 品質;如果是提示詞問題,調整提示詞;如果是條款寫得太隱蔽,考慮是否需要人工介入。
  • 偏差等級準確性:AI 標記為「重大偏差」的條款,法務覆核後有多少確實是重大偏差?如果誤報率高,說明偏差等級的定義不夠清晰,需要與法務重新對齊。
  • 標準效度檢查:有沒有哪些條款在標準範本中存在,但實際業務中從來沒有人堅持?如果有,考慮將其從「必要」降級為「可接受偏差」,或乾脆從標準中移除。標準應該反映真實的業務需求,而不是法務的想像。

一個清醒的期待:AI 不會消除風險,它只是把風險顯性化。風險治理的槓桿在標準與覆核兩層,不在模型層。

落地檢查表(分4週)

週次任務負責人驗收標準
第1週定義七類條款與標準範本法務團隊完成標準範本 v1、底線清單,經資深法務確認
第1週設定合規邊界與資料處理流程法務 + 資訊安全完成資料分級、工具使用許可確認、去識別化方案
第2週搭建 OCR + 抽取流程(Dify 或手動)法務 + IT能穩定處理 5 份測試合約(含掃描檔),抽取準確率 > 85%
第2週人工覆核基準線建立法務團隊人工審查 10 份合約,與 AI 對照表對照,標記不一致處
第3週小批量試運行(20–30 份合約)法務團隊完成全量人工覆核,調整提示詞與標準,不一致率 < 10%
第3週CLM 整合測試IT + 法務對照表能正確匯入 Ironclad/DocuSign,欄位映射無誤
第4週正式啟用與監控法務團隊開始處理真實合約,每日抽樣覆核,每週進行遺漏率檢查
第4週首輪複盤與標準迭代法務團隊完成遺漏率檢查、偏差等級準確性評估,修訂標準 v2

常見誤區

  • 讓 AI 直接輸出「可以簽/不能簽」:等於把決策責任交給黑盒子。出現爭議時,你對業務部門、對監管、對自己的管理層都解釋不了。
  • 忽略「未找到」的情況:模型傾向於編一條「應該存在」的標準條款填進去,而且填得格式完整、語氣正常——這是合約場景最致命的錯誤形態。
  • OCR 輸出不校對:合約中的數字、日期、金額、否定詞一旦辨識錯誤,條款意義整個反轉。OCR 後必須人工抽查關鍵段落。
  • 標準範本過時:如果標準範本是三年前寫的,而業務模式已經改變,那麼比對出來的「偏差」可能其實是合理的商業調整。標準必須定期更新。
  • 合約丟進未經公司允許的工具:合約個資與商業機密出了邊界,合規事故的代價遠大於審查省下的時間。
  • 標準悄悄修改:沒有版本號,你不知道某批結果是哪版標準跑的,複盤與爭議處理全部失效。
  • 忽略 CLM 整合:AI 對照表留在文件或聊天記錄裡,無法與後續審批流程、簽署記錄串聯,失去審計價值。
  • 期待 AI 零風險:模型會有遺漏與誤判。風險治理的責任在寫標準的人與覆核的人身上。
  • 不檢查遺漏率:如果 AI 經常漏掉實際存在的條款,說明抽取邏輯有問題。必須建立「AI 輸出→人工覆核→遺漏反饋」的閉環。

下一步