AI 可观测性泄露：你的追踪堆栈正成为数据外泄的出口

我最近接触的一个安全团队发现，他们的 prompt（提示词）和 response（响应）字段被完整地发送到了一个第三方 SaaS 日志后端，而他们从未与该厂商签署过《数据处理协议》（DPA）。这些字段包含客户的医疗摘要、支持人员误粘贴的 Stripe 私钥，以及某人要求内部助手总结的机密收购备忘录全文。Payload 中没有任何内容经过加密，也没有进行任何脱敏处理。数据保留期长达 400 天。这一集成是由一位初衷良好的工程师在黑客松期间通过 pip install 厂商的 SDK、填入 API 密钥后直接上线的。

这就是 AI 观测性泄露。每个 LLM 应用团队最终都会需要追踪（tracing）——没有它，你无法调试提示词回归或非确定性的智能体（agent）循环——因此 LangSmith、Langfuse、Helicone、Phoenix、Braintrust 或厂商提供的 AI 插件最终都会进入技术栈。默认设置会捕获整个请求和响应。对于大多数生产工作负载来说，这种默认设置就是一个等待被发现的合规性违规隐患。

令人不安的是，这并非厂商的错。托管的追踪服务完全按照你的配置在运行。失败的原因在于组织内部：法务负责 DPA，安全部门负责数据分类政策，而工程部门则负责 SDK 配置，默许地决定了哪些字段会越过信任边界。没有人对这一衔接处进行审计。

免费层级很少是真正免费的

围绕 AI 追踪平台的讨论已正确地从“我们是否用你的数据进行训练”转移开。LangSmith 明确表示不会使用客户数据进行训练。Langfuse Cloud 获得了 SOC 2 Type II 和 ISO 27001 认证。Helicone 及大多数竞争对手也有类似的声明。将“他们是否在训练？”视为主要风险，会忽略掉依然至关重要的三个风险：

保留期（Retention）。 LangSmith 对基础追踪数据存储 14 天，对扩展追踪（带有反馈的）存储 400 天，且在托管方案中保留期不可配置——仅在私有化部署（self-hosted）中可选。这意味着，在一个包含客户心理健康咨询的追踪记录上点击一次“踩（thumbs-down）”，就会将其生命周期延长近一年。你处理数据主体访问请求（DSAR）的事件响应窗口突然变得更宽了。

泄露表面（Breach surface）。 每一个托管的追踪平台都是一个容易受到攻击的目标。其全部价值主张就在于可搜索的 UI 中包含完整的提示词、完整的响应、工具调用参数和思维链。你的观测性厂商发生泄露——通过任何矢量，包括支持工程师被盗的手提电脑——就等同于你用户输入过的最敏感文本发生了泄露。你的事故披露必须点名该厂商，而你的客户并没有签约使用该厂商。

传票与合法访问（Subpoena and lawful access）。 存放在第三方美国云端的追踪数据受美国法律程序的管辖。对于欧盟客户数据，即使厂商在技术上合规，这仍然是一个 GDPR 问题，因为合规并不能免受 Schrems 风格的挑战。大多数团队在监管机构询问之前从未考虑过这一点。

“免费”层级尤其棘手，因为它们往往具有最弱的保留控制和最松散的隔离保证。如果你通过免费层级传输生产环境的提示词，你就是那个“产品”，这与免费社交网络用户的性质在结构上是一致的——不一定是出于训练目的，而是因为厂商的经济模型要求保持你的数据存储成本低廉且删除缓慢。

SDK 即政策

这就是让团队陷入困境的模式。法务谈判 DPA。安全部门编写数据分类政策——PHI（个人健康信息）存这里，PII（个人可识别信息）存那里，密钥永远不接触共享存储。工程部门接入 AI SDK。SDK 将 {prompt, response, tool_calls} 发送到 api.hosted-vendor.com。没有人将这三者联系起来。

你的 AI 栈的有效隐私政策并不是法务签署的 PDF。而是你的 @traceable 装饰器、langfuse.trace() 调用或 dd-trace 检测（instrumentation）在线路上实际发送的内容。如果工程部门切换了一个开始捕获 tool_result 负载的新 SDK 版本，隐私政策就改变了。没有审批，没有工单，仅仅是一个小版本号的更新。

2023 年的三星事件——工程师将源代码和会议记录粘贴到 ChatGPT 中，导致三星的数据落入 OpenAI 手中——成了关于提示词输入的警示案例。托管追踪版的这类故事更难被察觉，因为这并非人类的疏忽输入；而是你的生产代码忠实地执行了指令。没有提示词可供审查，泄露是结构性的。

一个真正适配 LLM 的数据分类模式

传统的数据分类（公开 / 内部 / 机密 / 限制）很难映射到 AI 追踪，因为单个 LLM 调用可能同时包含这四个层级。系统提示词是内部的。用户消息是用户输入的任何内容，可能属于任何层级。工具执行结果通常是受限的（例如来自客户数据库的一行）。模型输出则是上述所有内容的综合。

一个适用于 AI 工作负载的可行架构会对每个字段独立处理，并分配以下四种处置方式之一：

• 原样记录（Loggable verbatim）。 元数据：请求 ID、模型名称、延迟、Token 计数、成本、状态码、工具名称。可以安全地发送到任何追踪后端；这正是观测性真正需要的。
• 哈希记录（Loggable hashed）。 帮助你将追踪与会话关联但不需在 UI 中可读的标识符：用户 ID、会话 ID、追踪 ID。发送加盐哈希（salted hash），并将盐值保留在你的基础设施内部。
• 脱敏记录（Loggable redacted）。 在 PII/密钥脱敏工具将实体替换为类型 Token（如 <EMAIL>, <CREDIT_CARD>, <API_KEY>）后的提示词和响应文本。你失去了逐字重现追踪的能力，但保留了 90% 的调试价值。
• 永不记录（Never loggable）。 针对内部系统的工具执行结果（数据库行、包含 PHI 的搜索结果、S3 对象内容）、原始认证 Token、签名 URL、任何受法律保护的内容。无论追踪 SDK 如何配置，这些内容永远不会离开你的 VPC。

这种约束迫使工程部门必须按字段而不是按服务来决定处置方式。追踪 SDK 变成了一个“哑管道（dumb pipe）”；决策逻辑存在于你拥有的中间件层。

在数据流出前进行脱敏，而不是流出后

在链路追踪后端进行脱敏是错误的做法。是的，Datadog 的敏感数据扫描器（Sensitive Data Scanner）可以扫描 LLM 链路并在数据摄入时进行脱敏；是的，LangSmith 和 Langfuse 也有字段遮盖功能。但当数据到达供应商的摄入端点时，它已经离开了你的信任边界。如果脱敏程序存在 Bug，或者新增了供应商规则库未覆盖的字段，亦或是供应商的存储被攻破，在传输途中存在的始终是未经脱敏的数据。

正确的架构是在应用程序代码和链路追踪 SDK 之间设置一个脱敏器（Scrubber）。有两种合理的实现方式：

内联中间件（Inline middleware）。 这是对链路追踪库的包装，在 span 属性被序列化之前进行拦截。在 Python 生态中，OpenTelemetry 的 SpanProcessor 是规范的扩展点；它在导出器（Exporter）发送 span 之前运行。你的处理器会应用一套策略，识别哪些属性属于哪种分类，并对每个属性进行丢弃、哈希或脱敏处理。

AI 网关（AI gateway）。 在你的应用程序与模型提供商之间（理想情况下，也包括应用程序与任何出站观测端点之间）设置一个反向代理，在单一卡口强制执行脱敏。对于已经运行 Envoy、Kong 或自建代理的团队来说，这种方式最为契合，因为同一个代理还可以强制执行速率限制、供应商故障转移和成本核算。

脱敏引擎本身可以使用 Microsoft 的 Presidio（开源，结合了 NER、正则表达式和校验和验证器）、托管的 PII 分类器，或者——如果你的领域模式比较固定——使用几个编译后的正则表达式。引擎本身并不如放置的位置重要：必须在数据跨越网络边界之前，而不是之后。

一个值得警惕的陷阱：对于具有语义含义的实体类型，不要仅仅依赖正则表达式。正则表达式可以将 \b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b 识别为电子邮件，但会漏掉写成 "reach me at first dot last at gmail" 的表达。对于结构化密钥（AWS key、JWT、Stripe 令牌），正则表达式通常足够且精准。但对于 PII 叙述性文本，你需要一个真正的 NER（命名实体识别）模型。

零保留的不对称性

一个尴尬的事实是：模型提供商本身处理数据往往比你叠加在上面的观测层更谨慎。

OpenAI、Anthropic、Azure OpenAI 和 Vercel AI Gateway 都为企业客户提供零数据保留 (ZDR) 协议，符合条件的端点在请求生命周期之外完全不持久化 API 的输入或输出。Anthropic 在 2025 年底将默认的 API 日志保留期从 30 天减少到了 7 天。虽然大部分功能是可选的且需要销售沟通，但这种能力是存在的。

现在对比来看：LangSmith 在托管方案上保留基础链路数据 14 天，扩展链路数据 400 天，且不可配置。Langfuse Cloud 的保留期取决于方案。大多数供应商的 AI-APM 插件继承了父平台的保留期（通常指标默认为 15 个月，日志默认为 30 天）。

这种不对称性令人震惊。你与 Anthropic 签订的 ZDR 协议让你在模型侧实现了 0 天保留。然而，你的链路追踪设置却将同样的 Prompt 和响应以明文形式存储在第三方长达 400 天，而你并没有与该第三方签订 ZDR 协议。在上游所做的法律合规努力在下游被无声无息地抵消了。团队往往在第一次严肃的隐私审查中才发现这一点，意识到他们一直在通过侧信道保留那些他们明确要求正门不要保留的数据。

自托管再次成为一个现实的选项

以往反对自托管观测系统的理由是运维：既然供应商可以代劳，为什么要自己运行 Postgres 和 ClickHouse 呢？现在的权衡逻辑正在发生变化。

Langfuse 采用 MIT 许可，可以在几个容器上自托管；其开源版本与云端版本代码库相同。LangSmith 提供自托管层级。OpenLLMetry、Phoenix 和 Helicone 都有完善的自托管路径。在内部运行这些系统并非免费，但现在这只是一个下午的 Terraform 工作量加上持续的轮值运维，而不是一个耗时一个季度的平台工程项目。

这种权衡是真实存在的：自托管意味着你拥有存储、备份、TTL 强制执行、访问控制和漏洞暴露面。这意味着你不能再将合规性推卸给供应商的 SOC 2 报告。但你获得的是信任边界止于你的 VPC。对于医疗、金融、法律或任何受欧盟监管的团队来说，这往往是唯一能真正通过严肃审计的姿态。

更有价值的问题不是抽象的“自托管还是云端”，而是“我的哪些数据层可以流出，以及每个层级存放在哪里”。一种常见的且往往是正确的架构是混合设置：元数据发送到托管后端，而脱敏或哈希后的内容存放在自托管后端。

本季度实际该做的事情

如果你读到这里并怀疑你的技术栈存在上述不良模式，补救路径其实很短：

1. 在代码库中 Grep 所有的追踪 SDK、所有的 @traceable、每个 track_llm_call 和每个 dd-trace 集成。记录下每个集成实际抓取的内容。这是实际流出的清单，而不是你“认为”流出的清单。
2. 将每个抓取的字段映射到上述四种处理方式之一。任何目前正在流出的“绝不可记录”字段都是优先级最高的修复项。
3. 插入一个中间件层——span 处理器、AI 网关或 SDK 包装器——来强制执行这些处理方式。将其设为“故障关闭（fail-closed）”：默认脱敏未知字段。
4. 审查你发送数据的所有链路追踪供应商的保留政策。将其与你的合同及监管保留义务进行对比。如果不一致，要么更改政策，要么更换供应商。
5. 每季度让法务和工程团队在同一个房间里开一次会，梳理哪些字段实际流向了哪里。DPA（数据处理协议）与 SDK 配置之间的缝隙，只有在有人专门组织会议时才会被审计到。

更深层的教训是，观测系统与 AI 栈中的其他基础设施一样，并非纯粹的收益。它将你最敏感的数据以可搜索的形式集中在一个用户从未授权、且由你无法控制漏洞风险的供应商运营的系统中。这仍然可能是一个正确的权衡——可调试的 Agent 价值巨大——但前提是这种权衡是明确做出的，而不是从默认的 SDK 配置中继承来的。

你不拥有的链路追踪系统，归根结底是一个你不拥有的数据库。请像对待数据库一样对待它。