AI项目应该由技术部门负责，还是由业务部门负责？

Geoffrey Chen

《AI进入工作之后》· 第二季“从个人工具到组织能力”· 第二篇

一家机构准备让AI帮助处理客户来信。业务部门提出需求：“让回复更快、更一致。”技术部门选择模型、连接文件和客户系统，并建立界面。上线以后，业务人员抱怨建议不符合政策；技术人员则说需求从未说明哪些例外最重要。合规团队直到后期才发现部分信件涉及法定时限和敏感个人信息。

项目失败时，每个部门都能指出另一个部门缺少的东西。业务不懂模型，技术不懂决定，合规介入太晚。于是管理层问：这个AI项目到底应该归谁负责？

如果答案只能是“技术部门”或“业务部门”，组织已经把问题问错了。AI用例同时是一项业务决定、一套技术系统和一条持续运行的责任链。它需要一名拥有最终结果的业务负责人，也需要若干对技术、数据、安全、法律和运行承担明确责任的共同所有者。

技术部门不能决定业务目的

技术团队可以判断接口是否稳定、权限是否最小化、日志是否完整、系统能否回滚。它不能单独决定客户信件怎样算“正确处理”。

回复速度与准确性发生冲突时，以哪个为先？什么内容可以自动草拟，什么必须由具备授权的人判断？一种错误可能只是语气不自然，另一种错误可能使客户错过申诉期限。这些是业务目的、服务义务和风险容忍度问题。

如果业务部门只交出一句“提高效率”，技术团队就会被迫把隐含价值转化成可计算目标。最后，某个容易测量的指标——例如平均处理时间——可能取代真正目的。

因此，业务必须拥有用例的目的、完成标准和实际后果。

业务部门也不能独自拥有系统风险

业务人员理解流程，不代表他们能够判断模型更新、访问令牌、提示注入、数据保留、供应链依赖和监控设计。

一个看似简单的“起草回复”系统可能读取客户档案、检索内部政策、调用外部模型并把输出写回正式系统。业务负责人无权用一句“只作辅助”消除这些技术事实。

技术、安全和数据团队必须拥有各自能够控制的部分：架构、权限、集成、资产清单、更新、事件响应和恢复。他们也必须有权阻止不满足最低条件的部署。

这不是用技术否决业务，而是防止业务决定在不可见的基础设施中取得超出其理解的权力。

“共同负责”为什么常常等于无人负责

许多项目用跨部门委员会解决冲突。委员会可以汇集视角，却容易把责任稀释成会议参与。

真正的共同所有权不是所有人在名单上，而是每一种决定都有一名可以回答的人。例如：谁批准使用目的；谁确认权威资料；谁接受剩余风险；谁决定上线；谁监控错误；谁可以暂停；谁负责向受影响的人解释和补救。

NIST的AI RMF要求定义和区分人机配置与监督中的角色，并明确指出高级领导层应对AI开发和部署风险的决定承担责任。NIST AI RMF Core

澳大利亚政府《负责任使用AI政策》2.0要求受适用机构指定负责官员、建立用例责任、内部登记、培训和影响评估。它没有把责任交给一个通用“AI团队”，而是要求机构把治理落实到用例与角色。Digital Transformation Agency：Policy for the responsible use of AI in government

一项AI用例至少需要四种所有权

第一是结果所有权。业务负责人说明问题、受影响者、成功标准和不可接受后果，并批准是否采用结果。

第二是系统所有权。技术负责人维护架构、模型接入、权限、版本、可用性和恢复。

第三是信息所有权。数据或知识负责人确认资料来源、质量、访问范围、更新和保留规则。

第四是保证所有权。风险、法律、安全或专业人员决定需要哪些独立检查，并能把问题升级到有权停止项目的人。

这四种所有权可以由不同岗位承担，但必须连接在一份用例记录中。更高风险的项目还需要受影响群体、员工代表或外部专家参与；参与不等于承担机构的最终责任。

英国政府AI Playbook把目标定义、团队建设、采购、生命周期管理、恰当人工控制与保证放在同一套指导中，也说明AI建设不是技术团队的封闭项目。UK Government：AI Playbook

最终负责人必须拥有实际控制

为每个用例指定负责人是必要的，但名字本身不够。负责人需要看见评测结果和事故趋势，知道供应商或模型发生了什么变化，有预算修复问题，并有权暂停运行。

如果负责人只能签署上线文件，却不能限制数据、改变指标或停止服务，他承担的是名义责任。相反，如果技术团队可以随时更换模型却无需通知业务负责人，业务所有权也是空的。

ISO/IEC 42001把领导、规划、支持、运行、绩效评价和持续改进纳入AI管理系统，强调责任必须成为组织过程，而非一次项目任命。Standards Australia：AS ISO/IEC 42001

用决定权矩阵替代部门争夺

项目开始时可以列出关键决定，并为每项指定：谁提出、谁提供专业意见、谁批准、谁执行、谁被通知。至少覆盖目的、数据、模型与供应商、测试、上线、重大变更、异常处理和终止。

一旦现实发生变化，这张表也必须变化。试验阶段由创新团队维护，不代表进入正式客户流程后仍由它承担。系统从草拟升级为自动发送时，批准层级和保证要求应重新评估。

部门边界仍然重要，但它们不应成为责任的终点。AI用例的真实边界是一条从目的到后果的工作链。

所有权还必须有连续性。试点负责人调职、供应商更换或预算年度结束时，用例不能成为无人认领的遗留物。组织应在登记册中保留业务所有者、技术所有者、风险接受人、复核日期和停止条件；角色变化必须触发重新确认。只有这样，“共同负责”才不会在真正出现问题时变成每一方都只对自己熟悉的部分负责。

结论：业务拥有目的，技术拥有系统，机构拥有后果

AI项目不应简单“归IT”，因为技术部门不能独自决定服务目的和可接受后果；也不应简单“归业务”，因为模型、数据、集成和安全风险需要专业控制。

更准确的结构是：

由一名业务负责人对用例结果承担最终所有权，由技术、信息和保证负责人分别拥有其控制范围，而机构领导层对这套分工是否完整承担责任。

当出现错误时，组织不应再寻找“谁碰过AI”，而应沿着已经定义的决定权找到目的、系统、信息、批准和补救的负责人。只有这种所有权可以把跨部门合作从共同讨论变成共同运行。

主要资料

继续阅读：浏览《AI进入工作之后》系列文章

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。