洞见#法规#安全#工程

发布修复已成为法定义务,也是产能难题——PostHog 在 AI Tinkerers 维也纳给我们的启示

《网络韧性法案》、NIS2 和新版《产品责任指令》让安全更新成为义务。在 AI Tinkerers 维也纳活动上,我们看到开源项目 PostHog 如何把生产信号转化为经人工审核的修复。

作用于同一产品的两股力量:2024–2028 年欧盟法规与有限的团队产能——由信号、AI 起草的修复和人工审核连接起来

每个软件团队都熟悉这种张力。一方面是法规:在欧盟,发布漏洞和缺陷修复已不再只是良好实践,而是法定义务——有期限、有报告义务,也涉及责任。另一方面是产能:同一批工程师还需要改进产品、交付新功能、保持竞争力。两者都不可或缺,也都等不起。

为什么修复不再是可选项:2024–2028 年欧盟时间表

日期 法规 对软件修复的意义
2024 年 10 月 17 日 NIS2(转化期限) 关键和重要实体的风险管理、事件处理与供应链安全。
2024 年 12 月 10 日 **《网络韧性法案》(CRA)**生效 所有含数字元素产品的过渡期开始。
2024 年 12 月 13 日 **《通用产品安全法规》(GPSR)**适用 通用产品安全,包括纠正措施和召回。
2025 年 1 月 17 日 DORA 适用 金融行业及其 ICT 服务商的 ICT 风险与事件管理。
2025 年 8 月 1 日 **《无线电设备指令》**网络安全要求 联网无线设备必须满足安全要求(EN 18031)。
2026 年 9 月 11 日 CRA 报告义务 被积极利用的漏洞和严重事件:24 小时内预警、72 小时内通报,并提交最终报告——也适用于已上市产品。
2026 年 10 月 1 日 奥地利 NISG 2026 生效 NIS2 的国内实施;相关实体须登记。
2026 年 12 月 9 日 《产品责任指令》(EU)2024/2853 软件属于产品。制造商控制范围内缺失的安全更新可能使产品被认定为有缺陷。
2027 年 12 月 11 日 CRA 全面适用 安全设计、漏洞处理、在支持期内免费提供安全更新(原则上至少五年)、CE 标志。
2027 年 12 月 2 日 / 2028 年 8 月 2 日 **《人工智能法案》**高风险义务 因 2026 年“人工智能综合修订案”推迟;涉及高风险 AI 系统的稳健性、准确性和网络安全。

对架构师而言,信息很明确:快速发现、修复、记录并发布修正的能力,正在成为一项合规能力——而不仅仅是工程美德。

产能缺口

法规增加了工作量,却没有增加人手。分诊、根因分析、补丁、测试、发布说明、证据、报告——每一个修复背后都是一套流程。如果这套流程靠人工完成,就会直接与维持企业竞争力的产品工作争夺资源。答案不可能是“更加努力”,而必须是更好地设计工作本身。

AI Tinkerers 维也纳,2026 年 10 月 1 日:PostHog

我是 GitHub 和开源的忠实拥趸——但并非每个代码仓库都值得写一篇博客。2026 年 10 月 1 日在维也纳举行的 AI Tinkerers 聚会上展示的项目却值得:PostHog。

PostHog 是一个开源产品平台(核心采用 MIT 许可,另有完全免费的 FOSS 版本),将产品分析、会话回放、错误追踪、功能开关、实验、问卷、日志和大模型可观测性整合在一个系统中。自 2026 年 7 月起,它新增了**“自动驾驶”模式**:AI 智能体(“侦察兵”)持续监测真实的产品信号——异常、愤怒点击、失败的查询——在收件箱中聚类并排序,研究原因,并在沙箱中起草拉取请求(Pull Request)。由开发人员审核修改并决定是否合并。

真正的改进

  • **从信号到修复,一条链路完成。**错误、受影响的会话、对用户的影响和代码修改集中在同一上下文中,而不是分散在五个工具里。
  • **排好优先级、去除重复的问题。**相似错误被聚类并排序,团队优先处理对用户影响最大的问题。
  • **修复草案取代空白工单。**工程师从经过研究的方案和现成的拉取请求出发,而不是从零开始。
  • **人始终掌控。**未经人工审核和合并,任何修改都不会进入生产环境。
  • **开放、可审查。**代码托管在 GitHub 上;团队可以自行托管,或选择欧盟云以满足数据驻留要求。

真正的收益

  • 缩短修复时间——直接支持 CRA 的报告期限并降低责任风险。
  • 把产能还给产品开发——分诊和初步修复不再占用资深工程师。
  • 可追溯性成为副产品——信号、分析、修改和审批记录在同一处:是审核和事件报告的有力证据。
  • 更好的产品质量——由真实用户信号而非猜测来决定先修复什么。
  • 更低的锁定风险——开源意味着方法始终可复现、可审查。

与任何处理用户数据的工具一样,规则不变:必要时征得同意、数据最小化、欧盟托管或自行托管,并明确规定智能体可以修改什么。

架构师的结论:要授权——但绝不盲从

对我们来说,结果很简单:我们节省了大量时间。但更深层的启示在于:人力资源是每家软件公司最脆弱的资源——有限、难以替代,而且最容易被重复性工作耗尽。因此,架构师应当授权——交给工具、交给自动化、交给设计良好的循环。但不能仅仅因为工具能更快地执行,就去遵循毫无意义的流程。把糟糕的流程自动化,只会更快地产生糟糕的结果。

先审视流程,再实现自动化,并让决策权留在人手中。

想了解您的修复与发布流程如何在不拖垮团队的前提下满足新的欧盟要求吗?欢迎联系我们。

本文仅提供有关欧盟法规的一般性信息,不构成法律建议。人工智能治理相关问题,请参阅我们的姊妹品牌 KI-Beratung.st。

资料来源

资料核查日期:2026 年 10 月 3 日。

← 全部洞见与新闻

致电免费初步沟通