“评审前要补 Article 12 日志”：哪些证据归提供者，哪些归部署者？
在界定 AI 日志证据需求前，先分开欧盟 AI 法案 Article 12 的自动记录设计与部署者对日志的控制和保存。
重点监测信号
- 具名 AI 系统即将进入符合性、采购或部署评审，而团队只说缺少 Article 12 日志
- 提供者侧事件设计与部署者侧保存被交给同一家供应商，却没有确认谁实际控制每种记录
- 需求有评审日期，但高风险分类、预期用途和必须记录的具体事件仍未确定
一项 Article 12 日志需求有两个不同的证据负责人：提供者要说明高风险 AI 系统怎样自动记录事件，以及这些事件为何能为预期用途提供可追溯性；部署者要说明哪些自动生成日志在自己控制下，以及实际怎样保存。只说“我们要 Article 12 日志”，还没有界定工作。
AI 治理或可观测性服务商的商务拓展负责人，在获授权的模型提供者、企业 AI 和受监管行业 Telegram 群里，首先就要分清这两列。消息里出现具名系统、评审节点，以及记录、导出、完整性、访问或保存的具体缺口，才构成值得查看的商业 Signal。晚一天看到，符合性或采购团队可能已经选定架构，却没有让日志负责人参加。
定义：Article 12 是高风险系统的设计要求
条例（EU）2024/1689，即欧盟《人工智能法案》，并没有把 Article 12 施加给每个被称为 AI 的软件。Article 12 位于高风险 AI 系统要求中。系统是否属于高风险，要结合第 6 条、相关附件和预期用途判断。
Article 12 要求高风险 AI 系统在技术上允许系统整个生命周期内自动记录事件，也就是生成日志。日志能力需要记录与识别风险情形或重大修改有关的事件，协助上市后监测，并监测某些高风险系统的运行。可追溯程度应与预期用途相称。
为什么这点重要：通用基础设施日志可以对运维很有用，却不一定证明系统记录了其法律和安全场景需要的事件。反过来，Article 12 也没有要求每个内部事件永久保存。
第一位负责人：提供者设计自动记录
提供者掌握系统定义、预期用途和设计证据。它的 Article 12 记录至少要串起四层。
系统边界。 评估的是哪个已发布系统和版本？一个模型端点、组合多个组件的工作流和辅助人工决定的工具，事件边界可能不同。“我们的平台”不够具体。
事件目录。 系统会自动记下什么？版本、输入路径、输出或决定标识、人工监督介入、错误状态和重大配置变更都可能是有用条目。真正目录由预期用途决定，这些只是例子，不是通用法定最低项。
追溯目的。 每个事件能回答哪一种调查、监测或风险问题？只有很多字段、没有追溯用途，只是库存清单，不是有理由的日志设计。
完整性与访问。 说明事件怎样获得时间戳和标识，变更怎样受控，获授权人员怎样取回，以及有哪些限制。一张后台截图能证明“看得到”，却不一定证明导出完整或记录未被修改。
某些远程生物识别系统还受 Article 12(3) 的额外内容要求约束，包括使用时段、参考数据库、促成匹配的输入数据和参与核验的人员。不能把这个特殊段落机械复制到信用或招聘系统。
第二位负责人：部署者控制使用与保存
Article 19 给部署者的是另一项责任。高风险 AI 系统部署者必须保存系统自动生成、且处于自己控制之下的日志。保存期要与预期用途相称，并至少六个月；适用的欧盟法或成员国法律，特别是个人数据法律，另有规定时除外。
“控制之下”这几个字意味着顾问不能假定部署者能取得所有提供者侧事件。交接时要写明：
- 哪些日志流进入部署者环境；
- 哪些仍由提供者或其他处理者控制；
- 谁能访问和导出每种日志；
- 保存时钟从何时开始；
- 当前启用的是哪项保存设置，而不只是产品允许设置什么；
- 哪项法律或运营理由改变保存期；
- 部署者怎样把日志与一次真实使用事件对应起来。
提供者在法案其他条款下也可能有文档和记录保存责任，不能把角色分析简化成“所有人都保存六个月”。
一张双负责人证据图
本文的原创贡献是一张小图，每行只解决一个证明问题：
| 证明问题 | 提供者证据 | 部署者证据 | 仍未知 |
|---|---|---|---|
| 哪个系统在范围内 | 预期用途、版本和边界 | 已部署配置与使用场景 | 该使用是否改变分类 |
| 记录什么 | 自动事件目录与实现 | 实际收到的日志流 | 设计与可取得事件之间的缺口 |
| 为什么记录 | 追溯与监测理由 | 运营调查需要 | 每个事件是否足够 |
| 谁控制 | 访问与导出设计 | 角色、权限和处理者路径 | 合同和技术控制缺口 |
| 保存多久 | 产品能力与限制 | 生效的保存政策和证据 | 其他适用法律要求 |
这张图防止可观测性服务商接下自己无法作出的法律结论，也能产出具体范围：事件埋点、导出映射、时间戳完整性、访问控制复核或保存配置。
示例：一个周五评审，缺了两位负责人
下面是说明用的合成消息，不是客户对话：
“Risk 要周五前看到 Article 12 logs。vendor 说 logging 已开。”
“admin screen 能看到 decisions，raw events 可能在他们 cloud team。”
“Retention 还是 default，这边没人知道具体多久。”
这些片段暴露三个可能缺口：提供者证据被缩成一个开启的功能，部署者是否控制原始事件不清楚，保存期也没有核实。它们没有证明系统属于高风险、Article 12 适用、页面里的 decision 就是所需事件，也没有证明六个月是最终正确期限。
第一条商业问题不该是“每天多少 GB”，而是：谁已经按系统和预期用途作出分类？缺失证明在提供者列还是部署者列？ 如果两边都说不清系统边界，诚实的范围应从证据盘点开始。
AI literacy 记录说明的是操作系统周围的人员与能力，不是事件历史；可阅读Article 4 素养证据交接。Article 50 透明度需求解决告知和合成输出披露，也不是 Article 12 日志。价格与访问方式介绍发现工具。
TOP Prospect 可以在用户主动连接且有权访问的 Telegram 群里筛选、合并、去重和排序片段，保留原文、来源、时间、摘要和判断理由供人工查看。它不能替系统分类、读取私有日志基础设施、决定保存法律、认证符合性或联系发言者。
关键事实
- Article 12 适用于高风险 AI 系统，不是所有 AI 系统。
- 系统必须在技术上允许整个生命周期内自动记录事件。
- 日志要支持与预期用途相称的可追溯性，以及 Article 12 所述的监测和调查功能。
- 提供者证据解释系统边界、事件设计、目的、完整性与访问。
- Article 19 要求部署者对其控制下的自动生成日志按适当期限保存至少六个月，其他适用法律另有规定时除外。
- “后台看得到”和“设置已开启”本身不能证明事件完整、控制关系或保存期限。
常见问题
Article 12 适用于所有 AI 系统吗？
不适用。Article 12 是高风险 AI 系统的要求。应先依据 AI 法案的分类规则评估系统及其预期用途。
Article 12 对提供者侧系统设计要求什么？
高风险 AI 系统必须在技术上允许系统整个生命周期内自动记录事件。日志能力应支持与预期用途相称的可追溯性，并支持对规定风险和重大修改的监测与调查。
谁要把日志保存至少六个月？
Article 19 要求高风险 AI 系统部署者，对其控制之下的自动生成日志按与预期用途相称的期限保存，且至少六个月；其他适用的欧盟法或成员国法律另有规定时除外。
可观测性供应商能根据 Telegram 需求认证 Article 12 合规吗？
不能。供应商可以界定事件设计、导出、完整性或保存工作，但法律分类、角色分配、符合性证据和合规结论仍需获授权人员判断。
当高风险分类来源、提供者日志负责人、部署者日志负责人和缺失证明能写进同一条记录时，这项需求才适合进入技术范围沟通。
常见问题
Article 12 适用于所有 AI 系统吗？
不适用。Article 12 是高风险 AI 系统的要求。应先依据 AI 法案的分类规则评估系统及其预期用途。
Article 12 对提供者侧系统设计要求什么？
高风险 AI 系统必须在技术上允许系统整个生命周期内自动记录事件。日志能力应支持与预期用途相称的可追溯性，并支持对规定风险和重大修改的监测与调查。
谁要把日志保存至少六个月？
Article 19 要求高风险 AI 系统部署者，对其控制之下的自动生成日志按与预期用途相称的期限保存，且至少六个月；其他适用的欧盟法或成员国法律另有规定时除外。
可观测性供应商能根据 Telegram 需求认证 Article 12 合规吗？
不能。供应商可以界定事件设计、导出、完整性或保存工作，但法律分类、角色分配、符合性证据和合规结论仍需获授权人员判断。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
