人工智能治理评估：实用的准备指南

根据The Netwrix 2026 Data and Identity Security Report，只有11%的组织报告通过持续执行和监控实现了全面的AI安全准备。领导层仍然要求安全团队批准Microsoft 365 Copilot的部署，通常在固定的时间表上进行，且常常没有可靠的方式来确定这些工具能访问哪些敏感数据。部署批准与已知风险之间的差距，是AI治理评估存在的原因。

像 NIST AI RMF、EU AI Act 和 ISO/IEC 42001 这样的政策框架定义了 AI 系统应遵循的规则。这项准备工作在这些规则之下一层运作：它衡量安全团队现在可以验证的数据和身份暴露情况，在框架讨论开始之前。

评估侧重于数据和身份暴露；模型级治理、偏见审计和算法风险管理属于独立的治理工作流。运营问题是安全是否能证明AI工具在推出决策变得不可逆之前能够达到的范围。

什么是AI治理评估？

此评估是对Copilot等AI工具可访问内容、谁控制该访问以及组织是否能向董事会或审计员证明这些内容的结构化评估。采用AI治理平台或制定AI治理政策是独立的工作；评估是诊断步骤，告诉您这些工作实际需要涵盖的内容。

对安全团队最重要的区分是：治理框架定义了AI应遵循的规则，而准备度评估衡量这些规则下的数据和Identity层，这是安全工具可以验证的层。衡量暴露度为治理计划提供了政策、框架对齐和持续治理的基线。

为什么AI治理评估很重要

评估将这些压力转化为安全团队可以采取行动的事项，远早于正式治理计划的实施。

继承的权限变成可修复的列表

评估准确揭示了AI工具当前能访问的内容，包括位于诸如 "Everyone except external users"（EEEU）等宽泛且过时授权背后的所有内容，在这些访问变成聊天结果之前。Microsoft 365 Copilot是最明显的例子：其pre-rollout guidance标记了EEEU使用、过大受众和权限继承断裂，将无形风险转化为安全团队可在上线前清理的任务清单。

监管截止日期不再令人意外

提前进行评估意味着监督证据在固定日期到来之前就已准备好，而不是在截止压力下组装。EU AI Act's 2026年6月的数字综合协议将独立高风险义务推迟至2027年12月2日，但Article 50 的透明度和GPAI执法权仍将于2026年8月2日生效，同时还有Texas's TRAIGA 和 California's AB 2013，两者均于2026年1月1日生效。提前评估的团队在这些日期到来之前就已掌握证据。

董事会和审计员获得他们已经期望的证据

评估用董事会和审计员现在直接要求的证据替代了政策文件。ISACA 2026年3月指南直言不讳地指出：“如果唯一的证据是政策链接，那就是作秀。”NACD的董事指导更进一步，建议董事会要求实际的AI tool map 工具、数据访问和治理的地图，这正是此评估产生的成果。

Shadow AI 不再隐藏在盲点中

将评估范围扩大到授权工具之外，会暴露最大的盲点：员工采用浏览器扩展、个人ChatGPT账户和嵌入式SaaS AI功能的速度快于IT部门的审批和跟踪。Netskope 2026 Cloud and Threat Report发现47%的genAI用户依赖个人AI应用。将影子AI发现纳入清单，将该盲点转变为已知的、可管理的列表。

部署更快推进，充满真正的信心

提前进行评估使安全团队能够在部署前修复最高风险的暴露点，保持部署进展而非停滞。Gartner对132位IT领导者的调查发现，2025年数据过度共享导致40%的人将Copilot的部署推迟了三个月或更长时间。一旦团队了解了暴露点并提前解决，就能避免这种延迟。

AI治理准备评估的四大支柱

此评估衡量四个方面，而非通用的AI治理框架；它们共同决定AI部署是否具有可衡量的暴露、可追责的访问和可辩护的证据。

AI资产清单

一份当前维护的列表，涵盖所有影响环境的AI工具和AI功能：包括Copilot等批准部署、嵌入现有SaaS工具的AI功能，以及独立采用的影子AI员工。每条记录都需要有所有者、环境和业务职能。内部审计师协会（IIA）的AI Auditing Framework规定，清单应涵盖AI的目标、使用和管理者、使用的工具、风险考虑及监督者。

数据暴露映射

一张地图，显示库存中每个AI工具可以读取、索引或在响应中显示的数据存储库、文件共享、SharePoint站点、Microsoft 365（M365）工作负载和第三方SaaS平台。该支柱回答了董事会提出的第一个问题：这个AI工具能看到什么？

Netwrix 2026 Data and Identity Security Report发现，79%的组织缺乏对用于AI工具、模型或副驾驶的敏感数据的完整可见性。解决这一问题需要进行discovery and classification，涵盖结构化和非结构化数据，并建立data security posture的基线，以便推广。

身份和访问控制

评估哪些人类身份、机器身份、非人类身份和组可以访问前一支柱中映射的数据，重点关注全公司共享链接、广泛的安全组以及角色变更遗留的过期权限。将机器身份和AI代理与人类用户一起纳入考虑。

对于Copilot，经过身份验证的用户权限使得权限过度的服务帐户和广泛共享的邮箱成为高风险面，根据2026年5月的 Cloud Security Alliance (CSA) guidance。此观点定义了安全团队在部署前需要改进的identity risk posture。

监控与证据

事后需要的日志记录和审计追踪，用于回答哪个AI工具触及了哪些数据，由谁以及何时触及。ISACA 2026年5月的AI audit trail 指南指出，审计人员应期望“可审计的证据，证明敏感输出是由经过身份验证的请求生成，使用授权数据，并在强制控制下完成。”这一支柱是及时审计追踪的基础，用于捕捉滥用或过度共享行为。

如何分六步进行AI治理评估

当每个步骤都生成下一个步骤可以重用的工件时，流程效果最佳。

步骤1：清点所有正在使用或计划使用的AI工具

构建一份涵盖批准工具、内嵌SaaS AI功能和影子AI的单一列表，为每个条目附加所有者、环境和业务功能。同步从三个来源提取数据：采购和SaaS支出记录、Open Authorization（OAuth）授权及浏览器扩展审核，以及对业务部门的直接调查。每个来源都有盲点。

支出审查可能会遗漏低成本的已报销工具，而Microsoft的Defender for Cloud Apps OAuth审查仅显示请求委托权限的应用程序。此清单是后续所有步骤依赖的交付成果。

步骤2：定位并分类这些工具可以访问的敏感数据

对于库存中的每个AI工具，识别其可以读取或索引的存储库：文件共享、SharePoint、M365及连接的SaaS平台。这需要对环境进行发现和分类，因为工具的配置界面显示访问路径，分类则显示其中内容的敏感性。

微软自有工具展示了规模：SharePoint Data Access Governance reports 识别了访问最广泛的网站，包括向数千用户开放的网站。结果是一个数据地图，将每个AI工具与它可以接触的sensitive data 集合配对。

步骤3：评估围绕AI可访问数据的identity和访问控制

审查谁和什么可以访问步骤2中映射的数据，特别标记过于宽泛的授权：广泛的安全组、“Everyone except external users”样式的共享链接，以及角色变更后遗留的权限。有效权限很重要，因为访问通常通过嵌套的组成员身份流动，表面审查无法发现。这些发现为访问认证和identity governance 工具提供了一个与AI可访问数据相关的过度宽泛授权的命名列表，供审查者使用。

步骤4：根据相关框架评估现有的AI使用政策

无论已有何种AI使用政策，即使是非正式的，也请将其实际条款与NIST AI RMF、ISO/IEC 42001或欧盟AI法案进行对照，具体取决于组织的AI使用案例及当前生效的义务。政策缺口表现为：一项仅声明“负责任地使用AI”，却没有数据访问规则、审批流程及指定的执行负责人。输出结果是一份逐条缺口清单，供治理项目采取行动。

步骤5：审查监控、日志记录和证据能力

确认已有的遥测数据，例如M365审计日志，并测试其是否能回答特定问题：哪个AI工具以何身份、何时接触了哪些数据。Auditor证据是带时间戳的记录，将特定AI交互与特定数据集和身份关联。保留期限也很重要：欧盟AI法案第19条要求供应商至少保存自动生成的日志六个月。若当前遥测无法回答该问题，请记录差距。

第6步：评估准备情况并优先处理修复

对步骤1至5中的四个支柱分别进行评分，使用低、中、高等简单等级，并将得分最低的支柱转化为排名修复列表。SANS的AI成熟度模型的警告适用：在低成熟度阶段限制无文档证据的自我报告能力，并将每个分数与前面步骤中产生的工件关联。

AI 推出准备清单

任何“否”答案都意味着相应的支柱在推出前需要改进。

• 您能否生成环境中所有AI工具和AI功能（包括shadow AI）的最新列表，并标明各自的所有者？
• 您知道每个AI工具可以读取或显示哪些SharePoint站点、文件共享、M365工作负载和SaaS平台吗？
• 您能列出可以访问该数据的身份和组，包括通过嵌套组继承的访问权限吗？
• 您是否标记了EEEU资助、全公司共享链接以及与AI可访问数据相关的过期权限？
• 您的日志能否按工具、身份、数据集和时间重建AI数据活动？
• 您现有的AI使用政策是否逐条对应适用于您的框架（NIST AI RMF、ISO/IEC 42001或EU AI Act）？

在下一次AI部署决策之前，先修复有多个“否”回答的支柱。

Netwrix如何支持AI治理评估

AI治理评估工具应将数据暴露、身份上下文和审计证据连接在一个工作流程中，这正是Netwrix“Data Security That Starts With Identity™”方法的实际体现。

数据暴露可见性

Netwrix 1Secure™报告了Copilot和其他AI工具可以访问的存储库，包括对Microsoft环境中Copilot与敏感数据交互的可见性。 First National Bank Minnesota 使用了 Netwrix Auditor 和 Netwrix Data Classification 来发现、分类并移动敏感客户数据。

身份和访问上下文

Netwrix 1Secure 和 Netwrix Access Analyzer 显示了 Active Directory 和 Microsoft Entra ID 中的有效权限，展示了哪些身份和组可以访问 Copilot 及其他 AI 工具可见的数据，包括通过嵌套组路径授予的访问权限。 Eastern Carver County Schools 使用 Netwrix Privilege Secure 在几天内将常设权限替换为即时访问，临时账户 和零常设权限模型。

审计证据

Netwrix Auditor 提供了所需的变更历史，以回答谁何时访问了什么，并将AI可访问的数据随时间关联到特定身份。其免费的Microsoft Copilot插件收集了Copilot事件详情，包括文件名和精确路径，为安全团队提供带时间戳的记录，而非事后的手动重建。

在下一次AI部署之前开始您的AI治理评估

许多组织在部署包括Copilot的人工智能时，无法回答一个基本问题：该工具实际上可以访问哪些敏感数据？治理准备评估弥补了这一差距，并在完整的治理框架建立之前进行。

Netwrix 1Secure 为安全团队提供对 AI 数据访问、identity 上下文和审计证据的可见性，帮助他们立即进行此评估。超过 13,000 家组织，包括大约 25% 的财富 500 强，依赖 Netwrix 来回答有关 数据和 identity 风险 的此类问题。

请求演示，了解Netwrix如何帮助您映射AI工具的访问范围，解决对敏感数据的身份访问，并为您的下一次AI部署生成审计就绪的证据。