> 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-compliance-framework.md).

# 2027 年 AI 安全合规框架：为什么多数项目会早早停滞

本文整理自 Duaer 文档站，探讨企业在 2027 年构建 AI 安全合规框架时的核心难题，包括政策与系统脱节、责任归属不清、常见误区，以及可落地的四层框架和衡量方法。

## 真正的问题：有政策，但 AI 系统并不遵循

如今大多数企业都能拿出一份 AI 政策文件。它通常涵盖可接受的使用范围，禁止把客户数据粘贴到公开聊天机器人中，并指定一个委员会审查高风险项目。然而，当安全团队或审计人员问起一些简单的问题时，例如目前有哪些模型在生产环境中运行、它们可以访问什么数据、谁批准了它们的输出、一旦发生事故如何被发现，答案往往分散在电子表格、供应商门户和工程师的记忆里。

这种差距正是任何 AI 安全合规框架背后的核心痛点。框架不等于文档，它是一组控制措施、责任人、证据和审查周期的组合，用来确保 AI 的行为符合企业已经认可的边界。到 2027 年，随着 AI 从试点走向面向客户的业务流程和内部智能体，这一差距正成为项目停滞的主要原因：法务和安全团队无法签字放行，工程团队也无法正式上线。

## 框架为何难以建立

AI 与现有的安全和合规体系并不完全契合。传统应用有明确的代码库、固定的输入和可预测的输出；而 AI 系统包含的模型可能被供应商在未通知的情况下更新，提示词的改动会改变行为，检索管道每天都在引入新文档，输出还会因每次运行而有所不同。一项适用于静态网站应用的控制措施，很可能无法说明模型是否会被知识库中的恶意文档欺骗。

责任归属也存在问题。数据保护属于隐私团队，应用安全属于安全职能，模型评估属于数据科学团队，供应商风险则属于采购部门。每个团队的视角都有其价值，但没有人对某个具体 AI 用例是否可以安全运行负有端到端的责任。如果每个系统没有指定责任人，框架就会沦为一份没人执行的原则清单。

最后，资产清单通常并不完整。许多组织会发现，AI 功能已经嵌入在 SaaS 工具、浏览器扩展和开发者助手中，而这些往往是各个团队自行引入的。基于不完整清单建立的框架，必然会漏掉最重要的风险。

## 浪费时间的常见误区

第一个误区是把 AI 合规当作一次性审查。团队在上线时批准了某个模型或供应商，便默认该批准永久有效。但提示词会变化，数据源会扩展，供应商也会更新底层模型。没有重新审查触发机制的批准，只是对一个已经不存在的系统的快照。

第二个误区是认为供应商的通用安全认证就涵盖了具体的 AI 使用场景。供应商可能拥有基础设施层面的认证，但你的团队如何配置检索、日志和访问权限，才会真正产生实际风险。认证只是评估的输入，而不能替代评估本身。

第三个误区是过度依赖模型准确率作为合规指标。准确率固然重要，但合规关注的是另外一些问题：谁能访问输出？个人数据是否保留在日志中？能否还原系统给出某个答案的原因？一个准确率很高但没有审计轨迹的模型，依然无法通过严格的审查。

第四个误区是编写的框架只是照搬法规措辞，却没有转化为工程任务。“确保公平性”“保持透明度”之类的表述是目标，而工程师需要的是这样的控制措施：“对每一个面向客户的回答记录提示词和检索来源，保留规定时长，并且仅允许审计组访问。”

## 可行框架的四个层次

一个实用的框架包含四个层次。第一层是 AI 系统清单，包括供应商内嵌功能和内部智能体，每一项都要有明确的责任人和业务用途。第二层是风险分级，按数据敏感度、决策影响程度和自主程度对系统进行分类。起草营销文案的系统，与影响信贷或临床决策的系统，显然不应经过同样的审查流程。

第三层是映射到公认参考标准的控制措施目录。许多团队使用 NIST AI 风险管理框架作为结构参考，并用 ISO/IEC 42001 作为管理体系要求，再针对提示词、检索和模型更新补充自己的控制措施。这种映射非常关键，因为它让审计人员能够把每一项内部控制追溯到外部期望。

第四层是证据。每项控制都应该产出可以展示的东西：配置记录、评估报告、访问日志或签署的审查单。如果某项控制没有产出证据，无论实施得多好，都无法经受住审计。

在实践中，最有效的起步方式是选择一个高价值用例，端到端地走完上述四个层次，然后复用这一模式。那些在接触真实系统之前就试图建立完整控制目录的团队，通常最终只得到一份没人阅读的文档。

## 把控制措施落到真实的 AI 系统上

以一个常见场景为例：一个使用企业文档回答员工问题的内部助手。一套可行的控制措施至少应涵盖五个方面。访问控制确保检索层尊重现有的文档权限，使员工不会收到他们无法直接打开的文件中的内容。数据处理明确提示词和输出是否存储、存储在哪里、保存多久。输出保护检查敏感数据泄露的情况，并标记低置信度的回答。变更管理要求当底层模型、提示词模板或文档语料发生重大变化时重新评估。事件响应则规定，当有人报告错误或敏感回答时应通知谁，以及如何告知受影响的用户。

请注意，每一点都足够具体，可以分配给责任人并通过证据进行检查。这正是框架与政策的区别所在。许多组织发现，最难的部分往往是数据处理和权限层，因为它取决于现有知识系统的构建方式。如果你正在解决这一问题，关于在保持数据不外流的同时又让数据可用的指南是一份有用的参考：[2027 年数据不外流与可用但不可见的 AI 合规](https://doc.duaer.com/zh/guides/data-no-export-usable-invisible-ai-compliance-2027/)。

对于希望从规划走向持续运行流程的团队，像 Duaer 这样的平台可以把这些步骤集中组织起来，从系统清单、风险标记，到每项控制的证据收集都能覆盖。它不能取代你自身的法律或安全判断，但可以减少通常导致审查拖延的人工跟踪工作。

## 如何衡量框架是否有效，以及本周该做的一件事

框架应以运营信号来衡量，而不是看政策文件的厚度。以下四项指标很有用。第一是清单覆盖率：治理团队已知的 AI 系统占实际使用系统的比例，可以通过采购记录、网络或身份数据进行核对。未知系统是最常见的意外来源。第二是审查及时性：一个新用例从申请到决定需要多长时间，高风险案例是否得到了相称的关注，而非走过场。第三是证据完整性：抽取一部分生产系统，团队能否在短时间内提供所有必需的证据？第四是事件学习：发生 AI 相关问题后，根本原因是否能追溯到某个被修复的控制缺口。

要警惕虚荣指标，例如培训场次或发布政策的数量。这些只能说明活动在进行，并不能说明控制是否有效。一小组有充分证据支撑的控制措施，比一长串没人检查的清单更有价值。对于需要在更广层面治理 AI 的团队，[2027 年面向安全与合规的企业 AI 治理](https://doc.duaer.com/zh/guides/enterprise-ai-governance-security-compliance-2027/)中关于治理与合规判断的讨论，提供了一份很好的清单，可用于决定优先衡量哪些指标。

不要一上来就重写政策。先列出你的组织目前使用的每一个 AI 系统，包括现有软件中的功能以及各团队自行引入的工具。对每一个系统记录业务责任人、它所接触的数据、它是否做出或建议决策，以及上次重大变更后是否经过审查。然后选择数据最敏感或决策影响最大的那一个系统，按照上述四个层次走完一遍。这一次练习的结果，会比任何模板更清楚地告诉你框架缺失了什么。

如果你希望以结构化的方式运行这套清单和审查流程，可以前往 https://www.duaer.com 注册试用，并建立你的第一条系统记录。先从一个用例开始，看看责任人、风险等级和证据字段是否与团队的实际工作方式吻合，再逐步调整。

到 2027 年，可信的 AI 安全合规框架并不是更长的政策文件。它是一小组有明确名字的责任人、清晰的风险等级、映射好的控制措施，以及能够随时出示的证据，并且只有在应用于真正运行中的系统时，它才会真正落地。

## 常见问题

### 企业搭建 AI 安全合规框架应该从哪里开始？

建议不要先重写政策，而是先盘点组织内正在使用的所有 AI 系统，包括嵌入在现有软件中的功能和团队自行引入的工具。为每个系统记录业务责任人、涉及的数据、是否参与决策以及上次重大变更后是否审查过。然后选择数据最敏感或决策影响最大的系统，端到端地走完清单、风险分级、控制映射和证据收集四个层次。

### AI 合规审计通常需要哪些证据材料？

证据应与每项控制直接对应，例如配置记录、模型或提示词的评估报告、访问日志、变更后的重新审查签字记录，以及事件处理的记录。如果某项控制无法产出任何可展示的证据，即使实施得很好，也很难通过审计。因此在设计控制措施时，就应同步确定它将产生什么证据。

### 如何判断 AI 安全合规框架是否真正有效？

可以关注四类运营指标：资产清单的覆盖率、新用例的审查及时性、抽样系统在短时间内提供完整证据的能力，以及 AI 相关事件后能否追溯并修复控制缺口。相比培训场次或政策数量等活动指标，这些指标更能反映框架是否真正在约束系统行为。