人工智能治理框架：如何构建有效的框架

AI通过多个渠道同时进入大多数组织。这里有授权助手，那里有现有SaaS工具中启用的AI功能，还有一些无人提交工单的工具。

本应全面覆盖的治理框架通常较晚到位，甚至可能根本不到位。在 The Netwrix 2026 Data and Identity Security Report 中，41%的组织已经在代表人类运行代理式AI生产环境，11%的组织通过强制、持续和主动的审查实现了AI治理的运营化。

信心反映了这一差距，情况并不乐观。根据 Grant Thornton 的数据，只有18%的年收入在1亿至10亿美元之间的组织非常有信心能通过独立的人工智能治理和控制审计。

同时，42%的中端市场IT领导者在The Netrio’s Mid-Market AI Readiness Report 报告了过去一年内确认的与AI相关的安全事件或暴露。弥合这一差距的框架将每条书面规则与某人可以测试的控制和某人可以调取的记录联系起来。

什么是人工智能治理框架？

AI治理框架是一套结构化的政策、角色、流程和控制，管理组织如何设计、部署和使用AI系统。这包括许可的助手、员工通过浏览器访问的公共工具、内置于SaaS应用中的AI功能以及内部模型。

ISO/IEC 42001 指的是一个强调运营结构的人工智能管理系统。人工智能风险管理框架侧重于识别和处理风险。

这三份文件经常被混淆，而区分决定了谁负责。framework定义了整个生命周期阶段的责任和流程。policy设定规则，assessment测试在特定日期哪一个执行得更好。

为什么AI治理框架很重要

该框架通过将分散的决策转变为董事会、监管机构或审计员可以检查的内容，从而赢得其地位：

• 基于证据的批准： 安全部门可以通过列出每个工具访问内容及其身份的命名清单来批准AI部署，而不是依赖构建者的保证。
• 可辩护的审计追踪： 风险评估、访问报告、配置历史和委员会会议记录在有人需要时都集中在一个地方。
• 受控爆炸范围： 范围和访问限制决定了受损或配置错误的AI会话可以访问多少数据。
• 更快的审批，而非更慢： 固定的接收路径和风险等级让低风险用例快速通过，其余的则转交真实审核。
• 一个程序代替两个： AI风险进入已运行的登记册、控制库和审核门，因此无需重复维护。

这些都依赖于同一个根本点：了解AI当前在实时环境中能实现什么。

为什么现有的治理计划落后于人工智能

三股力量几乎同时袭击安全团队。每一股都加大了政策声明与环境可证明之间的差距。

AI到达的速度比获得批准的速度更快

使用率领先于政策，数字相差甚远。ISACA的2026 AI Pulse Poll发现90%的数字信任专业人士认为员工在其组织中使用AI，而只有38%的组织拥有正式、全面的AI政策。

排序解释了大部分不足。RSM AI调查报告发现，大约三分之一的中端市场组织在治理控制到位之前就进入试点或生产阶段，16%只有在出现问题后才达到治理。积累起来的是一堆一次性批准和未记录的例外情况。只要没人要求证据，这种情况就能维持。

合规截止日期已开始过去

标准首先出现并设定了结构的期望。ISO于2023年12月18日发布了作为国际AI管理系统标准的ISO/IEC 42001，大多数团队将其与NIST AI RMF作为自愿的补充搭配使用。

随后，欧盟时间表发生了变化，方向并非大多数团队预期的那样。Digital Omnibus on AI于2026年7月8日通过的欧盟条例（EU）2026/1744，将大多数高风险义务推迟至2027年12月2日，适用于独立的附录III系统，及2028年8月2日，适用于产品嵌入的附录I系统。

两个日期没有变动，且都已过去。根据AI Act enforcement timeline，自2026年8月2日起，第50条透明度义务和委员会对通用人工智能模型的执法权已生效。该日期之前已上市的生成系统，必须在2026年12月2日前满足第50条第2款的标记义务，这是大多数团队的下一个实际截止日期。

人工智能放大了您已有的权限负债

AI 工具使用的是已有的访问权限。 微软自身关于过度共享的指导 直言不讳：Copilot 继承了现有的 Microsoft 365 权限和保护，因此必须在部署前纠正权限过多的网站、继承的访问权限和缺失的敏感度标签。

多年无人注意的临时共享，一旦提示能够访问，就变得可搜索。首先修复这一层也是收益显现的地方，因为拥有统一Identity和数据治理的组织报告完全AI准备状态的可能性几乎高出五倍。

有效的AI治理框架的六大支柱

大多数已发布的框架将数据访问可见性埋藏在隐私或数据治理等更广泛的领域中。它拥有自己的支柱，因为认证和审计依赖于此，且 ISACA的AI审计程序 明确要求访问日志、变更管理流程和基于角色的策略。

1. 范围和清单

范围定义了其他所有控制措施适用的对象。它列出了所涉及的AI系统和用例，以及与每个用例相关的业务目标、风险偏好和监管义务。

ISO/IEC 42001 第4.3条要求范围作为文件化信息可用。没有任何支持清单的范围声明在第一次抽样时即失败。

2. 所有权和审批路径

责任归属于指定的个人。执行赞助人、治理负责人、安全、数据保护和业务单元所有者各自拥有特定的决策权。

ISO/IEC 42001 控制 A.3.2 直接指出，要求“AI 的角色和职责应根据组织的需求进行定义和分配。” 实际测试是是否有人能说出谁批准新的用例，谁能关闭它。

3. 映射到控制的策略

政策涵盖可接受的使用、禁止的数据类型、人工干预要求、透明度期望和事件处理。政策的有效性在于每一行都明确规定了执行该政策的控制措施。

这些控制是访问限制，data classification，已部署的DLP解决方案、条件访问和日志记录。没有控制的规则只是句子，不是保障措施。

4. 数据和身份可见性

这一支柱回答了关于任何AI交互的两个问题。工具可以访问哪些数据，以及是哪种人类、机器或非人类身份调用了它？

这也是大多数程序无法证明的支柱。报告量化了原因，发现74%的组织缺乏对敏感数据及其可访问身份的单一统一视图。授予的访问和有效访问是不同的列表，并且在任何有历史的环境中都会迅速分化。

5. 生命周期管理

生命周期从数据到模型开发、部署、审查和退役，每个过渡阶段都有决策门。退役是几乎无人达到的门，也是审计人员关注的重点。

Identity 生命周期管理 已经处理人员的入职、调动和离职，AI 代理也属于同一领域。NIST AI RMF 子类别 MANAGE 2.4 要求有机制和分配的责任来替代、断开或停用与预期用途不一致的 AI 系统。

6. 测量与改进

测量为治理委员会提供决策依据。获得认可的指标包括AI事件数量、政策例外、风险评估覆盖率和控制有效性。

ISO/IEC 42001的第9和第10条涵盖监控、内部审计、管理评审和纠正措施。任何不改变决策的事项都不值得跟踪。

如何分五步构建框架

这些支柱描述了完成的框架包含的内容。构建过程按不同顺序进行，从环境中已有的AI开始，而不是从某人想要编写的策略开始。按顺序完成这五个步骤。

1. 清点已运行的AI

从三个来源提取，因为没有单一系统知道一切。授权应用和service principals来自您的identity provider，嵌入式AI功能来自供应商发布说明和管理中心，未经授权的工具来自出口日志。

预计制裁名单将严重低估。一次 2026年PagerDuty调查 发现，66%的办公专业人员在工作中使用了AI，尽管他们认为政策不允许，只有20%的组织完全监控或管理影子AI。

然后将您发现的内容按风险等级分类。内部生产力、面向客户的服务和受监管的数据使用各自需要不同的审查级别，等级决定系统接收剩余工作的多少。

2. 指定所有者并构建审批路径

为每个 AI 系统指定一名 IT、安全、数据保护或使用该系统的业务部门的负责人。团队、委员会和分发列表不计入。

然后映射请求路径，从风险评估到控制设计、签署和审查日期。写下谁授予例外，谁能在风险变化时暂停系统。

通过定期的access certification，确认管理员、服务账户、应用程序和AI代理仅保留其当前工作所需的权限。Active Directory service accounts通常是过期权限隐藏的地方。

3. 将每条规则映射到您可以测试的控制项

逐行查看策略，并在旁边写下执行控制。如果无法命名，则该规则尚不可执行，应列入差距清单。

明确且直截了当地划定红线。禁止生成式AI访问未分类的个人身份信息（PII），并对法律和人力资源数据设定明确例外。

特权访问需要按照其自身的条件进行处理。配置 AI 服务的管理员需要提升权限，因此为每个批准的会话发放短期的即时（JIT）凭证，并对集成这些服务的账户应用 zero standing privilege。

4. 将AI融入您现有的流程中

将AI风险类别添加到现有的风险登记册、控制库和问题跟踪器中，然后通过已建立的接收、变更管理和安全审查关卡处理AI用例。 ISACA 指南正是如此推荐，AI风险管理补充了已建立的网络安全、风险和隐私程序。

对第三方和嵌入式AI采取相同的处理，记录提供商、数据流、集成方式、保留条款、所有者和退出计划。需要工具进行访问审查时，将IGA tools与已涵盖的系统进行比较。

5. 设定节奏，然后证明其有效

在首次审查到期前确定审查频率，并将这些措施纳入现有的 IT risk assessment周期中。购买新工具前，请检查已部署的合规工具是否能生成报告。

然后以审计员的方式测试该框架。选择一个AI系统，获取其所有者、风险等级、控制集、访问报告和最后审查日期，看看你能在一小时内生成多少内容。

使框架与NIST AI RMF和ISO/IEC 42001保持一致

以这种方式构建的框架最终会用您自己的词汇编写。审计员、客户和监管机构不会这样要求。他们会询问您遵循哪个标准，映射让您无需重建即可回答。

ISO/IEC 42001的第5条涵盖所有权和AI政策，第6和第8条涵盖风险和影响评估，第9和第10条涵盖测量和改进。上述六大支柱中有四个被重新命名。

先映射哪一个并非偶然，原因常被忽略，因为两者常被一同提及。ISO/IEC 42001 可审计且可认证，NIST AI RMF 则不是。这个差异决定了你能主张什么，以及你的证据应提交到哪里。

AI RMF 对数据中心程序能做和不能做的事

AI RMF Core 组织了贯穿 Govern、Map、Measure 和 Manage 的风险管理，其子类别是结果陈述，而非要求。NIST 不发布合规性评估方案、认证标准或认证机构要求。您可以说您的项目符合 AI RMF，或控制措施映射到其子类别，但不能说“已获得 NIST AI RMF 认证”。AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

在映射任何内容之前，有第二个限制值得了解。在所有72个子类别中，没有一个提到access control、identity、authentication、permissions或data provenance。因此，了解哪些identities可以访问哪些数据——证据包实际启用的内容——是通过解释而非文本钩子映射到AI RMF的。

三个子类别家族在实践中承担着这一重任。第三方集合最强大，包含 GOVERN 6.1 涵盖第三方AI风险政策，MANAGE 3.1要求“定期监控来自第三方资源的AI风险和收益”，以及 MAP 4.2 涵盖第三方组件的内部风险控制。MEASURE 2.7和2.10 是安全和隐私评估证据的归属地。对于撤销配置，请将MANAGE 2.4与GOVERN 1.7配对使用。

为什么在审计前需要翻译NIST crosswalk

NIST发布了一个从AI RMF子类别到ISO/IEC 42001的crosswalk，这节省了大量实际工作。它还有一个让团队容易忽视的特性。其202个控制引用均指向附录B，且未引用任何附录A的控制。

这种区分决定了您的映射是否能通过审计。附录A是规范性的，其控制条款使用“shall”，适用性声明基于此构建。附录B是实施指南，其控制条款使用“should”，并明确指出组织无需为在适用性声明中包含或排除该指南进行辩解。将MANAGE 2.4对应到“B.9.4 Intended use of the AI system”的交叉表行指向的是建议，而非可审计的控制。

翻译是机械的，因为42001对两个附录进行了并行编号，所以B.9.4是A.9.4的指导。跳过它是常见错误。另一个需要知道的是：crosswalk针对的是ISO/IEC FDIS 42001最终草案，而非已发布标准。

大多数程序忽略的条款

风险评估和影响评估是42001中的独立义务，将二者混淆是首次适用声明中最常见的缺失。第6.1.2条评估您自身AI目标的风险，包括可能性、风险等级和风险标准。第6.1.4条评估对个人、个人群体和社会的外部影响，不涉及任何可能性机制。

这种关系是单向的。第6.1.4条款要求在风险评估中考虑影响评估结果，而注释6.1.2指出组织可以使用影响评估来评估后果。每种都有其自身的文档化信息义务；附录A.5控制影响方面，第8.4条款要求在计划的间隔或重大变更时运行两者并保留结果。ISO/IEC 42005提供了方法，尽管它是指导性文件，不能作为认证依据。

数据和身份的可见性依赖于控制而非条款。在38个Annex A controls 个类别中，A.7.5 Data provenance 是数据中心程序所需的，因为它要求有记录 AI 数据来源的文档化流程。

认证实际要求的内容

认证根据ISO/IEC 17021-1分为两个阶段进行，认证机构的能力由ISO/IEC 42006设定，于2025年7月发布。第二阶段是人们计划的阶段，因为它根据完成的风险评估和AI系统事件日志等证据现场评估实施和有效性。

阶段1是最容易让人犯错的阶段。它评估阶段2的准备情况，包括内部审计和管理评审是否真正执行，而不仅仅是安排。你需要完成一个完整的内部审计周期，这通常会使实际认证日期比团队预期推迟一个季度。

AI治理框架清单

六个问题揭示了成为审计发现的漏洞。请根据您实际拥有的环境回答每个问题，而非政策中的环境：

• 该程序是否指定了负责人并设定了带有实际日期的审查周期？
• 您是否已找到所有正在使用的AI系统，并将每个系统映射到其访问的数据和身份？
• 您的 AI 策略是否针对特定技术控制，涵盖访问限制、DLP、条件访问和日志记录？
• 该框架是否符合NIST AI RMF、ISO/IEC 42001或两者，以便能够对覆盖范围进行基准测试？
• 您能根据请求生成风险评估、配置日志、访问报告和委员会会议记录吗？
• 您是否有计划在工具、法规和风险变化时更新框架？

任何你无法回答的问题都是需要负责人、补救计划和验证日期的漏洞。

Netwrix如何弥合AI治理证据差距

第四支柱是治理意图与环境现实相遇的地方，它依赖于本地工具以简明形式保存或分散在门户中的数据。Netwrix通过命名的AI governance功能提供该层，值得准确说明每个产品的功能。

报告人工智能能够达到的范围

Netwrix 1Secure 在决策仍可逆时回答预部署问题，报告Copilot在任何人启用之前可以访问的敏感数据。上线后，报告Copilot活动，列出用户、时间戳和引用的资源，并标记暴露敏感数据的响应。它还跟踪Microsoft Entra ID中的角色、权限和更改。

Netwrix Access Analyzer 处理问题中较难的部分。它解析嵌套的组成员关系以计算有效访问权限，适用于Active Directory和Microsoft Entra ID用户、SharePoint站点及文件系统，揭示开放访问和继承中断。这使得第四支柱从一种断言变成了可按身份提供的报告，方便传递。

超出日志窗口的证据保留

框架在决策几个月后进行审计，这使得这更多是一个保留问题，而非报告问题。 Netwrix Auditor 记录谁在何时更改了什么及其前后值，并生成时点报告，基于每日配置快照。

两家受监管的客户在审查时展示了差异。 First National Bank and Trust of Beloit在17个地点为300名用户保持持续的OCC合规，将一整周的手动检查表工作缩减为一小时的准备时间。

Credissimo证明其消费者金融业务符合GDPR和ISO/IEC 27001标准，审计报告生成速度提升85%，从一周缩短至一天。

Netwrix覆盖了支柱四所需的数据访问、identity和审计报告层，而更广泛的AI治理平台假设您已经拥有这些。这些平台运行更广泛的工作流程；AI供应商保留模型行为的控制权；框架、委员会和决策由您掌控。

首先在一个系统上验证该框架

当领导层在当前访问、配置和活动数据为其决策提供信息时，会信任一个框架。这反对一次性启动整个项目。选择一个高影响力系统，然后衡量敏感数据暴露、权限范围、异常数量和证据包的完整性。

在您现有租户上运行的授权助手是最佳原型，因为其权限模型依赖于已存在的访问决策，且可见性工具现已存在。针对该系统运行六大支柱，查看证据实际证明了什么，然后将此模式应用于其余的AI库存。

请求演示，以了解您的AI工具能达到的范围，映射其背后的身份，并保留下一次审计所需的变更历史。