海外安全合规指引

面向向欧盟市场交付含数字元素产品与 AI 系统的企业，梳理 EU AI Act 与 EU CRA 两部核心法规的合规义务与落地路径。

一、法规概览

欧盟针对"含数字元素产品"与"人工智能系统"构建了两部横向法规，共同构成市场准入的网络安全与安全底线：

法规	全称	核心目标
EU AI Act	Regulation (EU) 2024/1689	按风险分级管理 AI 系统的投放与使用
EU CRA	Regulation (EU) 2024/2847（网络弹性法案）	含数字元素产品全生命周期的网络安全底线

两部法规在风险评估、漏洞管理、技术文档、日志审计等工程主题上高度重叠。建议统一建设一套合规体系，同时满足两部法规要求，避免双轨运维。

适用范围

• CRA：任何含数字元素的产品（软件/硬件/远程数据处理方案），且其预期用途包含直接或间接的数据连接（连到设备或网络）。典型在范围：智能手机、工业 IoT、路由器、操作系统、移动 App、云连接家电等。
• AI Act：在欧盟市场投放或使用的 AI 系统。按风险分为四级：不可接受（禁止）、高风险（严格义务）、有限风险（透明度义务）、最小风险（无额外义务）。

CRA 对部分已有专门法规的产品设有豁免：医疗器械（EU 2017/745）、体外诊断器械（EU 2017/746）、机动车（EU 2019/2144）、民用航空（EU 2018/1139）、海事设备（2014/90/EU）。

二、关键时间线

AI Act 阶段性生效节点

日期	生效内容
2025-02-02	禁止类 AI 做法（不可接受风险）开始受管控
2025-08-02	通用 AI 模型（含系统性风险模型）义务开始受管控
2026-08-02	生成式/交互式 AI 系统透明度义务开始受管控
2026-08-02 / 2027-08-02	高风险 AI 系统按附件类别分批适用

CRA 两个硬性截止日

日期	生效内容	性质
2026-09-11	Article 14 报告义务	事件触发型——出现"已被积极利用的漏洞"或"严重安全事件"时必须上报
2027-12-11	Article 13 全面适用	产品安全要求 + 漏洞处理流程要求——从这一天起投放欧盟市场的产品必须合规

注意：Article 14 报告义务追溯适用——包括 2026-09-11 之前已上市的老产品。只要产品仍在欧盟市场且发生触发事件，就必须上报。

三、产品分级与符合性评估

CRA 产品分级

CRA 根据产品核心功能（非营销名称）将产品分为三级，等级决定符合性评估路径：

等级	评估路径	说明
Default（默认）	Module A 自评	未被归类为 important/critical 的产品，制造商自评并声明符合
Important Class I	Module A（应用协调标准时）/ Module B+C / H	列于 Annex III
Important Class II	始终需第三方评估（Module B+C / H）	列于 Annex III
Critical	强制第三方评估 + 可能要求欧盟网络安全证书	列于 Annex IV

符合性评估程序

• Module A — 内部控制：制造商自评并声明符合。适用于所有 default 类产品，以及正确应用协调标准时的 important Class I 产品。
• Module B+C — EU-type Examination：公告机构检查产品设计与开发，出具 EU-type 证书。强制适用于无协调标准的 important Class I、所有 Class II、所有 critical。
• Module H — 全质量保证：制造商建立完整质量管理体系并由公告机构评估。适合在欧盟市场投放多种产品类型的厂商。

产品族归并：具备足够相似性的产品可归并为产品族（product family），共用一个合规项目。从产品上下文、资产、安全机制、架构、操作系统五个维度评估相似性。这是降低合规成本的最大单点杠杆。

四、合规义务体系

以下八个工程主题覆盖了 AI Act 与 CRA 的全部核心义务。每个主题下列出两部法规的要求与落地建议。

1. 风险评估

法规要求：

• AI Act：高风险 AI 必须建立风险管理系统，覆盖"危害识别→风险评估→缓解措施→验证→残余风险"全链路闭环，且必须持续迭代。
• CRA：风险评估贯穿产品全生命周期，结论必须写入技术文档，直接影响合规路径（default 可自评 vs important/critical 需第三方）。

落地方法：

• 方法论：ISO/IEC 27005（流程框架）+ STRIDE（威胁覆盖）
• 六阶段流程：建立产品上下文 → 定义风险接受准则 → 资产与威胁识别 → 估计与评价风险 → 处置风险 → 建立监控与复评计划
• AI 产品需在 STRIDE 基础上补充四类 AI 攻击面：数据中毒、对抗样本/模型规避、模型/参数泄露、系统漏洞改变使用方式

核心口诀：圈边界 → 列资产 → STRIDE 找威胁 → 评等级 → 补措施 → 留文档 → 常更新

2. 漏洞管理

法规要求：

• AI Act：高风险 AI 必须建立漏洞识别和处理流程，关注 AI 特有漏洞（模型参数泄露、对抗输入绕过、训练数据投毒）。
• CRA：漏洞处理与披露全闭环——接收→评估→修复→发布→复盘→留档。对应标准 prEN 40000-1-3 定义了 6 个阶段、59 项强制要求。

落地要点：

• 建立漏洞披露政策（CVD），公开发布于公司官网
• 部署 security.txt 文件（RFC 9116 标准），提供专用安全邮箱（7×24 监控）
• 每漏洞一条工单，流转记录自动留存证据
• 在漏洞分类中增加 AI 类型：ai/poisoning、ai/evasion、ai/confidentiality
• 制造商需产出 7 份文档：漏洞处理策略、协调披露策略、SBOM、硬件组件清单、安全测试与评审计划、漏洞评估报告、安全公告

3. 事件响应与监管报告

法规要求：

• CRA Article 14（2026-09-11 生效）：发现"已被积极利用的漏洞"或"影响产品安全的严重事件"时，必须按倒计时制上报。

报告时间线：

阶段	时限	内容
早期预警	24 小时内	事件性质、初步影响（允许信息不完整）
详细通报	72 小时内	严重性与影响评估、IOCs、初步缓解措施
最终报告（漏洞）	修复后 14 天内	完整漏洞描述、根因、修复措施、版本范围
最终报告（严重事件）	首次通报后 1 个月内	事件描述、影响、根因、纠正措施

落地要点：

• 成立 PSIRT（产品安全事件响应团队），建立 7×24 值班与明确升级链
• 文档化"积极利用"和"严重事件"的判定标准
• 准备 24h/72h/最终报告三套模板
• 至少半年一次桌面演练
• 通过 ENISA 单一报告平台（SRP）一次提交，同时送达协调 CSIRT 与 ENISA
• 最高处罚：€15,000,000 或全球年营业额 2.5%，以高者为准

4. 技术文档

法规要求：

• AI Act（Article 11 + Annex IV）：高风险 AI 必须编制技术文档，含目标用途、系统设计、数据与模型信息、测试与验证结果、安全性与鲁棒性说明、限制条件。
• CRA：技术文档含系统边界与安全上下文、风险评估摘要、测试与验证结果、限制条件，且必须作为 CE 符合性评估的一部分。

落地要点：

• 两部法规的核心章节高度重叠，可写一份文档 + 一个 AI 附录
• 每个声明必须有验证记录链接（测试报告、审计日志、风险记录）
• 文档版本必须与产品版本对应，随版本迭代更新
• 不适用的 essential requirement 必须在技术文档中给出书面 justification

5. 安全开发与更新

法规要求：

• AI Act：高风险 AI 必须建立安全更新与发布链路（签名、回滚、灰度、可追溯），网络安全覆盖设计/开发/部署/运行全阶段。
• CRA：Security by Design + 全生命周期安全维护，明确安全上下文、攻击面最小化、默认安全、弹性机制。

落地要点：

• 安全门禁作为 SDLC 固定节点：设计评审 → 代码扫描 → 依赖审计 → 渗透测试
• 更新发布闭环：签名 → 灰度 → 覆盖验证 → 回滚机制
• 漏洞修复必须有对应版本号，能追溯受影响范围
• 默认安全配置文档化，变更需审批记录

6. 供应链安全

法规要求：

• AI Act：端到端供应链与组件可见性（SBOM），第三方模型/组件需提供透明度信息。
• CRA：关键组件/上游供应商的合同约束（24 小时通知义务），开源依赖持续监控，SBOM 覆盖多形态交付。

落地要点：

• 产出完整 SBOM（SPDX/CycloneDX 格式），覆盖开源/第三方/自研，标注版本与许可证
• SCA 持续监控：CVE/KEV 自动匹配 → 修复 SLA → 发布追踪
• 关键组件供应商必须书面承诺 24h 漏洞通知义务
• 多形态覆盖：固件/APP/云/容器/后端，所有交付形态都纳入 SBOM

7. 日志与审计

法规要求：

• AI Act：记录与日志支撑可追溯性、事件调查、合规审计。高风险 AI 必须记录设计决策、风险评估过程、模型训练与验证记录，人类监督的决策点需日志可复核。
• CRA：支撑调查、审计、证明"你做过且做对了"。关键安全事件日志、操作日志、版本/配置变更记录。

落地要点：

• 最小日志集：安全事件 + 操作变更 + 风险决策，三类缺一不可
• 关联 ID 串联全链路，一条请求/事件贯穿所有系统
• 脱敏分级：审计日志不含 PII，运维日志受控访问
• 明确区分热存储（调查用）和冷归档（合规留存）

8. AI 特有安全与评测

法规要求（AI Act 专门要求）：

• AI 特有攻击面：数据/训练集攻击、推理阶段攻击、机密性攻击、系统漏洞利用
• 稳健性与网络安全：对抗鲁棒性测试、数据质量与投毒检测、模型与数据访问控制
• 人类监督：关键决策点的可介入/可终止/可复核机制
• 数据治理与偏见控制：训练/验证/测试数据的质量、代表性、偏差评估

落地要点：

• 威胁建模扩展：STRIDE + 4 类 AI 攻击面
• 测试矩阵：功能测试 + 安全测试 + 对抗鲁棒性测试 + 偏差测试
• 识别所有需要人类决策的环节，设计介入/终止/复核流程
• 训练数据的来源、预处理步骤、质量评估记录必须可追溯

五、合规路线图

阶段一：基线评估（立即启动）

• 给产品分级：default / important Class I / Class II / critical
• 判定 AI Act 风险层级：不可接受 / 高风险 / 有限风险 / 最小风险
• 确定角色定位：Provider / Deployer / Importer / Distributor
• 尽可能归并产品族，确定需要跑多少个合规项目
• 用 ISO/IEC 27005 + STRIDE 启动风险评估
• 跑一次差距分析，在产品安全、漏洞处理、用户文档三大支柱上建立基线

阶段二：为 2026-09-11 做准备

• 确定应通报的 CSIRT（基于在欧盟的主要设立点）
• 掌握产品销售的成员国清单
• 建立漏洞披露通道（security.txt + 安全邮箱 + CVD 政策）
• 成立 PSIRT，建立升级链与判定标准
• 准备 24h/72h/最终报告三套模板
• 完成至少一次桌面演练
• SRP 上线后完成注册

阶段三：为 2027-12-11 做准备

• 起草《漏洞处理策略》，对齐 prEN 40000-1-3
• 发布 CVD 策略
• 构建/更新 SBOM 与硬件组件清单
• 建立《安全测试与评审计划》并留存执行证据
• 实施风险评估识别出的产品安全控制
• 准备 Annex II 用户文档包（14 项文档义务）
• 完成符合性评估，加贴 CE 标志

六、标准现状

CRA 定义的是 essential requirements——技术中高层次要求。具体可测的控制项由协调标准翻译。当前标准化授权下共有 41 项标准交付物，全部处于草案阶段，尚无任何一项正式通过。

横向标准（适用所有产品）：

• prEN 40000-1-2：风险评估与网络安全生命周期
• prEN 40000-1-3：漏洞处理要求（6 阶段、59 项强制要求）
• prEN 40000-1-4：产品安全要求（约 2/3 内容来源于 EN 18031 系列）

垂直标准（适用 important/critical 产品）：按产品类别制定，涵盖浏览器、密码管理器、VPN、操作系统、防火墙、SIEM 等类别。部分类别同时制定非工业产品标准（EN 304 6XX）与工业产品标准（基于 IEC 62443 的 EN 50770 系列）。

策略建议：现阶段先把能力与证据体系搭起来，标准定稿后做 gap 适配。选型时优先选"可审计、可配置、可持续演进"的体系，而非一次性模板。今天没有任何制造商可以合法地宣称已实现 CRA 合规。

七、常见误区

1. "漏洞处理义务从 2026 年 9 月开始"——错误。2026-09-11 生效的是 Article 14 报告义务（事件触发型），Article 13 的漏洞处理流程要求 2027-12-11 才全面适用。
2. "只有新产品才需要报告"——错误。Article 14 追溯适用，老产品同样在内。
3. "每个 CVE 都要上报"——错误。只有"已被积极利用的漏洞"或"严重事件"才触发，但必须有判定能力。
4. "建了 CVD 政策就等于合规 Article 14"——错误。CVD 是接收漏洞的上游通道，Article 14 是向监管的上报义务，两件事需分开管理。
5. "等标准定稿再动手"——错误。标准全部草案阶段，等到定稿再动手会在 2027 年底撞上被压缩的、昂贵的冲刺。

免责声明：本文基于 EU 2024/1689 与 EU 2024/2847 公开文本及权威解读材料整理，不构成法律意见。具体合规路径请结合企业实际产品与法律顾问意见制定。