你的 AI 功能忘记计入的 SIEM 账单

这里的数学逻辑很简单，但没人去算。在 AI 时代之前，单个用户操作（例如“总结这张工单”或“发送这封邮件”）只会产生一行应用程序日志。而在 AI 时代之后，同样的操作会产生一条请求日志、一个 LLM 调用追踪、代理调用的每个工具的工具调用 span、它读取的每个数据块的检索 span、一条响应日志，如果你采样进行离线评分，还会产生一条评估日志。一次用户点击的扇出（fan-out）现在会在你的可观测性流水线中产生 30 到 50 条记录，这还是在重试、子代理以及会让一切翻倍的规划器-执行器（planner-executor）拆分出现之前。

你在第一季度发布了一个 AI 功能。到了第二季度，你的安全总监拿着一份比上一个周期高出 4 倍的 Splunk 续订合同走进预算审查会议。AI 团队的人都不在现场。接下来的对话——关于谁来承担这笔费用、为什么威胁检测规则失效了，以及是否真的必须对每次对话进行法律保留（legal hold）——是你在设计阶段就应该进行但没有进行的对话，因为这笔成本没有出现在 LLM 的发票上。它出现在下游，出现在一个 AI 团队从未登录过的工具中。

这篇文章讨论的是没人建模的 AI 功能的二阶成本：当代理上线时，你的审计日志量、SIEM 摄取量、威胁检测基准和法律保留存储会发生什么变化。一阶成本（即 Token 账单）是每个人都在盯着的。它也是最容易预测的。二阶成本则是悄无声息地吞噬你的安全可观测性堆栈，并在发布六个月后以“续订惊喜”的方式出现在你面前。

没人向安全部门汇报过的 30 倍遥测倍数

传统的 REST 端点会产生一个体积小、形状良好的追踪：一个入站请求 span、几个数据库调用、可能还有一个出站 HTTP 调用以及一个响应。每个用户操作产生两到三个 span 是大多数平台团队十年来一直运行的稳态基准。他们的 SIEM 关联规则、成本预测、采样默认值——所有这些都是针对这一数量级进行校准的。

LLM 调用不是数据库调用。一旦你正确地进行了埋点（instrument），单次聊天补全会产生 8 到 15 个 span：网关 span、模型 span、用于输入格式化的子 span、输出解析、函数调用提取、内容审核、一个 Token 使用事件，以及如果你在进行离线评分时的评估采样 span。一个在回答前循环执行 5 个推理步骤的多步代理，会为用户感知的单次交互产生 40 到 75 个 span。行业分析现在认为 AI 工作负载的遥测数据量是传统服务的 10 到 50 倍。

这种倍数在三个没人汇报的维度上复合叠加。重试：代理会激进地重试工具调用和模型调用，因为推理失败通常是瞬时的——每一次重试都是另一个完整的子追踪。子代理：一旦你的顶级代理委派给规划器或专家代理，你就拥有了一棵树，每个节点都会展开到自己的 LLM 和工具 span。基数（Cardinality）：提示词、模型版本、工具名称和租户 ID 变成了高基数的 span 属性，而原本在 1 万个序列时免费的指标层级，在 20 万个序列时变成了超额付费项目。

结果是，“我们在结账环节增加了 AI 功能”反映在可观测性上就是摄取量增加了 4 到 8 倍。记录了 LLM 调用 payload 的 Datadog 客户公开报告称，由于捕获了大量的提示词和补全内容，他们的可观测性账单跳升了 40% 到 200%。账单还不是惊喜停止的地方。运行在摄取流之上的威胁检测层才是最先崩溃的部分。

为什么你的威胁检测规则会悄无声息地失效

SIEM 关联规则是统计性的。它们假设每个用户、每个服务、每个端点的“正常”活动基准，并在频率或模式偏离时触发告警。这些基准是针对 AI 之前的流量训练的。一旦代理上线，每个用户操作看起来都像是一次突发——多 span、多工具、多重试——针对“如果单个用户每分钟生成超过 500 个事件则告警”而调整的规则会在有人使用助手时就开始频繁触发。

首先发生的是规则疲劳。安全团队会因为一个仅仅是在完成工作的代理而收到告警。第二件事更糟糕：为了降低噪音，有人放宽了规则，现在原本用于捕获撞库（credential-stuffing）模式的阈值已经远高于撞库实际发生的水平。规则没有被删除，但它被调整得毫无用处，而执行调整的团队并不知道他们正在降低检测覆盖率，因为没人告诉他们代理的流量形态是全新的。

更深层的问题是 SIEM 关联引擎本身有层级限制。Splunk Enterprise Security 和大多数同类产品的定价是按每天摄取的 GB 数计算的，安全层级的摄取费用通常为每 GB 250 到 400 美元。当摄取量超过授权层级时，引擎会开始丢弃事件以维持运行。默认情况下，丢弃是静默的。最容易被丢弃的是长尾事件——那些不寻常的模式——而这恰恰是威胁检测规则试图寻找的群体。你的检测覆盖率下降了，而你的仪表盘看起来仍然是绿色的。

教训是，从 SIEM 的角度来看，开启 AI 功能是一次与十年前从单体架构迁移到微服务架构同样重大的工作负载迁移——它值得进行同样类型的跨职能设计评审。但它很少得到这种评审，因为 AI 团队和安全团队不在同一个值班表上，而且成本信号出现在不同的损益表中。

你刚刚将其永久化的法律保留范围

在 AI 时代之前，“必须保留的通信内容”指的是电子邮件、Slack 消息和通话录音。大多数 SaaS 产品并不认为其应用遥测数据 (telemetry) 属于通信内容。一旦产品中加入了 AI 功能，这条界线就发生了移动：每一次用户提示词 (prompt) 和每一次模型响应都是一次对话，且用户往往将系统视为对话者。法律团队正迅速将这些内容默认归类为：“是的，按照与客户消息相同的保留规则进行保留。”

存储保留的成本计算是残酷的。HIPAA 要求涉及 PHI 的记录需保留六年。SOX 和许多金融法规将其推高至七年。GDPR 虽然没有规定具体数字，但要求保留必须与记录在案的用途挂钩——而“针对模型临床建议的审计辩护”这一用途足以证明多年保留的合理性，即便运营侧的 SIEM 可能只需要 30 天的数据。同一段对话现在必须存在于两个地方：用于安全分析的热存储层，以及用于法律辩护的冷存储层，且需具备仅追加完整性和独立系统校验和，以便日志在宣誓证词中具有辩护效力。

冷存储层的成本并不是意外。对象存储很便宜。真正的意外是将数据从 SIEM 导出并进入冷存储层的成本，且导出的形式必须是法律团队真正可用的——这意味着数据必须是结构化的、可查询的、带有来源元数据的，并具备能满足你业务覆盖的下一个大司法管辖区要求的 PII 处理能力。那些没有为此进行设计的团队最终只能向 SIEM 供应商支付费用，以热存储的价格将所有内容保留数年，因为导出流水线从未建成，而续约日期却抢先一步到来了。

一个有用的框架：在设计时将保留策略视为针对每个租户 (per-tenant) 的策略。某些租户——医疗保健、金融、受监管的欧盟地区——适用包含完整内容的七年期冷存储。大多数租户则适用经过内容脱敏的 90 天运营存储层以及仅包含元数据的归档。默认选项不能是“在任何地方永远保留所有内容”，因为当你产品团队忘记询问时，默认选项就是你交付的内容。

压缩范围的设计选择

看到账单后的本能反应是关闭遥测。别这么做。行之有效的直觉是将安全流水线与工程流水线分离，将它们视为不同的产品，并根据各自的预算进行工程化。

以下几项架构举措可以完成大部分工作：

• 在安全路径中使用结构化日志，而非冗长的追踪 (traces)。 安全流水线不需要每个智能体 (agent) 运行产生 75 个 spans。它需要少量高信号的记录：谁执行了操作、调用了什么工具、授权决策是什么、涉及了哪类数据以及结果如何。工程可观测性可以保留完整的追踪；安全则获得一个独立的发射器，为每个特权操作生成一条扁平记录。
• 采用采样技术，在对正常路径进行子采样的同时保留错误和特权操作。 对常规流量进行 1–5% 的头部采样 (head sampling)，结合尾部采样 (tail sampling)，后者始终保留任何报错的内容、任何涉及特权工具的内容以及任何被评估采样器标记的内容。OpenTelemetry 社区报告称，仅靠尾部采样就能帮团队完成 70–80% 的可持续预算目标，剩下的则通过过滤和属性清洗来实现。
• 通过保留策略而非服务来区分热存储层和冷存储层。 在 SIEM 中保留 30 天热存储用于安全分析，在对象存储中保留 7 年冷存储用于合规。冷路径是仅追加的并带有离线校验和；热路径可以是允许丢失且可重新推导的。
• 在收集器 (collector) 端进行 OTel 属性清洗。 OpenTelemetry GenAI 语义规范明确指出，提示词和补全内容既可以作为 span 属性内联存储（成本低但冗长），也可以存储在外部并在 span 中保留引用（基础架构昂贵，但 span 小得多）。对于安全流水线，应将内容外部化并保留引用——SIEM 关联引擎不需要在索引中存储 8KB 的提示词。
• 采用每租户保留策略，而非全局默认策略。 在法律团队提出要求之前，先构建好导出和脱敏流水线。事后构建的代价是，因为冷存储导出功能尚未就绪，你不得不支付两年的 SIEM 热存储费用来保留对话内容。

这些举措背后的模式是相同的：设计两条独立的遥测流水线，并允许它们拥有不同的预算。工程流水线优化的是“值班工程师能否在五分钟内调试生产问题”。安全流水线优化的是“用户是否触发了策略违规，以及我们能否证明这一点”。它们共享 OTel 收集器，但不共享存储后端。

发布前必须进行的跨职能评审

架构上的实现是容易的部分。组织上的实现则更难：发布一项 AI 功能会对你的安全可观测性栈产生下游成本，而由于这不会出现在 LLM 的账单上，所以没人会对其建模。成本落在了一个未参与设计决策的团队身上，并且是在功能发布几个季度后，以必须在时间压力下进行续约谈判的形式显现出来的。

三个习惯可以防止这种情况。首先，AI 功能启动会从一开始就应包含一名安全可观测性负责人，并由其签署有关预计摄入量、保留策略和检测规则重定基准的预算。其次，发布清单应包含一个发布后 30 天的遥测评估，将实际摄入量与预测量进行对比，以免 SIEM 层级限制迫使你进行重新谈判。第三，AI 团队关注的成本看板应包含一条下游可观测性曲线，而不仅仅是 LLM 供应商的账单——这才是总拥有成本 (TCO) 的真实领先指标。

在发布前进行预测。激进地采样。按保留策略分层。并在设计变更成本尚低时，邀请安全团队参加设计评审。做到这些的团队在发布 AI 功能时，能够拥有在续约时经得起推敲的稳态运营成本。而没做到的团队，最终只能在复盘会上解释，一个在 Token 费用上能自给自足的功能，是如何悄然成为安全部门预算中成本最高的一项支出的。