夜雨聆风
各位好，我今天分享的主题是：企业法务部 AI 选型，从决策到落地，再到评价。
我自己的观察视角比较特殊。一方面，我有法律专业背景，担任inhouse时也长期参与过法务数字化、法律科技相关工作；另一方面，这几年我更多站在法律 AI 产品和项目落地的一线，和法务部门、IT 部门、采购部门、业务部门，以及厂商团队都打过交道。今天讲的很多教训，不是我从旁边看到的，而是我们自己一脚一脚踩出来的坑。
所以今天这场分享，我不想把它讲成一个厂商评测，也不想讲成一个采购指南。因为在真实项目里，很多问题不是"哪家产品更好"这么简单，而是：企业到底有没有把问题定义清楚？有没有准备好数据？有没有人能把法务需求翻译成 AI 能执行、能验收的任务？上线以后有没有持续运营？最后有没有办法证明价值？
01为什么有些法务 AI 项目"上线了，但没用起来"？
我们先看一个特别常见的场景。
项目启动的时候，一切看起来都很顺利。领导重视，预算到位，Demo 很精美，POC 也通过了。账号开通，系统上线，汇报材料里看起来项目进度也很完整。
如果只看这些表面指标，这个项目是成功的。它有上线节点，有功能清单，有验收材料。
但是几个月之后，另一个画面出现了：真正高频使用的人很少，法务同事又回到了 Word、邮件、微信，审查意见还是靠人工批注和经验传递。到了续费或者复盘的时候，管理层问了一个很朴素的问题：这个系统到底改变了什么？
这时候很多项目会发现，自己有功能清单，但没有采纳率；有上线记录，但没有审查质量变化；有系统账号，但没有真实业务闭环；有很多"功能可用"的证明，但没有"工作方式改变"的证明。
这也是我今天要讨论的主线：法务 AI 项目的成败，不只发生在采购阶段，更发生在选型、落地和评价这三个阶段的连续误判里。
02选型阶段的误判
这一阶段最常见的问题是：Demo 好看，不等于真实可用。
很多企业在选型的时候，会把注意力集中在产品演示效果上：界面是否漂亮，回答是否流畅，风险提示是否完整，生成报告是否好看。
但真正影响项目成败的因素，往往藏在 Demo 后面。比如跨部门协同有没有断层，数据能不能拿到，项目推动力会不会上线后消失；再比如 AI 底座能力是不是会快速折旧，私有化是不是反而带来维护负担；还有，企业内部有没有 AI-native 的人才，能把需求、专家经验、Prompt、规则和评测持续维护起来。
最后，还有一个很大的问题：评价机制错位。很多项目把"上线"当成成功，但其实上线只是开始。
1. 第一个误判，是把精致 Demo 当成真实交付能力。
我经常看到一种情况：Demo 里的合同非常干净，文本结构标准，主体清楚，条款完整，格式统一。这个时候，AI 的输出确实会很好看，风险提示也会很完整，甚至看起来非常专业。
但真实业务不是这样的。
真实业务里的合同，可能是扫描件，可能有修订痕迹，可能有多个附件，可能有历史版本，可能合同正文和背景材料分散在不同系统里。更常见的是，信息并不完整：业务背景没有写清楚，交易结构没有交代，审批意见散落在邮件或微信里。
所以 Demo 测出来的，很多时候是产品的表达能力；但上线以后真正考验的是系统承压能力。
这里有两个问题非常关键。
第一，风险提示能不能解释依据？不是只告诉我"这里有风险"，而是能不能告诉我为什么有风险，依据来自合同条款、公司制度、历史口径，还是法律法规。
第二，遇到不确定情况时，系统是提示人工确认，还是强行给答案？在法律场景里，强行给出一个看似确定的答案，反而可能比不回答更危险。
2. 第二个误判，是把 POC 做成表演赛，而不是压力测试。
很多 POC 其实只回答了一个问题：这份合同能不能审？而且测试材料往往是厂商可以提前调优或准备好的示范数据，或者企业挑出来比较规整的合同。
这样的 POC 很容易顺利通过，但它没有暴露真实风险。
有效的 POC 应该反过来设计。我们要拿最乱的合同，扫描版 PDF，带修订痕迹的 Word，附件不完整的合同，交易背景不清楚的合同来测。为什么？因为这些才是上线后真实会遇到的情况。
POC 还应该测几个关键问题：信息不完整时，系统会不会瞎编？同类问题多次审查，结果是否稳定？边界问题是否提示人工确认？复杂场景下是否仍然可用？
我自己做产品，体会最深的一点是关于"稳定"这件事。一个很懂业务的高手，靠个人能力可以把通用大模型调到 90 分。但你把同一个工具放进一个真实组织里，每个人的水平和视角千差万别，产出可能在 40 分到 90 分之间剧烈波动。组织管理最怕的，恰恰是这种不可控的方差。所以 POC 真正该测的，不是"高手用它能做到多好"，而是"一个普通同事，拿最差的那份合同来用，会差到什么程度"。能不能把这个下限托住、把方差压窄，才是一个产品真正的功夫——也是 Demo 永远测不出来的东西。
所以除了看结果，更要看指标。比如审查平均耗时是否下降，关键风险漏识别率有没有变化，重复测试结果的一致性如何。
这里我想强调一句：POC 的目的不是证明产品厉害，而是尽早暴露它在哪些情况下不可靠。 边界越早暴露，项目越容易成功；边界越晚暴露，风险越容易在上线后集中爆发。
3. 第三个误判，是一开始就用大场景和私有化来替代小场景验证。
很多企业一上来就说，我们希望做一个覆盖所有合同的智能审查系统。销售合同、采购合同、NDA、涉外合同、租赁合同都要覆盖。
这个愿望当然可以理解。但问题是，不同合同背后的业务流程、风险类型、角色分工和判断标准完全不同。范围一旦过大，需求就很难收敛。最后很容易变成每个场景都做了一点，但每个场景都没有做到足够深。
正确的起点应该是什么？是找一个足够痛、足够高频、足够可验证的小场景。比如销售合同初审，它高频，能度量耗时变化，也能观察用户是否采纳 AI 的审查意见。先把一个小场景做透，再用数据决定下一个场景，而不是一开始就把所有场景铺开。
这里还要讲一个常见的私有化误区。很多企业会觉得，只要私有化部署，项目就安全了。但私有化解决的是数据边界问题，不自动解决场景问题、模型问题、知识问题和使用率问题。
真正要问的是：部署之后谁来升级？谁来运营？谁来评价效果？谁来维护规则和知识？如果这些问题没有答案，私有化只是把系统搬进了企业内网，并不等于项目真的落地。
4. 第四个误判，是把 AI 底座当成一次性固定资产。
过去企业采购软件，可能会习惯性地把它当作相对稳定的固定资产。但 AI 底座不是这样。今天某个模型能力领先，几个月之后，这个先进能力可能就变成基础能力。开源模型也可能快速追平，价格、可控性和迁移能力都会变化。
所以选型时真正重要的问题，不是押中某一个模型，而是系统有没有能力适应模型变化。
这会带来几个很现实的选型问题。第一，能不能切换模型？是不是支持多模型调用？第二，模型升级以后，价格能不能重新谈？第三，数据和知识资产能不能迁移？第四，应用层、模型底座和知识库是不是分层设计，还是被一个供应商完全绑定？
在合同里，也要尽量写清楚模型版本升级、价格重议、数据迁移接口、知识资产归属这些问题。否则，今天看起来很先进的底座，明天可能就成为迁移成本最高的部分。
所以，真正重要的不是押中某个模型，而是系统有没有能力适应模型变化。 换个说法——你真正要买的，不是某个模型，而是一套不管底座怎么换、都能把企业自己的知识资产留下来的应用层。
03落地阶段的误判
这里的核心判断是：买了系统，不等于完成了智能化。
很多项目在采购完成后，会有一种错觉：合同签了，系统部署了，账号开通了，项目就基本结束了。但对法务 AI 来说，这恰恰是落地工作的开始。
落地阶段最关键的是三件事。第一，需求有没有被翻译成可验收的输入输出。第二，AI 应用有没有嵌入真实业务流程，而不是停留在单点工具。第三，专家经验有没有被结构化，系统上线之后有没有持续运营。
5. 第五个误判，是需求和数据没有先被工程化。
法务经常会说一句话：我们要智能审查合同。IT 听到的可能是：识别条款、标注风险。厂商听到的可能是：上传合同、调用模型、展示结果。
但法务真正需要的，往往不是这么简单。真正需要的是：结合企业制度、历史审查口径、交易背景和具体合同文本，输出可解释、可修改、可复核的审查意见。
这中间就需要一个非常稀缺的角色：翻译官。这个人要能同时理解法务语言、产品语言和技术边界。需求翻译不是写一句"支持智能审查"就结束了，而是要把业务语言转成可验收的输入、输出、边界和反例。
比如输入是什么？是真实合同，还是合同加背景信息？规则从哪里来？是制度、条款库，还是历史审查意见？输出是什么？是风险解释、修改建议，还是复核记录？
同时，数据也不是天然准备好的。合同正文可能在 OA，盖章版在印章系统，审查意见在邮件批注里，历史口径在资深法务脑子里。要让 AI 真正工作，这些材料必须被连接成同一条数据链。
所以，数据准备不是技术杂活，而是法务 AI 项目的第一道业务工程。
6. 第六个误判，是以为专家经验会自动变成 AI 能力。
很多法务团队会说，我们有很多资深专家，他们知道怎么审合同，所以 AI 应该能学习这些经验。
但问题是，专家经验通常是隐性的。专家看到一个条款，可能马上知道这里不对，但他的大脑里其实完成了很多判断：这个条款触发了什么风险？风险严重程度如何？依据是什么？建议怎么改？有没有例外情况？在什么交易背景下可以接受？这些东西如果不被拆解，AI 是无法稳定复用的。
所以专家经验必须从"隐性判断"变成"结构化表达"。至少要拆成几类信息：触发条件、风险是什么、判断依据、建议修改方式、例外情况、人工确认点。
这件事具体怎么做，我们自己摸索了很久，分享一个我觉得有用的思路，供大家参考。
很多 AI 研究助手的做法，是给模型接一个很大的知识库，让它搜索加总结。但我们发现，不管知识库多大，只要是"搜索加总结"，输出质量就还是不稳定——因为它不知道该先问什么、该重点查什么、什么信息可信、什么要存疑、最后该用什么格式交付。
而真正有经验的法律人做事，靠的根本不是"知识本身"，而是一套藏在脑子里的方法论：清晰的作业流程、判断优先级的框架、对输出质量的自我检验、鉴别信息源的标准。所以更好的做法，不是让 AI 在知识的海洋里自由泳，而是先把资深专家"处理这一类问题的方式"拆出来，固化成系统能稳定执行的作业流程。你要沉淀的，不是知识，而是"专家用知识的方式"。
也正因为这样，法务 AI 项目不是简单地把合同扔给模型，而是要把专家经验加工成系统可调用、可复核、可迭代的知识。AI 不会自动继承专家经验，经验要被拆解、表达、反馈、持续修正，才能逐步变成企业自己的 AI 能力。
7. 第七个误判，是认为系统上线后会自动越来越好。
现实往往相反：很多 AI 产品上线那一刻，可能是效果最好的时候。因为上线前，厂商集中调试过，项目组集中投入过，测试集也集中优化过。
但上线之后，真实业务开始不断变化。合同模板会变化，业务模式会变化，法律法规和公司制度会变化，新的审查口径会出现，用户也会提出新的问题。如果没有持续运营，效果就会慢慢退化。
这里的持续运营，不是简单地让 IT 维护服务器，也不是偶尔修一个 bug。它包括规则更新、知识维护、Prompt 调整、用户反馈收集、错误案例复盘、效果评估、版本迭代。
但这里我想多说一句：理想状态下，持续运营不该全靠人去推。更好的设计，是让运营长在产品里。比如——组织里每一次有人点"采纳"、"忽略"，或者动手把某句话改掉，这些动作都被记录下来；当某个修改反复出现，系统自己识别出这个规律，主动提议更新风控基准。这样，组织自己的口径就在日常使用中被无感地训练出来，而不是靠某一个人定期去维护一份没人看的文档。换句话说，一个好的法务 AI，应该能让前线员工的碎片动作，慢慢涌现成组织的知识资产。
所以，法务 AI 产品不是买回来就完成交付的系统，而是一套需要持续运营的能力。而一个没有人负责运营的 AI，会很快从"项目成果"退化成"无人照看的工具"。
05评价阶段的误判
这里最大的误判是：把"上线验收"当成"价值验收"。
功能上线只能证明系统能跑，但法务 AI 的价值，必须沿着真实任务继续往后证明。这里至少有四步。
第一，系统能跑。账号开通，功能可用，流程打通。这只是交付起点，不是项目成功。
第二，用户持续用。真实合同审查中，有人愿意用，反复用，并且把结果带回工作流。
第三，任务真的变好。比如耗时下降，返工减少，漏审降低，而且能和上线前基线对比。
第四，价值可以复盘。效率、质量、知识沉淀和管理透明度，能形成年度 ROI 故事。
增购时，管理层不会只问"上线了哪些功能"，而会问：AI 究竟对法务的工作方式和效率，改变了什么？
8. 第八个误判，是把功能上线等同于价值实现，同时用过于狭窄的方式看 ROI。
很多人一谈 AI 的 ROI，就会问：替代了几个人？节省了多少人力？这个问题当然重要，但如果只看人力替代，法务 AI 的很多真正价值会被低估。
法务 AI 的价值至少有四类。
第一是效率价值。比如一份合同审查从 60 分钟降到 30 分钟，法务可以把时间投入到更复杂的问题上。
第二是风险价值。比如过去容易漏掉的高风险条款，现在能被提前发现。这个价值未必每次都能直接折算成人力，但对企业非常重要。
第三是知识价值。资深法务的审查口径可以被新人复用，团队经验不再只停留在个别人脑子里。
第四是管理价值。法务工作变得更加可度量。哪些合同最耗时，哪些风险最常见，哪些业务线返工最多，这些都可以逐渐被看见。
所以我们不能只问 AI 替代了几个人，而要问：它有没有让法务工作更快、更稳、更可复用、更可管理。如果只用人力替代来衡量法务 AI，很多真正重要的价值都会被低估。
9. 第九个误判，是没有上线前基线。
很多项目一年后想复盘，才发现一个问题：我们说 AI 有用，但没有办法证明它有用。为什么？因为项目启动前没有记录起点数据。
在项目启动前，至少应该先问几个问题：现在一份合同平均审多久？哪类合同最耗时？每月处理多少份？哪些风险最容易漏？返工率是多少？用户满意度和采纳率现在怎么记录？
如果这些问题一开始没有答案，一年后就会很尴尬。没有起点数据，没有对照组，效果追踪也断断续续，最后只能说"大家感觉还不错"。但"感觉有用"和"证明有用"之间差距很大。
所以在正式选型前，企业就应该开始建立基线。哪怕数据不完美，也要先有一套可持续记录的指标。因为，没有基线，AI 项目就很难从"我感觉有用"走向"我证明它有用"。
06现在开始，能做什么
讲到这里，可能有些法总或 GC 会问：那我们现在还没正式选型，能做什么？
其实不用等到正式选型，现在就可以开始做四件事。
第一，看见影子 AI。很多员工其实已经在用通用 AI 工具处理工作了。不要只把它看成违规问题，也要把它看成需求信号。团队在哪些任务里偷偷用 AI，往往说明哪些任务最痛、最值得先验证。
第二，提前治理数据。合同、审查意见、制度依据、历史口径、专家经验，这些材料越早整理，后面选型越不盲目。否则系统买回来以后，才发现数据散落各处，项目会很被动。
第三，培养翻译官。企业内部需要有人懂法务，也懂 AI 的边界，能把需求写成输入、输出、边界和验收标准。这个角色未来会非常重要，可以理解为法务 AI 产品经理。
第四，接受小步试错。不要一上来就追求大而全。小场景、小样本、小周期、快复盘，先验证，再扩大。用数据决定下一步，而不是用想象决定大范围铺开。
所以，真正成熟的法务 AI 选型，不是等供应商来了才开始，而是在选型之前，企业自己就已经开始理解需求、治理数据、培养人才和建立试错机制。
最后，我想用三句话结束今天的分享。
法务 AI 选型不是买一个更聪明的软件，而是选择一种新的工作方式。 如果只是把 AI 当作一个工具插件，它很容易停留在浅层使用。但如果把它当作新的工作方式，企业就会重新思考流程、数据、知识、角色和评价机制。
真正决定项目成败的，往往不是 Demo 效果，而是场景、数据、人才、组织协同和评价机制。 Demo 可以帮助我们理解产品能力，但不能替代真实业务验证。真正的项目成败，发生在 Demo 之后。
GC / 法总不需要成为技术专家，但必须成为这场变化的持续推动者。法总不需要亲自研究模型参数，也不需要亲自写代码。但必须能提出正确的问题，推动组织准备数据，建立评价标准，培养翻译官，并且持续关注系统是否真的改变了工作方式。
今天分享的这些内容和标准，是我真心送给在座各位的——你们拿它去要求每一家供应商，也包括我们。如果你们已经把要求想清楚了，欢迎来看看：我们是怎么照着这些标准，一锤一锤把 Legato 这款产品做出来的。
欢迎前往aivigate.cn，体验Legato。
如果你正在思考同样的问题，欢迎关注公众号，联系我们，期待与你深入探讨。
如果感到对您有所启发，欢迎点赞或转发
让我们一起，在AI时代，探索无限可能
