签字前如何用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对话而不是法律对话，而这样的对话我们很乐意谈：联系我们。