生成式AI审计日志设计指南：欧盟《人工智能法》、ISO/IEC 42001 与日本《AI事业者指南》要求的“AI使用证据”及其留存方法
发布 阅读约 9 分钟
其他语言: English · 日本語 · Español · Français · Deutsch · Português
要点
- 生成式AI审计日志，是把每次AI执行作为“何时、何人、用哪个模型、作出了何种判断”的记录，以事后可核验的形式留存下来。
- 欧盟《人工智能法》推迟了高风险AI义务的适用日期，但自动记录日志并至少保存6个月的要求本身依然保留。
- 要让日志能作为证据使用，与其大量囤积提示词内容，不如做到不可改写、能识别操作者、能看出缺少哪些项目。
目录
在公司内部使用生成式AI、在产品中嵌入AI功能、把工作交给AI智能体——无论哪种用法，不久都会遇到需要说明“这个AI由谁、用于什么、如何管理”的场合。对方可能是审计师，也可能是客户的安全检查问卷。
这时仅靠口头说明或规章文件是不够的，关键在于能否用记录来证明。本文将依次梳理：为了以“可作为证据”的形式留存生成式AI审计日志，法规和标准有哪些要求、应记录哪些项目、在哪里记录，以及证据需满足的条件。
什么是生成式AI审计日志
生成式AI审计日志，是针对每一次AI执行，记录“何时、何人（哪个智能体）、用哪个模型、作出了何种判断”，并以第三方事后可以核验的形式留存下来的记录。
它与日常的操作日志或应用日志目的不同。
| 应用操作日志 | 生成式AI审计日志 | |
|---|---|---|
| 主要目的 | 故障排查、掌握使用情况 | 向审计、客户和监管机构作出说明 |
| 读者 | 本公司的工程师 | 审计师、客户、外部第三方 |
| 所需特性 | 便于检索 | 未被改写、能识别操作者 |
| 内容处理 | 为便于排查，常保留正文 | 不保留敏感正文，通常用指纹（哈希）和元数据即可 |
| 保存期限 | 按运维需要决定 | 按法规和审计期间决定 |
最大的区别在于读者是外部人员。如果无法向外部人员证明“这份日志事后未被改动”，那么无论记录得多详细，作为证据都很薄弱。
为什么现在会被问到“AI的证据”
主要有三个原因。
- 客户的安全检查：关于生成式AI的使用，询问使用范围、输入数据和日志保存情况的项目越来越多
- SOC 2 Type II 和 ISMS（ISO/IEC 27001）审查：需要证明控制措施在整个观察期内持续运行，AI的使用也被纳入说明范围
- AI智能体的普及：由AI而非人自主完成工作的场景越来越多，需要能以AI为单位追溯“是谁做的”的记录
法规与标准的记录要求速查表
以下是截至2026年10月31日、可通过一手资料确认的内容。
| 框架 | 与记录相关的内容 | 时间与状态 |
|---|---|---|
| 欧盟《人工智能法》第12条 | 高风险AI系统应具备在整个生命周期内自动记录事件（日志）的机制 | 见下方适用日期 |
| 欧盟《人工智能法》第19条(1) | 提供者应将其控制下的日志按用途保存适当期限，至少6个月 | 同上 |
| 欧盟《人工智能法》第26条(6) | 部署者（自行使用AI系统的一方）也应将其控制下的日志保存至少6个月 | 同上 |
| 欧盟《人工智能法》的适用日期 | 2026年7月的修订（数字综合方案，Digital Omnibus）推迟了高风险AI义务的适用。附录III所列高风险AI自2027年12月2日起适用，涉及附录I的高风险AI自2028年8月2日起适用 | 已在欧盟委员会的合并版本（截至2026年7月27日）中确认 |
| ISO/IEC 42001:2023 | 附录A中有一项控制措施（A.6.2.8），要求组织确定在AI系统生命周期的哪些阶段记录事件日志 | 标准原文需付费购买，此处仅列要点 |
| 日本总务省・经济产业省《AI事业者指南》 | 第1.2版将AI智能体新定义为“为实现目标而感知环境并自主行动的AI系统” | 第1.2版于2026年3月31日发布 |
| 日本《AI推进法》 | 推进AI研发与应用的日本法律，没有罚则规定 | 2025年9月1日全面施行 |
| SOC 2 | 未见AI专用的准则。会在现有的监控（CC7）和变更管理（CC8）中要求说明 | 截至2026年10月的确认结果 |
这里需要把握的是：欧盟《人工智能法》推迟的是适用日期，日志要求本身依然保留。 到开始适用时，需要已经积累了“至少6个月”的日志。因此，与其在适用日前夕才着手，不如现在就开始搭建日志机制，这才是现实的做法。
一手资料： 欧盟《人工智能法》第12条・ 第19条・ 第26条・ 第113条（适用日期）（欧盟委员会 AI Act Service Desk）／ 《AI事业者指南》（日本经济产业省）／ 《AI推进法》的施行（日本内阁府）
记录什么
如果每次AI执行都能记录以下项目，说明起来会容易得多。
| 项目 | 内容 | 用于说明的场景 |
|---|---|---|
| 何人 | 人员账户，或哪个AI智能体 | “是谁使用了这个AI” |
| 何时 | 执行时间 | 证明在整个期间内持续运行 |
| 用哪个模型 | 模型名称、提供方、版本 | 是否只使用了已批准的模型 |
| 判断 | 允许、拒绝、需确认等由本公司机制作出的判定 | 护栏（guardrail）是否在起作用 |
| 工具调用 | 智能体调用的外部工具或操作 | 智能体做了什么 |
| 用量与耗时 | token 数、处理时间、费用 | 说明使用情况与费用 |
| 关联用ID | 用于与本公司其他日志核对的标识符 | 与其他记录关联 |
| 输入与输出 | 不是正文，而是指纹（哈希）或引用 | 事后核验“当时的输入输出就是这些” |
是否应保留提示词与输出的正文
多数情况下，无需保留正文本身，用指纹（哈希）和不含内容的元数据就足够了。
正文中容易包含客户的个人信息或机密，囤积得越多，一旦泄露损失越大。只要保留了哈希，出现问题时就可以与手头的正文比对，确认“当时的输入输出就是这些”。
OWASP 关于 LLM 提示词注入防护的指南也在2026年10月4日的修订中要求：日志应保留“安全相关的元数据与判断”，并排除认证信息和不必要的敏感信息（OWASP Cheat Sheet）。
在哪里记录
记录的位置不同，能记录的内容和可信程度也不同。
| 记录位置 | 能记录的内容 | 弱点 |
|---|---|---|
| 应用或智能体的代码内部 | 判断理由、工具调用等，最为详细 | 需要修改代码。即使有遗漏也不易察觉 |
| AI API 之前（代理） | 无需修改代码，只要流量经过就能记录所有调用 | 看不到本公司的护栏拦截了什么 |
| AI提供方管理后台的日志 | 不费事 | 保存期限和项目取决于提供方，且位于本公司之外 |
代码内部和代理并非二选一，组合使用才更可靠。用代理无遗漏地捕捉“发生了调用”，判断理由则从作出判断的代码层记录。
另一个要点是：自己写、自己保管的日志，仅凭这一点很难获得外部人员的信任。 需要有能证明事后无法改写的机制，下一节将对此说明。
在审计中可作为证据的条件
要让日志能作为“证据”使用，需要满足以下5点。
- 能证明未被改写：把每条记录的指纹（哈希）与上一条记录串联起来，一旦改写中间任何一条，其后的链接都会对不上，从而检测出篡改
- 第三方能自行核验：即使不信任留下记录的公司或服务，也能在本地验证
- 满足保存期限：能覆盖欧盟《人工智能法》的“至少6个月”以及审计观察期（多为6–12个月）
- 能识别操作者：如果使用共享账户或共享密钥，就无法说明是谁使用的。应将人与智能体分开记录
- 能看出缺少哪些项目：明确列出“未记录的项目”，才能如实说明记录的范围。看不出哪些内容未被记录的日志，反而会降低可信度
AI智能体特有的议题
AI智能体会代替人自主调用工具、推进工作，因此会出现与人使用生成式AI不同的议题。
- 按智能体区分标识：分别记录哪个智能体做了什么。如果全部用一个 API 密钥运行，就无法区分
- 保留工具调用记录：只是生成了文本，还是操作了外部系统，风险截然不同
- 记录是否经过人工确认：重要操作之前是否有人确认，直接关系到责任归属的说明
- 将编码智能体也纳入范围：工程师日常使用的编码智能体，从通信上看也是AI调用。这一点容易被忽视，但应纳入记录范围
SPHIOR 能做什么
SPHIOR 的 AI 治理功能，是用于留存满足上述条件的记录的机制。
记录方式（4种）
| 方式 | 适用场景 |
|---|---|
代理（sphior-ai-governance-proxy） |
希望不改代码就开始。只需更改AI API 的连接地址，即可记录所有调用。AI提供方的 API 密钥不会发送给 SPHIOR |
| 远程 MCP | 希望让AI智能体自己记录自身的判断。通过 OAuth 2.1 连接 |
| REST API | 希望从任意语言发送 |
SDK（@sphior/evidence） |
希望在自己的代码中显式记录 |
可对接的AI与工具
| 类型 | 支持对象 | 记录方式 |
|---|---|---|
| AI提供方（API） | OpenAI、Azure OpenAI、Anthropic、OpenAI 兼容 API（Mistral、Groq、OpenRouter 等） | 代理 |
| 编码智能体 | Codex CLI、Claude Code、Cursor、Windsurf、Cline | 只需将连接地址指向代理 |
| 支持 MCP 的智能体与编辑器 | Claude Code、Cursor、Codex、Windsurf、Cline、Zed 等 | MCP |
| 本公司的应用与智能体 | Node.js（SDK）、其他语言（REST API） | SDK / REST API |
如果连接的 API 属于已知提供方，代理会记录其名称；其他情况（自托管模型、经由公司内部网关等）则原样记录连接目标的主机名。发送到了哪里，不会被随意推测填充。设置方法汇总在文档中。
记录的处理方式
- 不发送内容：默认不发送提示词与输出的正文，只记录指纹（哈希）和元数据
- 以可检测篡改的形式留存：将每条记录规范化后哈希，与上一条记录串联，并批量在外部固定时间
- 第三方可验证：使用公开的验证工具，无需信任 SPHIOR 也能在本地核验
- 判定仍由本公司机制作出：允许或拒绝的判定由本公司的护栏作出，SPHIOR 记录其结果
- 明确列出未记录的项目：例如代理在未设置单价时不记录费用（实际单价会因折扣或合同而变化，因此不作推测）。另外，代理看不到本公司护栏的判定，因此前提是判定需从代码层记录
可向审计师展示的内容
- 执行清单（可按智能体、模型、判定、期间筛选）
- 按智能体 × 模型统计的数量，以及判定（允许、拒绝等）的分布
- 每条记录的验证信息
- 指定期间的验证包（单次导出最多1,000条；数量较多时请分段导出）
价格
| 套餐 | 月费 | 每月记录数 |
|---|---|---|
| 免费 | $0 | 最多显示1万条（记录会持续到每月10万条） |
| Light | $99 | 10万条 |
| Standard | $199 | 100万条 |
| Unlimited | $499 | 无限制 |
我们没有采用按条数计费。如果按量计费，就会变成“记录得越少越便宜”，这与无遗漏地留存记录的目的相矛盾。付费套餐超出上限也不会停止记录，免费套餐也不会擅自转为付费。详情请参阅价格。
常见问题
日志保存6个月就够了吗
欧盟《人工智能法》第19条和第26条规定的是“至少6个月”。根据用途可能要求更长的期限，而在 SOC 2 Type II 等审计中，需要能覆盖观察期（多为6–12个月）。如果其他法律法规另有规定，也需一并遵守。
不保留提示词正文，出了问题岂不是无法调查
只要保留了指纹（哈希），就可以与手头留存的正文或提供方的日志比对，确认当时的输入输出是否一致。正文囤积得越多，泄露时的损失越大，因此是否保留正文，应权衡调查需要与泄露风险后再作决定，这才是现实的做法。
能否替代 ISO/IEC 42001 认证
不能。认证需经认证机构审核后取得。审计日志只是在该审核以及对内对外说明中使用的材料之一。
用自建的日志不行吗
并非不行。但在向外部人员展示时，需要能说明“事后未被改写”。如果通过哈希链或在外部固定时间等方式使之可被证明，说明起来会简短得多。
总结
- 生成式AI审计日志是用于向外部人员说明的记录。比起详细程度，更重要的是未被改写、能识别操作者
- 欧盟《人工智能法》推迟了适用日期，但自动记录日志和至少保存6个月的要求依然保留
- 基本做法是不保留正文，用指纹和元数据记录，并明确列出未记录的项目
- 组合使用代理与代码层，并将AI智能体和编码智能体也纳入记录范围