法律AI落地关键：从合同审阅到法律研究的工程化实践

Gemini Enterprise for Legal 这条消息，真正值得法律从业者关注的不是“AI 又进步了”，而是它把目标放在了合同审阅和法律研究这两个最消耗人力的环节上。律师的日常工作里，很大一部分不是出庭，而是读合同：几份采购合同、保密协议、合作框架，都要逐条看过去。哪怕执业多年的律师，也很难保证自己在十几份合同之间切换时，不会漏掉某个藏在附件的赔偿上限条款。AI 进入法律行业喊了很多年，从文档模板到条款库，从规则引擎到自然语言处理，工具层出不穷，但真正改变律师工作流的很少。Gemini Enterprise for Legal 的出现，也许能让这个局面发生一点变化。

我对这条消息的判断是：它真正有价值的点，不在某个合同能被 AI 看一遍，而在于把法律工作中最消耗人的两块——合同审阅和法律研究——从一次性任务变成了可复用、可追踪、可协作的流程。换句话说，它想解决的不是“更快地完成一次任务”，而是“让整个法律工作流变得可以被系统性地管理”。这个定位，和过去那些单点工具完全不同。

1. 为什么法律 AI 一直“看起来有用，真正用起来却很难”

1.1 过去法律 AI 卡在“单点功能”，而不是“完整流程”

过去十年，法律科技领域一直在尝试用技术替代部分法律工作。最先落地的是文档模板和条款库，把过去散落在硬盘里的 Word 文档变成可检索的资产。接着是合同管理系统，解决了版本混乱、审批流程不清的问题。再后来，规则引擎被引入，可以对合同做简单的逻辑校验，比如某个字段缺失、某个日期和另一个日期冲突。这些工具都有用，但它们都有一个共同的问题：解决了单点问题，却没有改变一个律师从头到尾的工作流。

合同管理系统管住了版本，但风险条款还是要人一条条看。搜索数据库能检索判例，但结论归纳和法律推理还是要人自己完成。规则引擎可以检查“有没有填”，但做不到“这句话背后有什么风险”。单点工具很多，完整工作流很少。这也是为什么很多律所花了几十万上系统，律师还是觉得“不如自己看”的主要原因。

1.2 这次的变化：从对话助手走向工作流入口

Gemini Enterprise for Legal 的不同之处，在于它的产品定位不是又一个“法律 AI 助手”，而是试图成为一个能嵌入现有工作流的入口。从项目标题看，它强调的是“Enterprise for Legal”，这个“Enterprise”比“Legal”更重要。Enterprise 意味着它考虑的是组织级的使用方式：权限、审计、团队协作、知识沉淀，而不只是一个人一个对话框。法律部门的日常工作，本质上是一个需要多人协作、多轮修改、严格留痕的流程。过去的 AI 工具往往只解决其中一环，Gemini Enterprise for Legal 想做的事情，更像是把合同审阅时用到的读取、分析、标注、摘要、复核、版本对比，都放进同一个体系里。

这种变化背后有一个很现实的原因：法律行业不缺知识，缺的是把知识快速转化为判断的通道。一个初级律师每天花大量时间做的事，并不是去理解非常复杂的法律问题，而是在大量文本里抽取关键信息、比对前后差异、查找可能的风险点。这些工作过去靠的是人工阅读和时间堆积，本质上属于一种“隐性重复劳动”。大模型最适合的恰恰就是这个环节。

1.3 对使用者来说，真正难的不是学模型，而是改习惯

技术产品落地最难的从来不是技术本身，而是使用习惯。律师的时间颗粒度很细，要求的是确定性。如果一个 AI 工具给出的结果每次都不一样，哪怕它 90% 的时候是对的，律师也不敢用它来辅助正式工作。Gemini Enterprise for Legal 如果希望被长期使用，就必须在输出稳定性、可解释性和复核路径上做足够的工程化。从目前的产品定位看，它更像是在做“AI 辅助人工复核”的流程，而不是“AI 全自动完成审阅”。这是更务实的做法。

我个人的判断是：用这类工具，最合理的姿势不是指望它替代人，而是让它把原本需要三个小时的流程压缩到三十分钟，然后把节省下来的时间投入到真正需要法律判断的部分。

2. 合同自动化：把“审合同”变成一条可复用的流水线

2.1 合同工作的真实构成：审一份合同不等于读一遍

在讨论“合同自动化”之前，必须先拆解一下律师审合同时到底在做什么。很多人以为审合同就是通读一遍，看看有没有明显问题。实际上，一份合同从拿到手到给出修改意见，通常包含这些动作：

• 识别合同类型和核心条款：这是采购合同、保密协议、合作协议，还是股权转让协议？
• 检查主体信息：甲乙双方名称、统一社会信用代码、地址、联系人是否完整一致。
• 核验关键商务条款：金额、付款节点、交付时间、违约责任、赔偿上限、期权、保密期限。
• 比对版本差异：上一版和这一版改了什么，有没有人悄悄删掉一个重要条款。
• 查找风险条款：比如单方终止权、无限责任、争议解决地对己方不利、知识产权归属不清。
• 给出修改建议：不只是指出风险，还要给出可操作的修改措辞。
• 留痕和归档：修改记录、审批记录、最终版本，都要能追溯。

在这些动作里，真正需要“法律智力”的其实只有最后一条——给出修改建议。前面几条，哪怕没有接受过法律训练，经过短期培训也能完成。这就是为什么法律 AI 有巨大的应用空间，因为大量的初级律师工作时间，其实消耗在这些“规则性强、但文本量大”的任务上。

2.2 一个可落地的合同自动化流程

从产品定位来看，一套典型的合同审阅流程可以设计成这样：上传合同之后，系统先对文档做基础解析，区分出封面、正文、附件、签字页；然后抽取合同主体、金额、时间、付款条件、违约责任等关键字段；接着把条款按类型拆成若干块，逐块匹配风险规则；最后生成一份摘要，列出高风险条款、待确认信息和修改建议。这个流程看起来不算复杂，但真正落到系统里，每一步都有很多细节。

文档解析这一步就很容易翻车。扫描件需要 OCR，PDF 里如果是图片而不是文字层，解析质量会直接下降。表格和复杂排版会让条款抽取变得混乱。这些不是模型的问题，而是数据处理的问题。从实践来看，先做文档清洗，再进入模型理解，是更稳妥的顺序。

字段抽取之后的条款比对，是真正能体现大模型能力的环节。传统规则引擎只能做字段匹配，无法理解“卖方有权在提前三十日书面通知后终止本协议”和“甲方可在任何时间书面通知乙方后解除本协议”这两种表述之间的实质区别。大模型可以做到语义层面的比较，并且可以把相似的条款归并到同一风险类别下。

2.3 关键参数从哪来：条款范围、风险词典和输出粒度

如果你要基于 Gemini API 做类似的合同审阅工具，最需要花时间设计的不是模型本身，而是三个东西：

• 条款分类体系。你希望系统重点识别哪些条款？是金额、期限、责任限制、知识产权、保密、解约条件，还是全部都要？条款分类越清晰，后续抽取值越稳定。
• 风险词典。哪些关键词、哪些句式组合，应该被标记为高风险？比如“赔偿总额不超过”“单方解除权”“无理由终止”“最终解释权归”等等。风险词典是业务经验的沉淀，不是模型能自己生成的。
• 输出粒度。是只输出合同摘要，还是输出条款级标注？是给出“低/中/高”风险等级，还是给出具体的修改建议？

这三个参数决定了工具是否真正可用。模型可以生成流畅的文本，但如果输出格式不稳定、字段不统一，后续就没办法接入审批流程。一个比较稳妥的做法是，让模型输出结构化的 JSON，包含摘要、关键条款、风险项和建议，然后由系统渲染成人类可读的报告。

{ "contract_type": "采购合同", "summary": "本合同约定乙方在12个月内分三期向甲方供货...", "key_clauses": [ { "clause_type": "付款条款", "content": "甲方应在收到乙方开具的发票后15个工作日内付款", "risk_level": "low", "comment": "付款期限相对宽松，建议关注发票开具时间" }, { "clause_type": "违约责任", "content": "乙方逾期交货超过30日，甲方有权单方解除合同并索赔合同金额30%的违约金", "risk_level": "medium", "comment": "违约金比例接近合法上限，建议根据实际损失评估" } ], "suggestions": [ "建议补充不可抗力条款", "建议明确争议管辖法院" ] }

一个结构化的输出之所以重要，是因为它能被程序自动处理。系统可以根据风险等级自动通知对应负责人，可以把高风险条款汇总成周报，可以对历史合同做统计分析。如果输出只是自由文本，这些能力全都实现不了。

2.4 别急着全自动：先跑通“人审+AI建议”的混合流程

我的建议是，不要一开始就追求“全自动审合同”。更稳妥的方式，是把流程设计成“AI 先做初稿，人工再做复核”。AI 负责抽取信息、标记风险、生成摘要；律师负责确认这些判断，并在需要修改的地方给出最终意见。这个模式的好处有三个：第一，降低出错风险，因为最终决策始终有人把关；第二，训练数据可以沉淀下来，律师的每一次修改都是在帮系统校准；第三，更容易被团队接受，因为工作流没有发生颠覆式改变。

还是那句老话：单次跑通只说明流程没断，真正难的是连续跑一个月、跑一百份合同都不出大问题。

3. 法律研究的难点不是搜索，而是归纳、溯源和验证

3.1 法律研究和普通搜索引擎的差距不在速度，在证据链

合同自动化是面向“文本处理”的，而法律研究是面向“知识获取与判断”的。这两件事的难度完全不是一个量级。

普通人在搜索引擎里找资料，找到几篇相关文章就觉得已经完成了。但律师做法律研究，目标不是找到“相关结果”，而是要形成一个“能写进法律备忘录、能支撑法律意见的结论”。这意味着法律研究必须满足几个要求：结论要准确，不能有猜测成分；依据要有出处，不能是 AI 编造的法条或判例；时效要新，不能引已经被废止的法律；逻辑要完整，从问题到结论到依据，中间不能断。

这恰恰是大模型目前最薄弱的地方。大模型擅长生成“看起来合理”的文本，但并不天然擅长做“每句话都有出处”的严肃文本。如果直接问一个通用大模型“某类合同纠纷中法院一般怎么认定”，它给出的答案在多数情况下是对的，但它的训练数据可能截止在两年前。法律研究这件事，差一年可能就是完全不同的结论。

3.2 大模型做法律研究时的三个天然短板

• 时效问题。法律条文会修订，司法解释会更新，指导案例会新增。模型训练时并不包含最新的法律变化，它甚至不会主动告诉你“我的知识有截止日期”。
• 来源不可靠。模型很可能把不同来源的信息混杂在一起，生成一个表面上完整的答案，但具体哪句话来自哪个判例，它自己也无法解释。
• 上下文限制。法律研究往往涉及长篇法规和系列判例，比如一份司法解释可能有几十条，一个指导案例可能有上万字。如果把全文塞进上下文里，现有模型很容易丢失前面的关键信息，或者在后半段开始无视前面的限定条件。

3.3 把法律研究流程拆解成五步

既然模型有短板，正确的用法就不是让它“直接给结论”，而是把它放到一个严谨的工作流里，让它做自己擅长的事。一个可复用的法律研究流程可以是这样的：

1. 明确研究问题。把“这个东西能不能退”改写成“买方在货物检验不合格后是否享有法定解除权，依据是什么”。
2. 拆解研究要素。把问题拆成几个独立的小问题：检验期限怎么约定、不合格的标准是什么、解除权是否已经产生、有没有经过催告程序。
3. 用模型做检索和初筛。针对每个小问题，让模型列出可能适用的法规、判例和常见观点，并用它对长篇材料做摘要。
4. 交叉验证。在模型给出的基础上，用权威法律数据库或者司法检索平台人工确认法条是否现行有效，判例是否仍具参考价值。
5. 人工定稿。由律师结合自己的经验，补上检索覆盖不到的部分，形成最终研究结论。

这五步里，AI 最主要的价值集中在第 3 步。第 1 步和第 5 步，必须由人来做。第 4 步，人机协同最重。

3.4 如何判断 AI 给的答案能不能用

给一个很实用的判断标准：如果一个 AI 给出的法律回答里，没有明确引用具体法条编号、没有显示检索时间范围、没有可点击查看的来源出处，那就只能把它当作线索，不能当作结论。再进一步，如果它引用了法条，你要去核实这条法律是否仍然有效；如果引用了案例，要注意案例的地域和审级，不同地方的法院对同一个问题可能存在不同裁判尺度。

建议：一次法律研究中，AI 生成了十个候选结论，你最终只用了一个，这不代表前面九个是浪费。这十个结论帮你快速锁定了研究边界，比从零开始检索要省很多时间。

4. 企业级落地：权限、审计和控制幻觉的真实取舍

4.1 法律数据的敏感性决定部署方式

任何法律部门在引入 AI 工具时，最先问的问题往往不是“它好不好用”，而是“我的合同放在你那里安不安全”。这背后的担忧很合理。合同和法律研究材料里包含着大量商业秘密：供应商价格、客户名单、合作条款、诉讼策略。如果这些材料被用来训练模型，或者被同平台的其他用户间接获取，法律风险会比效率提升带来更多问题。

所以“Enterprise”这个词的分量就体现在这里。企业级产品要满足的不只是功能需求，还包括权限隔离、审计追踪、访问控制这些看不见的能力。从前企业出合同要靠邮件来回发，不同版本散落在不同人的电脑里，想要确认“最后到底是谁改了这个条款”，只能靠回忆。如果整个合同流程都在一个统一平台里，每次查看、修改、导出都会有记录，反而比传统方式更容易定位责任。

4.2 权限、审计与来源管理是“企业版”的隐性核心

从组织部署角度看，这类系统通常需要做好三件事：

• 基于角色的访问控制。初级律师、高级律师、合伙人、法务专员、外部合作方，能看到的合同范围应该不一样。合同里的商务价格可能只对项目负责人可见，普通协办人员只需要看到与己相关的条款。
• 审计日志。谁在什么时间查看了哪份合同，AI 做了什么标注，人工在哪一步做了修改，都应该有记录。法律工作本质上是“可追溯性要求极高”的工作。
• 来源引用管理。AI 生成的摘要和建议，应该能关联回原始文档的具体条款。没有来源引用的 AI 法律输出，在企业场景里就是无效输出。

这些能力决定了系统能不能被放进合规审查流程，也决定了当争议发生时，你能不能拿出完整的证据链。一个企业级法律 AI 工具，如果不在这上面投入，做得再好看也没有意义。

4.3 幻觉控制：先接受它存在，再用流程把它管住

大模型的“幻觉”是一个绕不开的话题。在严肃法律场景里，一句编造的法条或案例足以毁掉整份法律文件的可信度。要让模型完全不出错，在现阶段不现实，更需要做的是用规则和流程去管理幻觉风险。

比较务实的做法有几个。第一，控制输出边界，让模型在“证据充分”的情况下才给出确定性判断，否则标注为需要人工核实。第二，加入引用校验环节，系统对模型输出的法条或案例做二次校验，发现引用不存在的条目时直接发出警告。第三，使用置信度标记，让模型对风险判断给出置信水平。虽然模型自我评估的置信度并不完全可靠，但作为一个提醒信号，可以帮助复核人员聚焦在重点位置。

4.4 当输出不对时，按这个顺序排查

实际使用中，AI 输出不符合预期是常态。遇到这种问题，如果只盯着结果抱怨“AI 又错了”，很难找到真正的原因。我建议按下面的顺序排查：

1. 先看输入。原始合同文件是否清晰？有没有缺页、扫描倾斜、中文繁体英文混合的情况？同一个 PDF，是一页页扫描件还是一张图片嵌入文档，解析结果可能完全不同。
2. 再看参数。合同类型选对了吗？条款分类体系当前覆盖哪些内容？风险词典里有没有对应的规则？很多“漏检”其实不是模型没看到，而是规则里根本没定义。
3. 然后看模型限制。当前上下文窗口够不够容纳整份合同？如果合同太长，被截断的部分自然不会被分析到。
4. 再看输出。摘要和条款清单是否忠实于原文？模型有没有自作主张补充了原文不存在的表述？
5. 最后落到流程。最关键的判断，是否需要人来复核？是否有第二层校验机制？

这个排查顺序同样适用于基于 Gemini API 做二次开发的场景。

5. 想验证它值不值得用，我建议按这四步来

5.1 第一步：挑三个真实任务，而不是用演示题目

很多团队验证 AI 工具时，喜欢拿网上现成的 Demo 题去测。比如“请总结这份合同”，然后看到了一个漂亮的摘要，就得出结论“很好用”。这种验证没有意义。真实任务里，合同会有行业特殊性，会有各种边角情况，会有反复修改的版本。

更合理的做法，是找三个正在进行的真实任务。一份正在谈判的采购合同，一个上周还在检索的法律问题，一批需要归档的旧合同。让系统在真实输入上跑，观察它到底能帮你省多少事。

5.2 第二步：把“看着不错”变成可验证的判断标准

法律 AI 的输出不能停留在“感觉不错”。建议提前建立一张标准表，把质量判断拆成具体维度。以下是常用维度：

这套标准不一定要一步到位，但至少要建立起来。因为人在看 AI 输出时很容易被流畅的文本带节奏。

5.3 第三步：主动测试失败场景

不要只测“它擅长什么”，还要测“它在什么情况下会崩”。常用的测试样本包括：超过 100 页的收购协议、包含大量附件的合同包、扫描质量很差的旧合同、英文和法条混合的文本、使用了特殊格式排版的条款。这些场景会暴露工具的真实边界。

特别要测试的是“长文档中间部分”。很多模型在处理超长文本时，会出现“两头强中间弱”的问题：合同开头和结尾的信息处理得好，中间夹着的某个重要条款却被忽略了。这是由模型注意力机制决定的，不是业务方设置参数能解决的，只能在流程上用分段处理来缓解。

5.4 第四步：选一个小团队试点，不要全面铺开

一旦通过了前面的测试，不要急着全所推广。先选一个较小的团队，比如三个人到十个人，跑一个月的真实业务。这一个月里要观察的是：使用频率是越来越高还是越来越低；律师是否愿意把 AI 标注的结果作为初稿；复核工作到底省了多少时间；错误率在可接受范围内。

试点阶段最重要的一件事，是收集失败案例，而不是收集成功案例。成功案例只能说明工具可用，失败案例才能告诉你边界在哪、训练数据需要怎么补、使用规则需要怎么调整。

6. 边界感：谁适合用，谁暂时不需要着急

6.1 它暂时不适合谁

需要先说清楚。Gemini Enterprise for Legal 这类工具，不适用的场景也很明确。如果一项工作高度依赖策略判断、价值观权衡、创造性论证，比如复杂诉讼的出庭策略、重大并购的交易结构设计、需要结合谈判对手心态做出判断的高难度谈判，那现阶段 AI 仍然只能做信息准备，无法替你做决策。

还有一类人暂时也不用着急上这类工具：如果团队的合同量很小，一年只有几十份，而且类型高度分散，那么引入一套企业级 AI 工具的边际收益会比较有限。对这类需求来说，先做好模板标准化和流程规范化，可能更实在。

6.2 它适合谁

它真正适合的，是那些“文本量大、结构化程度高、重复性强”的法律工作场景。

• 企业内部法务部。每天要处理大量采购合同、销售合同、NDA，使用频率高，对权限和审计要求严格。
• 提供标准化服务的律所团队。比如常年法律顾问、知识产权代理、劳动合规咨询。这类工作有相对固定的审查清单，适合用 AI 做初始化提效。
• 有知识管理需求的法律团队。AI 可以沉淀出条款库、风险词典、常用修改建议，这些资产在传统工作方式下很难被结构化保存。

它适合的不是“少数精英律师”，而是那些刚入行一两年、每天都在做重复审阅工作的初级法务。它帮他们省下时间，才有余力去接触真正需要法律判断的工作。这可能是 AI 对法律行业最深远的影响之一。

6.3 长期要看什么

法律 AI 行业有一个长期的观察点：工具带来的错误由谁负责。当一份 AI 辅助审阅的合同出了问题，责任是落在使用者身上，还是模型提供方，或者服务实施方？这个问题一天不解决，法律 AI 在正式业务里就始终只能做辅助角色。

另一个观察点是工作流集成的深度。如果 Gemini Enterprise for Legal 只停留在“一个更好用的网页工具”，那它对行业的改变有限。如果它能和 Office 套件、合同管理系统、企业审批流深度打通，那么法律工作的形态就会发生更本质的变化。所有企业级软件的真正护城河，从来不在模型本身，而在工作流的嵌入深度。

回到开头那句话。法律这个行业不缺知识，缺的是把知识快速转化为判断的通道。Gemini Enterprise for Legal 想做的，就是在这个通道上铺一段更顺的路。它不会取代律师的判断，但它会重新划分律师的时间：减少在文本里找线索的时间，增加在问题上做判断的时间。这，才是它最值得长期关注的底层价值。