为什么决定法律 AI 成效的，是数据平台，而不是模型 ｜ 技术实践

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

法律数据，例如合同、法律事务历史、外部律师费用支出和谈判记录，是企业中运营复杂度最高、访问敏感性最强的数据资产之一。随着组织将 AI 应用于合同审查、法务运营和合规管理，法律数据治理所面临的挑战，也远比传统分析场景更加严峻。

要以负责任的方式大规模部署法律 AI，组织必须采用以数据平台为中心，而非以模型为中心的方法。通过将治理控制、组织制度性知识和反馈机制直接嵌入企业数据平台，法务团队可以在合同智能、外部律师管理以及各专业领域运营中，实现一致且可执行的 AI 行为，同时保障数据机密性与审计能力。

为什么以模型为中心的法律 AI 存在局限

当前的法律 AI 系统通常遵循一种共同模式：上传合同、检索相关指引、生成条款级建议。无论该工具是商业产品还是定制化实现，其架构基本相同：将语言模型连接到文档存储系统和检索管道。

这种方法适用于孤立的条款分析。然而，它忽略了法务团队工作方式中的一个根本事实。经验丰富的律师在审查责任上限条款时，不会将其孤立看待。他们会综合考虑交易的商业价值、谈判所处阶段、其他条款中已经作出的让步，以及上一次面对类似交易对手并接受相似立场后所产生的结果。

以模型为中心的系统会将每个条款视为彼此独立的内容，无论上下文如何，相同输入都会产生相同输出。它们无法在一次受治理的查询中，将偏离记录、谈判手册中的标准立场和计费历史关联起来。它们也无法确保某一专业领域的让步模式，不会出现在另一团队的上下文窗口中。

当 AI 系统通过连接器访问合同生命周期管理平台、电子计费系统、文档存储库和消息工具中的数据时，每一项连接都可能带来延迟、安全边界和治理缺口。以模型为中心的方法将数据平台视为外围系统。要让法律 AI 达到法务团队所要求的严谨程度，数据平台必须成为整个体系的中心。

面向法律 AI 的数据原生架构

数据原生的法律 AI 技术栈由三层组成，所有层均在企业数据平台内部运行。

受治理的数据基础

每一种法律数据源，包括合同生命周期管理系统、电子计费系统、案件管理系统和文档存储库，都会通过自动化管道进入数据平台。真正的差异，体现在数据摄取完成之后。

行级和列级访问策略在查询引擎层面强制执行，确保每一种法务角色只能看到其获授权访问的数据。诉讼团队可以查看劳动争议案件，但不能查看采购请求；隐私团队可以查看数据处理协议审查记录，但不能查看股票交易预先审批信息；总法律顾问则可以查看全部数据。由于访问控制在平台层执行，所有下游工具都会自动继承相同的治理控制，无须编写应用层过滤代码。

语义层让结构化法律数据能够通过自然语言进行查询。当律师询问“哪些客户合同包含无限责任”时，系统会基于结构化条款元数据给出精确答案。这不是模糊搜索结果，而是一次受治理的聚合查询。

搜索服务会为谈判手册章节、合同文本段落和条款注释等非结构化内容建立索引，从而实现亚秒级语义检索，并支持属性级过滤。

这一架构最关键的特性在于：治理、结构化分析和语义搜索都基于相同的数据运行，并遵循相同的访问控制。当 AI 智能体查询合同数据时，它会继承请求用户的访问策略。无须进行中间件同步，也不会产生治理缺口。

上下文感知推理

模型正在日益商品化。但模型本身无法基于组织内部的制度性知识进行推理。以下三种机制必须依赖数据平台才能实现：

• 谈判立场评估：在审查任何条款之前，系统会评估交易的商业价值、所属行业、谈判阶段和战略重要性。这些因素决定 AI 是优先采取强硬反对立场、提出折中方案，还是建议接受对方要求。同一项合同条款会根据交易上下文产生不同建议，而无须修改模型或进行微调。只有数据平台能够在推理时提供这些上下文；

• 有状态的让步追踪：每一项潜在让步都会产生相应成本。系统会在包含多个条款的审查过程中，持续追踪累计的谈判成本。当可让步空间已经耗尽时，系统会向律师提示这一限制。无状态的“模型加检索”架构，若没有外部持久化层，便无法维护这种状态；

• 基于谈判手册的建议：每一项建议都会引用其所依据的具体谈判手册章节，并标记偏离标准立场的内容。由于谈判手册是在推理时建立索引并进行检索，而不是被嵌入模型指令中，因此，一旦更新某项立场，所有后续审查都会自动采用新的立场，无须重新部署系统。

持续产生复利效应的反馈闭环

数据平台的优势在这里转化为结构性优势，而以模型为中心的方法在根本上无法与之竞争。

当每一次谈判偏离、每一项律师决策和每一个合同结果都保存在同一个受治理的数据平台中时：

系统可以通过对比已签署合同与结构化谈判手册中的标准立场，自动识别偏离情况，无须人工记录。

模式识别可以作为定时任务运行：当同一种条款立场在一个滚动时间窗口内被反复推翻时，系统会提出谈判手册更新建议，供律师审查。

结果追踪可以将偏离历史与法律事务结果、外部律师费用支出和交易推进速度关联起来，从而分析特定让步模式是否与后续成本或风险存在相关性。

由此形成一个持续产生复利效应的飞轮：更多谈判会积累更多组织历史，这些历史能够提升让步判断的准确性，进而生成更优质的 AI 建议，并加快交易推进速度。每个季度，系统都会更加贴近组织的实际执业方式，而不是停留在通用模型的训练方式上。

为什么源系统权限不足以满足需求

最常见的反驳是：“直接在源系统中配置权限即可。”对于 AI 工作负载而言，这种方法会因以下四个原因而失效：

源系统权限无法延续到 AI 上下文窗口中。一旦 AI 系统将文本检索并写入提示词，原始系统的访问控制便不再生效。模型本身不会执行源系统的访问控制列表。平台级行访问策略则可以从源头防止未经授权的数据进入上下文窗口。

跨领域关联会破坏源系统层面的权限控制。一个合同审查问题可能需要关联合同生命周期管理数据、电子计费记录、案件管理事项和谈判手册内容。每个源系统都有各自独立的权限模型。只有统一的数据平台，才能对关联后的结果执行一致的治理控制。

AI 智能体需要派生权限。法务角色通常无法直接映射到源系统中的用户组。专注于合规的角色可能需要访问多个源系统中的合规类别数据，同时又必须在所有系统中受到限制，无法访问诉讼数据。这种跨源系统、基于数据类别的策略，只能在数据汇聚的平台中进行表达。

第三方权限模型无法扩展。外部律师计费数据来自电子计费服务商，条款抽取结果来自合同生命周期管理平台。组织无法在第三方系统中添加自定义行级策略。治理只能在数据落地的平台中执行。

源系统权限回答的是：“谁可以访问这个应用？”平台级治理回答的则是：“当 AI 智能体在一次查询中关联合同、费用支出和工作事项时，每种角色能够看到组合结果中的哪些数据行？”

对法律 AI 战略的启示

法律 AI 的限制因素并不是模型智能，而是数据架构。与其将数据平台视为模型通过连接器访问的外围系统，组织更应将其作为法律 AI 技术栈的核心。这样，组织才能部署默认受治理、在推理时具备上下文感知能力，并能够随着时间持续积累组织智能的 AI 系统。

了解 Snowflake 如何通过 Snowflake Cortex AI 为企业 AI 提供支持，并亲自进行体验。

原文地址：https://www.snowflake.com/en/blog/data-platform-legal-ai-outcomes/

点击链接立即报名注册：Ascent - Snowflake Platform Training - China，更多 Snowflake 精彩活动请关注专区。