19 谁来负责 AI 转型

19 谁来负责 AI 转型

一家公司决定上 AI，半年过去，我去问：这事现在谁在管？得到的答案通常是四个人互相指。老板等 IT 给方案，IT 等业务提需求，业务等 HR 改岗位，HR 等老板拍方向。

会都开了，系统也上了一点，培训也做了一轮。但真正的问题还在原地：这条流程谁改，系统谁建，结果谁背？

这个问题没人回答，AI 转型就是一个很热闹的空场。

这件事在现实里通常有两种坏法。

两种半截工程

第一种坏法，是把它做成 IT 项目。

系统上线了，接口打通了，测试通过了，供应商也交付了。可业务部门回到日常工作里，发现这个系统不是他们真正需要的东西。它能跑，但没人用。或者有人用，但流程没改，结果没人验收。CIO 说系统没问题，业务说系统不解决问题，项目就挂在中间。

这不是 CIO 的错。是组织里没人负责把业务问题翻译成系统要做的事，也没人负责把系统能力翻译回业务能用的流程。两头都缺一个翻译。

第二种坏法，是把它做成 HR 培训。培训做了，工具课上了，员工也开始试。年底汇报里有使用率，有学习人数，有优秀案例。但老板问一句：哪条流程被改写了？哪个岗位的交付结果变稳定了？哪些经验沉淀成组织能力了？

答不上来。这笔账不该记在 CHO 头上。根子在组织把 AI 转型当成了个人能力提升，不是组织系统改造。

美团“养虾”以后，谁来把这件事接住

美团的王莆中，在一次由网易转载的公开演讲中，回看了美团 2026 年上半年的 AI 推进。他把随着 OpenClaw 兴起开展的一轮使用和科普叫“养虾”——先把 AI 发下去，先让人用起来。可工具一热，真正的账就冒出来了。按他的讲述，成本、权限安全和错误输出随后开始给真实经营施压；4 月起，公司开始从顶层思考 AI 转型、在各大事业部设置 AI 组织；到六七月，大量项目一边赛马，一边梳理方法。¹

这就是 AI 最容易把公司带进去的场面：人人都在养虾，没人先把三笔账摊在桌上——钱谁付，门谁守，AI 说错话以后谁把它拉回来。别急着把这句话读成对美团的褒贬；公开叙述也不足以支持那样的结论。但他后面把话说得更直：企业 AI 变革不是丢给 CTO、CIO 或产研的技术项目，是业务、组织、技术结合的一号工程；落到具体流程，HR、业务、技术必须绑定。²

所以真正值得照镜子的，不是“美团也在养虾”，是你们公司现在这件事谁来接住。把 AI 当 IT 项目，流程没人接；把它当 HR 培训，岗位和绩效没人改。最后就会变成一场所有人都很忙、没人背结果的组织表演。工具可以先发，责任不能后补。

两种坏法看起来不同，本质一样：角色界面没有画清楚。

所以在明确一号位必须亲自抓什么之后，还得补一张责任界面表。不是为了给每个人划地盘，是为了防止组织把 AI 转型拆成几个互相甩锅的半截工程。

AI 转型不是 IT 项目，不是 HR 项目，也不是业务部门自己摸索。它是一项组织工程。组织工程的第一步，是把角色边界说清楚。上一章的五个角色是转型核心五角；这里把治理负责人补进来，展开完整的六类责任图。所以先别急着看下面六个角色写了什么，先在心里回答一句：你们公司现在这两种坏法，正在犯哪一种。

六类角色，各自回答什么

CEO，也就是一号位，负责回答组织目标。这个组织到底要变成什么样？AI 进来以后，哪些业务功能要被重写？公司先要降本、增产、提质，还是先要把组织能力沉下来？哪些组织代价能承担，哪些不能？

这些问题不能外包。因为它们不是专业建议，是经营取舍。CHO 可以提醒组织代价，CIO 可以提醒系统风险，业务 owner 可以提醒现场约束。但最后谁来定目标、定优先级、定授权？

答案只能是一号位。

如果一号位只说“你们去推进 AI”，但不回答组织要变成什么样，下面所有角色都会进入猜测状态。猜老板想降本，员工就防御。猜老板想创新，业务就做 Demo。猜老板想要短期数字，IT 就赶上线。组织会按不同猜测各自行动。

这就是失控的开始。

CHO 负责回答组织怎么接住。不是办培训，不是统计使用率，不是在能力模型里加一句“熟悉 AI”。这些事可以做，但不是核心。

CHO 真正要管的是五件事。人机搭配以后，岗位职责怎么重新设计。绩效怎么从看过程改成看结果。员工凭什么愿意把自己那套业务上下文交出来。组织记忆靠什么沉下来。员工的信任靠什么保住。

归结起来，CHO 要管的是人和机制。

AI 进流程以后，谁的工作被改变了？谁的判断还必须在场？谁的贡献过去看不见，现在要被记录？员工把自己的经验喂给组织 AI 以后，是被放大，还是被替代？

这些问题 IT 回答不了。

这里最容易被低估的是最后一条。我见过的岗位重写卡点，多数不是 JD 写得不好，是员工根本不知道这场变化要他怎么配合，再加一层担心：这是不是替代的前奏。员工不是天然反 AI，是不知道 AI 会把自己的工作改成什么样。这两层没处理，只改职责表，就是纸面变革。

如果 CHO 不接，AI 转型就会停在工具层。员工学会了 AI，组织没有变聪明。个人变快了，知识还是散的。系统跑起来了，信任却掉下去了。

CIO 负责回答系统怎么稳。系统能不能接 AI，哪些数据可以开放，权限怎么分级，日志怎么留，安全怎么兜，技术债怎么控——这些是 CIO 的主场。

CIO 不该替业务决定流程怎么改，也不该替 HR 决定岗位怎么变。但技术底座必须由他守住。系统不能为了一个漂亮 Demo 把未来搞烂。数据不能因为业务想快就随便开。AI 输出不能绕过审计直接进关键流程。

CIO 的一句话标准是：系统能不能安全、稳定、可追溯地跑。

这件事不能交给供应商，也不能交给业务部门凭热情推进。供应商倾向于多接，业务倾向于快上，只有 CIO 必须对系统三年后还能不能跑负责。

业务 owner 负责回答真实问题。这是很多 AI 转型最容易漏掉的角色。

业务 owner 不是“提需求的人”。他应该是那条流程的现场负责人：知道哪里慢，哪里贵，哪里错不起，哪里只是看起来能自动化，实际承载客户关系、责任边界和组织记忆。

让最懂 AI 的人去找业务场景，容易做成拿锤子找钉子。更好的顺序是：让最懂业务的人，拿 AI 去重写自己的现场。

因为真实损耗在现场，隐性规则在现场，例外处理在现场，客户情绪和历史关系也在现场。

业务 owner 要交付的不是“我支持 AI”，是清楚说出：这条流程要改哪里，改完以后用什么结果验收，出了问题谁承担业务后果。

没有业务 owner，AI 转型会变成系统上线和部门配合。听起来有分工，实际上没有人背结果。

AI 转型负责人负责翻译和闭环。这个角色最容易被做成协调员。协调员负责开会、催进度、汇报材料，AI 转型负责人不能停在这里。

他要做的是组织翻译，两个方向都要翻。往里翻：把业务那句模糊的“我们这块能不能用 AI”，翻成流程节点、系统要求、责任边界和验收指标。往外翻：把系统的真实能力翻回业务听得懂的话，告诉业务哪些能做，哪些不能做，哪些能做但风险不能接受。

他还要做闭环。系统上线之后，反馈有没有回来？错误模式有没有被记录？context 有没有沉淀？规则有没有更新？下一条流程能不能因为上一条流程的经验跑得更快？

这个角色缺一块就会歪。没有 CEO 授权，他只是会议秘书。有授权但不懂组织，他会把事情推成项目管理。有授权也懂组织，但不懂 AI 的能力边界，他会被供应商和技术术语牵着走。

所以这个角色的门槛不是头衔，是三件事：懂业务现场，懂 AI 能力边界，有组织授权。三件缺一件，这个位子就白设了。

治理负责人负责规则、权限、审计和例外。这四件事听起来像刹车，其实是在让 AI 能被大规模用起来。哪些场景自由使用，哪些抽检，哪些复核，哪些走审批，哪些干脆禁止？谁能让一个 AI 工作流上线？出了问题谁有权叫停？日志留在哪里？复盘怎么启动？例外怎么申请？

这些问题没人管，AI 应用就会自由生长。短期看很创新，长期看会变成权限、数据、质量和责任的烂账。

治理负责人不一定是一个独立部门。它可以挂在现有治理、法务、IT 风控或者 AI 转型办公室里。关键不是名字，是这四件事有人固定接住：规则、权限、审计、例外。

六类角色说完了，它们不是六个新增岗位。可以由现有岗位承担，也可能需要分工；兼任时要说明权限、资源和彼此制衡如何保留，不能让提出方案的人顺手包办独立验收。

第十三章引入的三类治理实践，在这里可以拿来检查职责表：结构上，谁被授权、能调什么资源；程序上，授权如何进入日常运行、变更和异常处置；关系上，受到影响的人能不能理解、提问并影响安排。填一个名字，只是开始找接口，连第一方面是否成立都还没证明。

一个用得上的验证方法

上面这六个角色写出来，看起来很整齐。但组织里最常见的情况是：表填完了，六个格子都有名字，转型照样空转。

填上名字和真接住这件事，中间隔着很远。

有一个办法可以快速检验这张表是不是真的。别从角色往下问，要从事故往回问。

挑一件 AI 已经参与的、有真实业务后果的事——一次对外的报价、一封客户回复、一份进了审批流的材料。然后按顺序问四个问题：谁下达的指令，AI 接触了哪些数据，AI 输出了什么，谁把这个输出推进了下一步。

这四个问题与第十三章的事实链相接，用来重建从指令到输出被采用的过程。记录接得上，可以继续查是谁依什么权限作出安排；记录接不上，就先补证据。能还原发生了什么，不等于权限、控制和责任都已有效。

我见过的情况是，大多数公司在第四问上卡住。前三问都能答：指令是某个业务同事下的，数据在系统里查得到，输出也留了记录。但”谁把这个输出推进下一步”——这一环经常没人答得上来。它不是被谁隐瞒了，是这一步在流程设计里就没有被当成一个需要署名的动作。它被默认成一个流转。不是一次放行。

推进下一步的动作，要能够追到它所依据的授权。可以是当次人工批准，也可以是在约定范围内自动执行；不能因为当时没有人点按钮，就说责任悬空。真正要查的是：谁批准这种运行安排，范围有没有被守住，出了异常谁能介入，结果由谁持续承接。

所以责任界面表还要填：这条流程允许怎样推进输出，依据在哪，谁能调整或暂停这个安排。

异常也按第十一章的控制规则查。哪些可由系统按已核定的规则处理，哪些超出能力、权限或损失承接范围，必须升级到有权处理的人？自动处理是否有效，要看处置记录与结果；升级给人也要确认对方能及时处理，不能让通知代替解决。

日志记录了异常，只说明它被记下；处置完成并留下可用于更新的依据，才有可能进入组织学习。

这两问——谁放行，什么必须升级——比六个角色的职责描述更能说明一家公司的准备程度。职责描述可以照抄，这两问答不上来就是答不上来。

OIO 只是可选机制

至于 OIO 这种说法，要降噪。

先把这三个字母拆开。OIO 全称是组织智能办公室，一个专管“人加 AI 怎么一起干活”的机制³。名字是我起的，不是行业标准。

新部门不是前提。先核现有安排能否接住工作单元台账、上线与退役、把关标准、跨部门冲突和错误模式复盘；接得住，就不必换牌子。确有空白，才讨论补职责、补资源，还是另设协作机制。

每项职责都要有可找到的接口和实际履行条件。光有五个名字不够，光有一个办公室也不够。

开一场责任界面会

老板下周开会，可以直接拿下面这张表。表填不出来，说明组织还没准备好大规模推进 AI。填出来了但没有授权，说明它只是讨论稿。填出来了也有授权，下一步才是选一条流程，做 90 天试点。

这张表不妨试着用一场90 分钟的责任界面会讨论。下面的时间分配是一种主持建议，不是经过验证的标准工时；复杂流程可能需要会前取证和后续专门讨论。

第一段 20 分钟，一号位只讲目标和边界。这次 AI 转型优先解决什么，不解决什么。是先降本，先增产，还是先把质量和稳定性提上来。哪些组织代价现在不能碰。

第二段 30 分钟，业务 owner 讲现场：流程哪里慢，哪里反复返工，哪里错不起，哪里看起来可以自动化、其实底下压着关系和责任。这个环节不能让技术先讲方案，否则整场会都会被工具带走。

第三段 20 分钟，CHO 和 CIO 分别讲承接条件。CHO 讲岗位、绩效、信任和 context 怎么接住。CIO 讲系统、数据、权限和审计能不能支撑。两个人不是互相汇报，是在同一条流程上对齐边界。

最后 20 分钟，AI 转型负责人把这张表收口：谁改流程，谁建系统，谁复核，谁验收，谁对结果负责，哪些信息必须进组织记忆。

会开完，如果只留下一份“继续推进”的纪要，这会就白开了。散会时必须留下三样东西：一条被选中的流程，一个明确的业务 owner，一张责任界面表。

没有这三样，AI 转型还在空转。

这里要特别防一个误读。

责任界面表不是让总部多一层审批，也不是让某个新办公室骑到业务头上。它的作用恰好相反：把每个角色能做什么、不能做什么提前说清楚，减少暗战，减少扯皮，减少出了问题以后临时抓人背锅。

好的责任界面要减少无效往返，但不会消灭摩擦。必要的复核、异议处理和跨部门协调都要花时间，也可能改变原来的方案。该比较的是：这些投入避免了哪些损失，是否值得，而不是会开得越少越好。这也呼应了第十三章的关系性治理：参与有成本，意见进入决定才有意义。

工具：AI 转型责任界面表

这张表别当模板存档，下周就拿去填。先填最后一列——每个角色不能越界什么。这一列比前三列难填，也比前三列值钱：能做什么大家都愿意认，不能做什么才是真界面。

CEO 亲自抓，不代表 CEO 亲自干所有事。真正要画清的，是每个角色回答什么问题、交付什么结果、不能越过什么边界。责任界面越早清楚，AI 转型越不容易变成一场互相等待，也越不容易在出事以后临时找人背锅。