如何制定AI治理政策（+应包含内容）

根据 The Netwrix 2026 Data and Identity Security Report，只有11%的组织在人工智能安全方面完全准备就绪。

大多数组织中的AI采用 是通过个人工具选择实现的，安全审核尚未跟上：员工将 Microsoft Copilot、ChatGPT 以及数十个嵌入式AI功能连接到他们的日常工作中，且在任何人制定访问规则以管理这些工具可访问内容之前。

该风险依然存在，因为AI访问遵循不同于普通用户请求的审核模式。这些工具及其背后的代理身份可以继承权限、查询敏感内容，并比人工审核更快地创建新的审计问题。

安全团队需要了解存在哪些工具、它们可以访问哪些数据、谁批准了它们，以及团队如何升级异常。书面政策通过定义AI在事件引发问题之前可以接触的内容来弥补这一差距，增强网络弹性，同时确保AI采用的责任。

什么是人工智能治理政策？

AI治理政策是定义组织的员工、承包商和供应商如何使用AI工具的规则的文件：这些工具可以访问哪些数据，组织批准哪些工具，以及团队如何升级违规行为。

团队经常将“AI治理”和“AI政策”混用，但它们描述的是同一问题的不同层面，这一区分决定了责任归属。

AI治理框架是政策运行的更广泛、持续的计划：包括保持政策最新的角色、审查周期和工具。外部参考框架，如NIST AI Risk Management Framework (AI RMF)和ISO/IEC 42001,提供了框架的结构，而政策则将该结构转化为您的团队可以遵循的规则。

AI治理政策的示例有哪些？

抽象原则易于认同，但难以实施。来自企业软件、医疗保健、金融服务和国防承包的参考政策展示了需求如何根据数据类型和法规变化。

Enterprise Copilot 和大型语言模型（LLM）数据访问策略

这些是大多数中端市场安全团队需要编写的最接近的类似内容，除非有任何特定行业的法规需要遵守。它们侧重于与已使用的特定工具类别相关的数据访问规则，例如 Microsoft 365 Copilot 或 ChatGPT，这使得执行基于真实工作流程。这些策略通常将 sensitivity labels 与 operating model 结合，区分分类所有权与技术执行。

医疗保健人工智能治理政策

医疗机构围绕《健康保险携带与责任法案》（HIPAA）制定这些政策，将临床AI使用（诊断或面向患者的工具，受最严格的访问和审计规则约束）与行政AI使用（排班、计费、内部文档）分开，因为两者在同一法规下具有不同的风险级别。示范政策：组织只有在供应商签署了Business Associate Agreement时，才可将受保护的健康信息（PHI）输入AI工具。

金融服务和国防承包商的人工智能治理政策

这些框架以特定的规范为主导：金融服务包括Service Organization Control 2（SOC 2）、通用数据保护条例（GDPR）和数字运营韧性法案（DORA），而国防承包则包括Cybersecurity Maturity Model Certification (CMMC)。两者都将风险等级直接与AI工具是否涉及客户财务数据或受控非机密信息（CUI）相关联。

防御政策更进一步：根据Information Security Oversight Office (ISOO) 指导，承包商不得将CUI输入公共或消费者AI工具，且任何处理CUI的AI工具必须出现在承包商的系统安全计划中。

使用这些示例，将您的政策基于组织实际拥有的工具、数据类型和合规义务。

为什么AI治理政策很重要

书面政策为AI采用提供了一个治理模型，安全团队可以衡量、执行和改进。它还将工具批准、数据访问、监控和升级转化为可审查的证据。

AI的采用比安全评估的速度更快地扩大了攻击面

每个新的Copilot、ChatGPT或嵌入式AI功能都需要访问组织数据，每个功能都会创建一个新的访问路径需要管理。Netwrix 2026 Data and Identity Security Report发现，76%的组织未能完全管理或监控其环境中的非人类身份，因此大多数AI工具的采用是在缺乏持续可见性的情况下进行的。

监管框架正从自愿指导转向强制执行

欧盟AI法案的合规性评估义务针对高风险系统通常自2026年8月2日起生效，附录I产品法规涵盖的高风险系统则自2027年8月2日起生效。书面政策有助于证明组织在要求成为强制性之前已跟踪该要求。等待法规生效后再记录，则无法证明善意努力的证据。

审计员和董事会现在期望有一份书面政策

当领导层问“我们在AI方面安全吗？”时，书面政策是证明答案不仅仅是意见的证据。口头保证在审计或事件审查中会瓦解。该政策将安全态势转化为审计员可以阅读、董事会可以指认的内容，这符合ISO/IEC 42001中正式制定的期望。

最小权限原则仅在策略定义其访问权限时适用于AI工具

安全团队多年来一直按角色限制人工访问。团队通常默认豁免AI工具的相同纪律，将其视为部署它们的人的扩展或通用服务账户。 Identity guidance 不鼓励这两种做法，因为 least privilege 需要有范围且负责任的访问。政策将AI工具定义为其自身的账户类别，受真实访问限制约束。

没有它的组织已经在为此买单

Netwrix 2026年数据和Identity安全报告发现，72%的组织表示由于AI和自动化，过去两年中与身份相关的敏感数据风险有所上升。政策差距已在风险数据中显现，报告此情况的组织也是采用AI最快的组织。

AI治理政策中应包含的内容

可用的政策需要包含安全、法律、IT 和数据所有者能够转化为审批和访问决策的条款。每条条款应将政策声明与使其可执行的所有者、工具、数据类别或控制联系起来。

• 范围和适用性： 定义政策涵盖的对象及其适用范围，包括员工、承包商、供应商和已使用的shadow AI工具。没有明确范围，政策只管理已知工具，其他则不受管控。
• 治理角色和指导委员会： 拥有该政策的人员姓名，以及在出现政策外情况时应升级至的人选。若无指定负责人，“政策执行”默认由最先发现问题的人负责。
• 风险分类： 根据涉及的数据或决策，将AI用例分为低、中、高风险。没有分级时，每个AI用例都接受相同程度的审查，导致高风险用例审查不足，低风险用例产生不必要的摩擦。
• 数据访问和使用规则： 指定AI工具各风险级别可以和不可以访问的数据。这是将价值声明转化为可执行控制的条款。没有它，“负责任的AI使用”没有技术意义。
• 批准的工具和供应商审核流程： 规定安全、法律和数据负责人如何审核并批准新的AI工具，确保在任何人将其连接到公司数据之前获得批准。没有此流程，工具的采用将由最先发现者决定，而非通过安全审核。
• 监控和审计要求： 定义组织如何验证团队在实践中遵守政策。无人核实现实的政策仅存在于纸面上。
• 事件响应与升级： 说明当AI工具引发或揭示安全或合规问题时的处理方式。没有此流程，团队会临时、错误地或过晚地处理与AI相关的事件。
• 法规对齐： 将政策映射到适用的框架，包括NIST AI RMF、ISO/IEC 42001和EU AI Act。这使得一项政策能够满足多个合规义务，而无需为每项法规准备单独的文件。
• 审查和更新频率： 承诺按照既定计划以及在出现重大触发事件（如新工具类别、法规变更或事件）后重新审视政策。AI工具的变化速度超过大多数政策审查周期，因此没有频率的政策会在几个月内过时。

如何制定兼顾采纳与问责的AI治理政策

领导层希望AI采用快速推进；如果行动不慎，安全团队将承担后果。请按照安全团队需要证据的顺序编写政策：先是所有者，然后是工具和数据流，再是风险等级、访问规则、法规映射和审查频率。通常在清单之前编写的访问规则会遗漏已经造成暴露的工具。

1. 在写任何文字之前，组建一个跨职能的治理团队

首先明确实际岗位：负责执行、法律和合规监管语言的信息安全或Identity and Access Management (IAM)负责人，了解敏感数据所在的IT或数据所有者，每天使用AI工具的业务部门代表，以及能够批准例外的执行赞助人。

根据哪个角色已经有权力绑定安全之外的业务单元来选择主席，而不仅仅是安全内部。在以安全为主导的组织中，那是CISO。在以风险为先的组织中，则是高级风险执行官，因为业务单元已经向该角色负责企业风险，AI治理也需要同等权力，否则这些单元会将其视为可选。

每个角色限制一人，只有在工作量要求时才设副手。如果安全部门单独制定政策，读起来像安全文件，可能缺乏管理产生风险的业务部门的权威。

2. 清点您已有的AI工具和数据流，包括shadow AI

同时从四个来源构建清单：SaaS支出、采购记录、浏览器扩展、Open Authorization (OAuth)授权审计，以及对业务部门的直接调查。

请交叉核对所有四项，因为员工通常会遗漏他们认为“只是写作助手”的工具，而采购记录会遗漏单独报销的项目。个人订阅可能低于审批门槛，支出审查可能会遗漏现有SaaS合同中捆绑的AI层级。

对于 Microsoft 365，枚举 Entra ID 中的企业应用程序和服务主体，并标记任何拥有委派或应用程序 Microsoft Graph 权限的项，因为每个授权都是 AI 工具可利用的访问路径。

OAuth 同意授权审计和 Microsoft 针对 非法同意授权 的修复步骤有助于揭露并清理风险授权。在进行过程中，记录每个工具的用途、业务负责人及其涉及的数据到 AI 系统清单中。

3. 按风险等级分类AI用例

将每个用例根据两个标准一起分类：

1. 工具涉及的数据（公开、内部、受监管或个人身份信息（PII））。
2. 它如何处理这些数据（总结并显示，支持业务决策，或采取自主行动）。

仅重写公开营销文案的工具无论多复杂风险都低。提取客户记录以回复支持工单的工具即使输出看似常规，风险也很高。

执行交易或修改生产的自主工具位于顶层，需强制人工审批。如果您在欧盟运营，请将这些内部层叠加在 EU AI Act categories 之上，以便两个方案都保持可见。

4. 定义每个风险等级可以和不可以访问的数据

将每条访问规则写成从风险等级到数据类别的直接映射。低风险工具可访问非敏感且已公开的内容。中风险工具仅限访问特定的已分类数据集。高风险工具在部署前需要明确的书面批准、访问日志记录和指定的人工审核员。

对于受监管的数据，请明确说明条件：PHI 需要签署的 Business Associate Agreement，且 CUI 不能输入到任何 认证环境 之外的工具中。

5. 在发布之前定义升级和事件响应

明确当 AI 工具引发或揭示安全或合规问题时会发生什么：谁会收到通知，通知速度如何，以及现有的哪个事件响应流程会处理此问题。将升级路径与步骤1中指定的治理角色关联起来，使问题有明确负责人，而不是默认由最先发现的人处理。

如果没有将此步骤书面化，团队最终会临时处理与AI相关的事件，使用错误的操作手册或处理得太晚，而这正是政策应在事件发生前弥补的缺口。

6. 将您的策略映射到适用的监管框架

一个控制矩阵可适用于您使用的所有框架。将四个AI RMF功能（Govern, Map, Measure, and Manage）与ISO/IEC 42001的管理体系条款及AI法案风险等级对齐，然后针对该组合矩阵一次性编写策略语言。

这两个标准相辅相成：NIST AI RMF 提供运营风险管理措施，ISO/IEC 42001 提供治理架构和审计追踪。在这些框架中使用相同的控制语言，可减少您所承担的每项义务中的重复文档。

7. 在发布前设定审查频率

承诺一个具体的时间间隔，至少每年一次，并设定指定触发条件，强制进行非周期性审查：采用新的AI工具类别、法规变更、事件，或收购或重组，包括业务流程和相关数据要求的重大变更。

根据风险调整频率，团队更频繁地审查高风险系统，治理委员会则按固定时间表定期召开会议。将频率、触发条件和负责人写入文档。仅存在于某人脑中的审查计划，一旦该人换岗即失效。

如何在实践中执行AI治理政策

策略条款需要安全能够验证的技术控制。“策略说不”只有在可见性、访问审查、警报和撤销使该答案成立时才有意义。

全面了解您的 AI 工具实际可以访问的内容

执行始于AI工具与数据连接的实时地图：OAuth授权、Microsoft 365和Microsoft Entra ID 权限、浏览器扩展以及现有SaaS平台内嵌的任何AI功能。

同时关闭前门：禁用用户对未经验证应用的同意，并通过管理员同意流程引导新请求，使新的 AI 集成默认进入审核流程。

安全团队通常可以回答“谁拥有什么访问权限”针对人类账户；此步骤构建了针对AI工具和代理的等效答案，包括有效权限，这些权限源自嵌套组和继承访问。

这里微软的原生工具有所帮助，尽管 Purview DSPM for AI 仅对前100个SharePoint站点运行其自动风险评估，因此更广泛的data security posture 视图有助于验证原生情况并识别差距。

专门针对Copilot，将敏感度标签与SharePoint站点访问限制和Restricted Content Discovery配对，确保过度共享永远不会触及Copilot所依赖的基础数据。

以对待人的相同方式执行对AI的最小权限原则

将 AI 工具和 代理身份 视为其自身的账户类别，适用相同的访问审查和 认证工作流，该工作流已用于人工账户。要求有范围限制且带过期的访问权限，而非广泛的常设权限，并执行入职-调动-离职流程，该流程同时管理人工离职和 AI 工具退役。

Zero Standing Privilege通过使用任务范围的ephemeral accounts来模拟这一原则，而非使用持久的提升权限凭据。

东卡弗县学校 正是采用了这种做法：没有让管理员账户随意访问学生数据，学区仅在需要时使用 Netwrix Privilege Secure 来限定特权访问，且部署用了几天，而非一个季度的项目时间。

将每个代理身份锚定到一个human sponsor，以便当人类所有者离开时，每个账户都有一个负责任的所有者。当前的身份指导建议比人更短的审查周期，至少每季度一次，高权限代理则每月一次，因为代理访问变化比年度认证更快。

持续监控由AI驱动的数据暴露

监控必须持续进行，因为一旦出现新的AI工具或集成，单次访问审查就会过时。跟踪AI工具实际查询和检索的数据，超出记录的权限范围，并标记超出批准使用的数量或敏感性模式。

在 Microsoft 365 中，Copilot 交互操作会被记录在统一审核日志中，因此请确认审核保留期与策略承诺的证据窗口相符，以防审计员要求查看去年的记录。这为安全团队提供了策略访问规则与实际 AI 行为一致的证据。

Netwrix AI Governance，通过Netwrix 1Secure™提供，增加了Copilot交互跟踪和报告，安全团队可以将其作为审计证据保存。

当AI工具越过其访问边界时，自动触发警报和升级

检测只有在触发政策已定义的升级路径时才有价值。将发现自动路由到政策治理部分中指定的incident response process，并将每个警报记录为审计证据。升级路径必须连接到具有明确所有权和时间安排的有效撤销流程。

将您的 AI 治理政策转化为可执行的控制措施

当每条款对应于技术控制时，书面政策可降低风险：可见AI工具能访问的内容、AI身份的最小权限以及持续监控。

许多与AI相关的风险遵循与身份事件相同的访问路径：攻击者使用合法凭据访问数据，而具有过度常驻访问权限的AI工具则成为环境中另一个权限过多的身份。

数据安全和身份安全是从两个角度看待的同一个问题，只有两者同时执行时，策略才能降低风险。

请求演示，了解1Secure如何映射AI工具访问、跟踪Copilot交互，并将您的策略访问规则转化为审计证据。