一位具有安全意识的客户拉取了其租户的审计导出文件，打开 JSON，从一个名为 llm.request.system 的字段中读到了逐字记录的拒绝策略、检索流水线结构以及一些内部产品标识符。没有漏洞利用。没有提示词注入。没有越狱。仅仅是你的平台团队在六个月前添加的一个日志字段，目的是让工程师能够将提示词版本与事件关联起来——结果通过你的企业团队出于 SOC 2 合规原因单独向租户开放的摘要（feed）泄露了出来。
泄露发生在周三下午。你的安全团队是由客户呼叫（paged）的，而不是报警系统。事件时间线显示泄露当天并没有部署——错误配置是在审计摘要扩大其字段白名单的那天发布的，那是另一个团队、另一个迭代周期（sprint）和另一张工单。两名评审员都批准了他们所看到的内容。但没有人从全局组合的角度去审视。
在受监管行业部署 LLM 的大多数团队都会以惨痛的方式发现他们的合规差距：审计员出现并要求提供特定日期哪个文档影响了某个特定输出的完整日志，而团队却无法给出答案。这并不是因为系统没有记录——它记录了——而是因为 LLM 调用的文本日志并不等同于具有防篡改证据的审计追踪，而 LLM API 的响应主体也不等同于输出溯源（Output Lineage）。
金融、医疗和法律领域不仅仅是消费类软件的“更严格”版本。它们需要通用 LLM 框架从未设计的底层基础设施原语：不可变事件链、单次输出溯源、拒绝处置记录（Refusal Disposition Records）以及结构化可解释性钩子。目前流行的编排框架都没有提供这些开箱即用的功能。本文介绍了这种架构差距，以及如何在不重构整个技术栈的情况下弥补这一差距。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
