先说日期——因为它们变了
Regulation (EU) 2026/1744（「AI 数字综合法案」，Digital Omnibus on AI）于 2026年7月24日 在《官方公报》发布，2026年7月27日 生效。它把 AI Act 第 113(3)(c) 条替换为固定日期：
- 2027年12月2日——附件 III 系统的高风险义务（第 III 章第 1–3 节，即第 6–27 条，第 6(5) 条除外）。
- 2028年8月2日——附件 I 系统的高风险义务（嵌入已受监管产品中的 AI）。
- 已经生效：第 4 条（AI 素养，自 2026年7月27日 起放宽为「采取措施支持」）、第 5 条（禁止的做法），以及第 50 条透明度义务，自 2026年8月2日 起生效——对已投放市场的系统，AI 生成内容的机器可读标记有宽限期至 2026年12月2日（新增第 111(4) 条）。
第 9、12、13、14、15、26 条、第 50(1)–(6) 条、附件 III 和附件 IV 没有被修改。任何还在告诉你「第 12 条日志义务 2026年8月 生效」的页面都已过时。
这些对 B2B SaaS 里的生成式 AI 功能适用吗？
第 8(1) 条：「高风险 AI 系统应符合本节规定的要求。」不属于附件 III 用例（招聘、信贷、教育、基本服务、执法等）的聊天机器人、RAG 助手或编码智能体（agent），不是高风险系统，第 9–15 条和第 26 条不适用于它。今天适用的是：第 4 条、第 5 条和第 50 条。对其他系统自愿适用高风险要求的唯一依据是第 95 条（行为准则）。
如果你的功能确实属于附件 III 类别——招聘筛选、信贷决策、学生评估——且不属于第 6(3) 条的豁免情形，它将于 2027年12月2日 成为高风险系统，下表也就从参考变成了实际要求。
EU AI Act——逐条对照
| 条款 | 要求（转述） | 约束对象 | 证据包 | 理由 |
|---|---|---|---|---|
| 第 9 条 风险管理 | 一个有文档记录、持续、迭代的风险管理体系；测试须「对照事先定义的指标和概率阈值」（第 9(8) 条）。 | 提供者 | PARTIAL | 我们方法的第 2–5 步是第 9(6)–(8) 条测试环节的直接证据。证据包是某个时间点的输入；它不是第 9(1)–(2) 条要求的持续性体系。 |
| 第 10 条 数据治理 | 训练、验证和测试数据须满足质量标准；来源有记录；对非训练型系统只适用于测试数据（第 10(6) 条）。 | 提供者 | PARTIAL（范围窄） | 仅当项目的评估集就是提供者的测试数据集、且我们记录了其来源时才适用。训练数据完全不涉及。 |
| 第 11 条 + 附件 IV 技术文档 | 附件 IV 2(g)：「验证和测试程序……用于衡量准确性、稳健性的指标……测试日志以及由负责人注明日期并签名的所有测试报告。」 | 提供者 | PARTIAL | 这是整部法案中文本上最贴近的一处：一份带签名、注明日期、附测试日志的外部测试报告。它是技术文档的一个组成部分，而不是整份文档。 |
| 第 12 条 记录保存 | 系统必须「在技术上允许在其生命周期内自动记录事件（日志）」，覆盖风险情形、上市后监测以及第 26(5) 条的监测。 | 提供者（设计层面） | PARTIAL | 领域 D 证明该能力是否存在以及记录了什么。我们证据包自身的日志是评估方的证据，不是系统的第 12 条日志。 |
| 第 13 条 对部署者的透明度 | 使用说明必须说明「高风险 AI 系统经测试所对照的准确性水平（含其指标）、稳健性和网络安全……」。 | 提供者 | PARTIAL | 实测的幻觉率和稳健性结果及其局限，可作为第 13(3)(b)(ii) 条的可用内容。我们不撰写使用说明。 |
| 第 14 条 人工监督 | 第 14(4)(e) 条：监督人员能够「通过『停止』按钮或类似程序中断系统，使系统在安全状态下停机」。 | 提供者（设计层面） | PARTIAL（纳入范围时） | 领域 D 的停止路径测试实证检查中断是否能让智能体在安全状态下停机。证据包不涉及界面设计或自动化偏见。 |
| 第 15 条 准确性、稳健性、网络安全 | 「适当水平的准确性、稳健性和网络安全」；对「旨在使 AI 模型出错的输入（对抗样本或模型规避）」的抵御能力（第 15(5) 条）。 | 提供者 | PARTIAL | 幻觉率测量（第 15(1) 条）和提示注入红队测试（第 15(5) 条）是整部法案中最直接的对应。我们证明的是做过测试，而不是整个生命周期内达到了「适当水平」。 |
| 第 26(5) 条 部署者监测 | 部署者监测系统运行，若系统可能带来风险则暂停使用。 | 部署者 | PARTIAL（弱） | 日志审查表明部署者具备监测手段。但这项义务是持续性、运营性的。 |
| 第 26(6) 条 日志留存 | 部署者保存自动生成的日志，「保存期限应与预期用途相适应……至少六个月」。 | 部署者 | NONE | 带时间戳的清单能证明某份日志摘录在时间 T 时未被篡改地存在。留存是一项独立的持续义务，证据包并不执行它。 |
| 第 50 条 透明度 | 告知用户正在与 AI 交互（第 50(1) 条）；合成内容以机器可读方式标记（第 50(2) 条）；部署者对深度伪造和公共利益文本进行披露（第 50(4) 条）。 | 提供者 / 部署者 | NONE（按当前范围） | 我们的四个领域都不测试标记或披露。可以作为第 50(1) 条的截图证据加入范围。注意欧盟委员会的 B2B 豁免很窄：输出必须「纯技术性」且永不离开公司。 |
| 第 4 条 AI 素养 | 「采取措施支持」员工 AI 素养的提升；不要求保证达到某个水平（综合法案之后的措辞）。 | 提供者和部署者 | NONE | 一份评估报告不是素养措施。 |
| 第 72 条 上市后监测 | 高风险系统的提供者须记录上市后监测体系；欧盟委员会模板应于 2027年9月2日 前发布。 | 提供者 | PARTIAL | 定期重跑同一套可复现评估（通过 Retainer）可作为可用的监测数据。 |
ISO/IEC 42001:2023（AI 管理体系标准）——附件 A 控制项
一份带签名证据的独立评估是你的管理体系的审计证据，绝不是认证。它能支持的控制项如下，控制项描述为转述（标准原文需付费获取；措辞已对照一份公开的适用性声明核实）：
| 控制项 | 描述 | 支持程度 |
|---|---|---|
| A.6.2.4 验证与确认 | 定义并记录验证与确认措施及其使用标准。 | 强 |
| A.6.2.6 运行与监测 | 定义持续运行的要素，至少包括系统和性能监测。 | 部分（单一时间点；在 Retainer 下为强） |
| A.6.2.8 事件日志 | 确定在哪些生命周期阶段启用事件日志，至少在使用阶段。 | 强（领域 D） |
| A.6.2.7 技术文档 | 确定各相关方需要哪些技术文档。 | 输入 |
| A.5.2 / A.5.3 影响评估 | AI 系统影响评估的流程与文档。 | 部分——审计发现可作为其输入 |
| A.7.4 / A.7.5 数据质量与来源 | AI 系统所用数据的质量与来源。 | 窄——仅限评估集 |
| A.9.2 / A.9.4 负责任使用与预期用途 | 负责任使用的流程；记录预期用途。 | 部分——红队测试证明对可预见误用的抵御能力 |
| A.10.3 / A.10.4 供应商与客户 | 供应商的使用与组织的方针一致；对客户的义务。 | 可作为供应商尽职调查证据 |
| A.3.x、A.8.3、A.8.4 角色、外部报告、事件 | 角色与职责；外部报告；事件沟通。 | 无 |
NIST AI RMF 1.0（AI 风险管理框架）与生成式 AI 概要（Generative AI Profile，AI 600-1）
自愿性框架，也是所有人都会对照的框架。外部评估落在 MEASURE 功能里。引用的子类别：
- MEASURE 1.3——「未担任该系统一线开发人员的内部专家和/或独立评估者参与定期评估与更新。」唯一一条直接点名我们所做工作的子类别。
- MEASURE 2.1——「记录 TEVV 过程中使用的测试集、指标和工具细节。」对应我们的方法论和可复现性说明。
- MEASURE 2.3——「AI 系统性能或保证（assurance）标准经定性或定量测量，并在与部署环境相似的条件下得到验证。」
- MEASURE 2.5——验证有效性和可靠性；「记录可泛化性的局限……」。
- MEASURE 2.7——评估安全性和韧性；GenAI 概要中的行动项 MS-2.7-007：「开展 AI 红队测试，评估对……GAI 攻击（例如提示注入）的抵御能力。」
- MEASURE 2.13——「评估并记录所采用的 TEVV 指标和流程的有效性……」；MS-2.13-001 要求给出测量误差模型，并记录所用指标或人工反馈流程中的偏差。这几乎就是我们领域 C 的原文。
- GOVERN 4.3、MAP 5.1、MANAGE 4.1——仅作辅助证据。
AI 600-1 将虚构（confabulation）——「生成语气自信但错误或虚假的内容（俗称『幻觉』）」——列为生成式 AI 第二大风险，并将 AI 红队测试定义为「用于探测 AI 系统以发现缺陷和漏洞的结构化测试活动」。两者正是领域 A 和领域 B 所测量的内容。
我们会说什么，不会说什么
我们会说：独立技术评估；可复现；对照预先定义的指标进行测试的证据；在高风险规则适用时，作为你附件 IV 技术文档的输入；支持 NIST MEASURE 1.3、2.1、2.3、2.5、2.7、2.13 以及 ISO 42001 A.6.2.4、A.6.2.6、A.6.2.8、A.10.3；支持依第 95 条自愿适用第 III 章要求。
我们不会说：「符合 AI Act」；「合格评定」（第 3(20) 条——第 43 条下的正式程序）；「已认证」；法定意义上的「审计」；「NIST 认证」；「合格推定」（仅限第 40–41 条）；「满足第 12 条或第 26(6) 条」；「AI Act 要求的」——对于非高风险系统，我们四种项目类型没有一种是法规要求的。
签名和时间戳在法律上值多少
eIDAS 第 41(1) 条：电子时间戳「不得仅因其为电子形式而被否定法律效力和在法律程序中作为证据的可采性」。第 41(2) 条：合格电子时间戳「应享有其所示日期和时间准确、且与该日期时间绑定的数据完整的推定」。合格地位要求提供者是第 42 条下列入信任列表的服务提供者。
RFC 3161 是一个协议，不是法律地位。我们默认的时间戳来自公共时间戳机构，依第 41(1) 条可采，但不享有第 41(2) 条的推定。对于受欧盟监管的客户，我们可按要求获取合格时间戳。在 AI Act 本身之中，唯一的文本依据是附件 IV 2(g)——「测试日志以及由负责人注明日期并签名的所有测试报告」——一份带签名、注明日期的外部报告可作为提供者技术文档的一个组成部分满足这一点。
未经核实。ISO/IEC 42001 官方文本（需付费——控制项措辞取自一份公开的适用性声明和两份二手清单）；欧盟委员会是否已依第 11(1) 条发布面向中小企业的简化技术文档表格；CEN-CENELEC JTC 21 针对第 9–15 条的协调标准的进展；各国关于非合格时间戳在具体法院中证明力的规则。
- Regulation (EU) 2026/1744，OJ L 2026年7月24日——EUR-Lex。White & Case，「EU AI Omnibus enters into force」，2026年7月。
- Regulation (EU) 2024/1689，整合版——第 3、4、6、8、9–15、26、43、50、72、95、113 条；附件 IV——AI Act Explorer。
- 欧盟委员会，第 50 条透明度义务指南，2026年7月20日，及 FAQ。
- Regulation (EU) 910/2014（eIDAS），2024年10月18日 整合版——第 25、35、41、42、46 条。
- NIST AI 100-1，AI Risk Management Framework 1.0（2023年1月）；NIST AI 600-1，Generative AI Profile（2024年7月）；NIST AIRC Playbook，MEASURE。
- ISO/IEC 42001:2023 附件 A——控制项措辞来自一份公开的适用性声明（Darktrace）和二手控制项清单（DeepInspect、iso42001toolkit），访问日期 2026年9月12日。