一、ISO/IEC 42001:2023 5.3 标准原文

二、条款解读说明

2.1 为什么AI治理比多数管理体系更依赖职责清晰

很多传统管理体系虽然也要求岗位职责明确，但AI治理的跨界特征使这一要求格外重要。一个AI应用从需求提出到上线运行，通常会经过业务定义、数据准备、模型开发或采购、系统集成、法律审查、风险评估、监测运维和事件响应多个环节。每个环节背后可能是不同部门、不同管理线、甚至不同法人主体。若职责与权限没有在体系中说清楚，很多关键任务就会落空。

实际工作中常见的问题非常典型：业务团队认为模型可靠性由技术团队负责，技术团队认为应用后果由业务负责，采购认为供应商透明度是法务问题，法务认为模型监测是技术问题，结果一旦发生偏差、误用、投诉或外部质疑，组织内部没有完整责任链。5.3就是要避免这种“人人参与、无人总责”的状态。

2.2 5.3在AIMS中的关键角色视角

2.3 职责明确不等于把所有工作塞给一个“AI负责人”

不少组织为了快速应对体系要求，会指定一个“AI治理负责人”或“AI合规经理”，希望通过这个岗位解决所有问题。这种做法只能解决协调问题，不能解决责任问题。因为AI治理涉及的许多职责天然属于不同业务线和专业线，例如业务后果由业务负责人承担，模型监测由技术或运维承担，合同义务由采购和法务承担，用户影响和投诉处理则可能落在客服和运营侧。

因此，5.3的正确理解不是“找一个人总负责所有工作”，而是建立清晰的责任链和权限链。一个组织可以有AIMS负责人负责统筹，但不能用这个岗位代替全部业务责任、技术责任和管理责任。成熟组织更常见的做法，是通过RACI矩阵、治理委员会、分层审批和例外上升路径，把AI治理责任真正拆分清楚。

三、实施要点

3.1 先识别AIMS关键活动，再反推责任角色

• 建议先梳理AIMS关键活动，如AI活动识别、影响评估、风险处置、供应商准入、上线审批、运行监测、事件处置、审核评审和持续改进，再判断每项活动的责任方、执行方和批准方。
• 不要先画组织结构图再勉强把任务往里塞，先看任务更容易避免责任空洞。
• 任务视角下的职责分配通常更贴近真实运行。

3.2 明确业务责任不能被技术责任替代

• AI项目中，业务部门应对用途、场景适当性、用户影响和人工介入边界承担责任，不能将所有责任都下沉给算法或平台团队。
• 技术团队则应对模型实现、验证、监测和运行控制承担责任，但不应被迫独自定义业务后果。
• 业务责任和技术责任一旦混为一谈，治理几乎一定会失衡。

3.3 对重大例外、残余风险和高影响场景设置上升权限

• 并非所有AI治理决策都应在项目组内部解决。对于高影响应用、关键供应商依赖、重要例外和重大投诉，应有明确上升到管理层或治理委员会的路径。
• 如果权限设计过低，项目现场往往会在时间和商业压力下做出超出授权边界的决定。
• 权限结构决定了责任结构是否真正可执行。

3.4 将外部参与方纳入职责界面管理

• 模型供应商、外包开发方、数据服务商、云平台方和第三方测试机构并不是组织内部岗位，但它们的责任界面必须通过合同、流程和接口机制被说明清楚。
• 尤其对依赖程度高的外部方，应明确谁负责管理关系、谁负责核验交付、谁负责接收问题和推动整改。
• 没有人管外部接口，内部职责再清楚也会在关键边界上失效。

3.5 用职责矩阵、流程图和宣贯确保分工被真正理解

• 职责如果只写在岗位说明里，很容易在实际协作中失真。建议结合RACI矩阵、审批流程、例会机制和案例培训，把职责落到可操作层。
• 特别要让管理层、业务负责人和技术负责人理解彼此边界，而不是只让AIMS团队理解。
• 职责被写下来只是第一步，被理解和执行才是真正完成。

四、常用工具与实施方法

五、典型案例

案例一：模型输出有争议时，业务和技术团队互相等待

1. 背景：某AI系统上线后出现明显偏差，客户投诉不断。
2. 问题：业务认为模型问题归技术团队，技术认为是否继续上线应由业务决定，没人总责。
3. 5.3动作：组织重新梳理责任矩阵，明确业务负责用途与后果、技术负责实现与监测、管理层负责重大残余风险决策。
4. 结果：问题处置效率和责任边界显著改善。
5. 启示：AI治理最怕的不是有人犯错，而是没人知道这错该谁来收口。

案例二：外包开发团队在关键控制点无人对接

1. 背景：组织将部分AI能力开发外包，但内部没有明确接口人负责供应商治理。
2. 问题：测试结果、文档交接和漏洞修复都在项目末端才集中暴露。
3. 5.3动作：明确采购、技术和业务三方在外包治理中的责任分工。
4. 结果：外部责任界面不再悬空。
5. 启示：外包场景中的职责不清，往往会把内部问题放大成供应链问题。

案例三：重大例外没有上升机制，项目现场长期自行放行

1. 背景：多个项目在时间压力下自行接受高残余风险上线。
2. 问题：组织后来发现这些决定既无统一标准，也没有管理层知情。
3. 5.3动作：建立重大例外上升审批机制和统一记录口径。
4. 结果：高风险事项开始进入正式治理层决策。
5. 启示：权限边界不清，责任边界就一定会漂移。

六、成文信息管理要求

5.3审核时，审核员通常会关注组织是否真的明确了AIMS相关职责，而不仅是简单列出部门名称。特别是在AI治理场景下，能够展示职责如何落到关键活动和例外决策上，往往比一份通用岗位说明更有说服力。

七、常见误区及踩坑提醒