為爭議處理團隊而設的個案審閱系統

想像一個 12 人爭議處理團隊，同時處理六宗進行中的商業爭議事項。

每宗事項都有一位合夥人、一位資深律師、兩三位初級律師，並由法律助理和營運同事共同支援。團隊已經有文件管理、電郵、日曆、工時紀錄、工作清單和事項筆記。問題不是沒有人掌握資料。問題是每次個案審閱會議，都要有人從太多地方重新拼合背景。

每逢星期五，合夥人想知道有甚麼改變、哪些期限正在推近、仍欠哪些證據、哪些客戶承諾仍未完成，以及下一步之前有哪些事項需要判斷。一般 AI 助手可以摘要文件，但這並不足夠。團隊需要圍繞審閱節奏的一套基礎設施。

這正是 Proximity 可以被調整成個案審閱系統的地方。

目的不是自動化法律判斷。目的，是令審閱會議準備得更好、更有來源依據，並減少依賴某一位剛好有時間整理會議包的人。

工作流程

這個工作流程，是為進行中的爭議事項做每週個案審閱。

團隊需要對每宗事項有一個可重複使用的視圖：

• 自上次審閱後有甚麼改變。
• 哪些期限、提交事項和客戶承諾即將到期。
• 哪些文件、往來通訊或筆記支持目前立場。
• 哪些問題仍在等待證據、指示或內部審閱。
• 哪些草稿已準備好交由律師審閱。
• 哪些跟進已逾期或仍然不清楚。

聽起來簡單，但爭議處理工作很少只存在於一個系統裏。一個關鍵點可能在電郵內。程序期限可能在日曆上。客戶指示可能在通話紀錄裏。證人相關重點可能在草擬中的時序表。某個疑慮可能曾在聊天工具提出，卻從未加入事項筆記。

Proximity 不會取代正式事項紀錄。它會連接圍繞事項的營運背景，讓團隊能較順暢地準備和審閱。

對爭議處理、仲裁或商業訴訟團隊而言，這種背景整理本身就是實務工作的一部分。正式文件可能在文件管理系統，程序期限可能在日曆，客戶指示可能在會議筆記或電郵，證據問題可能散落在時序表和草稿裏。每項資料單獨看都有用，但每週審閱需要的是可追溯、可檢查、可分工的整體狀態。

因此，系統支援的是審閱節奏，而不是一次性的文件摘要。它應幫助團隊看見同一宗事項自上次審閱後有甚麼改變、哪些點仍缺證據、哪些承諾仍未履行，以及哪些事項已準備好交由合夥人或負責律師判斷。

Proximity 會建立甚麼模型

在這個部署中，Proximity 會以「事項」作為核心容器。

系統會連接經批准的來源，例如：

• 文件管理紀錄。
• 事項筆記和時序表。
• 相關電郵討論串。
• 日曆期限和審閱日期。
• 工作負責人和跟進承諾。
• 客戶指示和會議筆記。
• 等待審閱的草稿。

有用的模型，不只是「關於這宗事項的所有文字」。它是結構化的營運背景：

• 事項、客戶、對方、階段和負責律師。
• 來源文件、版本、日期和保密狀態。
• 未解決問題、負責人、來源證據和下一次審閱日期。
• 期限、依據、負責人和信心水平。
• 草稿、審閱人、審閱狀態和未解問題。
• 客戶承諾、來源、負責人和到期日。

這一點重要，因為法律工作高度依賴證據，也高度依賴責任分工。American Bar Association 的 Model Rule 1.1 將稱職代表描述為需要具備該工作合理所需的法律知識、技能、周全程度和準備。ABA 關於生成式 AI 的 Formal Opinion 512 亦強調稱職、保密、溝通、監督、坦誠和費用等責任。這些責任由律師履行，不是由軟件履行。軟件只有在令準備和監督更容易執行時，才真正有幫助。

把事項建模成結構化背景，亦能避免「看起來完整」的風險。一般摘要可能把多個來源揉成一段流暢文字，但爭議工作需要知道每一點來自哪裏、是否最新、是否已審閱、是否受保密或特權限制，以及是否只是某人的假設。Proximity 應保留這些分別，而不是為了易讀而抹平。

例如，同一句「對方同意延長期限」可以有完全不同的狀態：它可能來自正式命令、律師之間的保密通訊、會議中未確認的口頭討論，或初級律師在筆記中的理解。系統如果不能顯示來源和狀態，就不能安全地支援審閱。

系統會準備甚麼

每次每週審閱之前，Proximity 可以準備一份事項審閱包。

審閱包會包括：

• 自上次審閱以來的變更摘要，附來源連結。
• 期限和承諾清單，列明負責人和證據。
• 欠缺背景部分，標示仍未清楚的事實、文件、批核或指示。
• 草擬時序表更新，並清楚標示為草稿。
• 需要律師注意的文件或通訊審閱佇列。
• 跟進清單，顯示承諾了甚麼、由誰負責，以及有甚麼證據支持。

系統亦可以在會議前為合夥人準備簡報筆記。這些筆記應該把已確認事實、未決問題和假設分開。每一點都應顯示來源。如果某一點沒有獲經批准的事項紀錄支持，就應標示為欠缺或不確定。

這就是把 source grounding 應用在個案審閱上。輸出有用，是因為它減少搜尋時間，並暴露缺口。它有用並不是因為模型有自己的法律觀點。

審閱包亦應把「已確認」、「待核實」和「需要判斷」分開。已確認事實可以連到文件或正式紀錄；待核實事項可能需要追客戶、追對方律師或查閱原始文件；需要判斷的問題則應交由律師決定，例如證據是否足夠、策略是否應改變、某個草稿是否可以發出。這種分類比單純摘要更重要，因為它直接影響會議如何分配時間。

對合夥人而言，會前簡報的價值不應只是「更短」。它應讓合夥人快速看見哪些問題已準備好審閱、哪些仍欠材料、哪些承諾可能影響客戶期望，以及哪些期限需要即時處理。對初級律師而言，系統亦能把跟進責任和來源證據放在同一處，減少靠記憶追蹤。

甚麼仍然由人負責

法律意見仍然由人負責。

系統不得決定訴訟策略、向客戶提供建議、批准通訊、判斷特權保密、提交文件、提出法律論點，或決定證據是否足夠。未經人手審閱，它亦不應發送客戶通訊或更新正式事項立場。

合夥人和律師仍然負責：

• 法律分析。
• 專業判斷。
• 策略。
• 客戶建議。
• 最終措辭。
• 特權和保密決定。
• 批核和提交。
• 任何對外溝通。

Proximity 的角色是基礎設施。它在專業工作發生之前，先把房間準備好。

這條界線亦會影響產品設計。草稿需要標籤。審閱包需要來源。欠缺證據要保持可見。敏感材料需要能理解事項背景的權限控制。ABA Model Rule 1.6 關於保密的規定，是一個有用提醒：資訊邊界是專業系統的一部分，不是可有可無的保安功能。

因此，Proximity 不應把草稿改寫成像最終法律意見，也不應把未經核實的來源推成結論。它可以標示「這裏可能欠客戶指示」或「這個期限的依據未在批准來源中找到」，但是否需要向客戶追問、如何表述法律風險、是否改變策略，都仍由律師負責。

權限亦要跟事項背景一致。同一團隊內，不同人未必應看到所有文件、特權材料或敏感客戶資訊。系統如果只是把所有內容集中做摘要，反而可能製造保密風險。較好的設計，是在保持來源連結的同時，尊重既有文件權限和事項牆。

試點形態

一個合理試點，可以由兩宗進行中事項和一個審閱節奏開始。

第一週會梳理現有審閱流程：筆記在哪裏、誰準備會議、哪些來源具權威性、哪些期限重要，以及合夥人想看到甚麼。第二週會連接一組較窄的來源，並產出第一份審閱包。第三和第四週，則根據團隊實際使用審閱包的方式，調整分類、欠缺背景標示和審閱佇列。

試點不應衡量 AI 能否「做法律工作」。它應衡量團隊進入審閱時，是否擁有更好的背景。

有用的成功訊號包括：

• 較少時間花在組裝審閱筆記。
• 較少遺漏跟進。
• 審閱重點有更清楚的來源連結。
• 更容易看見欠缺的指示或證據。
• 律師之間的事項交接更一致。
• 合夥人認為審閱一開始已更接近真正問題。

試點還應觀察會議質素是否改變。如果團隊只是更快產生摘要，但會議仍花大量時間追問「這點從哪裏來」、「誰承諾過」、「文件是否最新版」、「客戶有沒有確認」，就代表系統仍未真正做到 evidence-aware。成功的部署，應讓會議更快進入法律和策略判斷，同時令欠缺證據和未完成跟進更難被忽略。

試點範圍亦應刻意限制。選兩宗活躍事項，比一次過接入所有爭議工作更容易驗證價值。團隊可以先定義哪些文件和筆記是權威來源、哪些材料受權限限制、哪些輸出只可作草稿，然後用四星期觀察審閱包是否真正減少準備時間和遺漏跟進。若這些基礎未清楚，加入更多 AI 功能只會放大混亂。

團隊亦應要求系統保留律師修正。若某項期限被錯誤理解、某段通訊不應被引用、某個草稿狀態已改變，負責律師的更正應成為下一次審閱的來源。法律工作需要的不只是初步整理，而是可被專業人士持續校正的事項記憶。

這種校正紀錄亦有助監督初級同事和外部支援，因為每次修正都能回到具體來源和責任人，而不是只留在口頭提醒中。長遠而言，事項記憶會更穩定：團隊不是讓 AI 生成一次會議材料後就忘記，而是在每次審閱、修正和跟進中，逐步建立更可靠的工作狀態。

這仍然不改變文章的核心界線。系統可以令準備工作更完整、更有證據和更容易監督，但法律判斷、策略和客戶建議仍然要由具名律師承擔。試點若能證明這條界線清楚，才值得擴大。

換句話說，好的試點會讓團隊更早看到問題，而不是讓系統更快給出法律答案。這正是 evidence-aware AI 在法律工作中的合理位置。

如果這個位置被守住，AI 帶來的是更好的準備、更清楚的來源和更穩定的跟進，而不是對專業責任的轉移。