受监管行业的 AI 合规基础设施：大语言模型框架没能提供给你的东西

在受监管行业部署 LLM 的大多数团队都会以惨痛的方式发现他们的合规差距：审计员出现并要求提供特定日期哪个文档影响了某个特定输出的完整日志，而团队却无法给出答案。这并不是因为系统没有记录——它记录了——而是因为 LLM 调用的文本日志并不等同于具有防篡改证据的审计追踪，而 LLM API 的响应主体也不等同于输出溯源（Output Lineage）。

金融、医疗和法律领域不仅仅是消费类软件的“更严格”版本。它们需要通用 LLM 框架从未设计的底层基础设施原语：不可变事件链、单次输出溯源、拒绝处置记录（Refusal Disposition Records）以及结构化可解释性钩子。目前流行的编排框架都没有提供这些开箱即用的功能。本文介绍了这种架构差距，以及如何在不重构整个技术栈的情况下弥补这一差距。

差距在于基础设施，而非配置

将 LLM 产品推向消费者的团队学会了从数据隐私的角度考虑合规性：在数据进入模型前清除个人身份信息 (PII)，与你的服务提供商签署商业伙伴协议 (BAA)，启用静态加密。这些确实是硬性要求，但在受监管的垂直领域，它们只是入场费，而非终点。

FINRA 第 3110 号规则要求金融机构了解 AI 的输出是如何得出的，以及它们是否符合监管义务。HIPAA 要求审计追踪能够重构谁在什么情况下访问了受保护的健康信息。欧盟《人工智能法案》将信用评分、保险风险评估和医疗诊断系统归类为高风险——这一定义触发了从 2026 年 8 月开始生效的文档记录义务、对抗性测试要求和事件报告指令。

SOC 2 Type II 使问题进一步复杂化。该框架的处理完整性（Processing Integrity）标准假设系统能正确且一致地处理数据。然而 LLM 的输出是非确定性的。对一个由 LLM 驱动的产品进行原始的 SOC 2 审计会产生一个悖论：你如何为一个本质上具有多变性的组件提供处理完整性的证据？

答案不是去对抗非确定性。而是在它周围构建基础设施，以足够的保真度捕捉所发生的一切，从而满足监管机构、原告律师或审计员的要求——即使模型的下一次运行会产生不同的输出。

框架未提供的功能

LangChain 和 LlamaIndex 是为编排而设计的。它们为你提供了回调钩子、到 LangSmith 或兼容的可观测性后端的结构化日志以及检索源引用。但它们没有提供：

不可变审计追踪。 标准日志是约定式追加（Append-by-convention），而非构造式追加（Append-by-construction）。任何日志记录都可以通过相应的数据库权限进行修改或删除。对于受监管的环境，你需要防篡改证据：每个事件记录都包含前一个记录的加密哈希，因此对历史条目的任何修改都是立即可检测的。AuditableLLM 框架 专门针对 LLM 交互展示了这种哈希链方法。你标准的结构化日志管道并没有实现这一点。

输出溯源 (Output Lineage)。 当 LLM 输出进入病历、贷款申请或合同时，需要能够从该输出回溯到确切的检索上下文、模型版本、提示词版本以及产生它的输入。LlamaIndex 会记录 RAG 查询的源文档，这已经很接近了——但它没有将该检索记录与下游输出产物链接起来，不跟踪正在使用的模型版本，也没有为诸如“向我展示进入输出 ID X 的所有内容”之类的合规查询提供 API。

拒绝追踪。 拒绝请求的 LLM 已经做出了一个与合规相关的决策。金融服务业尤其需要知道：系统拒绝回答本该回答的问题的频率是多少？内容拦截的误报率是多少？是否存在特定请求类型被错误拒绝的模式？监控框架将拒绝视为质量指标。合规团队则需要将它们作为处置记录——带时间戳、分类且可查询。

可解释性钩子。 FINRA 关于自主 AI 决策的指南规定，企业需要为高风险输出提供关键输入因素和输出理由的书面摘要。这并非模型可解释性研究；而是一个结构化字段，被追加到每一条可能触发监管审查的决策记录中。

行之有效的架构

好消息是，你不需要更换你的编排层。你只需要添加一个轻量级的合规中间件层来包装它。

不可变事件账本

其基础是一个采用哈希链的仅追加 (append-only) 事件存储。LLM 流水线产生的每一个事件 —— 接收到用户查询、发出检索查询、选定分块、发起模型调用、交付输出、触发护栏 —— 都会被序列化为 JSON，并写入一个包含 SHA256(event_data || hash_of_previous_event) 的计算字段。链路中的第一个事件使用固定的创世哈希。

在存储方面，带有不可变行约束的 PostgreSQL 适用于大多数部署场景。对于更高安全性要求的环境，对象存储（如 S3 Object Lock、Azure Immutable Blob Storage）结合时间戳服务，可以生成由第三方提供加密链接和时间戳的链路条目。

关键的设计决策是：每个流水线组件在将数据传递到下一阶段 之前，必须向该账本发送事件。只有在执行期间写入账本，才能重建合规链，而不是事后从应用程序日志中合成。

通过 Trace ID 实现输出血缘追踪

Trace ID 在整个流水线中传播。当接收到用户请求时产生一个 Trace，并向下游流经检索、上下文组装、模型调用和响应交付。账本中的每条事件记录都携带该 Trace ID。

输出产物 —— 即交付给用户或写入下游系统的特定文本 —— 作为其 Trace 中的终止事件存储在账本中，并带有作为稳定标识符的内容哈希。给定一个输出标识符，合规查询可以重建完整的因果链：检索了哪些文档分块、哪些向量搜索参数产生了这些分块、哪个模型版本处理了它们、当时生效的是哪个提示词模板。

特别对于 RAG 部署，这要求进行大多数团队都会忽略的向量数据库查询日志记录。每次检索查询都需要记录查询嵌入 (embedding)、返回的分块 ID 及其相似度得分。如果没有这些，血缘链就会在监管机构最感兴趣的地方出现断裂：系统是如何决定模型会看到哪些信息的？

拒绝与护栏处置记录

在模型看到请求之前拦截请求的输入护栏需要写入处置记录 (disposition records)，而不仅仅是静默拦截。处置记录捕获：分类结果（ACCEPTED、BLOCKED、FLAGGED）、原因代码（PHI_DETECTED、HIGH_RISK_TOPIC、PII_CONFIDENCE_EXCEEDED）、置信度得分和时间戳。

针对模型响应的输出护栏也以同样的方式工作。如果模型输出在交付前被过滤或修改，该修改就是一个合规事件。

这些记录使受监管环境所需的合规分析成为可能：

• 误报率分析：被标记的输入中有多少比例是合法的查询？
• 覆盖率分析：护栏捕获的内容是否存在系统性漏洞？
• 漂移检测：特定主题的拒绝率是否呈上升趋势，从而表明模型的行为正在发生变化？

作为结构化字段的可解释性

对于属于可解释性要求的输出类别 —— 如贷款中的信用决策、医疗保健中的诊断建议、法律中的合同解释 —— 流水线会在主要输出之外生成一个结构化摘要字段。这并非 LLM 生成的散文，而是一个包含必需字段的架构：按相关性得分排序的前三个检索上下文项、模型版本标识符、提示词模板版本，以及源自输出一致性检查的置信度指标。

此摘要字段随输出一起进入接收它的任何下游系统，并作为 Trace 中终止事件的一部分写入合规账本。需要解释特定决策的审计员拥有的是结构化记录，而不是叙事性的重构。

RAG 特有的问题

RAG 流水线引入了直接模型调用所不存在的合规挑战：检索语料库本身可能就是一个合规风险点。向量数据库对于它们索引的文档没有等效的监管链 (chain-of-custody)。如果一个文档被检索并由模型总结，且该总结影响了一个受监管的决策，组织需要能够证明：

• 检索时索引的是哪个版本的文档
• 哪些访问控制规定了哪些用户可以触发该文档的检索
• 检索权限是在查询时强制执行的，而不仅仅是在索引时

向量数据库中的行级安全性 (Row-level security) 是架构层面的解决方案。查询流水线使用用户身份和数据访问权限扩展每个用户查询，向量存储据此过滤检索结果。这一授权决策作为一种单独的事件类型记录在合规账本中 —— 与检索事件分开，如果访问被拒绝，则带有其自身的原因代码。

实际结果是：授权强制执行必须发生在数据层，而不是模型指令中。在系统提示词中加入 "不要讨论用户无权访问的文档" 并不是访问控制。它在对抗性输入下会失效，且不会产生审计记录。

生产环境中的故障模式

未部署此类基础设施的团队通常不会立即在合规审计中失败。只有当出现问题且监管机构询问“为什么”时，他们才会失败。

一个医疗文档 AI 生成了病历摘要，随后医生对其提出了异议。监管机构要求提供生成该输出的确切数据。如果没有输出血缘（output lineage），团队只能检索到模型的响应——但无法得知该响应基于哪些文档、运行的是哪个版本的文档索引流水线，或者检索上下文包含了什么。

一个信用评分模型拒绝了一项申请。申请人根据《平等信用机会法》（Equal Credit Opportunity Act）行使解释权。如果该输出缺乏结构化的可解释性记录，团队就必须根据不完整的日志重新构建解释——由于这种做法具有天生的“自证性”，法院和监管机构通常会持怀疑态度。

一家律师事务所部署用于辅助合同审查的 LLM 虚构了一个引证。虚构的权威依据出现在了提交的辩护状中。审计的问题在于，该事务所是否设置了拦截此类错误的护栏（guardrails），以及这些护栏是否正常运行。如果没有护栏处理记录，就拿不出证据。

在这三种情况下，导致合规失败的并不是底层模型的行为，而是缺失的基础设施。

优先事项

如果你在没有此类基础设施的情况下向受监管环境进行部署，请根据监管风险敞口按以下顺序排列优先级：

第一：具有追踪 ID（trace ID）传播功能的只增（append-only）事件日志。 你可以稍后添加哈希链和加密证明。确保事件记录以正确的顺序写入并带有稳定的追踪 ID，是所有其他工作赖以生存的基础。

第二：护栏处理记录。 这些最容易事后补救，因为护栏在流水线中已经是明确的干预点。在其现有功能中添加结构化日志的开销很低。

第三：高风险决策类别的输出血缘。 你不需要为每一个输出都建立完整的血缘。识别出最有可能受到监管查询的输出类别——如贷款决策、诊断建议、合同解释——并专门针对这些类别构建血缘捕捉机制。

第四：向不可变存储迁移。 一旦事件流正常运行，升级存储后端以强制执行哈希链完整性和对象锁定约束就属于基础设施变更，不需要重写应用代码。

合规基础设施问题之所以比看起来更难，部分原因在于那些能提高 LLM 应用开发效率的框架在设计之初是为了“性能”（capability），而非“问责”（accountability）。事后再构建问责层是可行的，但在拥有生产流量之前设计好追踪 ID 传播和事件日志架构要容易得多——而且与监管机构询问时才发现差距相比，成本要低得多。

AI 部署速度最快的受监管行业——医疗、金融服务、法律——也正是这种“被动发现”成本最高的行业。弥补这一差距的基础设施已经存在。那些在需求产生之前就构建好它的团队，才是能够让其部署持续运行的团队。