企业AI转型谁来负责？CEO、业务、IT与AI CoE如何分工与协同

一句话看懂：企业AI转型的组织难题不在模型，而在跨部门权责如何分配。CEO应牵头战略牵引与跨部门协调，但具体场景的业务责任必须交给业务负责人。通过RACI分工明确决策权，业务Owner对场景选择、流程修改与经营结果负责，IT与平台负责系统稳定与权限，AI CoE负责统一需求入口、共享标准与业务赋能，风险合规拥有独立审查权。集中还是放权取决于业务风险与团队成熟度，上线流程须先验证业务问题、重设计工作流、分开业务评测与安全审查，并由证据决定扩展或退出。

一、CEO应该牵头企业AI转型，但不意味着所有项目都由CEO管理

企业AI转型最容易遇到的组织难题，不是找不到模型，而是跨部门的工作如何重新分配：销售团队希望缩短客户跟进时间，IT需要控制系统权限，法务担心敏感信息泄露，人力资源部门则要考虑员工如何接受新的工作方式。如果这些问题没有共同的决策人，AI项目即使上线，也可能只是一件没人愿意长期使用的新工具。

因此，Runwise的判断是：CEO或一号位应当对企业AI转型承担战略牵引与跨部门协调责任，但必须把具体场景的业务责任交给业务负责人。 对大型集团，CEO可以授权COO、CIO、首席数字官或专职AI负责人统筹日常推进；授权不能使业务目标、预算优先级和部门冲突成为无人负责的事情。董事会、风险管理和合规部门的监督职责，也不会因为CEO牵头而消失。

这一判断有研究依据，却不是放之四海皆准的组织公式。麦肯锡2025年《AI现状》调研发现，CEO监督AI治理与企业自报的生成式AI利润影响存在相关性，28%的相关受访者表示由CEO监督AI治理；同一研究也指出，重新设计工作流程，是其分析的25项组织因素中与利润影响关联最强的因素。这些是问卷调查和统计相关性，不能证明只要CEO担任负责人，AI投资就必然成功。

2026年8月，麦肯锡最新调研给出了更现实的提醒：80%的受访者报告AI提升了个人生产率，但只有37%报告AI对所在企业的息税前利润（EBIT）产生正面贡献。两项都是受访者报告，而不是独立核算的全部企业财务数据。个人工作更快，不等于企业流程已改变，也不等于经营收益自动兑现。

CEO真正需要做的，是确定哪些业务结果值得投入、哪些部门必须一起改变，以及失败时谁有权调整方向。CEO本人了解AI的能力与局限、在高管团队中示范实际使用，会有帮助；但“带头”不能变成要求每个部门比拼Agent数量。否则，技术使用的热闹反而可能掩盖业务价值不足。

二、CEO、业务、IT与AI CoE如何分工：把职责落实到决策权

原来常见的分工表会写：CEO管战略，业务管需求，IT管技术，CoE管标准。这还不够。企业真正发生争议时，需要能回答更具体的问题：谁有最后决定权？谁执行？谁必须参与审查？谁只需要了解结果？

可以借助RACI方法，把每项关键事项分配给具体岗位。其中A是最终责任人（Accountable），R是执行人（Responsible），C是被征询方（Consulted），I是知情方（Informed）。每一项决策只设一个A，但可能有多个R。下表是Runwise结合微软Agent卓越中心指南整理的建议分工，并非所有公司的法定组织标准；企业应根据现有授权体系调整到具体岗位，而不是停留在部门名称上。

表中的“风险／合规审批人”应按具体事项落实到一个获得授权的岗位，安全、法务及风控人员仍需按各自职责参与；不能由三个部门笼统共享一个最终责任。另有两个需要注意的边界。首先，业务验收通过不等于已经获得安全合规放行；一个会生成正确销售建议的Agent，如果越权访问客户数据，仍不能上线。其次，“项目投资是否继续”与“发生安全事故时是否立即停用系统”是不同决策，不能混用同一张审批单。

业务负责人应对场景选择、业务流程修改、员工采用以及能够核实的经营结果承担责任。IT和平台团队负责系统稳定、集成、身份与权限、监控及恢复能力。CoE提供共用方法、评测工具、标准和跨部门协同；它不应该自动成为所有业务应用的唯一开发团队。安全、法务及风控应拥有独立的审查与紧急处置职责，不能被简单归并为IT的附属环节。

例如，销售副总希望AI自动整理客户拜访记录。谁来界定记录是否准确、销售人员是否真正使用、客户跟进是否改善？应是销售业务负责人。谁来决定可以读取哪些客户信息、如何接入CRM、如何保留操作日志？需要IT、数据管理和安全团队共同处理。CEO只有在多个部门对预算、客户数据边界或考核调整无法达成一致时，才需要介入裁决。

三、AI CoE究竟怎样运作：不是替业务做项目，而是让项目能持续运行

AI卓越中心（AI Center of Excellence，简称AI CoE）与AI Office的名称、编制并没有统一定义。它们可以是专职部门，也可以是跨部门虚拟团队。关键不在牌子，而在企业是否有人持续负责统一需求入口、共同标准、业务赋能与结果复盘。

第一，CoE要管理需求入口。业务部门提出场景时，应说明要改变的流程、现有基线、预期价值、需要访问的数据、相关负责人和初步风险。CoE将这些需求放进同一个可见的优先级清单，检查是否重复建设，帮助管理层选择先做什么、暂缓什么，而不是按哪个部门催得急来排队。

第二，CoE要建设可复用资产。企业不应让每个部门重新解决模型接入、用户身份、知识库更新、评测样例和使用日志等共同问题。可统一建设的包括经过批准的技术平台、常用连接器、提示词及Agent模板、数据权限规范和上线检查方法。共享的是标准和基础能力，业务知识质量与具体使用效果仍需业务Owner负责。

第三，CoE要形成持续的运营节奏。Runwise建议：每周看新增需求、故障与使用反馈；每月讨论跨部门优先级、成本及异常；每季度评估哪些应用值得扩大、哪些应改善或退出。它们是管理建议，不是行业强制频率；已有经营会议可以承接这些工作，无须额外制造一套只为AI开会的组织体系。

第四，CoE要帮助业务形成自主实施能力。它应组织业务专家参与评测，培训关键用户，建立经验共享方式，使成熟的低风险场景可以由业务团队自行迭代。一个CoE的好坏，不能只看自己开发了多少Agent，还要看业务应用是否持续使用、质量是否可控，以及共同资产是否减少了重复投入。

这些事情必须落实到可复核的管理节奏。微软2026年更新的CoE运行指南建议将每周运行情况和需求排查、每月重点项目与风险复盘、季度价值与成熟度审查衔接起来，并明确这只是可调整的管理起点。Runwise建议把每次复盘的结果落实为三种决定：继续投入、修改范围、停止或退出；会议纪要至少记录责任人、待解决问题与下次复核条件，而不是只展示“本月上线多少Agent”。

真实企业也在沿着这条思路探索。微软2025年发布的阿根廷Banco Ciudad银行客户案例介绍，该行建立AI CoE统筹AI路线，先以约1000个Copilot许可启动试用，技术、资产保护、客户体验、内部沟通和培训等部门参与；随后约六个月内开发了十余个AI Agent。银行负责人在案例中自报，呼叫中心情感分析应用每月节省超过1.45万美元。这里的节省数据来自供应商发布的客户案例及银行管理人员陈述，不能将其认定为独立审计结果，也不能据此推算CoE单独创造了多少利润。它可供借鉴的是跨部门协作方式，而不是工具数量。

何时需要专职AI Office？不必设“超过多少员工”或“有三个部门、满足两个条件”等通用硬门槛。当多个业务单元出现重复采购、重要系统开始接受AI执行操作、或管理层已无法统一掌握投入与效果时，就有理由设立稳定的专职能力。规模较小、应用有限的企业，可以先让一名被授权的高管协调IT、业务与风控人员组成虚拟团队；真正的升级信号，是治理与复用工作量已经超出兼职团队的承载能力。

四、集中还是放权：根据业务风险和团队成熟度选择AI组织模式

企业AI转型不必只有一种组织结构。微软的Agent卓越中心指南把常见安排分为集中式、混合式和联邦式，并指出许多企业会因场景不同同时使用几种模式。麦肯锡对金融机构的研究也认为，早期适当集中有利于建立共享能力，但随着业务团队成熟，交付权可以逐步下放。

因此，真正值得集中的是身份权限、安全基线、数据分级、公共技术平台、Agent登记、审计要求和风险分级标准；应该尽量交给业务的是选择场景、设计工作流程、维护业务知识、组织用户采用，以及定义和复盘业务指标。集中管理不等于中央团队包揽开发；联邦交付也不等于可以绕开安全基线。

对于Agent，还要进一步按能做什么区分风险。Gartner在2026年5月提出四级自主程度：只能读取和观察；能生成建议但由人执行；获得逐项人工批准后执行；以及在约束内自主执行。它们对数据访问、人工审批、日志、回滚和紧急停止的要求不能完全一样。一个仅供员工查询知识的助手，与一个可以修改CRM记录、发送客户邮件或执行采购的Agent，不应经过同样的上线流程。

选择组织模式时，可以先问两个问题：业务团队能否对上线后的质量、采用、异常和成本持续负责？中央平台能否通过权限、监控与评测手段自动落实公共要求？两项都成立，才有条件进一步下放实施权。如果业务只会搭建、不会运营，联邦模式可能只是将风险分散到了多个部门。

五、从业务需求到Agent上线：企业如何跑通一套完整流程

下面这套实施路径适用于涉及业务流程、企业数据或系统操作的AI应用。它是在微软Agent生命周期指南与NIST AI风险管理框架的基础上，经Runwise整合形成的实践方法，不是任何一家企业已经照此完整实施的案例。普通员工使用经批准的通用AI工具，可以采用更轻的管理方式；高风险Agent则需要更严格的审查。

第一步：先确定业务问题，再决定要不要做Agent

业务Owner提交需求时，至少讲清楚原来由谁完成任务、每月大约处理多少、最主要的时间或质量问题、准备改变哪一步，以及希望通过什么指标验证。IT与CoE一起检查数据能否合法合规使用、系统是否具备接口，判断普通搜索、固定规则自动化或现有软件功能是否已足够。不是每个AI需求都值得开发成Agent。

场景评估应把业务价值、技术可行性、数据准备度、实施成本与影响范围放在一起讨论。通过的需求进入可见的优先级清单，暂缓或否决的理由也应记录。这样既能防止重复建设，也能防止高管临时提出的新想法不断挤掉更有价值的工作。

第二步：由业务重新设计工作流，确定人的责任

确定用AI后，不是直接让工程师接模型，而是先画出现有任务怎样从输入走到结果，再明确AI介入哪里、哪些操作只能建议、哪些必须经人审批、异常交给谁处理。业务Owner负责判断新流程能否在实际岗位运行；IT负责数据、权限和系统接口；CoE提供可复用的开发与评测方法。

以客户拜访助手为例，这里给出一个示意情景，并非真实企业的已发生案例：销售人员完成拜访后，由AI从授权的会议记录生成CRM摘要及跟进建议；销售人员检查姓名、客户需求与承诺事项，确认后才写入客户档案；对客户发送的正式沟通仍由销售人员决定。这样的设计比“自动生成一切”更容易界定谁为内容负责。

第三步：用业务评测与安全审查决定能否上线

上线之前，需要把业务质量与系统风险分开检验。业务专家用真实但经过适当处理的任务样本检查答案准确性、遗漏、错误建议和实际可用性；平台团队检查身份与最小权限、异常调用、数据泄露风险及恢复方案。涉及个人信息、客户权益或监管要求时，还需相应的法务、隐私与风控审核。

每个应用的验收阈值应根据业务后果与企业风险承受能力确定，不存在适用于全部Agent的统一“准确率达标线”。尤其是可以对外发送信息或修改业务系统的Agent，必须验证人工审批是否真正有效，并为必要的紧急停用做好准备。评测通过不代表风险审查自动通过，两类结论都要有记录。

第四步：从受控试点进入正式运营，观察实际采用

小范围试点应有明确的使用人群、业务Owner、反馈渠道和对照基线。上线后不只看注册数或账号开通量，还要看真实任务完成次数、返工率、人工审核负担、处理时长及最终业务质量。条件允许时，与原流程或可比团队做对照，避免把业务本来就会发生的变化都归因于AI。

知识库更新、模型或提示词调整、系统接口变化，都可能使已上线应用的表现下降。CoE提供统一的评测与监控方式，业务Owner负责持续反馈与知识校正，平台负责系统可靠性。微软的生命周期指南也强调，Agent上线以后仍需要持续评测、监控、改进或退出，而不是在交付当天结束责任。

第五步：扩大、修改还是退出，由证据决定

当试点确有业务价值、质量稳定、后续维护成本可承受时，再决定扩展人员、部门或权限范围。若实际采用低、返工增加、风险上升或已有更合适的替代方案，就应回到业务流程和技术选择重新判断。长期无价值的应用需要按程序下线、撤销权限、处理保留数据和解除系统依赖；退出不是失败的同义词，而是正常的经营选择。

六、谁对AI投资回报负责，谁有权叫停一个Agent

企业AI项目的ROI不应由IT单独承诺，也不应完全交给CoE汇总。业务Owner对场景的业务收益负责，财务部门校验收益计算口径，IT和CoE提供用量、成本及运行数据，CEO或授权管理层决定跨项目资源分配。 对跨部门共同使用的公共平台，可以由平台或CoE承担成本归集责任，但各业务线仍应说明自身获得了什么价值。企业尤其要区分平台公共成本与某个业务场景的边际成本：不能把全部共享平台建设费用机械压给一个试点，也不能因中央团队付款就免除业务部门对采用和价值的验收。

评估时至少区分三类数据：一是使用情况，例如真正使用的人数和完成的任务；二是业务结果，例如周期缩短、差错下降、客户转化或收入变化；三是全部成本，包括软件许可、模型调用、开发集成、业务专家评测、培训、人工复核及持续维护。声称“节省1000小时”时，还要看这些时间是否转向新的有价值工作，或者确实减少了可支出的成本。时间等效不等于真实裁员，员工更快完成任务也不等于公司利润同步增长。

停用权应分成两类。业务Owner可以根据效果提出暂停推广、缩小范围或永久退出，涉及重大资源配置时按企业授权提交管理层决定；而一旦发生越权访问、安全事故、异常交易或系统故障，事先被授权的平台或安全团队必须能够立即采取技术止损措施，不应等一次经营会议批准后才行动。紧急处置之后，仍要进行事件记录、恢复条件审核与责任复盘。

一个有效的AI决策小组不必庞大。CEO或授权负责人、重点业务Owner、CIO／平台负责人、CoE及必要的风控人员，定期只解决难以在部门内完成的事项：优先级冲突、重大资源分配、跨部门流程改造和重大风险例外。低风险应用的日常迭代应该由已授权的岗位处理，避免所有变更都进入最高层会议。

建议再明确一条升级路径。 当业务Owner与IT对某个场景的可用性、权限或接入方式意见不一致时，先要求双方分别提交业务影响和技术／安全证据；普通实施分歧由已授权的CoE或项目负责人组织解决，涉及新增重大风险、预算或跨部门责任变化的事项再提交相应决策层。风险审核人不能因业务催上线而失去独立的否决权限；同样，IT不应以笼统的“技术上不支持”取代可检验的理由。

对CEO而言，判断企业AI组织是否有效，不是看任命了多少负责人、成立了多少委员会，而是看三个结果：业务部门能不能自己提出并验证真正有价值的场景；IT与CoE能不能让安全、质量和复用成为可持续能力；遇到效果不佳或风险上升时，有没有明确的人能及时修改、暂停或退出。把这三件事落实，企业AI才可能从个人工具使用走向经营流程的持续改善。

数据来源

• The state of AI: How organizations are rewiring to capture value｜McKinsey｜2025-03-12
• The state of AI in 2026: On the road to ROI｜McKinsey｜2026-08-25
• Define roles, responsibilities, and decision rights｜Microsoft Learn｜2026-07-14更新
• Choose your CoE structure and operating model｜Microsoft Learn｜访问于2026-10-10
• Intake and prioritize agent ideas｜Microsoft Learn｜2026-07-14更新
• Manage the agent lifecycle｜Microsoft Learn｜2026-07-14更新
• Monitor, measure, and report value｜Microsoft Learn｜访问于2026-10-10
• Run the CoE operating rhythm｜Microsoft Learn｜2026-07-14更新
• Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure｜Gartner｜2026-05-26
• NIST AI RMF Playbook｜NIST｜访问于2026-10-10
• Banco Ciudad accelerates innovation and reduces time to market with AI｜Microsoft Customer Stories｜2025-05-30
• Scaling gen AI in banking: Choosing the best operating model｜McKinsey｜访问于2026-10-10

想把这套打法用到你自己的业务上？

读完这篇文章，如果你还不确定自己的企业该从哪个场景切入、谁该为结果负责，可以用AI顾问做一次快速诊断，看看你的AI组织分工哪里最可能卡住。

💎 核心承诺：先诊断、再合作，思路不对不推进。

专属咨询热线：400 822 8832

扫码加顾问 Ben 评估