AI 审计追踪：你需要记录什么以及为什么监管机构会要求查看

审计追踪不是要记录一切。它的目的是能够在事后回答具体问题：做了什么决策、由什么系统做出、基于什么输入、在什么时间、有什么人工监督、以及接下来发生了什么。

欧盟、美国和英国的监管机构正在趋向于提出类似的问题。他们可能使用不同的法律措辞，但核心要求是相同的：如果你的 AI 做出了重大决策，你应该能够完整地重建它。

大多数企业 AI 部署今天还无法做到这一点。以下是你需要什么，以及每个监管框架的要求。

法规实际上怎么说

EU AI Act

EU AI Act 有三个条款直接涉及日志记录要求：

**第13条（透明度）**要求高风险 AI 系统足够透明，使部署者能够适当地解释和使用输出。系统必须提供可解释的输出——不仅仅是决策，还有决策的基础。

**第17条（质量管理体系）**要求高风险 AI 系统的提供者实施质量管理体系，包括记录保存程序、数据治理和上市后监控。质量管理体系本身必须被记录并可审计。

**附件IV（技术文档）**规定了必须记录的内容：系统的总体描述、包括训练方法和训练数据在内的设计和开发的详细描述、监控和评估措施以及风险管理措施。此文档必须维护并保持最新。

第30条是最具体的日志记录要求：高风险 AI 系统的提供者和部署者必须保留 AI 系统自动生成的日志，保留期限应与预期目的相适应，最少10年。日志必须足以支持对决策的事后调查。

十年是一个很长的保留期。大多数工程团队对日志保留的概念是以周或月为单位。对于 EU AI Act 下归类为高风险的 AI 系统，义务是十年。

HIPAA 技术保障措施 (45 CFR §164.312)

HIPAA 的技术保障要求适用于任何创建、接收、维护或传输电子受保护健康信息（ePHI）的系统。如果你的 AI 系统涉及患者数据，这些规定就适用：

访问控制：唯一用户标识、自动注销、加密
审计控制：记录和检查包含 ePHI 的信息系统活动的硬件、软件和程序机制
完整性控制：验证 ePHI 未被更改或销毁的机制
传输安全：传输中 ePHI 的加密

审计控制要求是这里的相关要求。HIPAA 没有确切规定要记录什么，但 HHS 指南明确指出日志应捕获谁访问了什么数据、何时访问以及出于什么目的。保留期限：自创建或最后生效日期起6年。

SR 11-7（美联储/OCC 模型风险管理）

美联储 SR 11-7 关于模型风险管理的指南要求银行使用的模型具有以下文档：

模型目的和预期用途
理论和逻辑描述
数据输入和假设
模型局限性
验证程序
持续性能监控

对于 AI/ML 模型，监管机构特别强调了记录模型输入、输出和性能指标的重要性，以实现持续监控和故障调查。关键原则是独立验证者必须能够重现模型输出——这需要完整记录推理时的输入和模型版本。

AI 审计追踪的8个最低要素

这八个要素涵盖了任何合规级 AI 审计追踪必须捕获的最低内容。缺少任何一个都会产生监管机构会发现的缺口。

1. 带完整性哈希的输入数据

记录呈现给模型的输入——如果原始输入太大，则记录其表示。至关重要的是，要包含输入数据的加密哈希（SHA-256 是标准）。这使你可以稍后验证记录的输入与实际处理的内容一致。没有完整性哈希，记录的输入记录可能会被质疑。

对于包含 ePHI 的输入，记录数据记录的引用而不是数据本身——但确保引用是明确的，并且哈希覆盖了引用的内容。

2. 模型版本和配置

这是最常缺失的要素。记录处理请求的确切模型版本：不是"GPT-4"，而是具体的版本、检查点或模型 ID。包括推理配置：temperature、top-p、最大 token 数、系统提示词哈希。

如果你无法在历史推理时指定确切的模型版本，你就无法重建该系统当时产生的行为。这对任何监管审查来说都是一个关键缺口。

3. 带置信度或概率的输出

记录完整的模型输出。对于分类任务，记录置信度分数或概率分布，而不仅仅是最高预测。"已批准「的二元分类输出远不如」已批准（0.73置信度）"有用——后者告诉你这是一个确定的还是边界的决策。

对于生成式输出，记录完整文本。存储成本很低。在监管调查期间无法提供驱动下游行动的确切输出则代价高昂。

4. UTC 时间戳

记录 UTC 时间戳，而不是本地时间。监管调查经常跨越时区边界。毫秒精度的 UTC 消除了歧义。确保你的日志基础设施有 NTP 同步——时间戳完整性很重要。

记录请求接收时间和响应返回时间。延迟数据可能与性能调查相关。

5. 执行用户或系统身份

谁或什么触发了这次推理？对于人工发起的请求，记录经过身份验证的用户 ID，对于自动管道请求，记录系统/服务标识符。这支持访问模式分析，并识别哪些用户或系统参与了正在审查的决策。

不要记录共享凭证。你的 AI 管道中的每个参与者都应该有唯一的、可审计的身份。

6. 适用 HITL 的人工审查决策

如果你的系统包含人在回路审查——在 AI 输出驱动重大行动之前由人工审查——明确记录审查结果。谁审查的、什么时候、做了什么决定、以及是否推翻了 AI 建议。

人工审查通常是监管机构对高风险决策最感兴趣的部分。"AI 将其标记为高风险「如果没有」持证专业人员审查并同意/不同意"的记录是不完整的。

7. 采取的下游行动

记录 AI 输出导致了什么结果。孤立的分类没有意义——你的系统用它做了什么？记录下游行动：索赔已批准、申请标记待审查、文档路由到X部门、向Y发送警报。

这在 AI 决策和现实世界后果之间形成了闭环。它让你能够回答"系统在3月5日对患者12345做了什么？"

8. 任何覆盖或升级

当人工覆盖 AI 决策，或触发异常处理流程时，明确将其记录为覆盖事件。如果你的工作流捕获了原因，则包含原因。这些数据对监管目的和模型改进都很有价值——系统性覆盖表明模型在哪些方面校准不准确。

血缘缺口

大多数考虑过这个问题的团队已经覆盖了输入和输出的日志记录。缺口在中间：转换管道。

你的 AI 输出不仅仅是原始用户输入的函数。它是检索结果、预处理步骤、上下文组装、提示词模板和系统指令的函数——这些都可能没有被记录。

EU AI Act 第30条要求记录整个管道，而不仅仅是输入和输出。如果你的 AI 系统涉及检索增强生成，检索到的文档是决定输出的输入的一部分。如果预处理对输入进行了标准化或转换，那个转换就是血缘的一部分。

映射原始输入和模型调用之间的每个转换步骤，并记录每一个。这比记录边界更难——但这是监管机构在调查特定决策时所寻找的。

监管机构在审计中实际看什么

进行 AI 审计的监管机构不会读每一条日志条目。他们会抽样，并提出具体问题。

模式是：一个特定决策正在接受审查（一个被拒绝的索赔、一个标记的交易、一个高风险分类）。监管机构想要完整地重建该决策。他们会要求那个特定推理的记录——输入、模型版本、输出、人工审查、下游行动。然后他们会检查完整性：所有8个要素是否都存在？时间戳是否一致？模型版本是否有记录？是否有人工监督的证据？

如果被审查的特定决策缺少任何要素，那就是一个发现。如果审计追踪无法确认特定日期运行的是什么模型版本，那就是一个发现。如果政策要求人工审查但日志中没有记录，那就是一个发现。

实际意义是：你的审计追踪基础设施需要使单个记录查找快速，并且需要确保写入时的完整性——而不是作为定期批量检查。

存储和保留

保留要求因框架而异：

HIPAA：自创建或最后生效日期起6年
EU AI Act（高风险系统）：最少10年
SR 11-7：没有明确规定的期限，但银行检查周期表明实践中为5-7年
FDA SaMD：与产品生命周期一致，通常为2年或产品寿命中的较长者

按照你的监管环境中适用的最长期限进行设计。分层存储（近期记录热存储、较旧记录冷存储）在保持可访问性的同时管理成本。确保冷存储可以进行特定记录检索——需要完整恢复才能查询的批量归档存储不符合审计就绪要求。

Ertas Data Suite：内置审计日志

对于 AI 数据准备管道——生成训练数据、微调数据集和标注语料库的上游工作——Ertas Data Suite 记录每个转换步骤，包括时间戳、操作员 ID 和应用操作的完整记录。每个摄入、清理、标注、增强和导出操作都是不可变审计链的一部分。

该平台直接导出符合 EU AI Act 第30条的技术文档。对于数据准备管道本身受审计约束的受监管企业，这意味着血缘是默认捕获的——而不是事后重建的。

与 Ertas 预约发现会议 →

审计追踪不是在你构建完系统后再添加的东西。它们需要从一开始就设计进去。将全面日志改造到生产 AI 系统中的成本始终高于第一次就正确构建——而在监管调查中遗漏的成本则更高。