开发团队按既有流程做安全审查、核对访问权限、记录基础设施变更，这些动作一样不少。可同一套AI系统还会带出另一类问题：它打算用来做什么、模型行为怎么评估、风险归谁、上线之后谁持续盯着。这些事如果和工程流程分开放，技术实现和组织治理之间就会留下缝隙。

打开网易新闻 查看精彩图片

ISO/IEC 27001 和 ISO/IEC 42001 提供的都是管理体系框架。真正要做的，是把治理要求和团队实际构建、部署、维护AI系统的方式接上，而不是给每个合规任务单开一套流程。

安全控制覆盖不到的地方

信息安全是AI治理的重要部分，但它不等于AI治理的全部。设想一个应用，调用第三方语言模型来总结客服对话。工程团队可能早就有保护API凭证、控制数据库访问、响应安全事件的流程，这些做法保护了应用和数据本身。

但团队还得回答另一串问题：模型输入会不会暴露敏感信息？输出是否需要人工复核？模型变更怎么评估？部署之后谁来监控？这些问题的答案，需要技术和组织层面协同做出决定。

ISO 27001 建立的是信息安全管理框架，ISO 42001 建立的是管理AI相关风险与机会的框架。两套标准的要求各自独立，相关流程可以协调起来跑。

把两套标准放进开发生命周期

比较实用的做法，是把管理体系活动和已有的工程流程对接。按阶段看：

  1. 系统规划：开发开始前，先弄清这个AI功能的预期用途和随之而来的责任。要回答的问题包括：它解决什么业务问题？会不会处理个人、机密或其他敏感信息？依赖哪些外部模型、API或数据集？谁拥有这个系统、谁批准重要变更？部署前需要评估哪些风险？信息安全要求可以帮助为数据和基础设施建立防护，AI治理流程则帮助团队评估这个系统更广泛的影响。把这些决定尽早记录下来，工程师和治理团队就有了共同的起点。
  2. 开发与测试：安全审查和AI评估都要贴合系统本身的特征。团队可能测试认证、授权、依赖漏洞和密钥管理，也可能需要评估AI特有的问题，比如不当输出、性能局限、人工监督是否有效。需要做哪些评估，取决于系统用途、风险和适用要求。测了什么、结果如何、哪些问题还没解决，都要记录；需要审批的环节，要指明由谁负责审。
  3. 部署与变更管理：模型、提示词、数据集、依赖或周边应用一改，AI系统就变了。常规的软件发布流程能提供审查和批准的控制手段，但组织要判断现有流程是否充分覆盖了AI相关风险。一个从工程角度看很小的变更，可能影响输出质量或系统的预期用途。团队可以设定与风险相称的审查标准，判断什么时候需要额外测试、风险评估或审批才能上生产。
  4. 生产监控：部署不等于不用管了。工程团队通常监控可用性、延迟、错误和基础设施性能，视应用而定，还可能需要评估输出质量、反复出现的故障模式、用户反馈等AI特有指标。监控责任要清楚：谁看结果、问题怎么上报、什么时候必须采取纠正措施。监控流程也应体现组织已记录的风险评估和相关管理体系要求。

建一套共享的证据流程

同时跑多套管理体系，一个实际难题是记录对不上。安全团队维护风险登记册，工程团队把测试结果存在开发工具里，合规团队在另外的文档里管审批。这些记录彼此断开，就很难看清做过哪些决定、该做的动作有没有完成。

共享的证据流程可以提升可追溯性。对每个AI系统，组织可以维护这些链接：系统负责人和预期用途、相关的信息安全与AI风险评估、测试结果和审查记录、已批准的变更和部署决定、监控发现和纠正措施。

这不意味着所有记录都得存在同一个应用里。关键在于组织能找到证据、认出它的负责人、弄清它支撑的是哪项要求。共享证据也不等于要求相同：一项安全测试可以支撑某个信息安全控制，却不能证明AI专项评估已经完成。

把责任分清楚

治理能不能落地，取决于职责不同的人能不能配合。开发者懂实现，安全人员关注系统和信息防护，产品负责人懂预期用途和业务优先级，合规人员帮助解读适用要求、协调证据。这些职责可以重叠，但不能含糊。

一套可用的责任模型要说明：谁识别和记录AI系统、谁开展或协调风险评估、谁落实技术和组织控制、谁审查和批准相关决定、谁监控系统并管理纠正措施。模型要匹配组织规模和运作结构——小团队可以一人兼多项，大组织可能需要更正式的审查和上报流程。要紧的是决定有明确归属，负责人具备相应的能力和权限。

和欧盟AI法案是什么关系

在欧洲运营的组织可能还需要考虑欧盟AI法案下的义务。该法案的要求取决于组织角色、AI系统的预期用途以及它在立法下的分类。ISO 27001 和 ISO 42001 可以支撑相关的治理活动，但两套标准都不会自动让组织满足欧盟AI法案的每一项适用要求。

组织应单独评估自身的法律义务，再确定现有管理体系流程如何支撑所需的控制、文档和监督。当团队把认证当作更广泛治理计划的证据时，这个区分尤其重要：管理体系证书和法律合规评估，用途并不相同。

工程团队的务实起点

不需要一次性重做所有工程流程。合理的起点是挑一个AI系统，把它的生命周期、现有安全控制、治理责任和可用证据梳理一遍。接着找出当前流程没有覆盖相关AI管理要求的地方，按重要程度排序，指定负责人，记录需要做的改动。流程经过评审之后，再把经验用到其他合适的AI系统上。

这样做的目的是让责任可见、让相关风险得到处理、让记录支撑有依据的决定，而不是给软件开发叠加不必要的审批步骤。把工程、安全和治理团队放进同一个流程，AI监督才能成为系统开发和维护中更稳定的一部分。