AI 治理合规:2026 年审计方如今要求什么

如果您最近经历过 SOC 2、ISO 27001 或供应商安全审查,可能已经注意到问卷中出现了一个新板块:您的组织如何治理其对 AI 的使用?

这不是一时的潮流。Gartner 预计,2026 年大约每四份合规审计中就有一份会包含 AI 治理方面的问询。原因很直接——监管机构和各类框架已经意识到,AI 系统如今日常性地接触敏感数据,而使用这些系统的组织也日益需要为这种访问负责。本文将实际地阐述审查方在寻找什么,以及如何用证据而非临场应对来做好准备。

AI 治理为何被纳入审计范围

三股力量推动 AI 治理从“提一提就好”变成了“需要证明”。

第一是监管因素。欧盟《人工智能法案》的高风险义务将在 2026 年至 2027 年间分阶段生效；科罗拉多州《人工智能法案》将于 2026 年生效；NAIC 示范通告已在美国约二十多个州获得采纳。每一项法规都以其自身的方式,要求组织记录如何评估和控制自动化系统。

第二是责任归属的转移。法院已开始将部署 AI 的公司视为对其行为负责——例如美国的 *Mobley 诉 Workday* 一案中,法院允许原告依据代理理论(agency theory)提起的诉讼请求继续进行,并随后有条件地批准了一项全国性集体诉讼(collective action)的认证。当部署方需要承担责任时,审计方就会要求提供治理证明。我们在关于 AI 责任与企业责任的概述文章中详细解析了这一法律层面的转变。

第三则单纯是事件数据。行业调查显示,大多数组织——在近期 CSA / Token Security 的研究中约为 65%——在过去一年中经历过 AI 代理安全事件,而*影子 AI*(未经 IT 批准而采用的工具)会显著推高违规成本。审计方追踪的是风险所在,而风险已经转移了方向。

审计方实际要求提供什么

在各种框架中,AI 治理相关的问题往往集中在五个方面。这些都不是什么新奇的概念;它们正是审计方早已应用于访问和变更管理的同一套控制理念,如今指向了 AI。

1. 清单:您知道 AI 能触及您的哪些数据吗?

第一个问题最基础,也最能说明问题:列出能够访问公司数据的 AI 代理、服务账户和第三方 AI 应用,并说明每一项能触及的范围。许多组织做不到这一点。清单不完整本身就是一项审计发现,因为之后的每一项控制都依赖于它。这也是影子 AI 浮出水面的地方——员工通过普通的 OAuth 授权连接、却从未经过审查的那些工具。

2. 访问治理:是谁批准的,权限级别是什么?

审查方希望看到 AI 访问遵循最小权限原则,且授权受到审查——而不是某个营销工具因为有人在十八个月前点击了“允许”,就悄悄持有对整个 Drive 的完整读取权限。他们会询问访问是如何申请的、由谁批准,以及多久重新审查一次。

3. 监控与检测:您能否察觉到滥用行为?

仅仅一次性谨慎地授予访问权限是不够的。审计方会询问您是否能够检测到异常行为——外部共享的突然激增、休眠代理的重新激活、向未知应用授予的 OAuth 权限。检测正是将静态政策转变为鲜活控制机制的关键。

4. 审计日志:您能否还原发生的事情?

这正是许多项目的薄弱环节。各类框架期望有一份不可篡改、带时间戳的访问决策与变更记录,并可导出供审查使用(通常导出到 SIEM)。日志是连接“我们有政策”与“我们能证明政策确实在运行”之间的纽带。没有日志,即便是运行良好的项目,看起来也和无人管理的项目没有区别。

5. 记录在案的响应:发现问题时您做了什么?

最后,审查方会寻找长期尽职的证据——即您察觉到风险并采取了行动。一份记录完整的事件时间线,其价值远胜于一份看似完美无瑕的快照,因为它证明了这套项目确实在运作,而不仅仅停留在纸面上。

将 AI 治理对应到您已经在报告的各类框架

令人欣慰的是,AI 治理并不需要一套全新的控制体系。它可以清晰地对应到您可能已经在维护的控制项上:

• SOC 2 —— 访问控制(CC6)与监控(CC7)标准直接适用于 AI 代理和服务账户。
• ISO 27001 —— 附录 A 中关于访问管理、日志记录和供应商关系的控制项自然延伸至 AI 工具。
• GDPR —— 问责制以及证明个人数据处理合法且受到治理的能力。
• NIST 人工智能风险管理框架 —— 一套用于*治理、映射、衡量*和*管理* AI 风险的结构化方法,审计方越来越多地参考它。

实际意义在于:如果您能够针对这些现有控制项提供 AI 专属的证据,那么您在 AI 治理审查方面已经完成了大部分工作。您不是在搭建一个独立的项目,而是在扩展您已经在报告的那一套体系。

如何在不临时抱佛脚的情况下做好审计准备

一次顺利的审查与一次充满压力的审查之间的区别,在于审计方提出问题时证据是否已经存在。这正是 8200.dev 为使用 Google Workspace 的组织所要弥补的差距。

通过只读方式连接后,它会盘点每一个能够访问您数据的 AI 代理和 OAuth 授权,按风险为每一项打分,揭示您此前不知道的影子 AI,让您能够强制执行治理规则——而对审计而言至关重要的是——生成一份对应 SOC 2、ISO 27001 和 GDPR 控制项的证据包,并附带可导出的审计日志和记录在案的风险时间线。它对照公认的框架进行映射,并生成审查方所要求的文档;但它不会认证您符合任何标准,也不保证审计结果。它所消除的,是那种临时抱佛脚的慌乱。

一个合理的准备方式是,将审计方的五个问题当作一份清单,确认自己对每一项都能拿出实物证据来回答,而不是仅凭口头保证。如果任何一项的答案是“我们得去查一查”,那正是应该着手的起点——而清单几乎总是正确的第一份实物证据,因为其他一切都建立在“首先知道 AI 能触及哪些数据”这一基础之上。同样值得一提的是,应该在正式审计窗口开启之前很久就进行这项演练,那时您仍有时间去修复清单所揭示出的问题,而不是在截止日期压力下去解释它。审计方能察觉出一个早已准备就绪的项目与一个在审计前一周临时拼凑起来的项目之间的差异,进行自身供应商审查的企业客户同样能察觉这种差异。

您可以免费生成您的首份 AI 治理证据,查看完整功能列表,或阅读我们 AI 责任说明页面上更广泛的背景介绍。

*本文仅供一般性参考,不构成法律或审计建议。具体要求因框架、审计方和司法管辖区而异。请就您的具体义务咨询您的合规与法律顾问。*