企业 AI 项目谁负责：业务、IT、数据与合规怎么分工

企业 AI 项目的业务成败，应由一名业务负责人最终负责，而不是 IT 部门或外部供应商。项目经理协调进度和决策，IT、数据、安全与合规对各自专业边界负责，一线使用者参与需求与验收，供应商对合同约定的交付负责。角色可以兼任，但最终责任不能悬空。

AI 项目横跨流程、数据、系统和风险，最常见的问题不是缺少参与者，而是同一句「负责」被理解成了不同的事：有人以为负责就是参加会议，有人以为提过意见就拥有否决权，也有人以为供应商接单后会替企业决定业务规则。真正需要的不是更长的参会名单，而是一张能回答「谁做、谁拍板、谁提供意见、谁只需获知」的责任图。

一个项目只能有一个业务结果责任人

业务结果责任人通常是拥有目标流程、预算或经营指标的部门负责人。他决定问题是否值得解决、首期范围在哪里、为哪些残余风险买单，以及试点后继续、调整还是停止。这个角色不需要决定模型或接口细节，但必须能在部门利益冲突、范围变化和资源不足时做取舍。

项目经理与业务负责人不是同一个概念。项目经理维护计划、风险、会议、依赖和变更记录，推动需要拍板的问题及时到达正确的人；业务负责人则对「为什么做、做到什么程度、结果是否值得」负责。小企业里两者可以是同一个人，但文档上仍要分别写清两顶帽子，避免日常协调替代业务判断。

立项前如果找不到愿意承担这个角色的人，项目大概率还只是技术兴趣或模糊愿望。此时应先回答预算、风险、流程所有权和长期运营等问题，管理者批准 AI 项目前需要问的六个问题可作为入口。没有业务结果责任人，不宜让 IT 先做一个版本再等业务认领。

用四种标签区分做事、拍板、会签和知会

责任分配矩阵常用 RACI 四类标记：Responsible 是执行具体工作的人，Accountable 是对该项结果最终负责并拍板的人，Consulted 是决策前必须提供专业意见的人，Informed 是决策后需要获知的人。Project Management Institute 2008 年发布的项目管理论文也用这四类解释 RACI。中文落表时不必拘泥字母，写成做事的人、最终拍板的人、提供意见的人、需要获知的人更不容易误读。

一项工作可以有多个执行者，例如数据工程师整理数据、业务骨干标注样本；但一项关键决策只能有一个最终责任席位。如果范围变更同时写着业务、IT 和供应商三方拍板，遇到冲突时仍然没人能结束讨论。相反，提供意见的人可以很多，但必须说明意见覆盖什么边界，以及最终责任人不采纳时是否需要记录理由。

知会也不是礼貌性抄送。需要获知的人应与后续动作有关，例如服务台要知道新系统何时开放，财务要知道预算口径变化，使用者要知道规则和入口更新。若某人每次都需要提前批准，就不应被写成知会；若只是想了解进度，就不应占用会签席位。

七类角色承担的是不同风险，不是同一种负责人

业务负责人和一线使用者定义问题是否真实

业务负责人拥有目标和范围，一线使用者拥有流程细节。前者决定本期只解决哪一段、可以接受什么权衡；后者提供真实样本、隐性规则、例外情况和复核成本，并参加用户验收。只访谈负责人，需求容易停在「提高效率」；只听一线意见，范围又可能变成所有不便的总清单。两者要共同把问题写成可交付需求，具体字段可参考AI 需求文档的写法。

项目经理、IT 和数据角色把方案放进真实环境

项目经理维护决策链和交付节奏，不替专业角色签字。IT 负责身份、接口、环境、可用性、日志、备份、监控和与现有系统的兼容边界；数据负责人确认数据来源、字段含义、质量、版本、更新责任和访问方式。模型能否给出好答案，只是方案的一部分；账号能否正确隔离、资料过期由谁发现、失败后能否恢复，同样决定系统能否运行。

安全合规与供应商分别守边界和完成交付

安全与合规角色根据企业制度、适用要求和场景风险提出控制条件，审查数据流向、权限、留存、外发、审计与事件处理，不负责替业务判断项目价值。供应商负责澄清技术前提、交付约定功能、说明限制、提供测试与运维资料，并按合同处理缺陷；它可以提出方案，但不能替客户企业决定哪些资料可用、哪些错误可接受。

数据边界需要业务、数据、IT 与安全共同参与，但最终拍板席位仍要明确。业务说明用途和必要字段，数据角色确认来源与质量，IT 验证访问机制，安全合规给出控制要求，授权所有者作最终决定。梳理时可对照使用公司资料前应确定的数据边界，避免把「技术上能读取」误写成「业务上可以使用」。

不要按部门分工，要按六个关键决策点分工

写「业务部负责业务、IT 部负责技术、供应商负责开发」看似清楚，真正开工后仍会出现大片空白。责任矩阵的行应该是可交付物或决策，而不是部门名称。至少把下面六类决策逐项写出四种角色：

• 问题与范围：谁提交现状基线和用户流程，谁批准首期范围，新增场景由谁决定是否进入本期。
• 数据与权限：谁列数据清单、确认质量、批准用途和访问，谁配置账号，发生越权或泄露疑虑时谁停止处理。
• 方案与集成：谁提出技术选项，谁验证架构、接口和运行约束，业务在成本、效果和风险之间由谁作最终选择。
• 测试与验收：谁准备样本、谁执行测试、谁判定业务结果，关键风险项由谁会签，未达标由谁决定修复还是缩范围。
• 上线与回退：谁批准开放用户和自动化等级，谁执行发布、监控与回退，谁通知受影响部门并处理现场问题。
• 运营与变更：谁更新资料、看告警、复核输出、处理异常和批准规则变化，费用、质量与风险分别向谁报告。

每一行还要附交付物和完成证据。比如「数据负责人负责数据」过于宽泛；「数据管理员在试点开始前提交已批准的数据清单、字段说明、质量问题和更新责任人，业务负责人确认用途」才可检查。责任矩阵不是组织架构图，而是让关键决定在需要发生时找到唯一出口。

用一个售后助手场景检验责任是否闭环

假设企业要做一个为售后坐席推荐保修答复的内部助手。业务负责人批准目标：减少查找时间，但首期不得自动发送；售后主管和坐席提供问题样本、当前处理流程与例外规则；数据管理员整理有效政策及版本；IT 配置登录、接口、日志和环境；安全合规确认资料范围、结果留存与访问控制；供应商按约定实现检索、答案建议、引用和转人工标记；项目经理把这些交付物、依赖与决策串起来。

到了验收，坐席执行真实任务并记录是否可用，业务主管对业务质量和复核时间作判断，IT 验证性能、告警和回退，数据角色检查引用版本，安全合规检查权限与日志，供应商修复约定范围内的缺陷。采用业务定义，技术验证，共同签字的方式，不代表所有人共同承担最终责任：是否达到业务验收并进入下一阶段，仍由业务负责人作出决定。

验收标准也要有内容负责人和批准人。谁制作测试集、谁解释口径、谁确认关键错误为零容忍，最好在需求阶段就写清；试点验收条件怎么写可用于补齐样本、阈值、观察窗口和停止条件。否则上线会议很容易变成每个部门拿一套标准说话。

三种责任失控，靠增加参会人解决不了

第一种是把 IT 变成业务所有者。业务只说「你们懂 AI，先做出来」，IT 只好代替业务猜流程、范围和错误代价；交付后业务又认为不符合使用习惯。修法不是让 IT 多访谈几次，而是要求业务负责人批准问题定义、样本和验收口径，IT 只对技术可行性与运行质量负责。

第二种是把供应商变成最终责任人。供应商可以承诺合同中的系统能力和服务水平，无法拥有企业内部流程，也不能替企业批准数据用途或接受业务残余风险。供应商对交付负责，企业对业务选择负责。若双方边界只写成「保证项目成功」，出现数据不完整、用户不用或规则冲突时，责任一定会互相推回。

第三种是所有人都被列为会签人。范围、提示词、界面甚至普通缺陷都要跨部门一致同意，项目看似谨慎，实际没有分级决策。应按风险设决策门槛：影响数据用途、对外动作、客户权益或核心系统的变化进入正式会签；不改变边界的日常优化由指定产品或运营角色批准并留记录。

责任矩阵的价值不在把每个人放进表格，而在问题出现时，团队无需重新讨论谁有权结束讨论。

项目结束前，把交付责任迁移成运营责任

试点期的项目组不能天然等于上线后的运营团队。开发完成后，仍有人要更新资料、查看失败和接管率、处理用户反馈、管理账号、核对费用、安排复测并决定何时扩大范围。若这些工作继续挂在临时群里，热度下降后就会逐渐无人处理。AI 试点到正式上线之间缺什么进一步拆解了监控、SOP、回退和运营所有权。

交接前应逐项确认运营负责人、替补、处理时限、所需权限、看板、操作手册和升级路径，并完成一次异常与回退演练。项目经理确认交付物完整，IT 和供应商完成技术移交，业务负责人接受残余问题和后续资源安排。此时责任矩阵要从项目责任迁移为运营责任，而不是归档后不再打开。

有效分工最终体现在三个时刻：范围争议时有人拍板，异常发生时有人接手，效果变化时有人决定调整或停止。只要这三个出口清楚，小团队可以一人兼任多个角色；如果出口不清楚，参与部门再多、会议再密，也只是把责任藏在协作的表面之下。