企業法務真正面對的量能問題
企業法務的難處通常不是合約很難，而是大部分都不難，但數量多到這件事幫不上忙。
NDA、供應商合約、採購條款、SOW、續約通知從公司各單位一起進來，用對方版本的機率不比用自家範本低。多數平淡無奇，少數藏著要命的東西：沒有上限的補償責任、應該是授權卻寫成讓與的智慧財產權條款、一次自動續約三年、事先問絕不會同意的準據法。平凡的與危險的排在同一個佇列裡，從外觀上看不出差別。
由此產生兩種狀況，而且通常同時存在。一是塞車：法務變成瓶頸，業務單位等不及，最後某個主管沒送法務就簽了。二是拉平：為了消化件數，全部都只做同樣深度的粗看，結果是平淡的合約被過度關注，真正危險的那一份得到的注意力也不會更多。
加人只解決佇列，不改變結構。改變結構的做法是事先把「什麼可以接受」定下來，讓閱讀只發生在答案還不確定的地方。
以操作角度說明什麼是法律 playbook
Playbook 是把團隊的立場寫下來，寫到一個沒有參與當初決策的人也能照著判斷的精確程度。
每一類條款要寫三件事：最想要的版本、不必往上呈報就能接受的範圍、以及過了哪一條線就是不行。以責任限制為例，一則條目會寫出希望的責任上限、對小額供應商可接受的較低上限、無論如何都必須排除在上限之外的項目，以及完全不能設限的類型（例如資料外洩、智慧財產權侵權）。每一則最好連建議回覆的替代文字一起寫，因為談判的人需要的是一句可以直接送回去的句子，而不只是一個標準。
多數團隊其實已經有 playbook，只是散在資深律師的腦袋、範本資料夾與過往談判的記憶裡。把它寫下來就是主要的工作，而這是法律工作，不是軟體工作。寫的過程會逼出從沒解決的內部分歧、為了一個公司已經不再是的樣貌而訂的立場，以及一些老實說「要看情況」、應該保留給人判斷的條款。
自動化是在這之後才可能。工具能套用 playbook，但生不出 playbook。期待軟體從過去的合約反推出風險胃納，等於要它把過去的不一致複製一遍。
自動紅線標記：什麼由系統分堆、什麼往上呈報
自動審閱靠的是比對，不是理解。它辨識合約裡有哪些條款、分類、逐條對照 playbook，然後分成三堆：符合、在可接受範圍內偏離、超出範圍。
價值在分堆，不在紅線本身。一位審閱者打開合約時已經知道十一條符合、三條可接受、一條超出政策，跟從第一頁開始讀的人做的是不同的工作。系統產出的修訂文字是初稿，有用是因為那些替代文字本來就要有人打，而不是因為工具替你決定了什麼。
有兩種失誤要先想好。缺漏比寫壞更難處理：逐條比對的工具可能讓一份完全沒有責任限制條款的合約直接通過，而這通常比一個不好的上限更糟——playbook 除了檢查內容，也要檢查有沒有。另一種是非典型寫法會讓分類失效：義務被拆散寫在三個不相干的句子裡，或是定義條款悄悄改寫了「機密資訊」的範圍，條款層級的比對抓不到。
由此得到的設計原則是：呈報路徑比準確率重要。標記過多的系統還救得回來，默默放過自己看不懂的東西則救不回來。優先選會誠實回報「這一段我無法分類」的工具。
跨國條款與自動化的邊界
Playbook 自動化的前提是答案可以事先訂好。跨國案件正是這個前提開始失效的地方，值得把原因講清楚。
有一部分確實是機械性的，也適合交給工具：辨識準據法與管轄條款、發現沒有仲裁條款、確認個資保護條款引用的是正確的法規、指出某份為某一法域撰寫的範本被直接套用到另一個法域。這些屬於「有沒有、一不一致」的檢核，交給系統是合理的。
不能自動化的是：這個條款在實際會發生爭訟的地方是否有效、是否明智。這取決於當地法律、當地法院過去如何處理類似條款，以及商業關係本身。工具若直接給出特定法域的結論，等於做了它撐不住的主張；而標記「這個條款是為另一個法域寫的，請洽當地律師確認」，做的才是有用的那一半。
比較誠實的說法是：自動化改變的是哪些案件會送到具備資格的律師手上，而不是還需不需要律師。在跨國合約組合裡，實際的目標是——每一份需要當地意見的合約都被辨識出來，其餘的不必經過。這是分流問題，而分流正是軟體擅長的事。