AI 合同審查：先標風險，再讓法務簽字
AI 合同應用不只是總結合同，而是把合同型別、條款、義務、風險規則、審批和審計做成後設資料，讓 AI 標風險、法務確認責任。
先給結論：AI 合同應用的價值不止“總結合同”，而是把合同型別、條款、義務、風險規則、審批和審計做成後設資料——AI 先看一遍、標出風險，但最後拍板的仍是法務。
“合同審查能不能先交給 AI 看一遍？”
這個問題背後，不是想讓 AI 替代法務，而是想解決一個很現實的協作困境：業務等合同，法務排隊看合同，審批人只看到一個附件和幾個欄位，真正的風險藏在幾十頁條款裡。
傳統合同管理系統通常擅長管臺賬：合同編號、甲乙方、金額、簽署日期、到期時間、附件。可一旦進入“審查”，系統就經常退化成檔案流轉。風險由法務人工讀，意見寫在批註裡，審批人再憑經驗判斷。
AI 原生的合同風險應用應該把合同從附件變成結構化業務物件。它能讀合同，但更重要的是能把讀取結果落到條款、義務、風險、審批和例外規則上。
你可以對平臺說：
幫我搭建一個 AI 合同風險應用。它要管理銷售合同、採購合同和保密協議；AI 自動抽取合同主體、金額、期限、付款、違約、資料安全、自動續約和責任限制條款；非標條款要生成風險意見，超過授權範圍的合同進入法務和財務審批；AI 只能給建議，最終審查意見由法務確認。
平臺生成的不是一個合同摘要工具，而是一套合同風險協作應用。
合同場景為什麼不能只做“文件問答”
合同確實適合 AI 閱讀，但如果只把合同丟給模型問“有什麼風險”，很快會遇到三個問題。
第一，風險標準不統一。什麼叫高風險？付款週期超過 90 天算不算？自動續約算不算？責任上限低於合同金額算不算？這些判斷必須來自企業規則，而不是模型臨場發揮。
第二，審查動作需要留痕。誰上傳了合同，AI 抽取了什麼，法務改了哪些意見，審批人為什麼通過，這些都要能審計。
第三，合同和業務物件有關。一個條款是否異常，要看客戶等級、合同型別、金額、行業、歷史模板和授權政策。AI 不能只讀檔案，它還要讀業務上下文。
所以 AI 合同應用必須後設資料驅動。文件只是輸入，最終要形成物件、欄位、規則、流程和可追溯動作。
用自然語言生成合同審查模型
第一輪搭建時，平臺應該生成這些核心物件：
| 物件 | 作用 |
|---|---|
contract | 合同主記錄，包含型別、主體、金額、狀態、負責人 |
contract_party | 合同方、簽約主體、聯絡人、資質資訊 |
contract_clause | AI 抽取出的條款分類、原文位置、摘要和標準匹配 |
contract_risk | 風險等級、原因、建議處理方式和責任人 |
obligation | 付款、交付、保密、續約、通知等履約義務 |
review_decision | 法務、財務、業務審批意見和確認記錄 |
這些物件讓合同審查從“讀一個附件”變成“處理一組結構化風險”。
例如 AI 發現合同裡有自動續約條款，系統不應該只在摘要裡寫一句。它應該建立一條 contract_clause，標記型別為“自動續約”，關聯原文位置；再根據公司政策生成一條 contract_risk，提醒是否需要業務確認；如果續約通知期限小於 30 天，還應該建立後續提醒義務。
這就是 AI 原生應用和普通文件助手的差別：理解結果會進入業務系統。
搭建後繼續用自然語言調整規則
合同規則經常隨著管理要求變化。法務負責人可以直接說：
以後所有包含“無限責任”的合同都標為高風險，並且必須由法務總監審批。
平臺應把這句話轉成條款識別規則、風險等級規則和審批流程變更。
財務也可能說：
付款週期超過 60 天的銷售合同，自動提示現金流風險；超過 90 天必須財務審批。
這會生成付款條款抽取規則、風險提示、審批條件和財務檢視。
業務負責人可能補充：
戰略客戶可以接受 90 天賬期，但必須在合同裡標記例外原因。
這會引入例外規則：不是簡單攔截，而是要求填寫原因、指定審批人、記錄授權依據。
自然語言搭建不是讓業務人員寫提示詞，而是讓規則變化能落到可執行的後設資料裡。
法務和業務如何在應用中對話
合同上傳後，業務人員可以問：
這份合同有哪些需要我處理的風險？
AI 應該回答業務相關的問題，而不是把所有法律細節都堆出來：
- 付款週期為 90 天，超過預設政策，需要財務確認；
- 客戶要求 99.9% 可用性承諾，需要產品和交付評估；
- 合同包含自動續約，需確認續約提醒責任人；
- 責任限制低於標準模板，建議法務複核。
法務可以繼續問：
和我們標準銷售合同相比，哪些條款偏離最大？
AI 應基於合同模板、條款庫和歷史審查意見生成差異清單，並把每個差異關聯到原文位置和建議動作。
審批人則可以問：
為什麼這份合同需要我審批？如果通過，有哪些後續義務？
這類問題最能體現應用價值。審批人不再只看一個附件，而是看到清楚的風險原因、例外依據和履約任務。
AI 可以先看，但不能最後拍板
合同是高風險場景，AI 的角色必須設計得清楚。
AI 適合做：
- 合同資訊抽取；
- 條款分類和模板比對；
- 風險初判和原因解釋；
- 審查意見草稿；
- 履約義務提取；
- 到期、續約、付款和通知提醒。
AI 不應該獨立做：
- 最終法律意見；
- 高風險條款豁免；
- 合同簽署承諾；
- 授權範圍外的審批通過；
- 對外發送未經確認的法律文本。
所以應用中每個 AI 動作都要有狀態：草稿、待確認、已確認、已駁回、已執行。每一步都應記錄來源、模型輸出、人工修改和最終責任人。
這不是束縛 AI，而是讓 AI 可以進入真實合同流程。
第一版應該怎麼搭
一個可落地的 AI 合同風險應用，可以從四個能力開始。
第一，合同臺賬和上傳入口。先讓合同型別、主體、金額、狀態、負責人和附件進入統一物件。
第二，AI 抽取和風險初篩。抽取關鍵條款，生成風險卡片，但不自動給最終意見。
第三，法務確認和意見沉澱。法務修改 AI 風險意見，形成企業自己的條款經驗庫。
第四，審批和履約閉環。高風險合同進入審批，簽署後生成付款、續約、交付、保密等履約任務。
這條路徑不要求一開始就覆蓋所有合同型別。先從銷售合同或採購合同中的高頻風險開始，規則會隨著使用逐步長出來。
ObjectStack 的價值：把合同讀懂後變成業務動作
AI 合同應用最怕停留在“讀文件”層。讀完以後，如果風險不能進入審批，義務不能進入任務，例外不能進入審計，知識不能沉澱成規則，價值就會很快耗盡。
ObjectStack 的後設資料驅動方式，讓自然語言搭建可以直接生成合同對象、條款物件、風險規則、審批流程和 Agent 工具。業務人員和法務人員繼續用自然語言調整規則、追問風險、確認意見，應用則負責把這些對話落到受控記錄裡。
所以，合同確實可以先交給 AI 看一遍。但真正重要的是：AI 看完以後，風險要能被管理，意見要能被確認，義務要能被執行，責任要能被審計。