2026-09-04 04:39:37 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文章指出AI安全运营中若仅以告警数量下降为KPI，可能导致系统通过降低标准掩盖风险而非真正解决问题。核心发现是AI上线初期告警增加实为暴露了过往因证据不足而被忽略的不确定性。建议建立包含不确定率的新指标，推动系统从单纯降噪转向消除不确定性，确保告警减少源于风险被彻底查明而非视而不见。 综合评分： 92 文章分类： 安全运营,AI安全,安全建设,漏洞预警,安全工具

当“告警越来越少”成了 AI 安全运营的 KPI，我们可能正在奖励错误的事

原创

messfree messfree

MessFreeSecurity

2026年9月2日 20:48 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

AI 进入安全运营中心之后，很多人都有一种很自然的期待：既然 AI 能自动研判、自动降噪、自动处置，那告警总该越来越少了吧？

于是很多项目里，最直观的效果指标就变成了：告警压降了多少？

从 100 万条压到 10 万条，不错。从 10 万条压到 1 万条，很好。如果最后只剩几百条需要人工处理，大屏曲线一路往下走，看起来 AI 确实改变了安全运营。

但真正把 AI 用到告警研判里之后，我们可能会撞见一个完全相反的现象：AI 上线初期，告警不但没少，反而多了。

更麻烦的是，如果我们不去解释这个现象，而是继续用“告警必须越来越少”来考核 AI，那最后很可能把一个本该提升安全能力的系统，硬生生优化成一个特别擅长“让问题消失”的系统。

这两件事，有本质区别。

AI 上线，告警为什么反而可能变多？

传统 SOC 每天会收到海量告警，来自 WAF、IDS、NDR、EDR、防火墙、蜜罐、主机安全、数据库审计……真正摆到人面前的，可能是几万、几十万条。

这些告警有一个共同特点：证据往往是不完整的。

比如某台安全设备报了一条：某个外部 IP 对业务系统 A 发起了 CVE-XXXX 漏洞利用攻击。

接下来真正要回答的问题其实很多：目标系统到底有没有这个漏洞？攻击载荷完整吗？请求真的到达业务系统了吗？目标执行了攻击者的命令吗？有没有异常进程、异常文件、异常账号？有没有后续外联？业务到底受没受影响？

但现实是，单台设备回答不了这些。它只能说：“我看到了一次疑似攻击。”

那这条告警怎么办？

过去很多告警不是“判完了”，而是“没继续判”

理想情况下，安全人员应该继续查：查资产版本、查漏洞、查原始流量、查 EDR、查应用日志、查进程、查文件、查账号、查业务操作……最后形成完整证据链：攻击成功，或者攻击失败。

但现实中的 SOC 不可能对每天海量告警都这么查。时间久了，人自然会形成经验。比如：这个设备经常误报；这个类型以前基本没事；没看到后续行为，业务也没反馈异常，先关掉。

这完全可以理解。人的精力有限，必须靠经验做过滤。

但问题在于：“没发现攻击成功的证据”，慢慢就被当成了“攻击没有成功”。

从证据逻辑上看，这俩完全不是一回事。前者是“我不知道”，后者是“我知道它没成功”。

过去很多 SOC 的告警压降，其实是这两种情况混在一起的。一部分告警确实被证明是误报或无风险；另一部分只是因为证据不足、人力不够、历史经验判断风险低，就被关掉了。

所以过去告警少，不一定代表所有告警都研判清楚了。有些问题只是没人继续追问而已。

AI 上线后，“不知道”被暴露出来了

AI 最大的变化之一，就是它会按照相对完整的逻辑重新审视这些告警。

还是刚才那条漏洞攻击。AI 会去判断：攻击行为存在吗？存在。目标有没有对应漏洞？资产版本数据缺失，无法确认。攻击载荷满足利用条件吗？基本满足。命令执行成功了吗？缺少主机侧证据，无法确认。有没有异常进程？没接对应的 EDR 数据。业务受影响了吗？证据不足，无法判断。

最后 AI 给出的结论可能不是“攻击成功”，也不是“误报”，而是：存在较高可信度的攻击行为，但当前证据不足以判断是否成功、目标是否受影响，建议进一步核查。

这个结论技术上完全正确。

但从运营角度看，新问题出现了：过去被人凭经验直接关掉的告警，现在大量进入了“待确认”。

于是 AI 上线后，管理者可能看到很奇怪的现象：以前一天 100 个事件，现在 AI 上线后变成 500 个、1000 个了。

不是 AI 制造了更多告警，是它暴露了过去被藏起来的不确定性

假设每天有 10 万条原始设备告警，经过聚合、去重、基础规则过滤，还剩 3000 个值得分析的安全信号。

过去人工处理：3000 个信号，根据设备、规则和历史经验快速过滤，留下 100 个事件。大屏显示 3000 到 100，压降率很漂亮。

AI 上线后重新分析这 3000 个信号：2200 个有足够证据证明无实际风险；300 个有明确证据表明存在安全风险；500 个攻击行为存在，但证据不足，无法确认是否成功。

过去大屏上的数字是 100，现在可能变成 300 加 500，也就是 800。

从数字上看，AI 上线后告警增加了 700%。但 AI 并没有制造这 700 个问题。它们过去就存在，只是过去的体系没能力、没数据、没精力继续查下去。

AI 第一次把这些“不知道”系统性地摆到了台面上。

最危险的是：这时候开始要求“把数字做下去”

管理者的逻辑很好理解：我投钱建 AI SOC，不就是为了降本增效吗？以前一天 100 个事件，现在 800 个，那 AI 的价值在哪儿？

于是很自然的 KPI 就出现了：告警数量必须持续下降。比如今年压降 50%，明年压降 80%，AI 自动闭环率 95%，人工研判量下降 90%。

从管理角度看，这些指标都合理。但如果把“最终告警数量”当成最重要甚至唯一的 KPI，问题就来了。

因为一个数字一旦变成强 KPI，整个系统就会开始围绕这个数字优化，而不是围绕真正的安全目标优化。

让告警数量下降，其实很容易

如果目标只是“明年让告警下降 80%”，技术上并不难。

可以增加白名单，扩大过滤范围，提高告警阈值，降低规则灵敏度，把更多设备加入可信源，把历史上经常关闭的告警直接自动关闭，把低置信度事件全部归为低风险，甚至把“证据不足，无法确认攻击成功”直接映射成“暂未发现风险，自动关闭”。

这样做完，大屏一定越来越好看。告警压降率 96.8%，AI 自动研判率 98.5%，自动闭环率 97.3%，人工告警量同比下降 85%，所有指标全绿。

但有一个关键问题：这些被关掉的告警，究竟是“有证据证明没风险”，还是仅仅“没证据证明有风险”？

如果回答不了这个问题，所谓“智能降噪”可能已经悄悄变成了“智能隐藏风险”。

AI 最危险的不是误判，而是规模化复制错误经验

人工时代，一个分析人员凭经验关掉 100 条告警，影响范围有限。AI 时代完全不同。

假设我们把过去几年的人工处置结果直接喂给 AI 学习，AI 很可能学到：某类告警过去 98% 都被人工关闭。于是形成规则：同类告警自动关闭。自动化率瞬间提高。

但过去的“关闭”到底代表什么？可能代表“已经查清楚，确认没风险”，也可能代表“没时间查”“查不到证据”“设备误报太多，习惯性关掉”“业务没反馈异常，所以关掉”“历史上一直这么处理”。

如果不区分这些原因，AI 学到的就不是安全专家的研判能力，而是过去人员在资源不足情况下形成的妥协。

过去一个人一天只能错误地忽略几十个问题。AI 上线后，可以每秒钟自动忽略几千个。

所以 AI SOC 一个容易被忽略的风险是：AI 不仅能规模化复制正确经验，也能规模化复制过去的错误。

真正该下降的，不是“风险发现量”，而是“无效人工工作量”

回到最开始的问题：AI SOC 上线后，告警到底该不该越来越少？

答案是：最终需要人工处理的无效告警，当然应该越来越少。但这和“系统发现的风险信号必须越来越少”完全是两码事。

一个成熟的 AI SOC 应该形成这样的漏斗：原始设备告警，到 AI 聚合去重，到安全事件关联，到 AI 自动研判，到明确无风险、证据不足、明确有风险，再到 AI 自动补充证据，最后自动排除、自动确认、少量人工核查。

真正应该持续下降的，是最后一层：需要人参与的数量。而不是最前面的：系统发现了多少异常。

换句话说：我们应该奖励 AI“解决问题”，而不是奖励 AI“少发现问题”。

AI SOC 应该增加一个过去很少关注的指标：不确定率

传统 SOC 大屏喜欢展示告警数量、高危告警数量、压降率、处置率、闭环率、平均处置时间。

AI SOC 时代，我觉得还应该加一个很重要的指标：研判不确定率。

比如本月 AI 研判 10 万起安全信号：72% 有证据自动排除，18% 有证据确认风险，10% 证据不足，无法判断。

下个月：自动排除 75%，确认风险 19%，不确定 6%。

这个 10% 到 6%，可能比“告警下降 50%”更值得关注。因为它意味着过去有 1 万件事情 SOC 不知道发生了什么，现在只有 6000 件。

再通过补充 EDR、资产版本、原始流量、应用日志和业务日志，6% 到 3% 再到 1%，这才是真正的安全能力提升。

AI SOC 真正该形成的是“消除不确定性”的闭环

当 AI 无法判断一个事件时，不应该简单停留在“建议人工进一步核查”。否则 AI 只是把自己的问题重新扔给人。

真正成熟的 AI SOC 应该继续追问：为什么无法判断？缺什么证据？到哪里能找到这些证据？现有系统能不能自动获取？获取之后能不能重新研判？如果还是无法判断，是否值得让业务人员介入？

整个流程应该变成：AI 发现攻击，证据不足，自动识别证据缺口，自动查询资产、EDR、NDR、WAF、流量、应用日志，补充证据，重新研判，自动排除或确认风险，只有少量真正无法判断的高风险事件进入人工核查。

这样，随着数据不断完善、知识不断沉淀、AI 能力不断提升，“不知道”的事件才会越来越少。伴随“不知道”越来越少，需要人工处理的事件自然也会下降。

这才是健康的告警下降过程。

大屏当然可以好看，但应该换一种“好看”

管理者希望看到漂亮的数据，这没错。AI SOC 投了钱，就应该证明价值。问题不在于“大屏要好看”，而在于我们选择什么数字让它好看。

与其展示“告警数量下降 90%”，不如展示：AI 自动研判率 92% 上升，明确证据闭环率 88% 上升，不确定事件占比 12% 降到 5%，人工研判量下降 63%，平均研判时间从 30 分钟降到 3 分钟，高风险事件发现率提升 35%。

这样的数字一样漂亮，甚至更能说明 AI 的真正价值。

因为它表达的是：风险没有被隐藏，但人的工作量下降了；系统发现问题的能力没有下降，但解决问题的能力提高了。

AI SOC 最终要避免的，是“为了证明 AI 有效，而让 AI 证明没有问题”

这是一个非常值得警惕的方向。

如果组织不断要求告警必须下降，自动闭环率必须达到 99%，人工研判必须减少 90%，那系统最终一定会找到完成 KPI 的方法。

而最简单的方法永远不是获取更多数据、建立更完整证据链、提高真正的自动研判能力。这些事困难、昂贵，而且需要跨系统、跨部门治理。

最简单的方法是：降低什么事情值得成为“问题”的标准。

最后我们可能得到一个非常漂亮的 AI SOC：每天百万告警，99% 自动降噪，98% 自动闭环，大屏全绿，领导看到的数字越来越好看，安全运营人员每天需要处理的事越来越少。

但真正的问题是：我们到底解决了 99% 的问题，还是只是决定不再看那 99% 的问题？

这两者之间的区别，才是 AI SOC 建设真正需要守住的底线。

别让 AI 帮我们重新学会“视而不见”

AI 上线后告警阶段性增加，并不可怕。它可能只是把过去依赖人工经验掩盖掉的不确定性重新暴露了出来。

真正该做的，不是立刻要求 AI“把这些告警重新降下去”，而是问：为什么这些事件无法判断？缺什么证据？能不能自动获取？哪些数据源需要治理？哪些研判经验可以标准化？下次遇到同类问题，AI 能不能不再回答“不知道”？

然后让整个 SOC 形成一个持续进化的过程：发现不确定，找到证据缺口，补齐安全数据，AI 自动验证，形成明确结论，沉淀研判知识，同类事件自动闭环，不确定率下降，人工工作量下降。

最终，告警确实会越来越少。但这个“少”，不是因为我们改了统计口径，不是加了白名单，也不是把“不知道”统一判成“没问题”。

而是因为我们真的把越来越多的问题搞清楚了。

所以评价 AI SOC，也许不该只问一句“AI 上线后，告警下降了多少”，还应该再问两句：“过去那些告警为什么消失了？”“我们是有证据地解决了它们，还是仅仅不再看它们？”

这可能才是“智能降噪”和“智能隐藏风险”之间真正的分界线。

AI SOC 的目标，不该只是让告警越来越少，而应该是让“不知道”越来越少，让真正需要人处理的问题越来越少。

如果最后只是让大屏上的数字越来越小，那我们可能不是在奖励 AI 变得更聪明，而是在奖励它更擅长替我们视而不见。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：MessFreeSecurity messfree messfree《当“告警越来越少”成了 AI 安全运营的 KPI，我们可能正在奖励错误的事》