先区分已经开始的报告义务与后续要求

截至 2026 年 10 月 7 日，欧盟《网络韧性法案》（CRA）已进入分阶段适用过程。欧盟委员会说明指出：第 14 条报告义务自 2026 年 9 月 11 日适用，全面适用日期为 2027 年 12 月 11 日。不要把后一个日期理解为此前无需处理报告问题。

本篇讨论进入欧盟市场的相关数字产品，不把欧盟规则直接套用于英国或美国，也不判断某一设备是否属于适用范围或例外。产品功能、销售方式、经营主体和法律角色，应由团队与合资格专业人士核对。

“制造商”不一定就是组装工厂

委员会的同一说明将以自己名称或商标销售、委托他人设计或制造产品的主体也纳入制造商定义。对品牌团队而言，把生产外包，并不能仅凭这个事实认定所有法定义务都转给工厂。

建议先画一张角色图：销售主体、品牌主体、固件维护方、应用开发方、云服务方、组装方分别是谁。每项写法人名称和联系人，不只写“香港团队”或“深圳供应链”。这是沟通底稿，不是替代法律判断的责任划分协议。

把报告时钟与修复时钟分开

委员会的报告说明区分正在被积极利用的漏洞，以及影响产品安全的严重事件：知悉后的早期预警期限为 24 小时，后续通知为 72 小时；前者的最终报告期限与纠正措施可用后的 14 天相关，后者则为 72 小时通知后一个月内。具体触发条件与例外仍须按规则判断，不是每个普通软件缺陷都自动触发同一义务。

ENISA 的单一报告平台说明提供正式入口和操作指南。团队应提前确认有权提交的人及其替补，不要等事件发生才寻找账号。修复尚未完成，不能自行当作延后判断报告义务的理由。

以下是编辑提出的内部交接表，不是监管机构的指定表格：

工作环节 需要留下的记录 交接前要回答的问题
接收线索 接收时间、原始信息、接收人 是否已通知指定安全负责人？
确认产品范围 型号、固件和应用版本、组件版本 哪些已交付产品可能受影响？
专业判断 已知事实、未知事项、判断负责人 是否触发报告，依据是什么？
正式提交 授权人、提交记录、后续节点 谁确认提交完成并保存回执？
修复和沟通 修复版本、测试证据、用户通知 如何确认客户实际获得了修复？

用一次不涉及真实漏洞的演练检查交接

设想一个虚构的联网语音设备：品牌团队在海外，香港协调项目，深圳合作方维护固件。演练只使用模拟信息，不攻击设备、不上传真实客户数据，也不向监管平台提交虚假报告。

主持人给出“某批次可能受影响”的模拟消息，观察团队能否找出该批次对应的软件版本、通知到正确人员、区分事实与猜测，并建立待办清单。如果得到的回答只是“工程师正在看”，还不足以说明对外报告和内部修复分别由谁推进。

演练后的改进应具体：补一个版本索引、增加值班替补，或让合同明确供应商提供影响范围和补丁资料的方式。不要用一场演练宣布产品已经合规。

把安全维护放进供应链讨论

采购阶段除了价格、交期和量产良率，还可以讨论交付后的维护配合：组件通知发给谁，停止维护前如何告知，修复测试由谁执行，哪些资料能在授权范围内共享。没有答案时，把它列为未解决事项，而不是填上“供应商负责”就结束。

AI 可以帮助整理已获授权的版本清单、对照通知和生成待核实问题；法定角色、报告触发和提交决定仍须由负责任的人员判断。日志中的个人信息、密钥和商业秘密，不应为了省事进入未经批准的工具。

与瞻行资本讨论的是协作问题，而非合规保证

瞻行资本连接香港、大湾区与海外创业团队的价值，可以从把问题交给正确的人开始：产品团队说明市场和功能，供应链伙伴提供工程证据，专业顾问核对法律边界。相关资源对接与工作范围需逐项商定，不代表瞻行资本是检测认证机构或欧盟授权代表。

欢迎用一份不涉密的产品说明联系 Justin Zhan / 詹培勋，注明销售市场、研发分工和目前卡住的交接事项。也可继续阅读大湾区 AI 硬件专题（英文）及机构介绍。

本文为编辑研究与协作建议，不是法律意见或产品合规结论；规则和平台流程可能更新，个案需专业核查。