指南
2027年AI安全标准ISO:采购前需要核实什么
本文整理自 Duaer 文档站,围绕企业采购 AI 系统时如何核实 ISO 认证的范围、证据与风险匹配展开,说明证书能证明什么,又不能证明什么。
为什么「ISO认证的AI」比看上去更难核实
采购团队总在问同一个问题:你们是否拿到了 AI 相关的 ISO 认证?这听起来像是打个勾就能过关的事,但实际上,答案决定了法务、安全和审计团队能否信任一个 AI 系统,而且很容易被误读。
与 AI 相关的 ISO 和 IEC 标准并不是同一份文件。ISO/IEC 27001 覆盖信息安全管理体系,已经使用多年;ISO/IEC 42001 发布于 2023 年底,规定了 AI 管理体系的要求;ISO/IEC 23894 提供 AI 风险管理指南;ISO/IEC 27701 扩展了隐私管理;ISO/IEC 5338 则涉及 AI 系统的生命周期。供应商完全可以如实地说自己持有其中一项,却几乎没有透露你计划部署的那个模型的情况。
核心问题在于范围。证书适用于一个组织或其中被界定的部分,依据的是声明的管理体系,它并不证明某个特定模型在你的业务流程中是准确、无偏见或安全的。证书上的范围声明是最重要的一段,它告诉你哪些产品、场所、业务单元和流程被覆盖。许多真正的缺口,就藏在证书所写内容与销售材料所暗示内容之间的空隙里。
避免三个常见误读
第一个误读是把认证当成产品保证。证书表明供应商运行了一套有文件记录的流程,并且通过了认可机构对该流程的审计。它并不意味着模型的每个输出都正确,也不意味着因为你自己选择的某项配置,数据就永远不会被误用。
第二个误读是以为 ISO/IEC 27001 就已足够。信息安全控制固然重要,但 AI 会带来传统信息安全审计可能不会深入检查的风险,例如训练数据的来源、提示注入、模型更新后的漂移、输出过滤,以及对第三方基础模型的依赖。一份扎实的 27001 证书是良好的基础,但并不构成完整的 AI 保障体系。
第三个误读是把「正在进行中」当成「已经认证」。许多供应商会把路线图描述为既成成就。你应当索取证书编号、签发机构及其认可状态、精确的范围以及到期日。只要其中任何一项缺失,就说明该供应商还没有为你要购买的产品获得认证。
把标准对应到你的实际风险
与其纠结哪个标准最好,不如从风险出发。先写下这个系统做什么、接触哪些数据、谁依赖它的输出,以及它出错时会发生什么。然后把风险与证据对应起来。
如果系统处理个人数据或跨境传输数据,应首先关注隐私控制,例如 ISO/IEC 27701,以及你自身的数据驻留规则。如果关注点是访问、日志和基础设施,那么 ISO/IEC 27001 的范围声明是相关文件。如果问题是组织如何跨团队治理 AI 的使用,ISO/IEC 42001 更接近目标。如果你需要评估模型失效模式的方法,ISO/IEC 23894 提供了有用的参考。
证据的力度应与后果相匹配。一个只依据政策手册回答问题的内部助手,所需的审查就比起草面向客户决策或涉及受监管记录的系统要轻。试点上线前,最好先过一遍简短的检查清单;我们的指南 2027年AI安全合规试点检查要点 涵盖了团队最常遗漏的事项。
如何系统地核实供应商
向每一位候选供应商发送相同的证据请求。一份有用的材料包括:
1. 证书,并注明精确范围、签发机构、认可状态和到期日。
2. 适用性声明(Statement of Applicability),说明哪些控制适用、哪些被排除以及排除原因。
3. 最近一次审计结果的摘要,包括不符合项及其关闭方式。
4. 模型层面的文档:训练数据类别、评估方法、已知局限和失效模式。
5. 分包商清单、数据保留条款和安全事件通知承诺。
比较的是答案,而不是形容词。如果供应商自称「企业级」或「安全设计」,却拿不出适用性声明,这本身就是明确的信号。反之,愿意提供文件并解释其中排除项的供应商,通常在合同期内也更好合作。
这一接收环节正是结构化工作流的价值所在。如果你的团队要为多个 AI 工具同时收集这些证据,可以在 Duaer 中运行相同的请求、审核和跟进流程,使每个系统的范围、证据和未决问题都与其记录保持关联。它不能替代你的审计人员或认证机构,但当有人问某项决策的依据来自哪里时,它能让文件记录具备可追溯性。
衡量证书无法体现的内容,并避开内部推行的两个陷阱
认证只是起点。系统投入使用后,应跟踪一些运营指标,以判断控制措施在实践中是否有效:
- 范围覆盖率:你的 AI 系统清单中,落在认证或评估范围之内的比例。范围之外的系统应列为例外并予以记录,而不是忽略。
- 未关闭的不符合项及其关闭所需时间。
- 对比内部审查与外部审计的发现。如果外部审计员发现了你的团队没有发现的问题,说明内部审查尚未发挥作用。
- AI 相关事件从发现到遏制的时长,包括提示注入尝试和数据暴露事件。
- 剩余风险登记册:已接受的风险数量、每项风险是否有明确负责人,以及是否设定了复审日期。
应避免只看数字的虚荣指标,例如编写了多少政策、举办了多少培训。它们体现的是活动量,而不是控制效果。如需更全面地了解治理决策如何与安全和合规结果相连接,可参阅 2027年企业AI治理与安全合规判断。
内部推行中有两个常见陷阱。第一个是把所有 ISO 工作都交给一名合规专员。像 42001 这样的标准需要工程、产品负责人、法务以及实际使用系统的业务单元共同参与。否则,管理体系描述的只是一个没有人遵循的流程。第二个是在盘点系统之前就急于编写政策。影子 AI 工具、浏览器插件和嵌入式模型功能往往会在审计时浮出水面,悄悄削弱已界定的范围。在早期建立准确的清单,远比在审计压力下重建要便宜。
本周可以做什么
选出团队最常使用的三个 AI 工具。针对每一个工具,写一页范围说明,写明负责人、涉及的数据类别、用户群体,以及供应商的认证状态及其精确范围。然后发出前文所述的证据请求。如果某个供应商无法以书面形式说明其范围,那就把该工具标记为在缺口补齐之前暂不批准用于敏感数据。
如果你希望把这件事变成可重复的流程,而不是一次性的电子表格,可以前往 https://www.duaer.com 开始试用。在那里注册后,你可以在同一个地方建立 AI 系统清单并完成供应商证据审核,看看这套工作流是否契合你的安全和采购团队现有的工作方式。
ISO 认证能告诉你,供应商运行着一套有明确定义并经过审计的流程,这一点值得核实。但它不能说明每一个 AI 输出都是安全的。因此,应让证据与风险相匹配,并持续检查证书无法体现的那些部分。
常见问题
ISO/IEC 27001 认证能否证明 AI 系统是安全的?
不能完全证明。27001 说明供应商运行了经过审计的信息安全管理流程,是良好的基础,但提示注入、训练数据来源、模型漂移等 AI 特有风险通常不是传统信息安全审计的重点,还需要额外的模型层面证据。
供应商说自己「正在申请认证」,采购方应该怎么做?
要求其提供证书编号、签发机构及其认可状态、精确范围和到期日。只要缺少其中任何一项,就说明该供应商尚未对你要购买的产品获得认证,在缺口补齐之前不应将其用于敏感数据。
ISO/IEC 42001 和 27001 应该先看哪一个?
取决于风险。涉及个人数据或跨境传输时,应先看隐私控制(27701);关注访问、日志和基础设施时,看 27001 的范围声明;如果想了解组织如何跨团队治理 AI 的使用,则 42001 更贴近目标。