受监管行业的 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）、置信度得分和时间戳。