> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/ai-security-standards-iso.md).

# 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安全合规试点检查要点](https://doc.duaer.com/zh/guides/ai-security-compliance-2027-pilot-checks/) 涵盖了团队最常遗漏的事项。

## 如何系统地核实供应商

向每一位候选供应商发送相同的证据请求。一份有用的材料包括：

1. 证书，并注明精确范围、签发机构、认可状态和到期日。

2. 适用性声明（Statement of Applicability），说明哪些控制适用、哪些被排除以及排除原因。

3. 最近一次审计结果的摘要，包括不符合项及其关闭方式。

4. 模型层面的文档：训练数据类别、评估方法、已知局限和失效模式。

5. 分包商清单、数据保留条款和安全事件通知承诺。

比较的是答案，而不是形容词。如果供应商自称「企业级」或「安全设计」，却拿不出适用性声明，这本身就是明确的信号。反之，愿意提供文件并解释其中排除项的供应商，通常在合同期内也更好合作。

这一接收环节正是结构化工作流的价值所在。如果你的团队要为多个 AI 工具同时收集这些证据，可以在 [Duaer](https://www.duaer.com) 中运行相同的请求、审核和跟进流程，使每个系统的范围、证据和未决问题都与其记录保持关联。它不能替代你的审计人员或认证机构，但当有人问某项决策的依据来自哪里时，它能让文件记录具备可追溯性。

## 衡量证书无法体现的内容，并避开内部推行的两个陷阱

认证只是起点。系统投入使用后，应跟踪一些运营指标，以判断控制措施在实践中是否有效：

- 范围覆盖率：你的 AI 系统清单中，落在认证或评估范围之内的比例。范围之外的系统应列为例外并予以记录，而不是忽略。

- 未关闭的不符合项及其关闭所需时间。

- 对比内部审查与外部审计的发现。如果外部审计员发现了你的团队没有发现的问题，说明内部审查尚未发挥作用。

- AI 相关事件从发现到遏制的时长，包括提示注入尝试和数据暴露事件。

- 剩余风险登记册：已接受的风险数量、每项风险是否有明确负责人，以及是否设定了复审日期。

应避免只看数字的虚荣指标，例如编写了多少政策、举办了多少培训。它们体现的是活动量，而不是控制效果。如需更全面地了解治理决策如何与安全和合规结果相连接，可参阅 [2027年企业AI治理与安全合规判断](https://doc.duaer.com/zh/guides/enterprise-ai-governance-security-compliance-2027/)。

内部推行中有两个常见陷阱。第一个是把所有 ISO 工作都交给一名合规专员。像 42001 这样的标准需要工程、产品负责人、法务以及实际使用系统的业务单元共同参与。否则，管理体系描述的只是一个没有人遵循的流程。第二个是在盘点系统之前就急于编写政策。影子 AI 工具、浏览器插件和嵌入式模型功能往往会在审计时浮出水面，悄悄削弱已界定的范围。在早期建立准确的清单，远比在审计压力下重建要便宜。

## 本周可以做什么

选出团队最常使用的三个 AI 工具。针对每一个工具，写一页范围说明，写明负责人、涉及的数据类别、用户群体，以及供应商的认证状态及其精确范围。然后发出前文所述的证据请求。如果某个供应商无法以书面形式说明其范围，那就把该工具标记为在缺口补齐之前暂不批准用于敏感数据。

如果你希望把这件事变成可重复的流程，而不是一次性的电子表格，可以前往 [https://www.duaer.com](https://www.duaer.com) 开始试用。在那里注册后，你可以在同一个地方建立 AI 系统清单并完成供应商证据审核，看看这套工作流是否契合你的安全和采购团队现有的工作方式。

ISO 认证能告诉你，供应商运行着一套有明确定义并经过审计的流程，这一点值得核实。但它不能说明每一个 AI 输出都是安全的。因此，应让证据与风险相匹配，并持续检查证书无法体现的那些部分。

## 常见问题

### ISO/IEC 27001 认证能否证明 AI 系统是安全的？

不能完全证明。27001 说明供应商运行了经过审计的信息安全管理流程，是良好的基础，但提示注入、训练数据来源、模型漂移等 AI 特有风险通常不是传统信息安全审计的重点，还需要额外的模型层面证据。

### 供应商说自己「正在申请认证」，采购方应该怎么做？

要求其提供证书编号、签发机构及其认可状态、精确范围和到期日。只要缺少其中任何一项，就说明该供应商尚未对你要购买的产品获得认证，在缺口补齐之前不应将其用于敏感数据。

### ISO/IEC 42001 和 27001 应该先看哪一个？

取决于风险。涉及个人数据或跨境传输时，应先看隐私控制（27701）；关注访问、日志和基础设施时，看 27001 的范围声明；如果想了解组织如何跨团队治理 AI 的使用，则 42001 更贴近目标。