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 也支援上傳合約後自動觸發審查流程，這讓整個鏈路可以完全自動化。
二、定義條款對照表的欄位
固定抽七類條款，每類都要有結果（找不到也是結果，見下文）：
- 期限與終止：合作期限、續約機制、提前終止的條件與通知期
- 付款與價格：金額與幣別、付款節點與條件、遲延付款的處理
- 違約與救濟：什麼構成違約、救濟方式、補正期間
- 智慧財產：成果歸屬、授權範圍、背景智財的處理
- 責任限制：有沒有責任上限、除外情形、上限的計算基礎
- 保密：保密資訊範圍、保密期間、例外情形
- 管轄與爭議解決：準據法、管轄法院或仲裁安排、前置協商程序
對照表每一行的欄位設計：
| 欄位 | 填什麼 |
|---|---|
| 條款類別 | 上述七類之一 |
| 合約原文摘錄 | 節錄關鍵原句，不改寫 |
| 原文位置 | 頁碼＋條號 |
| 你方標準立場 | 來自標準範本與底線清單，由法務預填 |
| 偏差描述 | 與標準的具體差異（哪句、差在哪） |
| 偏差等級 | 與標準一致／可接受偏差／重大偏差／合約未找到 |
| 覆核狀態 | 待覆核／已覆核／有爭議 |
| 覆核者與日期 | 人工覆核後填寫 |
兩個設計要點。「未找到」是一等公民：缺少責任上限條款的合約，可能比責任上限異常的更危險——空白本身就是風險信號，絕不能留白或用範本內容補上。偏差等級只標事實（與標準差多少），風險的最終定性由覆核的法務填，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 輸出→人工覆核→遺漏反饋」的閉環。
下一步
- 合約簽署後的自動化追蹤：合規性審查與政策更新追蹤
- 合規邊界的完整框架：AI 合規與風險邊界
- 資料分級與本地方案：企業資料安全基本盤
- 同一套「標準顯性化＋逐條比對＋人工覆核」模式用在簡歷篩選：AI簡歷篩選與候選人評分系統
- 先判斷哪些環節根本不該自動化：什麼時候不該用 AI
- 想把編排流程親手搭一遍：不寫程式做出你的第一個 AI 工作流
- 員工入職時的合約簽署自動化：員工入職自動化檢查清單