一、ISO/IEC 42001:2023 7.2 标准原文
原文:组织应:确定在组织控制下从事会影响组织人工智能绩效的工作人员的必要能力;确保上述人员具备适当的教育、培训或经验;适用时,采取措施以获得必要的能力,并评估所采取措施的有效性;保留适当的文件化信息作为能力的证据。
注 1:B.4.6 中提供了人力资源实施指南,包括对必要专业知识的考虑。
注 2:适用的措施可包括,例如:为现有雇员提供培训、指导或重新分配;雇用或签约有能力的人员。
二、条款解读说明
2.1 AI能力是跨学科能力,不是单点技术能力
在人工智能管理体系中,“能力”这个词很容易被误解为建模和编程能力。但标准的关注点远比这宽。会影响组织人工智能绩效的人员,既包括数据科学家、算法工程师和开发人员,也包括业务负责人、产品经理、测试验证人员、人工监督人员、法务合规、采购、运维支持、客户沟通人员,甚至包括外包团队和第三方支持人员。因为AI绩效并不只由模型本身决定,还由需求定义、数据选择、部署方式、监督机制、用户告知、事件响应和供应商管理共同决定。
因此,7.2条要求组织做的不是“证明团队整体很强”,而是证明每一类关键岗位具备完成其职责所需的能力。举例来说,负责人工监督的人未必需要会训练模型,但必须理解系统用途、输出局限、何时应介入和如何上报异常;负责采购AI服务的人未必需要写代码,但必须能理解供应商文档、审查关键控制和识别重大依赖。只有这样,AIMS的每一个环节才不会因为能力缺口而失效。
2.2 7.2关注的四个核心动作
| 动作 | 标准要求 | 组织要回答的问题 | 典型证据 |
|---|---|---|---|
| 识别能力要求 | 确定必要能力 | 哪些岗位会影响AI绩效,各自需要什么能力 | 岗位能力矩阵 |
| 保障能力具备 | 确保具备适当教育、培训或经验 | 现有人是否够用,外部能力是否需要引入 | 简历、资历、任命依据 |
| 采取提升措施 | 适用时采取措施获得能力 | 通过培训、指导、重分配还是外部签约补齐缺口 | 培训计划、辅导记录、外包协议 |
| 验证有效性 | 评估措施有效性并保留证据 | 培训之后是否真的能胜任工作 | 考核结果、试岗记录、绩效评价 |
2.3 能力不足是AI治理失败最隐蔽的原因之一
组织在AIMS中最容易出现的一个问题,是制度看起来很完整,但执行效果始终不稳定。追到最后,根因往往不是制度缺失,而是相关岗位并没有真正理解自己在AI系统中的职责。比如,算法团队了解模型原理,却不理解行业监管约束;业务团队知道场景痛点,却不了解数据局限和自动化边界;人工复核人员看到了异常,却不知道何时该升级上报;采购人员签了合同,却没要求供应商交付必要文档。所有这些问题,本质上都属于7.2条没有做好。
所以,7.2的关键不只是培训次数,而是能力与岗位的匹配度。组织要从“谁会影响AI绩效”倒推“谁应具备什么能力”,而不是开几场通用培训就默认要求已经满足。对高影响场景而言,必要时还应引入外部专家、领域专家或可信AI相关专业能力,确保组织并非在自己不理解的风险上作重大决定。
三、实施要点
3.1 先识别关键岗位,再定义能力要求
- 建议从AI系统生命周期和治理链条出发,识别开发、验证、部署、运行、监督、采购、沟通和事件响应相关岗位。
- 对每类岗位明确知识要求、技能要求和经验要求,而不是笼统写“熟悉AI”。
- 岗位能力矩阵是落实7.2最有效的基础工具。
3.2 用多种方式补足能力缺口
- 能力不足时,不一定只能靠招聘。组织可根据情况采取培训、导师辅导、岗位调整、联合评审、签约外部专家等方式补足。
- 对短期高影响项目,外部专业能力往往比临时内部转岗更可靠。
- 关键是措施要和风险等级、业务影响相匹配。
3.3 能力建设应覆盖技术和非技术角色
- 研发岗位需要模型、数据和验证能力,业务岗位需要理解用途边界和人工监督要求,法务和采购岗位需要理解外部要求与供应商责任。
- 如果只培训技术团队,AIMS很容易在跨部门接口处失效。
- 跨学科能力是AI管理体系区别于普通技术项目管理的关键特征。
3.4 培训后要验证效果,而不是只保留签到表
- 标准明确要求评估所采取措施的有效性,因此培训完成不等于能力具备。
- 可通过考试、实操演练、案例复盘、评审表现、试运行观察等方式验证能力是否转化为实际工作能力。
- 高影响岗位应采用更严格的评估方式。
3.5 能力要求要随着系统和风险变化更新
- 当组织引入新模型类型、新监管要求、新供应商或新场景时,原先的能力要求可能已不够。
- 因此,能力矩阵应与变更管理、目标更新和管理评审联动。
- 能力要求静态不变,通常意味着组织的治理能力开始落后于AI变化速度。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 实施建议 | 输出成果 |
|---|---|---|---|
| 岗位能力矩阵 | 定义不同角色的能力要求 | 按知识、技能、经验三维度设计 | 能力标准表 |
| 能力差距评估 | 识别现有人员与岗位要求的差距 | 结合项目和系统风险等级开展 | 差距分析报告 |
| 角色化培训计划 | 按岗位提供差异化培训 | 避免所有人员上同一种通识课 | 培训计划与记录 |
| 实操考核/案例演练 | 验证培训有效性 | 围绕真实系统和事件场景设计 | 考核结果 |
| 专家支持机制 | 补足高难度或高影响场景能力 | 通过顾问、委员会或专项评审引入 | 专家参与记录 |
五、典型案例
案例一:算法团队很强,但项目仍然失控
- 背景:某企业拥有成熟算法团队,自认为能力充足。
- 问题:上线后发现业务人员不知道何时应人工复核,客户经理也无法解释AI输出边界。
- 改进:组织按岗位重新梳理能力要求,把业务使用、用户沟通和异常上报能力纳入管理。
- 结果:AI系统的实际使用质量明显提升,误用率下降。
案例二:培训做了很多,能力证据仍然不足
- 背景:某团队每年组织多次AI培训,签到表非常完整。
- 问题:审核时无法说明培训后人员是否真的掌握关键要求,也没有岗位化能力标准。
- 改进:组织建立能力矩阵和实操考核机制,把培训结果与岗位任命和评审表现挂钩。
- 结果:能力管理从“学过”转向“会做”。
案例三:通过外部专家补足高影响场景能力
- 背景:某组织计划在敏感场景部署AI,但内部缺少隐私、公平性和领域专家。
- 问题:项目团队难以独立判断高影响风险和控制措施。
- 改进:组织引入外部专家参与评估和评审,同时安排内部岗位跟学。
- 结果:既补齐了短期能力缺口,也加快了内部能力沉淀。
六、成文信息管理要求
7.2明确要求保留适当的文件化信息作为能力证据,因此组织至少应保留岗位能力要求、人员能力证明、提升措施和有效性验证记录。只保留培训通知和签到表,通常不足以支撑审核。
| 建议文件或记录 | 关键内容 | 用途 |
|---|---|---|
| 岗位能力矩阵 | 岗位、职责、知识技能经验要求 | 证明必要能力已被确定 |
| 人员能力证明 | 教育背景、资历、项目经验、任命依据 | 证明相关人员具备能力 |
| 培训与辅导记录 | 培训内容、对象、时间、讲师、结果 | 证明已采取能力提升措施 |
| 能力有效性评估记录 | 考试、演练、评审表现、试岗结果 | 证明措施有效 |
| 外部专家或签约人员资料 | 能力说明、服务范围、使用场景 | 证明外部能力已纳入控制 |
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 把能力理解为纯技术能力 | 忽略业务、法务、监督和沟通岗位 | 按影响AI绩效的岗位全面识别能力需求 |
| 培训次数多就等于能力满足 | 只有签到表,没有效果验证 | 增加考试、演练和实际表现验证 |
| 只管正式员工,不管外包人员 | 关键支持人员不在能力管理范围内 | 将组织控制下相关人员全部纳入 |
| 岗位能力要求多年不更新 | 新场景新风险出现后仍沿用旧标准 | 随变更和评审更新能力矩阵 |
| 只在审核前集中补培训 | 能力建设与实际项目节奏脱节 | 把能力建设嵌入立项、上线和运行阶段 |