用ChatGPT審閱IT服務合約：該查什麼

簡而言之： 把協議上傳上去，然後對它跑一套固定的問題清單，而不是叫它「總結一下」——哪些在服務範圍內、哪些被明確排除、「回應時間」到底是怎麼定義的、服務抵扣實際能賠多少、合約怎麼結束、以及退出時你的組態資料歸誰。二十分鐘就能把缺口翻出來。但它不會告訴你這筆交易值不值得簽。

IT服務協議是大多數中小企業買方不會認真讀的一類文件，而這個決定是出於錯誤理由做出的理性選擇。它是十四頁密密麻麻、看上去很通用的文字，業務一路都很配合，價格已經談定，而看起來可談的那幾項——費率、期間、人頭——幾週前就在信件裡談完了。剩下的部分讀起來像樣板條款。

它不是樣板條款。真正決定「出事之後會怎樣」的那些段落，恰恰是沒人讀的那些，而它們是供應商的法務寫的、為供應商寫的。這不是什麼醜聞，合約本來就是這麼運作的。不對稱只在於：一方已經讀過這份文件一百遍，另一方是第一次讀。

語言模型能以很低的成本彌合其中一部分差距。它不會告訴你一份協議是否公平，它也不是律師。它擅長的是：對著一張清單把十四頁讀完，而且讀到第九頁也不會分神——這恰恰是一個忙碌的買方晚上六點審合約時最典型的失敗方式。

那些日後要花錢的條款，以及它們為什麼讀起來像樣板

昂貴的條款很少是咄咄逼人的。它們通常只是精確到了一個讀者沒在注意的程度。

「回應時間」幾乎從來不是「修好時間」。 四小時回應SLA通常意味著有人在四小時內確認了這張工單。問題是當天解決、當週解決、還是根本沒解決，往往隻字未提。這一個定義上的缺口，是「我們明明有SLA，結果還是拖了三天」這種對話最常見的來源。

排除條款比服務範圍清單更能決定結果。 服務範圍那一節是業務給你看的。而排除清單——第三方軟體故障、任何涉及原廠自己支援佇列的事、佈線工程、「因客戶自備設備引起的問題」——才決定你實際的帳單。任何被排除的東西都會落到一張費率表上，而那個費率你多半從來沒跟別家比過。

服務抵扣通常比事故本身小得多。 常見結構是把抵扣上限設為一個月費用的某個百分比。如果一天停機對你造成的損失明顯高於這個數，那麼這份抵扣就不是補救，而是一個姿態。這件事值得事前知道，而不是事後。

自動續約加上一個很長的通知期，是一筆實打實的成本。 十二個月期間、自動續約、需提前九十天書面通知才能終止：錯過這個窗口一週，你就又買了一年。簽字當天就把通知日期記進行事曆。

退出交接是一項服務，而服務是要收費的。 誰來匯出文件、移交管理員憑證、轉移RMM租戶、提供資產清冊——費用由誰承擔？如果協議對此沉默，那麼在一段糟糕的分手時刻，答案就是「按我們的標準時薪，等我們排得開再說」。

跑一套結構化審閱，而不是「總結這份合約」

叫它總結，你就得到一份總結——一份流暢、準確、毫無用處的、關於這份文件如何自我描述的複述。價值在於追問，而追問來自兩個習慣：問固定的問題，以及問缺了什麼。

每次都值得跑一遍的問題清單

把文件給模型，並給它一個明確的角色：你是在代表客戶方審閱這份文件，你的任務是找出客戶的預期與白紙黑字之間的分歧在哪裡。然後一條軸一條軸地過，而不是一次全問。

服務範圍與排除。 讓它列出所有明確包含的服務、所有明確排除的服務，以及——最有用的那一項——所有一個理性的委外IT買方可能預設包含、但文件裡正反兩面都沒提過的事項。爭議就住在沉默裡。

SLA機制。 讓它原文引用回應時間、解決時間、嚴重等級、上班時間的確切定義，以及非上班時間會怎樣。問清楚：判定SLA是否達成的證據是什麼、由誰來量測。「以服務商的工單系統為準」是一個站得住腳的答案，但你應該知道這就是答案。

錢。讓它列出所有可能產生月費之外收費的情形——範圍外工作、最低出勤費、差旅、非上班時間倍率、專案制工作、年度調漲、匯率條款。

期間與退出。 讓它給出期間、續約機制、通知期、雙方各自的任意終止權，以及服務商在退出時必須交付什麼。

資料與存取權。 誰擁有文件、資產清冊、監控組態和備份；合約結束時你的資料會怎樣；以及服務商對你的租戶持有什麼樣的管理員存取權限。

有兩個技巧決定了這是個新鮮玩意兒還是一次真正管用的審閱。要求原文引用，而不是概括——每一條發現都應當附上條款原文，因為模型在轉述合約時會漂移，而一句引文幾秒鐘就能核對。以及，要求列出你所承擔的義務，而不是供應商的。買方讀的都是供應商的承諾；而「客戶義務」條款裡悄悄躺著「客戶應為所有在保硬體維持有效的原廠支援」，緊挨著的是一條「若未做到則SLA失效」。

用同一組維度比較兩家供應商

這正是這套方法回本的地方。兩份委外服務提案按原文幾乎從來不可比，因為它們用同樣的詞指著不同的東西，而且定價結構是故意做得不一樣的。

分別對每份文件跑同一套問題清單，然後要求按你抽取出來的維度做一份並排對照。一定要讓它標出兩份協議對同一個術語定義不同的地方——一家的「P1」可能要求服務完全中斷，另一家的可能包含某位高階主管的一台筆電。這個差別的價值遠高於每個席次幾塊錢，而且在有人把定義並排放好之前，它是看不見的。

一個實際例子——一份標準委外服務協議裡的三處發現

一家120人的製造企業，香港有辦公室、深圳有工廠，正準備簽一份區域性委外服務協議。文件十五頁外加兩個附件，是一家有能力的服務商出的、正常且並不過分的合約。

發現一：回應SLA其實是確認SLA。 附件A把P1回應定義為一小時，而全文根本沒有定義解決時間。這不稀奇，也不一定是問題——但買方一直在跟董事會說關鍵問題會「在一小時內修好」。修正只需要加一行：給P1一個目標解決時間，或者明確寫清解決屬於盡力而為。兩者都行。相信錯的那個則不行。

發現二：上線在範圍內，移轉不在。 服務範圍清單裡寫著「上線與轉換」。排除附件裡排除了「資料移轉及因前任服務商的組態而引起的任何工作」。這兩條條款描述的是同一段八週的工作，而客戶對「自己買到了什麼」的心理模型，完全是由前一條塑造的。

發現三：通知窗口比續約提醒還長。 自動續約，九十天通知。而買方的採購行事曆把年度供應商複核提醒設在了到期前六十天。錯過窗口這件事，早就被排進日程了。

這三條都不能證明這是一家糟糕的供應商。三條都是值得在簽字前問、而不是在事故中問的問題，而且三條都是二十分鐘對著清單過一遍出來的。模型沒有做到的是：告訴他們價格是否合理、該選哪一家，或者管轄法律條款在兩個法域之間是否可執行。那些是不同的問題，答案也不同。

AI輔助合約審閱 vs 商務律師 vs 直接簽範本

成本與周轉 — AI輔助審閱完勝。二十分鐘一遍，邊際成本幾乎為零，而且是在你真正拿到文件的那一刻就可用。
找出定義缺口和內部前後矛盾 — AI輔助審閱勝出。把SLA附件、排除附件和正文三者互相比對，是機械性的閱讀工作，而模型正擅長機械閱讀。
可執行性、管轄權與責任上限 — 商務律師勝出，而且差距很大。一條責任限制條款在香港、新加坡還是中國大陸能否站得住，是一個關於特定法域的法律問題，不是閱讀理解問題。
談判籌碼與市場慣例 — 律師或有經驗的IT顧問勝出。知道哪些條款服務商通常會讓步，來自談過很多份這類合約，而這不在文件裡。
建議出錯時誰來負責 — 律師絕對勝出。專業意見附帶專業責任。一段對話紀錄什麼都不附帶。
不讀就簽範本 — 只在速度上勝出，而這正是多數中小企業的做法。這也是為什麼這類對話往往發生在事故之後而不是之前。

對多數中小企業買方而言，現實的順序並不是在三者之間選一個。而是：用模型生成一份簡短、具體的問題清單，其中大部分直接跟供應商談掉，只把剩下的拿去問律師——這可比「請幫我審一下這份合約」便宜太多了。

這不是法律意見，而且這個區別不是一句免責聲明

值得把這個差別說精確，因為「不構成法律意見」通常被當成一句客套。

模型讀的是擺在它面前的文字。它可以告訴你第11.3條把責任上限設為三個月費用，而且考慮到你陳述的風險曝險，這個上限是有實質影響的。它沒法告訴你這個上限在第19條指定的管轄法律下是否成立、該法域的法院是否曾經收窄過類似條款，或者第12條的賠償條款與你的保險如何相互作用。這些取決於文件之外的法律與判例。

它對籌碼也沒有判斷。你能不能改掉一條條款，取決於服務商有多想要這單、現在是哪個季度、以及你還有什麼替代方案——這些都不在紙面上。

把產出當成一份問題清單，而不是一份裁決。這個定位不是謙虛，而是對你手上東西的準確描述。

把這件事做對——商業保密、保密協議，以及什麼時候該讓IT介入

在你上傳任何東西之前，有三點實務問題。

先確認這份文件是否禁止你正要做的事。 很多協議草案、以及幾乎所有保密協議，都限制把內容揭露給第三方。把文件送進一個AI服務算不算揭露，取決於措辭，也取決於該服務的條款——一個帶有合約化資料處理承諾的商業版或企業版，與一個消費級帳號是實質不同的處境。在你審這份合約之前，先讀它的保密條款，並核實你實際所在方案當前的資料保留與訓練條款，而不是想當然。

去掉你不需要的東西。 這套審閱依據的是結構和定義，不是身分。供應商名稱、你方法人實體名稱、具體聯絡人，有時還包括價格，都可以換成佔位符，而不會削弱任何一條發現。

技術附件才是非技術買方翻車的地方。 修補窗口、備份的RPO與RTO、在保設備數量以及超出後會怎樣、監控涵蓋範圍、以及「客戶自備設備」的排除——這些都是穿著技術外衣的商務條款。應該由真正管過IT資產的人來讀，而這套紀律——明確的交付項、明確的排除項、可度量的驗收標準——正是一份寫得好的IT工作說明書存在的意義。我們的AI+支援與委外IT支援則分列它的兩側。自2007年在北京創立以來，Brocent一直在亞洲各地撰寫並履行這類協議，總部設於新加坡，2016年起在香港設有辦公室——其中偶爾也包括客戶拿這套清單來審我們自己的文件。一家願意把「你該問什麼」公開出來的供應商，是在做一個自己必須兌現的承諾。同樣的「審問文件」套路，也值得和用AI審閱財務模型一起讀。

常見問題

把一份受保密協議約束的合約上傳給AI工具，算違約嗎？

有可能，而答案就在文件裡。保密條款通常限制向第三方揭露，有時會給「承擔同等義務的專業顧問與服務提供方」留一個例外口子。一家AI廠商是否落入這個口子，取決於該條款，也取決於該廠商針對你所在方案的合約條款。如果這份協議敏感，就用帶資料處理承諾的商業版或企業版、把可識別資訊去識別化，或者直接問對方——問一句並不示弱。

AI能發現缺失的退出或終止條款嗎？

能，而且「缺失」正是它最有用的地方——前提是你直接問。模型回答「這份文件有沒有處理X」要比自發注意到「X不見了」強得多。給它一份「這類完整協議通常會涵蓋什麼」的清單，然後問哪些項沒有被處理。這個換問法把一個難任務變成了一個容易的任務。

這能取代商務律師嗎？

不能。它取代的是「根本沒人讀這份合約」的那個版本——而那才是多數中小企業的現實替代方案。用得好，它反而讓請律師更便宜：你不是拿著「請審一下這份協議」去，而是帶著六條具體條款和每條對應的一個問題去。

SLA裡我們應該堅持哪些定義？

至少要有：回應與解決的書面區分；按業務衝擊而非按服務商判斷來定義的嚴重等級；寫明的上班時間以及非上班時間的明確處理方式；以及一個指明的量測來源。至於你是否還需要一個解決時間承諾，取決於停機對你實際值多少錢——而這個數字，值得在談判之前就先算出來。

怎樣公平地比較兩份MSP報價？

從兩份文件裡抽取同樣的維度——範圍、排除、SLA定義、所有可能產生收費的情形、期間與退出、資料歸屬——然後比較維度，而不是比較提案本身。特別留意兩份文件都在用、但定義不同的術語。每席次單價是最容易比的東西，卻很少是決定總成本的東西。

它能處理掃描件PDF或者雙語合約嗎？

掃描件需要先有可靠的文字擷取；一份糟糕的掃描會產出自信滿滿的胡話，所以要抽查幾條條款，把擷取出來的文字和原件對一對。雙語協議在本地區很常見，通常會指定其中一種語言為準。先讓模型找出那條「以何種語言為準」的條款，然後審閱為準的那個版本——並且把它發現的兩版之間的任何差異當成一個要問供應商的問題，而不是一個結論。

從哪裡開始

拿你上一次簽的那份協議來試，而不是眼前這份。你已經知道那段合作關係後來怎麼樣了，所以你等於白得一次方法準確性的檢驗——而如果審閱正好翻出了那件讓你彆扭了一年的事，你就知道續約時該提什麼了。如果它產出的問題最後都是關於範圍和排除，而不是法律風險，那這就是一場IT對話而不是法律對話，而這樣的對話我們很樂意談：聯絡我們。