法律行业使用 AI，难点从来不只是模型能不能读懂合同。律师处理的是受特权保护的通信、带有伦理墙的案件资料、律所自己的审阅规则，以及持续变化的法律与监管要求。一个通用聊天机器人可以给出看似合理的答案，却无法自动满足权限继承、可追溯引用、保密和专业判断这些生产环境要求。
Gemini Enterprise for Legal 的核心思路，是在模型之外构建一整套法律工作系统：把律所知识封装成可复用技能，把现有业务系统接入代理，把代理放进统一的治理控制平面，并通过开放生态适配不同的法律技术栈。
从模型能力转向四层工作系统
1. 把专业方法写成可执行技能
法律技能不是一句“请审查这份合同”的提示词，而是包含任务上下文、审阅步骤、引用规则、事务所 playbook 和 house style 的可复用指令包。合同审阅、红线修改、监管趋势扫描、法律研究、DSAR 响应和 NDA 起草，都可以围绕这些技能标准化。
这一步的价值在于把原本依赖资深合伙人反复口头解释的机构知识，转化为代理能够稳定执行的工作规范。它并不消除律师判断，而是把低价值的重复判断前置为一致的检查流程。
2. 让权限跟着数据一起流动
法律数据不能因为接入 AI 就被汇总到一个没有边界的知识库。通过安全的 MCP 连接器，代理可以连接文档管理、案件资料库、电子取证、法律研究和合同生命周期系统，并继承原系统的用户权限、文档级访问控制和伦理墙。
例如，iManage、NetDocuments、Everlaw 和 RelativityOne 中的内容，应当继续由各自的访问规则约束；Google Workspace 和 Microsoft 365 中的邮件、文档与 matter 文件夹，也必须保留原有工作上下文。理想的查询结果不是“系统知道所有内容”，而是“系统只使用当前用户本来就有权访问的内容”。
3. 让代理完成工作，而不只是返回建议
技能与连接器组合后，AI 才能从被动问答走向代理执行。一个监管扫描代理可以追踪法规更新、法院 docket 和监管机构公告，将变化与企业政策交叉比对，标出暴露缺口，并生成供律师审核的政策草案。
类似地，合同代理可以按照企业 playbook 对供应商协议、NDA 或并购文件进行基准比较，定位高风险条款和可接受的 fallback position；DSAR 代理则可以在多个企业系统中发现个人数据，汇总响应材料，并帮助团队满足监管时限。
这些流程的共同点是：代理在受控数据范围内推进任务，最终输出仍需由专业人员确认。
4. 用开放生态适应真实的法律技术栈
每家律所和企业法务部门的系统组合、审批流程与实践方式都不同。开放的连接器、第三方代理和实施伙伴因此是架构的一部分，而不是附属销售渠道。
平台可以接入 CourtListener、Courtroom5、Thomson Reuters HighQ 等法律研究和公共 docket 数据，也可以通过 Harvey、Solve Intelligence、Legora 等专业工具扩展法律推理、专利研究和复杂事务处理。Accenture、Deloitte、KPMG、Valtech 等系统集成商则可参与复杂企业架构的定制与落地，降低被单一供应商锁定的风险。
控制平面决定能否进入生产环境
法律技术的保密性不是一个可选功能，而是使用系统的前提。统一控制平面需要至少回答四个问题：谁访问了什么数据，代理依据了哪些来源，输出是否可以复核，以及组织策略是否真正被执行。
Gemini Enterprise for Legal 强调在 Google Cloud 基础设施和 Gemini Enterprise 平台上运行，通过 VPC、CMEK、私有数据隔离和可追溯引用等机制提供治理边界。企业数据、内部 playbook、定制代理与模型输出保持组织私有，并且不会被用于训练或微调 Google 的基础模型。
“有引用”也不等于“可信”。生产部署仍应检查引用是否来自授权文档、是否覆盖关键结论、是否引用了过期版本，以及代理有没有把推测写成事实。
一个可改造的合同审阅代理配置
下面是一个最小的 YAML 示例，用来表达一个权限受限、要求逐条引用的合同审阅工作流。它是配置示意，具体字段需要根据实际代理平台和连接器 API 调整。运行前请替换 matter_id、连接器名称和企业 playbook 标识。
name: vendor-contract-review
version: 1
input:
document_id: contract-2025-001
matter_id: matter-legal-042
user: current_user
connectors:
- name: im एडocs
type: document_management
permission_mode: inherit
filters:
matter_id: matter-legal-042
- name: contract-playbook
type: governed_knowledge
permission_mode: inherit
skill:
instructions: |
Review the agreement against the approved vendor-contract playbook.
Identify deviations, material risks, fallback language, and missing terms.
Every finding must cite the source document and the playbook section.
Never infer a missing clause as acceptable. Mark uncertainty for attorney review.
output:
format: markdown
required_sections:
- executive_summary
- high_risk_clauses
- recommended_redlines
- open_questions
require_citations: true
human_approval: required
logging:
retain_trace: true
redact_sensitive_output: true
这个示例有三个关键约束。permission_mode: inherit 表示代理不应绕过文档系统的权限；require_citations: true 让每个结论都能回到源文档和 playbook；human_approval: required 则把高风险法律判断留在律师审批环节。实际系统还应增加版本锁定、提示词和技能变更审计、失败重试边界，以及对跨 matter 数据访问的自动拒绝。
适合优先落地的工作流
可以从高频、规则相对清晰、结果容易复核的场景开始：
- 供应商合同和 NDA 的条款比较、风险标记与结构校验。
- 将历史协议提炼成动态 contracting playbook。
- 监管变化扫描，并与企业政策进行差距分析。
- 从分散系统中发现个人数据，辅助 DSAR 响应。
- 为申请封存的诉讼文件识别敏感词和个人信息，交给律师确认。
- 从授权案件资料中生成时间线、事实摘要和研究线索。
不建议一开始就把代理设置为自动提交法院文件、自动发送客户意见或自动决定诉讼策略。越接近法律结论、客户承诺和不可逆外部动作，越需要清晰的审批、责任归属和回滚机制。
落地前的检查清单
评估这类平台时，可以用以下问题代替“模型回答得像不像律师”：
- 是否继承身份、文档级权限和伦理墙，而不是建立一套平行权限？
- 每个事实和建议能否定位到授权来源，并显示文档版本？
- 技能是否纳入 playbook、引用格式、辖区和事务类型？
- 代理能否完成跨系统流程，同时记录每一步动作？
- 高风险输出是否默认需要律师确认？
- 客户数据、内部知识和输出是否与模型训练隔离？
- 是否能接入现有 DMS、电子取证、研究和合同系统？
- 成本、延迟、错误率和人工复核时间是否有可量化指标？
Gemini Enterprise for Legal 的重要变化，不是又提供了一个法律问答入口，而是尝试把模型、专业技能、受权限约束的数据连接、可执行代理和治理统一起来。对律所和企业法务而言，真正值得验证的指标也应随之变化：不是“它能写出多像法律文本”，而是“它能否在正确的数据边界内，依据可审计来源，稳定完成一项可复核的法律工作”。