AI项目验收只是起点，真正的难题是后续运营
最近拜访一位CIO朋友，他向我展示了一个已经成功落地的AI试点项目。
这是一个合同审查工具。业务部门上传合同后，系统自动识别付款条款、违约责任、履约周期和风险条款，并给出审查建议。
试点数据表现优异。
准确率接近九成，法务复核时间显著缩短，汇报时领导也很认可。
他问我：“这个项目，现在算成功了吗？”
我问他：“现在谁在负责规则维护？”
他停顿了一下，说：“目前还是项目组在跟进。”
我又问：“合同模板变化了谁更新？风险条款遗漏了谁补充？业务部门不采纳建议谁来做复盘？”
他没有立即回答。
这就是众多企业AI试点成功之后最常面临的困境。
试点能跑通，说明AI在特定场景中验证了可行性。但可行性不等于可持续，更不等于可复制。
许多企业将AI试点当作项目来推进。启动、开发、测试、上线、验收，验收通过就觉得大功告成。
但AI能力不是普通的交付物。
合同模板会更新，业务规则会调整，数据口径会变化，用户使用方式也会改变。只要这些在变化，AI的输出质量就会受到影响。
因此，AI试点跑通之后，企业最需要的不是更多的演示版本。
而是运营。
更准确地说，是一套让AI能力持续被校准、被更新、被追责、被复用的运营体系。
我见过太多类似的情况。
一个AI试点做得很出色，汇报时领导说继续推广，业务部门也觉得挺好。但三个月后再看，试点还停留在原来的部门，规则没有更新，样例没有补充，问题没有跟进，使用人数也没有增长。
不是试点失败了。
而是企业没有从项目交付模式切换到能力运营模式。
项目交付看的是有没有上线。
能力运营看的是上线之后有没有人持续维护、持续校准、持续复盘。
某企业曾做过一个智能合同审查试点。测试集上准确率达到92%，审批效率提升近三倍。试点汇报时数据很漂亮，团队也信心满满。
但三个月后，推广只覆盖了两个部门。合同模板库无人维护，审查规则还停留在试点版本，业务部门新增的几类合同没有纳入规则库。
AI仍然能运行。
但它运行的是旧规则。
这比完全不能运行更棘手。因为完全不能运行的问题容易被发现，按旧规则运行的问题反而容易被误认为系统运转正常。
这里有一个反直觉的判断：
一个没有运营的91%准确率AI，可能比一个有人运营的80%准确率AI更危险。
因为后者知道自己哪里不准确，什么时候该停下来，出了问题谁来修正。
前者看起来很准确，但一旦业务发生变化，它会稳定地把错误带入流程中。
许多企业以为AI的核心问题是“准不准”。
但试点之后，真正的问题变成了：
谁让它持续保持准确？谁发现它不准确？谁决定它什么时候该停止使用？
这不是模型问题。
这是运营问题。
许多企业不是不知道运营的重要性，而是组织机制不支持运营。
IT部门负责系统上线，业务部门负责提出需求，风控或法务部门负责审查风险。表面上看分工明确，但AI能力上线之后，恰好落在几个部门之间的空白地带。
规则变化了，业务说这是系统配置问题。
系统出错了，IT说规则是业务提供的。
风险暴露了，风控说上线前没有充分评估。
结果就是，上线有项目经理，验收有负责人，但持续更新规则、维护样例、复盘误判、调整边界，往往没有明确归属。
更现实的是，许多企业的考核奖励的是“项目上线”，而不是“上线后持续有效”。
上线可以汇报。
验收可以签字。
效率提升可以写进总结。
但规则维护、问题复盘、样例更新、边界调整，往往被看作琐碎工作，甚至被降格为运维事项。
所以AI试点容易停留在演示阶段，不只是因为大家不努力，而是因为组织天然把“上线”当成果，把“运营”当杂活。
这才是问题的根源。
如果不改变这个逻辑，再好的试点也会在热闹之后逐渐冷却。
前文提到，一个AI试点完成之后，应该留下几类东西：场景判断标准、高质量样例、规则和边界、问题清单、复盘记录、可复制的方法。
这些东西不是为了写总结报告，也不是为了验收归档。
它们真正的用途，是支撑后续运营。
场景判断标准，解决的是下次遇到类似场景要不要上AI的问题。它不应该只是文档，而应该变成筛选流程。类似场景来了，谁来判断，用什么标准判断，风险怎么评估，都要有依据。
高质量样例，解决的是AI能力有没有退化的问题。模型升级、规则调整、模板变化之后，要用这些样例重新测试一遍。以前能识别的风险现在识别不出来了，就说明能力在退化。
规则和边界，解决的是AI在什么情况下可以判断，什么情况下必须停下。试点期间发现AI不准确的场景，往往比AI准确的场景更有价值。因为它决定风险在哪里。
问题清单和复盘记录，解决的是持续优化的问题。AI被人工修改了，建议被业务拒绝了，输出无法进入流程了，这些都应该变成问题项，而不是散落在微信群和会议纪要里。
可复制的方法，解决的是这个试点能不能变成下一个场景的起点。真正有价值的不是这个场景做成了，而是做成这件事的方法可以被复用。
如果这些东西只是放在共享文件夹里，它们还是材料。
只有进入规则库、样例库、问题看板、权限配置和责任机制，它们才会变成运营工具。
德鲁克讲过一个很朴素的方法，叫反馈分析：做一件事之前，先写下预期结果；一段时间后，再拿实际结果来对照。
这个方法放到AI运营里非常适用。
AI给出建议时，企业不能只看当下答案是否像样，而要记录它的预期判断、实际结果、人工修正和后续影响。
只有这样，AI的每一次使用才不是一次消耗，而是一次能力校准。
我更愿意把AI运营能力分成三层。
第一层，让AI会跑。
第二层，让AI不乱跑。
第三层，出事了有人扛。
这比“规则运营、样例运营、问题运营、权限运营、责任运营”更好理解。
因为企业真正需要的不是几个运营名词，而是一条能跑起来、管得住、兜得住的能力链。
第一层，让AI会跑。
这靠规则、样例和问题反馈。
一家企业做发票自动匹配。发票来了，AI自动匹配采购订单和入库单，匹配成功就入账，匹配失败再推人工处理。试点阶段表现很好，匹配率达到91%。
上线第三周，问题出现了。
有一批发票被AI匹配到了错误订单，但没有触发任何拦截，直接入了账。
财务负责人后来复盘时说了一句话：“它不是没跑，是跑得太顺了。”
原因是这批发票来自新业务线，订单号不在原来的规则库里。AI按相似度匹配到了一个老订单，流程走通了，但账记错了。
这不是模型突然变差。
是规则没有覆盖新业务。
规则库里没有的东西，AI不会天然知道自己不知道。它会继续给答案。它会猜。猜对了看起来很聪明，猜错了就是风险。
所以，运营的第一层不是“让AI更智能”，而是让AI的规则、样例和问题反馈持续更新。
规则要更新。业务变了、流程变了、政策变了，规则库就要跟着变。
样例要更新。合同审查里那些典型风险条款，发票匹配里那些容易误判的订单，供应商评分里那些边界案例，都应该进入样例库。每次规则调整、模型升级、模板变化，都拿样例库跑一遍。
问题也要更新。AI被人工改了，建议被业务拒了，输出没进流程，这些都不能只是口头反馈。它们要进入问题看板，变成下一轮优化的输入。
会跑，不是指系统能执行。
会跑，是指能力能持续更新。
第二层，让AI不乱跑。
这靠SOP、权限和模板。
试点阶段，三五个人用，问题还不明显。推广到多个部门之后，谁能用、能看到什么、能改什么、能不能让AI执行动作，都会变成管理问题。
比如合同审查Skill，可以允许业务人员发起初审，但风险条款修改必须由法务确认。
发票匹配Skill，可以允许系统自动推荐匹配结果，但超出规则边界的发票必须进入人工复核。
供应商评分Skill，可以给出建议等级，但降级动作必须由采购负责人确认。
这些不是技术配置。
这是管理政策。
SOP解决怎么做。
权限解决谁能做。
模板解决做成什么样。
如果没有这一层，AI能力就会在推广中失控。
有人把建议当结论，有人把辅助当审批，有人把参考结果直接写进流程。最后出了问题，大家才发现，系统虽然上线了，但使用边界从来没有被定义过。
不乱跑，比会跑更重要。
因为企业真正怕的，不是AI什么都不做，而是AI做了不该做的事。
第三层，出事了有人扛。
这是最容易被忽视的一层，也是最关键的一层。
AI给出建议，谁背书？
AI误判了，谁复核？
规则过期了，谁更新？
边界需要调整，谁拍板？
异常发生了，谁兜底？
如果这些问题不上线前说清楚，出事以后再追责，就一定会变成扯皮。
责任运营不是为了找人背锅，而是为了让AI能力可以持续运转。
一个AI能力如果没有责任人，就会慢慢变成大家都觉得有用，但没人真正维护的东西。
最后它不是坏掉，而是被遗忘。
开头那位CIO问我：“这个项目现在算成功了吗？”
如果按试点标准看，算成功了。
准确率不错，效率提升明显，业务也认可。
但如果按运营标准看，还没有。
因为规则没人长期维护，边界没人持续校准，异常没人明确兜底。
AI试点真正成功，不是准确率达标。
而是有人管规则，有人审边界，有人背责任。
一个试点跑通之后，第一件事不是扩大范围，而是建立运营机制。
第一，把试点沉淀物从文件变成工具。
规则边界、问题清单、复盘记录，最好直接进入AI系统或管理看板，而不是放在共享文件夹里。
沉淀物不能被调用，就只是档案。
第二，明确维护责任。
规则变了，谁更新规则库？
模板变了，谁维护样例？
误判了，谁修正并记录？
边界冲突了，谁决定是否调整？
这些责任要落实到具体角色，不能只写业务部门负责或IT部门负责。
第三，建立反馈循环。
AI做完一次动作，不是结束，而是开始。
结果对不对，用户满不满意，边界需不需要调整，规则是否覆盖，输出有没有被人工修改，都要进入反馈循环。
运营不是偶尔检查一次，而是每次使用都在产生数据，每个数据都在优化下一次输出。
第四，把Skill变成标准组件。
试点阶段封装的Skill，上线运营后要进入企业的能力仓库。
以后任何业务场景需要调用这个能力，不需要重新发明，只需要引用、配置和验证。
Skill是企业AI能力的最小运营单元。如果一个Skill只能在一个试点里用，它只是项目成果。如果它能被多个场景调用，它才是企业能力。
第五，补齐SOP、权限和模板。
谁可以调用这个AI能力，什么条件下可以直接使用，什么情况下必须人工复核，输出结果用什么模板进入流程，都要明确。
这一步看起来不像AI，但它决定AI能不能进入企业日常运转。
不做这一步，AI永远是某个部门的锦上添花，不是企业的系统能力。
企业AI落地的关键转折，是从项目交付思维转向能力运营思维。项目交付的终点是验收，能力运营的起点是上线。
交付是一次性的，运营是持续性的。
交付看好不好用，运营看好不好管。
这个转变，不是技术团队能独立完成的。它需要业务部门、IT部门、风控部门一起，把AI当成一条新的能力生产线来管理，而不是当成一个新工具来使用。
生产线有标准操作规程，有质量检测，有故障处理流程，有持续改进机制。
AI运营也一样。
试点跑通之后，企业真正要思考的是：能不能像管理一条生产线一样管理这条AI能力？
能做到，AI就不再是一个项目成果，而是一套可复用的生产能力。
做不到，再漂亮的试点，也只是一段留在汇报PPT里的高光时刻。
生产线停机会出废品。
AI运营断了，出的是看不见的坏账。