三月，一位用户告诉你的智能体停止推荐有室外座位的餐厅——他们搬到了一个带宝宝的公寓，深夜外出已经结束了。九月，智能体为他们的周年纪念建议了一家屋顶酒吧。用户感到恼火，而你感到困惑，因为你亲眼看着三月份的纠正生效了。它被写入了记忆。它仍然在那儿。问题在于它与最初的偏好并排存在，而最初的偏好也还在那里，检索算法浮现了旧的那个，因为它对“周年纪念晚餐”的向量嵌入（embedding）匹配度稍高一点。
这是没有人针对其设计的失败模式。团队在记忆写入上花费数周时间——提取、摘要、嵌入、命名空间——而将删除视为以后再解决的问题。长期记忆使得添加一个事实几乎是零成本的，因此事实不断堆积。但记忆库不是日记。日记允许包含过去真实的事情。智能体读取并据此做出决策的记忆库则不然，因为智能体无法区分事实与过时的残余。
我最近接触的一个安全团队发现，他们的 prompt（提示词）和 response（响应）字段被完整地发送到了一个第三方 SaaS 日志后端，而他们从未与该厂商签署过《数据处理协议》（DPA）。这些字段包含客户的医疗摘要、支持人员误粘贴的 Stripe 私钥，以及某人要求内部助手总结的机密收购备忘录全文。Payload 中没有任何内容经过加密，也没有进行任何脱敏处理。数据保留期长达 400 天。这一集成是由一位初衷良好的工程师在黑客松期间通过 pip install 厂商的 SDK、填入 API 密钥后直接上线的。
这就是 AI 观测性泄露。每个 LLM 应用团队最终都会需要追踪（tracing）——没有它，你无法调试提示词回归或非确定性的智能体（agent）循环——因此 LangSmith、Langfuse、Helicone、Phoenix、Braintrust 或厂商提供的 AI 插件最终都会进入技术栈。默认设置会捕获整个请求和响应。对于大多数生产工作负载来说，这种默认设置就是一个等待被发现的合规性违规隐患。
大多数团队发现他们的 AI 智能体存在 GDPR 问题的方式都是错误的：当一个数据主体提交删除请求时，法务团队询问哪些系统持有该用户的数据，而工程团队开出的工单最终演变成了一场长达六个月的审计。个人数据散落在对话历史中、向量存储的某个角落、可能缓存的工具调用输出中，甚至可能嵌入在微调后的模型检查点里 —— 却没有任何人事先对此进行梳理。
这不是配置上的疏忽，而是架构上的缺失。决定你的 AI 系统是否具备合规性的决策，通常在构建的头几周就已经做出，远早于法务部门找上门来。本文涵盖了受监管行业工程师在将 AI 智能体投入生产环境之前需要解决的四个结构性冲突。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
