面向安全和IT团队的AI治理审计

领导层批准了Microsoft 365 Copilot，两天后法务部门想知道它可以读取哪些敏感文件。在Netwrix 2026 Data and Identity Security Report调查中，71%的安全和IT领导表示，他们无法立即确定哪些身份有权访问特定的敏感数据。

助手本身很少是问题。微软的文档指出，Copilot显示组织数据，个人用户至少拥有查看权限，因此每个过时的组成员资格和过度共享的网站都可能成为提示结果。控制缺口存在于底层权限层，那里积累了多年未经审查的临时共享。

逐一测试第一层身份和文件，才能得出无需任何人凭信任接受的答案。

什么是人工智能治理审计？

AI治理审计检查管理AI访问数据、身份和工作流程的控制是否按设计运行。证据包括日志、测试结果、权限报告和带日期的审查。PwC的审计指导将任务定义为测试与AI相关的控制的设计和有效性。这意味着记录每个控制的设计方式、运行方式以及管理层如何测试它。

治理审计以控制有效性结束。模型性能测试是一个独立的学科，涵盖偏差、漂移、准确性和可解释性。

范围涵盖治理和政策、技术和模型风险，以及数据访问和身份控制。IIA's AI Auditing Framework 按责任分配工作，将其映射到三线模型，使治理机构、管理层和内部审计各自拥有明确的份额。身份明确包含在范围内，ISACA AAIA outline 要求审计人员评估组织的特定于AI的身份和访问管理程序。

为什么AI治理审计比政策文件更重要

政策表达了一种意图。审计产生的证据表明该意图在与实际租户接触后依然有效。这个差距区分了治理计划与治理幻灯片，并在四个具体方面带来回报。

基于证据批准AI采用

安全团队被要求在别人设定的时间表上批准AI部署。完成的审计让他们能够凭借一份列明哪些AI工具以哪些身份访问哪些数据的名单进行签署。批准基于的是有人实际测试过的边界，而不仅仅是描述。

将策略转化为测量记录

NIST AI RMF 对持续测量的期望体现在 MEASURE 2.4 中。它指出，AI 系统及其组件的功能和行为（在 MAP 功能中识别）应当“在生产中被监控。” 审计将书面政策转化为满足该期望的记录，该记录由日志、权限报告、签署的测试结果和附有日期及姓名的审查组成。

在成为事件之前发现暴露

过度共享的网站和过时的权限通常会在他人安排的时间出现，通常是在调查期间。Netwrix 2026 Data and Identity Security Report发现，75%的敏感数据泄露始于身份被攻破或权限配置错误。这使得权限层成为最值得关注的地方。

计划审计会将这些条件转化为带有工单和指定负责人 的发现，早于违规审查数月。

计划的审计会将这些条件转化为带有工单和指定负责人的发现，提前数月进行违规审查。

为领导层提供一个有影响力的数字

董事会为他们能够跟踪的工作提供资金，完成的审计会产生未解决漏洞的数量，以及负责人和目标日期。团队根据失败的控制测试和未解决的问题得出该数量，因此进展显示为趋势线，就像补丁合规率或钓鱼失败率一样。

如何审计AI治理控制

一份可辩护的审计按顺序回答五个问题。它涵盖了正在使用的AI系统、每个系统可以访问的敏感数据、它们所使用的身份、适用的控制措施，以及显示这些控制措施有效的证据。按顺序完成以下六个步骤，并以最后指定的工件结束每一步。

1. 构建并验证AI资产和数据访问清单

从三个来源拉取清单，因为没有单一系统能知道所有信息。获取来自 Microsoft Entra ID 的授权 AI 应用和 service principals。添加每个 SaaS 供应商发布说明和管理中心中的嵌入式 AI 功能，以及来自出口日志或您的 CASB 的未授权工具。对于每个条目，记录所有者、业务目的、环境以及工具可以读取的存储库。

然后对三份列表进行核对，将每个差异视为发现。为每个未注册工具指定负责人和决策日期，决定是保留还是阻止，并记录结果。未经授权的使用很少出现在采购记录中，这就是为什么shadow AI security应与授权工具一起在首次审核中处理。

对您已批准的工具也要进行同样严格的审查，因为批准和安全是两个不同的问题。某个租户中Copilot是否安全取决于其许可身份可以访问什么，而这个清单就是对此的回答。

当环境中的每个AI工具都出现在一个单一列表中，并带有所有者和数据源映射时，即视为步骤完成。NIST AI RMF GOVERN 1.6要求具备根据组织风险优先级对AI系统进行清点和资源分配的机制。该列表满足此要求。该工件是带有附加发现列表的验证清单。

2. 针对执行该策略的角色测试每条 AI 策略

在查看任何控制措施之前，请根据四个问题阅读每项AI使用政策。确定哪些使用是可接受的，哪些数据类型被禁止，在哪些环节需要人工介入，以及输出结果的保留时间。将每个问题的答案写下来，并标记政策未明确的问题。

然后构建一个两栏地图，将每条政策声明放置在负责执行该政策的指定角色旁边。请指明个人姓名，因为团队名称无法为审计员提供可采访的对象，无法了解谁批准新的AI用例，谁审查高风险工作流程的输出。任何未附姓名的声明即为发现。

扩展您现有的治理，而不是编写一套平行的AI规则。一个IAM risk assessment已记录审批路径，且已有建立的identity governance and administration程序已定义角色所有权。确认这些规则延伸至AI使用，并记录其终止点。

GOVERN 2.1 要求对映射、衡量和管理 AI 风险的角色、职责和沟通线路进行记录，并确保组织内的个人和团队清楚。产物是该政策到角色的映射，未归属的声明被列为差距。

3. 映射每个AI可访问数据源的有效访问权限

将此步骤分四次执行，从许可证到文件。首先，列出持有Copilot许可证的用户和组。其次，解析每个组的实际成员，包括嵌套组。第三，列出包含敏感数据且解析成员可以访问的SharePoint站点、Teams和邮箱。

第四轮覆盖了人们容易忘记的身份，从访客开始。访客账户比任何其他账户都更快地扩大地图，因此请审核 Teams guest access 对相同的敏感站点。然后对非人类身份重复整个过程，因为 Active Directory service accounts 和应用注册通常拥有比任何在职人员更广泛的访问权限。

从原生报告开始映射，然后检查遗漏的内容。Microsoft的"Site permissions for users"报告列出了指定用户可以直接或通过组访问的SharePoint或OneDrive站点，是最接近的按身份的原生视图。

在将该输出视为完整之前，请针对您自己的环境验证三个限制。该报告依赖于 organization-wide permissions report，该报告仅显示按允许用户数排名前100的网站，并排除已归档网站和处于NoAccess锁定状态的网站。数据生成可能延迟最长48小时，每个租户限制为每30天刷新五份报告。

使用能够一次性解决整个资产嵌套问题的工具来覆盖剩余部分。这正是 data access governance 功能以及更广泛的 data access governance tools 类别存在的目的。产物是一组带有风险评级的每个身份访问发现。

4. 证明日志轨迹可以重建AI交互

通过选择最近一次Copilot交互并尝试仅从日志重建它来测试追踪。检索登录、提示事件、涉及的文件以及对AI设置的任何管理员更改，然后检查file access monitoring是否覆盖了相关的存储库。任何无法检索的内容都会直接列入发现清单，作为覆盖缺口。

在断定有任何内容缺失之前，先了解每种记录类型包含什么。Purview 的CopilotInteraction audit records 捕获交互元数据和 Copilot 用于响应请求的文件引用。但提示和响应内容存储在用户的邮箱中，需要 eDiscovery 来收集。

Next, measure your retention window against the investigation window you'd actually need. Under Microsoft's audit retention policies, Audit (Standard) retains records for 180 days, and Audit (Premium) extends that period to 1 year for Microsoft Entra ID, Exchange, OneDrive, and SharePoint activity generated by users with E5 or equivalent licensing. Anything longer than a year requires the 10-Year Audit Log Retention add-on in addition to E5.

通过测试记录是否实际跨系统连接来完成此步骤。确认团队能够将AI事件关联到身份，再关联到文件访问记录，无需手动关联，并记录链条断裂的工具缺口。产物是一份说明每个工作负载日志覆盖和保留窗口的评估报告。

5. 从允许和不允许的身份运行控制测试

在运行测试之前先定义它，因为事后写下的预期结果毫无价值。选择一个带有已知敏感标签的文件，一个应该访问它的身份，以及一个应该被拒绝的身份，然后写下你对每个的预期结果。

从两个身份发出相同的检索提示，并比较两个响应。允许的身份应返回内容，受限的身份应拒绝或返回空结果。检查两次尝试的审计日志，因为无记录的静默失败本身就是一个发现。

对同一测试文件中的DLP进行相同的逐表面处理。在执行之前，以模拟模式运行策略，并应用适合租户的DLP策略最佳实践。在聊天、Word和电子邮件摘要中重复每个案例，因为在一个地方有效的策略在另一个地方可能表现不同。

记录每个案例的范围、预期结果、实际结果和补救措施，然后签署工作文件并附上截图和日志导出。该工件是一个签署的测试日志，每个失败案例都有负责人和复测日期。

6. 编写报告，使发现转化为补救措施

像其他 IT risk assessment 交付物一样构建报告，涵盖范围、方法、发现、风险评级和补救措施。按重要性排序发现，让读者先看到最严重的漏洞。

对于每个观察，包含审阅者在签署前查找的五个要素。IIA的报告撰写工具包建议提供一个关键性评级和涵盖状况、标准、原因和影响的事实陈述，以及一个管理行动计划，列明商定的行动、负责人员和截止日期。

在分发报告之前设置下一次审计日期，趁范围还新鲜。按计划间隔安排，并为新的AI功能、权限变更、策略修订和日志变更添加变更触发器。该工件就是这份报告，日历上已标注了复测日期。

如何验证 Microsoft 365 Copilot 的访问控制

Microsoft Copilot 获得了自己的通行证，因为其保护栏位于通用方法无法指向的命名管理员界面中，并且其中一个控制正在被淘汰。微软的部署指导将推出顺序划分为发现、分类、审计、保护、监控和治理，每个动词对应一个带有记录结果的测试。

1. 首先阅读Purview数据风险评估

打开 Microsoft Purview Data Security Posture Management (DSPM)，进入 Discover，然后选择 Data risk assessments，运行自定义操作前请先阅读默认评估。该评估每周针对使用量排名前100的 SharePoint 站点执行，首次结果大约在新租户中出现需4天左右。

将输出视为仍需扩展的候选名单，因为使用情况和敏感度排名方向不同。将评估标记的所有内容纳入步骤3的按身份映射，并将未排名的网站纳入范围内。

2. 获取SharePoint数据访问治理报告

生成 Data Access Governance 报告，处理风险共享链接、权限状态和 Everyone Except External Users (EEEU) 暴露。持有受监管数据的网站上的每个 EEEU 授权都是一个发现，匿名共享链接是撤销最快的。

在信任这些报告提供的覆盖范围之前，请检查您的许可级别。仅E5提供活动报告，限制为10,000个站点，数据保留28天。快照报告和修复操作需要SharePoint Advanced Management，该管理包含Copilot许可、Plan 1附加组件或Microsoft 365 E7。

3. 用受支持的控件替换受限的 SharePoint 搜索

检查租户是否仍依赖 Restricted SharePoint Search（RSS）来限制 Copilot，并在发现时记录迁移结果。微软已通过 Microsoft 365 消息中心宣布将于 2026 年 7 月 31 日起阻止新的 RSS 启用，并于 2027 年 1 月 31 日完全停用该功能。

趁还有时间，规划替换方案，因为现有的RSS配置不会自动迁移到Restricted Content Discovery。清点当前受RSS保护的网站，并将每个网站映射到权限修复或Restricted Content Discovery条目。

4. 在每个Copilot界面测试标签和DLP

首先验证测试文件上的敏感度标签，然后验证Purview DLP 配置在 Microsoft 365 Copilot 和 Copilot Chat 中。分别在 Copilot Chat、Word 和邮件摘要中运行相同的案例，并分别记录每个界面。

将结果与策略操作实际执行的内容进行对比。DLP操作阻止Copilot处理敏感内容，但不会影响用户对文件的访问，因此仍然打开文档的用户即为通过测试。对于每种情况，记录身份、文件、预期结果、实际结果、适用的标签或DLP规则以及时间戳。

5. 导出证据并安排复查

导出测试窗口内Copilot活动的Purview审计记录，并设置审计日志保留期限，以匹配团队实际需要的调查期。安排Microsoft Entra access reviews，针对控制Teams和站点访问的组成员资格，然后为每个未通过的测试分配负责人，并预订复测日期。

根据单一具体标准而非审查设置清单来评估Copilot验证。当团队能够指出文件名，证明Copilot不会在受限身份下进行摘要，解释是哪项权限、标签或DLP规则阻止了它，并提供证明测试发生的Purview记录时，即视为通过。

AI治理审计的证据和准备清单

AI数据访问审计基于审计员可以检查的证据。四个类别占据了大部分权重：

• 库存证据： 包含所有者和环境的AI系统和工具列表，以及每个系统可访问的数据源文档
• 政策和控制证据： 含变更日志的使用政策、角色定义以及用于AI治理的responsible、accountable、consulted和informed（RACI）矩阵，以及每个AI用例的风险评估
• Identity、访问和监控证据： 按Identity的访问报告、AI活动日志，以及DLP触发、Conditional Access决策和访问审查结果等控制事件记录
• 审查和监督证据： 记录AI治理决策的会议记录或工单，先前评估后的补救审计轨迹，以及跟踪治理绩效的指标

如果错过四项中的任何一项，那就是审计员首先发现的漏洞。下面的准备问题从另一个角度测试相同内容，每一个未回答的问题都是需要负责人、补救计划和复测日期的缺口。

Netwrix如何弥合AI治理审计差距

上述四个步骤基于本地工具短暂保留或分散在各门户的数据，涵盖有效权限、AI活动记录、提示级别的执行和变更历史。

Netwrix将这些归类为AI governance，作为混合Microsoft环境的命名平台功能，每项工作由不同产品承担。

报告Copilot在部署前后的可达范围

Netwrix 1Secure 报告了Copilot在租户启用之前可以访问的敏感数据，回答了在部署仍可逆时的准备情况问题。上线后，它列出每次交互的用户、时间戳和引用资源，并标记暴露敏感数据的Copilot响应。

覆盖范围包括SharePoint Online、Windows文件服务器、Active Directory、Microsoft Entra ID和Exchange Online，因此日志跟踪步骤4所需内容均来自一个控制台。

计算每个Identity背后的有效权限

Netwrix Access Analyzer 解决嵌套的AD组成员身份和损坏的SharePoint继承，计算每个身份实际可以访问的内容，揭示每个站点报告中被平铺的开放访问和过期权限。这将步骤3中的四次映射转化为可交给审计员的报告。

该 Microsoft 365 Copilot readiness 评估在部署前进行相同的分析，因此过度授权的内容会在任何用户收到提示之前得到修复。

在端点阻止AI提示中的敏感数据

Netwrix Endpoint Protector 检查端点上的提示内容，并在敏感数据到达 ChatGPT、Microsoft Copilot、Google Gemini、Claude 或 DeepSeek 之前阻止它。每个被阻止的事件都与其背后的身份相关联，这使得书面的禁止数据规则成为步骤5可以测试的内容。

保留原生日志窗口之外的变更证据

Netwrix Auditor记录每个 AD 和 Entra ID 配置及目录更改的前后值，形成可搜索的轨迹。它将这些值保存在一个长期存档中，默认保存120个月，远远超过 Purview 的180天标准窗口期。

两家受监管的客户展示了在审查过程中保留的痕迹价值。 First National Bank 和Trust of Beloit通过Netwrix Auditor在17个地点的300名用户中保持持续的OCC合规，取代了曾经需要一整周的手动检查表工作，仅需一小时准备。 Flagler Bank 以一人IT部门识别并减轻整个网络的IT风险，关闭调查仅需10分钟，而手动日志搜索曾延长至数小时。

Netwrix报告AI数据访问并在端点阻止。Microsoft自身的执行层仍通过敏感度标签、Purview DLP和条件访问决定身份在Microsoft 365中的权限。审计验证这些控制，模型行为由数据科学和模型风险团队负责。

请求演示，以映射Copilot可访问的身份，监控其在部署后的表现，并保留审查员所需的变更证据。