EU AI Act 日志清单：提供者和部署者必须记录什么

EU AI Act 中最细致的文档要求，全部落在高风险 AI 系统上。其中第12条和第19条专门规定日志记录：对事件进行自动、持续的记录，使主管当局能够审计系统行为、把某个决策追溯到具体的输入和模型版本，并在事故发生后展开调查。

只要你在欧盟境内开发、部署高风险 AI 系统，或者把这类系统进口到欧盟，这些日志义务就适用于你。本清单逐条列出这些日志义务的每一项要求，说明它们在实际操作中究竟意味着什么，并指出那些最容易造成合规敞口的实施缺口。

适用对象

EU AI Act 区分了两种角色，两者各自承担义务：

提供者指开发高风险 AI 系统并将其投放欧盟市场或投入使用的组织。模型或系统是你构建的，你就是提供者。提供者承担主要的文档负担，包括第11条（技术文档）和第17条（质量管理体系），以及第12条规定的日志义务（这部分再向部署者一侧衔接到第12条和第19条）。

部署者指在专业活动过程中使用高风险 AI 系统的组织。即使模型不是你构建的，你也可能是部署者：只要你在业务运营中使用了供应商的高风险 AI 系统，你就是部署者。第26条规定了部署者义务，第26条第6款则具体规定部署者需要就自己使用该系统的情况记录哪些内容。

很多组织同时具备提供者和部署者两种身份：既构建自己的 AI 系统（提供者），也部署由别人构建的 AI 系统（部署者）。

高风险 AI 系统主要由法案附件 III 界定，涵盖以下领域使用的系统：

• 生物特征识别与分类
• 关键基础设施管理
• 教育和职业培训（录取、评估）
• 就业与劳动者管理（招聘、绩效、晋升）
• 基本私人服务和公共福利的获取（信用评分、保险、社会福利）
• 执法
• 移民、庇护与边境管控
• 司法行政与民主程序

你的系统只要落在上述任何一个领域里，几乎可以肯定属于高风险。拿不准的时候，先按高风险处理，并咨询法律顾问。

理清各条款的关系

EU AI Act 里有多项文档要求，实践中经常被混为一谈。它们各自的分工如下：

这几项条款管的是系统运行期间你记录了什么，它们与第11条的技术文档要求和第17条的质量管理要求并行适用。

适用日期

对于附件 III 所涵盖的大多数高风险 AI 系统，完整的各项要求自 2026 年 8 月起适用。附件 I 涵盖的系统（医疗器械、航空设备这类受监管产品）过渡期则更长。

如果你是在 2026 年初读到这篇文章，留给你搭建合规日志基础设施的时间已经不多。

---

日志合规清单

第12条第1款：自动事件日志

法案要求高风险 AI 系统必须能够在“系统整个运行生命周期中”自动生成事件日志。

实施要求：

[ ] AI 系统本身（或你在其外围搭建的部署基础设施）能够自动记录事件，手工流程不满足要求

[ ] 日志在系统整个运行生命周期内持续产生，而非抽样采集或仅在出错时触发

[ ] 日志安全存储，并有访问控制限定谁可以读取

[ ] 已就位防篡改机制，例如哈希链、一次写入存储或等效手段，使日志写入后无法在不被发现的情况下被改动

[ ] 日志从部署第一天起就在生产环境中开启，而非事后补上

常见缺口：完全依赖供应商所提供 API 的组织，往往默认日志这件事由供应商负责。请逐条核对你和供应商签的合同：不少供应商只提供基础的用量日志，拿不出第26条第6款要求的那种细粒度、可归属到具体部署者的输入/输出日志。这种情况下，你可能需要在自己的集成层里补上日志记录。

---

第12条第2款：可追溯性要求

日志的详细程度必须足以把某一事件追溯回具体的输入、具体的模型版本，以及具体的使用期间。

实施要求：

[ ] 每一次 AI 输出都记录了：时间戳（UTC）、模型版本或模型标识符，以及产生该输出的相关输入

[ ] 日志包含足以识别使用期间的信息，也就是某一套部署配置的启用日期和停用日期

[ ] 日志标明每一条事件对应的责任部署者（多个部署者共用同一套基础设施时，这一点尤其重要）

[ ] 对于作用于具体个人的系统（就业决策、信贷决策等）：日志必须能够识别出哪些个人在什么时间被处理过

[ ] 日志的记录粒度足以判断系统在什么时候超出了预期用途运行，或者在什么时候脱离了正常的运行条件

[ ] 日志除成功的推理之外，还覆盖错误、超时、被拒绝的输入和边界情况

常见缺口：只记录成功输出、不记录失败的系统，恰好漏掉了事故调查中最需要的那些事件。某个输入让系统静默失败（返回一个默认输出而不是报错），在日志不完整的情况下几乎无从发现。

---

第19条：留存、存储与访问

日志的存储方式必须做到三点：足够持久、对获授权的一方保持可访问，并且能够防止丢失。

实施要求：

[ ] 日志的保存期限与系统的预期用途以及适用的法规要求相匹配

第19条为提供者设定了至少六个月的下限，第26条第6款为部署者设定了同样的下限，两者都以欧盟或成员国其他法律未要求更长期限为前提。各行业的监管规则经常要求更长的期限：对于做出重大个人层面决策的系统（信贷、就业、福利），考虑到相关时效期间和监管调查的时间跨度，保留 5 到 10 年是站得住脚的。后果较轻的系统，EU AI Act 早期指引给出的下限是 6 个月。

[ ] 访问控制确保只有以下几方能读取日志：获授权的内部人员（审计、合规、法务）、国家主管当局（应要求时）以及获授权的外部审计人员

[ ] 国家主管当局提出要求时，日志能够无不当延迟地提供。这里的“要求”指监管问询，而非日常报送

[ ] 日志有防意外丢失和损毁的措施，备份流程、冗余存储和数据保留策略都要覆盖到

[ ] 对日志的访问本身也纳入审计：谁在什么时候、出于什么目的读取了日志，这些同样应当被记录

常见缺口：很多组织把日志放在沿用了运营数据策略的系统里，保留周期一到，日志就被自动清理掉了。要把 AI 决策日志单独分类，使其不受一般数据生命周期管理的短周期清理约束。

---

第26条第6款：部署者专属要求

即便底层 AI 系统由提供者供给，部署者仍要就自己的具体部署场景承担独立的日志义务。

实施要求：

[ ] 部署者维护一份覆盖自身部署情况的日志：部署的是哪一个系统、采用的是哪一种配置、用在哪一个用例上

[ ] 部署者日志包含：部署开始日期、部署结束日期（或标记为“进行中”），以及部署期间做过的任何配置变更（提示词修改、阈值调整、集成改动）

[ ] 部署者日志记录系统健康监控事件：性能告警、错误率、准确率指标的变化

[ ] 部署者保存所有已实施的人工监督措施记录。对于 HITL（人机协同）系统，这意味着每一次人工审查决策都要留下日志，所需的日志字段见 HITL 工作流设计工作表

[ ] 如果部署者相对提供者的说明修改了系统行为（换了提示词、换了阈值、换了输入预处理），这些修改要记录在案，并评估其对性能的影响

常见缺口：部署者有时把人工监督当成一项政策承诺，而不是一项留痕的控制措施。口头上说“我们有 HITL”，却拿不出每一次人工审查决策的带时间戳、可审计的记录，并不满足第26条第6款。人工审查决策本身就是必须记录的日志事件。

---

附件 IV：技术文档（提供者义务）

附件 IV 规定了提供者在把高风险 AI 系统投放市场或投入使用之前必须准备的技术文档。这属于提供者义务，与日志要求分属两件事，但从提供者处接收 AI 系统的部署者应当核实这份文档确实存在。

必备的文档要素：

[ ] AI 系统的总体说明，其中包括系统的预期用途，以及投放市场的具体版本

[ ] 开发过程说明：

• 开发中做出的各项设计选择，以及做出这些选择的理由
• 训练数据的特征：数据来源、标注方法、数据准备流程，以及数据量
• 所采用的训练流程和测试流程
• 性能指标与验证结果

[ ] 系统监控、运行与控制方面的文档：

• 系统的技术能力与技术局限
• 已知的或可预见的风险，其中包括系统被误用所引发的风险
• 准确率指标（在适用的情况下，按相关的子群体分别列出）
• 鲁棒性措施与网络安全措施

[ ] 本系统所需的人工监督措施：

• 需要哪一种人工监督（HITL、HOTL 或其他形式）
• 人工监督在技术层面和操作层面分别如何落实
• 由谁负责落实这些措施

[ ] 系统在整个生命周期内所做的各项变更，也就是版本历史

[ ] 在基本权利与反歧视这一语境下所做的风险评估

对于接收供应商系统的部署者：在部署之前向供应商索取附件 IV 文档包。拿不出这份文档的供应商，说明它在法案下的义务尚未完成，而这个缺口要由你来兜。没有它就上线，你会和供应商一起暴露在监管风险之下。

---

实施实务指引

哪些内容算作需要记录的“事件”

法案用了“事件”这个词，却没有给出穷举定义。结合监管语境，以下内容至少应当记录：

按数据类型设计日志保留策略

AI 决策日志里往往含有个人数据，模型的输入可能包括姓名、财务数据、健康信息或其他个人身份信息。这就让 EU AI Act 的日志要求与 GDPR 的数据最小化和存储限制原则之间产生了张力。

实操上的化解办法：

1. 把运营日志和决策日志分开。运营日志（性能指标、错误率、时延）可以按较短周期保留。决策日志（输入、输出、模型版本、人工审查决策）需要更长的保留期，并且必须在明确的法律依据下管理。

2. 尽可能对决策日志做假名化。日志里记录假名化的案件标识符，而不是直接的个人标识符；映射表单独存放，并配套相应的访问控制。这样既降低了日志在 GDPR 下的敏感度，又保住了可追溯性。

3. 写清楚日志保留的法律依据。按照 GDPR，处理日志中的个人数据需要有法律依据。对于受监管的用途（信贷、就业、福利），法律依据通常是履行法定义务，也就是 EU AI Act 本身。请在数据处理记录中把这一点明确写下来。

数据主权问题

这些日志本身就可能含有个人数据，从而触发 GDPR 关于数据存放地点的义务。如果你的 AI 系统处理欧盟居民的数据，那么这些处理活动的日志一般也应当存放在欧盟境内，或存放在获得充分性认定的司法辖区，除非你另有合法的跨境传输机制。

这一点对使用云端日志基础设施的组织有着直接的现实影响：请在部署之前就确认日志存储所在的区域与你对外做出的数据驻留承诺一致，而不是等监管机构问询之后才去核对。

---

从清单到落地

从零开始落实这些日志要求，需要三样东西：集成层（也就是你的应用调用 AI 系统的地方）的埋点、一套带访问控制和保留策略的日志存储系统，以及一个能把人工监督决策沉淀为结构化、可查询日志的审查流程。

Ertas Data Suite 直接从数据处理流水线生成对应 EU AI Act 第12条记录留存要求的审计日志。每一次数据转换都带时间戳和操作员 ID。日志防篡改，并可导出为结构化格式用于监管提交。对于本地部署的组织（数据不能离开办公场所的气隙隔离环境），Data Suite 的原生桌面架构让日志在本地生成、在本地存储，数据不会离开你的基础设施。

预约 Ertas 发现通话 →

摘要合规清单

在 2026 年 8 月的截止日期之前，用这份清单做一次就绪度自评：

基础设施： [ ] 生产环境中已开启自动日志记录（既不是手工记录，也不是抽样记录） [ ] 防篡改的日志存储已经就位 [ ] 已设定日志保留策略（下限为 6 个月；涉及重大后果的决策要更长） [ ] 访问控制已经落实，并且本身纳入了审计 [ ] 日志数据已有配套的备份流程和恢复流程

内容： [ ] 每一次推理都记录了：时间戳、模型版本、输入、输出 [ ] 人工监督决策按照每一次决策逐条记录 [ ] 各项配置变更已记录 [ ] 错误和边界情况已记录

治理： [ ] 已从供应商处取得附件 IV 技术文档（自研的系统则由内部产出） [ ] 日志保留所依据的数据处理法律依据已写明 [ ] 日志数据的驻留地已确认（欧盟境内，或获得充分性认定的辖区） [ ] 能够在可接受的时间范围内，向主管当局提供对日志的访问

部署者专属： [ ] 部署的起止日期以及各项配置变更均已记录 [ ] 人工审查决策已按 HITL 工作表的要求逐条记录 [ ] 与提供者使用说明之间的各项偏离均已记录在案

把这份清单全部完成的组织，在这些日志义务面前站得住脚。尚未完成的组织应当优先补上基础设施这一块：日志基础设施要搭建正确需要时间，而已经发生过的决策无法事后补记。