一个企业 AI 试点停了。

系统还能打开，知识库也还在，但没人知道下一步该做什么。负责这个项目的人调岗了，接口密码在他手里，知识库的更新规则也只有他清楚。

业务部门说，这是“他的项目”。IT 说，业务没提新需求。项目就停在那里。

我们复盘时发现，问题不是这个人不负责。恰恰相反，他太负责了，负责到项目只有他一个人。

一开始，一个人确实更快

这个项目启动时，他是最合适的人选。

懂业务，愿意折腾工具，能自己整理资料，也能直接和供应商沟通。很多决定他在现场就拍了，不用开会。

前两个月进展很快。系统能查资料、能写摘要，试用的人也说方便。

大家默认这是一种好状态：效率高，沟通短，没人拖后腿。

但“一个人跑得快”和“项目能留下来”，是两件事。

他调岗后，问题才暴露

第一个问题，是知识没人更新。

产品资料变了，知识库还是旧的。新来的同事不知道哪些文档该放进去，也不知道谁有权限改。

第二个问题，是接口没人管。

系统接了两个内部服务，账号是个人申请的。人一走，权限回收，接口就断了。没有人知道当初为什么这么接。

第三个问题，是业务不认。

试用时大家说“挺好用”，但那是看他的面子。真正要推广时，业务负责人问了一句：这个项目解决了我们哪个指标？

没人答得上来。

不是人的问题，是项目没有组织位

我们后来把这件事拆开看，发现项目从一开始就缺三样东西。

业务负责人。 不是“帮忙试用的人”，而是能决定场景优先级、验收标准和例外处理的人。

IT 边界。 不是只买服务器，而是把数据、接口、权限和账号归属管清楚。

一线参与。 不是最后被通知“我们上了个 AI”，而是在真实任务里用过，知道哪里不顺手。

这三样缺了，项目就会自然落到一个人身上。不是因为他想揽权，而是因为没有别人接。

交接不是离职时才做

很多项目把交接当成离职流程的一部分。其实从第一天起，就应该知道：如果负责人不在，谁能接手？

至少要留下四样东西：

  • 场景边界和需求说明；
  • 知识和数据清单；
  • 接口、账号和权限说明；
  • 验收样本和运维手册。

不是为了写文档而写文档。是为了让第二个人不用从头猜。

小试点也需要第二个人

有人会说，第一版就是小范围试，没必要搞这么重。

小范围可以，但不能只有一个人知道全部。

哪怕只多一个人：一个业务备份，一个 IT 接口人，或者一个愿意一起试用的同事。关键时候能接上，项目就不会因为一个人离开而停摆。

复盘后的改变

这个项目后来重新启动了，范围比原来小。

先只做一个任务：售后常见问题查询。业务负责人固定，IT 接口人固定，知识库每周更新一次，验收题从真实问题里抽。

没有原来那么“聪明”，但至少不再依赖某一个人。

企业 AI 落地不是买一个系统，而是改变一部分工作方式。只靠一个人推动，改变很难留下来。

如果你在搭 AI 项目组，可以看我们的企业 AI 诊断与陪跑，也可以从企业 AI 落地为什么总停在试点开始，先看项目有没有第二个人能接手。