律所的数据有一处和别处不同：真正值钱的东西大多以非结构化形式存在——法律意见书、尽调底稿、合同、往来邮件，再加上工时表和账单。这些资料可读性很高，可检索性很差。与此同时，客户名称、案件标的、交易结构都属于高度保密信息，任何引入外部工具的动作都要先过保密审查这一关。这两点决定了法律行业的 AI 项目，起点通常不是上模型，而是先把资料和数据管起来。
一、先分清企业AI的两类用法
律所谈 AI，容易把两件事混在一起。一类是问答型：法规检索、制度问答、合同要点提取、材料归档；另一类是数据型：案件进展、工时记录、创收分析、回款跟踪。前者依赖文档和知识库，后者依赖业务系统和统一口径。两者都需要，但决定 AI 能不能进入管理层的，是第二类。
类型 | 典型形态 | 依赖什么 | 适合的场景 |
问答型 | 法规检索、制度问答、合同要点提取、材料归档 | 文档与知识库 | 法规学习、制度查询、文书辅助 |
数据型 | 案件进展、工时统计、创收分析、回款跟踪 | 业务系统与统一口径 | 经营分析、团队考核、客户管理 |
问答型见效快、风险低，适合作为切入点；数据型决定 AI 能否参与经营判断。法律行业的难点在后一类——律所最核心的数据（工时、计费、分配）往往还停留在表格甚至纸质记录的阶段。
二、法律行业的六个落点
2.1 案件与项目管理
律所同时在办的案件数量多、周期长、参与人员多。案件台账通常由助理手工维护，节点提醒靠人记。把案件信息结构化以后，进展、节点、责任人、关联文档可以在同一个视图里看，跨团队协作时的信息断层会明显减少。
2.2 工时与计费
工时是律所收入的基础。工时记录如果依赖事后补填，计费的准确性和人员考核都会失真。把工时记录、案件、客户、账单连起来之后，计费清单的生成和回款进度的跟踪可以自动完成，律师也不必再月底集中回忆。
2.3 团队创收与利润分摊
这是律所经营分析的核心，也是最难的部分。按团队、业务线、客户维度看创收和成本，需要把案件收入、人力成本、公共费用分摊放在同一口径下计算。合伙人最关心的问题在这里，数据口径的复杂度也在这里。
2.4 客户结构与案源分析
客户集中度、案源渠道、客户贡献度、交叉服务机会，这些分析在律所通常靠合伙人的个人经验判断，缺少数据支撑。客户数据整合起来以后，结构变化可以被提前看到，比如某个行业客户的占比正在下降。
2.5 文档与知识资产
法律意见书、合同模板、判例研究、尽职调查底稿，体量巨大但检索困难。资料入库并建立检索能力之后，律师可以按问题直接检索历史材料，回答可以溯源到原文，而不必靠翻文件夹或者问同事。
2.6 合同审阅与法规跟踪
合同要点提取、风险条款识别、法规与政策动态跟踪，是 AI 在法律相关场景里落地相对成熟的方向。这里有一点需要提前明确：AI 输出的是待复核项，最终判断仍然由律师作出。
场景 | 典型痛点 | AI 可以做什么 | 看得见的结果 |
案件与项目管理 | 在办案件多、周期长，台账靠人工维护，节点提醒不及时 | 案件信息结构化，进展、节点、责任人、文档统一视图 | 在办进展一眼可见，节点不遗漏 |
工时与计费 | 工时靠事后补填，账单生成与回款跟踪脱节 | 工时、案件、客户、账单打通，自动生成计费清单 | 计费口径统一，回款可追 |
团队创收与利润 | 收入、人力成本与分摊规则分散，靠财务手工汇总 | 按团队、业务线、客户维度自动计算创收与成本 | 合伙人能按经营单位看结果 |
客户结构与案源 | 客户集中度、案源渠道、交叉机会靠经验判断 | 客户数据整合，按贡献度与行业多维分析 | 客户结构变化提前发现 |
文档与知识资产 | 法律意见书、合同模板、判例资料体量大、检索难 | 文档入库后支持自然语言检索，回答可溯源原文 | 历史材料可复用，新人上手更快 |
合同审阅与法规跟踪 | 合同要点提取与政策跟踪占用大量人力 | 提取合同要点与风险条款，生成检查清单，跟踪政策动态 | 审阅有清单可依，判断仍由律师作出 |
三、能落地的前提：平台要具备什么
法律行业的组织形态和数据敏感度，决定了平台选型不能只看模型能力。下面四点，是实操中最容易踩空的地方。
3.1 数据接入：把案件、工时、财务接进来
律所的数据往往散在案件管理系统、财务软件、工时表和共享盘里。如果 AI 只能看到其中一部分，它给出的分析就只是片段。平台需要具备直连业务与财务系统的能力，用自然语言转查询语句的方式取数，而不是要求律师先把材料导出、整理再交给 AI。
3.2 口径统一：创收和成本怎么算，先说清楚
同一个“团队创收”，按收款算、按开票算还是按确认收入算，结果差别很大。成本如何分摊到案件，也需要事先约定。平台需要具备语义层能力，把指标定义、取数逻辑和维度归属统一管理，让每个指标只有一个算法，避免同一份报表出现两个版本。
3.3 权限与保密：谁能看到哪些案件和金额
律所对保密的要求高于多数行业。不同合伙人、不同团队、不同岗位可以看到的案件范围、客户信息和金额区间都不一样。平台需要支持菜单、数据表、字段级的三级权限体系，并结合字段级脱敏和全链路操作审计日志。对处理敏感案件的机构来说，本地私有化部署通常是硬性要求。
3.4 交付形态：结果要出现在律师日常用的入口里
律师的工作入口是邮件、即时通讯和文档系统，而不是一个新的管理后台。如果 AI 的输出只能在一个独立页面查看，使用率很难维持。把经营摘要、案件提醒、风险预警推送到团队已经在用的协同工具里，是决定长期使用率的关键。
业务场景 | 平台动作 | 交付形态 |
案件与工时查询 | 直连案件管理系统与财务、工时数据，统一指标口径 | 在协同工具内提问，或走统一 AI 入口 |
经营与创收报告 | 按合伙人、团队、业务线生成经营摘要与分析报告 | 报告定时推送至团队群组与邮件 |
合同与文档助手 | 提取合同要点、识别风险条款、生成检查清单，文档可溯源 | 在办公入口内直接调用 |
法规与政策跟踪 | 跟踪法律法规与行业动态，生成摘要与提示 | 摘要定向推送至相关团队 |
3.5 项目需要业务角色参与
还有一点容易被忽略：法律行业的 AI 项目需要业务角色实际投入。案件进展、工时记录、计费口径这些信息，只有律师和团队秘书最清楚，单靠 IT 或财务推不动。项目启动阶段就把合伙人、团队秘书和财务拉到一起确认口径，比上线之后再返工便宜得多。
五、落地建议
第一，从一个具体问题切入。律所里最容易验证的场景通常是案件进展查询或团队创收分析，问题明确、数据边界清楚。
第二，先约定口径，再上系统。创收、成本、分摊的定义如果没谈清楚，工具上线后争议会更多。
第三，把保密要求前置。权限分级、字段脱敏、操作留痕和部署方式，都应在方案设计阶段就确定，而不是上线前临时处理。
第四，AI 的定位要讲清楚。它是辅助提取和整理的助手，专业判断仍然由律师作出，这个边界越清晰，内部接受度越高。
第五，控制第一期范围。选一两个团队先跑通，把数据口径和权限规则磨合好，再考虑推广到全所。
结语
法律行业的 AI 落地，难点不在于让模型读懂法条，而在于把案件、工时、账单、文档这些本来就存在的记录，接成一条可以查询、可以核对的链路。当合伙人能直接问出团队创收的变化，当律师能一句话查到六年前类似条款的处理方式，AI 才算真正进入了这家机构的日常工作。