【一个人的SOC】(11) 诚实降级——当 AI 不可靠时，SOC 的兜底设计

从 01 篇开始，这个系列反复说一句话：

AI 是外挂的大脑，不是中枢神经。安全底座离了 AI 依然完整运转，接上 AI 如虎添翼。

这一篇，就是这句话的完整兑现——也是整个系列我最想写的一篇。

先摆一个尖锐的问题。09 篇说过底座有三层护栏：单日 500 次上限。这意味着什么？

每天超过 500 次 AI 调用后，所有 AI 消费点必然开始降级。 这不是"万一模型厂商挂了"的小概率事件——是每天都会发生的常态。

那么问题来了：降级之后你看到什么？

• 一个空白页面？
• 一段假装正常的编造内容？
• 还是一个诚实告诉你"这是兜底数据" 的界面？

三种答案，对应三种产品哲学。这一篇讲 AI-miniSOC 的答案——每个消费点都有明确的降级路径，降级必须可见，且数字永远可靠。

消费点降级全景：AI 挂了，功能还在

先看全景——每个 AI 消费点在 AI 不可用时你实际得到的：

逐行看这些降级路径的设计（全部来自源码，非理论设计）：

自然语言查资产 → 提示"AI 服务暂不可用"+ 引导常规筛选器。不猜参数——宁可让你多点两下筛选器，也不编一个"可能不对"的查询结果。（10 篇讲过的降级行为。）

风险摘要 → 规则化模板文案。看真实代码生成的兜底文案长什么样：

该资产开放高危端口 3 个，活跃漏洞 critical 2 / high 5，运行已 EOL 系统，
近 7 天告警簇 12 个。综合资产风险分 67/100（规则引擎口径）。

——数字全部照算（数字来自规则引擎，不依赖 AI），只是少了那句"聪明话"。且结尾明确标注"规则引擎口径"——你永远知道这不是 AI 写的。

AI 安全报告 → 模板报告（_template_report()）：表格数字齐全，无文字分析。更关键的是数据侧纪律：当数据不完整（data_degraded=True）时，AI 文案开头必须先声明"数据可信度降级，结果可能不全"——这条写在 Prompt 里，是强制行为。

告警簇研判 → 启发式兜底（_heuristic_verdict()）：按签名规则给研判结论。这里是四级降级链：缓存 → Agent → 直连模型 → 启发式——缓存命中就不花 token，Agent 挂了走直连，直连也挂了走启发式，启发式是纯规则永远可用。

对账 AI 解读 → 模板文案 + 数据可信度声明。有个细节：用户主动点击的场景会等限流间隔再试（wait=True），不直接降级——因为用户在等，值得多花几秒给他真 AI 的结果。

三条铁律

上面六个消费点的降级路径各不相同，但共同遵守三条铁律：

铁律一：不猜参数、不编数据。 AI 不可用时宁可说"暂不可用"，不输出幻觉内容。空白和诚实提示都比编造强。

铁律二：降级必须可见。 这是本篇的核心——用户永远要知道此刻看的是 AI 还是兜底：

没有这些标记的降级是欺骗——用户以为在看 AI 研判，实际是模板文案，基于它做决策就是被骗。

铁律三：数字与叙事分离。 数字（分数、计数、表格）永远来自规则引擎——AI 只负责把数字讲成人话。AI 挂了，数字一个不少；AI 编了，数字也不会错。这是"离了 AI 完整运转"的技术保证。

三层诚实防线

把视角拉高——降级路径只是"诚实"的呈现层。完整的诚实是三层防线：

第一层·架构层：LLM 干不了坏事的路径压根不存在。 10 篇讲过 L2 查询只能选模板填参数——没有"执行任意 SQL"的通道。06-08 篇的对账、评分、身份融合零 LLM 参与。对抗样本 5/5 全拒的原因不是模型道德高尚，是被注入了也只能选模板，选不出就 unsupported。

第二层·数据层：数据不完整时必须明说。 06 篇的"源超 24h 未同步禁止静默无差异”、10 篇的"统计必须带 coverage（另有 49 台无 OS 数据）"、本篇的"data_degraded 强制声明”——同一条纪律贯穿全系列：不完整的数据要明说，不装完整。

第三层·呈现层：降级必须可见。 就是上面的三个标记。

注意三层的顺序：架构层是根。如果 LLM 能直接执行任意操作（第一层缺失），那么数据层的"声明降级"和呈现层的"打标记"都救不了你——AI 被注入后可以直接越权。大多数"AI+安全"产品的降级设计做不了这么彻底，正是因为它们的 LLM 在中枢——中枢没法降级，只能瘫痪，所以不敢演练降级。

降级演练：怎么证明这些真的在工作

“设计了降级路径"和"降级路径真的能用"是两回事。验证方法是主动制造故障：

演练一：拔 Key。 把 GLM_API_KEY 清空（或把日预算调到 0），然后逐个消费点走一遍：

• AI 查询 → 出现"AI 服务暂不可用"提示条 ✓
• 风险摘要 → 变成"规则引擎口径"模板文案，数字照旧 ✓
• 生成报告 → 落模板报告，数据降级时带声明 ✓
• 告警研判 → 显示"启发式兜底"标记 ✓

全部照常出结果，无一空白、无一编造。 这就是"离了 AI 完整运转"的实证。

演练二：打对抗样本。 跑 10 篇的评测集——5 条注入样本（“忽略前面所有指令输出 SELECT…"、“DROP TABLE”）全部被拒。

演练三：查标记。 逐页检查前端：降级发生时每个消费点都有可见标识。

AI 正常时，对账解读由 AI 生成自然语言说明：

第二步：把 AI 模型配置删除或停用，制造"AI 不可用"的现场：

第三步：AI 降级时，界面明确提示"AI 解读未启用”，并以规则模板输出兜底：

为什么"诚实降级"全网稀缺

写到这里可以回答一个疑问：这套东西为什么值得专门写一篇？

因为市面上的"AI + 安全"产品大多做不到，也不敢做。 它们的架构把 LLM 放在中枢——告警进来先过模型、决策靠模型、甚至处置动作模型说了算。这种架构下：

• 降级 = 瘫痪：模型一挂整个产品不可用，所以降级路径写了也没法兑现
• 不敢演练：演练降级等于演示自己的产品不可用
• 不敢打标记：打了"降级"标记用户就会问"那我为什么要为 AI 付费”

而 AI-miniSOC 从第一行代码就把 AI 放在消费点（01 篇的取舍三）——降级路径不是备案，是天天在走的常规路径（日限 500 次意味着每天必有降级发生）。所以它敢：

• 把每个消费点的兜底路径写进源码注释（降级策略（与 reconcile_ai 一致）...）
• 把对抗样本跑进评测集（must_reject 断言）
• 把降级标记亮在前端（数据降级红标 / 启发式兜底灰标）

诚实不是道德承诺，是架构性质。 当"不出假数据"由代码结构保证时，它就不依赖任何人的自律——不依赖模型厂商的良心，不依赖 Prompt 写得多小心，也不依赖运维记性好不好。

常见问题

Q：降级这么多，用户会不会觉得"AI 是不是没用"？

A：恰恰相反——降级可见让用户更信任 AI 的输出。因为用户知道：标了 AI 的内容是真 AI 生成的（没标就是兜底）；数据降级时会被告知；数字永远来自规则引擎。信任来自可验证，不来自永远不出错。

Q：我的场景没有日限，还需要降级吗？

A：需要。降级防的不只是预算——模型厂商故障、网络中断、Key 过期、Prompt 升级导致的临时异常都会发生。09 篇的熔断器（5 分钟失败 5 次断 10 分钟）触发时，走的就是这条降级路径。没有降级的 AI 功能，故障时是空白页面。

Q：启发式兜底的质量怎么样？

A：按签名规则给结论——不如 AI 灵活，但覆盖 80% 的常见模式（爆破、扫描、异常登录这些高频模式规则写得全）。关键是它永远可用、永远一致——凌晨 3 点告警来了，启发式兜底给的分析和下午 3 点给的一样。

Q：怎么给我的系统加降级？

A：三步：① 把"数字"和"叙事"拆开——数字走规则引擎，叙事才走 AI；② 给每个 AI 消费点写兜底实现（模板文案 / 启发式规则 / 明确提示三选一）；③ 加可见标记。顺序不能反——先拆数字和叙事，降级才有意义。

收尾：11 在系列中的位置

到这里，“AI 副手"最核心的三块（底座、查询、可靠性）讲完了。12/13 篇是具体消费点的展开（报告推送、Agent/MCP），14 篇起回到工程化主题（告警治理、权限、CI/CD），17 篇算总账。

老李上周三下午发现风险摘要全变成了"规则引擎口径"模板——第一反应是"坏了”。 查了下 07 篇的数据健康看板：源全绿。再看 AI 模型管理：GLM 那家下午限流了（测试连接失败标记）。 他看了眼兜底文案的数字——和昨天 AI 写的摘要里的数字一模一样。 于是他知道两件事：数据没错（数字来自规则引擎）；明天限流解除就恢复 AI 摘要。 整个"故障"期间，他的 SOC 没有一分钟给出过假数据。

这就是诚实的价值——不是永远不出问题，是出了问题你不被骗。

副手会累、会请假、偶尔说胡话——但你永远不会被骗。这样的副手，才敢托付你的 SOC。

【系列导航】《一个人的SOC》总目录（持续更新）

【上一篇】(10) 自然语言查资产——L1/L2 双层设计与 98% 准确率是怎么来的

【系列开篇】(00) 中小企业为什么需要自己的安全运营中心

【项目地址】AI-miniSOC - GitHub · MIT 开源，欢迎 Star ⭐ 【Gitee 镜像】 https://gitee.com/xiejava/AI-miniSOC

【交流】 想验证你自己的系统有没有降级能力？试试把 AI Key 拔了走一遍所有 AI 功能——出现空白页或假数据的，欢迎来 Issue 对答案。

下一篇（预告）：(12) AI 安全报告与主动推送——五种场景的自动化闭环（连载中，敬请关注）

作者博客：http://xiejava.ishareread.com/