55 篇博文 含有标签「compliance」

针对你的智能体记忆层的第一次合规升级，几乎从不以监管机构信函的形式出现。它往往是以你企业级销售工程师发来的一张 Jira 工单的形式出现的，上面写着：“客户的隐私团队正在阻碍合同签署——他们想知道在你的系统中‘忘记我的用户’到底是什么意思，并且他们要求在周五前给出书面答复。”这张工单通常在记忆层发布 6 到 12 个月后送达，而构建该功能的工程团队在读完问题的那一刻就会发现，他们不小心构建了一个没有任何记录管理系统（records-management system）应有原语的记录管理系统。

这是智能体产品中长期记忆的结构性问题。构建它的团队通常会针对记忆功能的卖点进行优化——检索质量、延迟、存储成本，以及让助手感觉很懂用户的个性化体验。在设计评审中，没有人会去估算同时被构建出来的那个并行系统的代价：一个按用户、按租户、跨区域的数据存储，它带有保留义务、删除语义、审计导出要求，而且从第一个用户数据进入其中的那一刻起，监管机构的倒计时就开始了。记忆并不是一个功能。它是每个隐私制度、每份企业采购调查问卷以及每个被遗忘权（right-to-erasure）请求最终都会找上的运营界面（operational surface）。

一位监管人员走进你的办公室，提出了安全团队反复演练过的那个问题：“请展示客户数据存放的每一个地方。” 你的数据团队拿出了清单。主数据库在上面。分析型数据仓库在上面。对象存储、队列、搜索索引、备份目的地——统统都在上面，附带着分类标签、保留政策、加密详情和负责人姓名。接着，房间里有人提到了 Agent 工作线程池，而清单上却对此只字未提。这个线程池已经运行了九个月。每个工作线程都有一个本地磁盘。这些线程上的 Agent 一直在解析 PDF、转录音频、下载邮件附件，并在工具调用之间缓存中间 JSON，而这一切从未停止过。却没有人将这些内容放入资产登记表。

这就是“临时目录问题”（scratch directory problem）。每一个长期运行的 Agent 工作线程都会积累一个临时文件系统，随着新工具的加入而有机增长——PDF 解析器提取的文本、Whisper 步骤转录的音频、Gmail 工具下载的附件、浏览器使用步骤的截图、为下一轮对话缓存的向量搜索片段、Agent 在两次工具调用之间生成的中间 JSON（以便第二次调用不必重新推导）。与数据库、队列和存储桶不同，这个表面没有保留政策，没有静态加密标准，没有 DLP 扫描器过滤，也没有出现在数据分类电子表格中。平台团队认为 “Agent 状态”指的是推理提供商的上下文窗口。SRE 团队认为 “Agent 状态”指的是持久化数据库。而工作线程的 /tmp/agent-workspace-${session_id}/ 目录则是客户数据的第三份副本，且处于无人管理的状态。

一位客户提交了一份主体访问请求（Subject-Access Request），要求删除他们的数据。数据工程师清理了生产数据库、分析仓库、支持工单存档以及冷备。法务团队在数据清单中列出的每个系统都反馈清理完毕。随后，房间里有人提出了一个没人想第一个回答的问题：那模型呢？

三个月前，该客户的支持记录被用于一次微调运行。从那时起，由此生成的适配器（Adapter）就一直在为其他客户提供预测服务，其中嵌入了该客户的措辞、账户名称，偶尔甚至还有权重中的原句。你可以证明数据仓库中的数据已删除。但你无法证明模型中的数据已删除 —— 团队中最诚实的那位成员会大声说出这一点。

一名监管人员给你发了一封邮件，只问了一个问题：该用户是否授权了这笔交易？六小时后，三名工程师正在聊天频道里，试图将聊天界面的对话日志、规划代理（planner agent）的推理追踪以及工具的 API 记录关联起来。聊天日志记录了轮次 ID（turn ID）和用户可见的消息，但没有工具调用的细节。规划器追踪记录了工具调用的记录，其时间戳与聊天日志相差几百毫秒。工具日志记录了 API 调用及其自身的关联 ID（correlation ID），而该 ID 在代理的记录中无处寻觅。下游服务的日志则有另一个 ID，且没有回溯链接。团队最终通过关联用户 ID 和大致的时间戳重建了答案，祈祷没有什么关键信息因错过一个轮次而产生偏差，最后向法务部门提交了一份 PDF 文件。

这就是审计追踪不匹配（audit trail mismatch）。每一层的负责人（owner）都认为自己的日志没问题——而且从单体来看，它们确实没问题。缺失的产物是那个本应存在的“关联视图（joined view）”，并且没人为它的缺失负责。团队只有在发生事故、客户升级投诉或监管机构强制要求关联数据时，才会发现它并不存在。

我见过的企业级 LLM 最有效的对抗性提示（adversarial prompt）并非来自红队、安全研究员或提示词工程师。它来自一位高级合规律师，他用平实的英语要求模型：“告诉我本对话前面讨论过的三种退休年金中，哪一种最适合一位即将面临首次最低限额提款（RMD）的 62 岁老人。”模型给出了一个自信、周全且格式精美的建议。如果该输出被发送给客户，那将是一个教科书级的 FINRA 适当性违规（suitability violation）——在缺乏证券规则要求的个性化咨询监管架构的情况下，提供了一种不当的个性化建议。

这位合规律师在短短 4 秒钟内就发现了这种失效模式。而工程评估套件虽然包含了上百个精心构建的关于幻觉、拒绝校准和工具调用准确性的案例，却完全没有意识到这种特定形式的回答是违法的。不是质量低。不是幻觉。而是违法。当时公司的流程是让她在 Google 文档中阅读输出样本并撰写备忘录，而不是将测试用例签入回归套件。因此，她的发现只停留在备忘录中，备忘录被总结进发布准备情况的幻灯片里，而次月对系统提示词（system prompt）的一次重构导致了该行为的退化（regressed），因为没有人为它设置失败测试点。

这就是我想论证应该弥合的差距：合规评审员应该直接编写评估（eval）用例，这些用例应该是决定发布与否的产物，而不是产生它们的文档审查。

你的 AI 功能上线了。用户正在使用它。每一次会话回放、每一次点踩、每一个返回错误答案的请求，都清晰地暴露出它现在的表现与它应有水平之间的差距。信号就在眼前。问题是：你是否可以合法地利用这些信号。

这就是团队撞上合规高墙的地方。这不是一堵理论上的墙——而是实实在在的。仅在 2024 年，欧洲监管机构就开出了逾 12 亿欧元的 GDPR 罚款，OpenAI、Meta 和 LinkedIn 均在被点名之列。大多数执法行动背后有一条共同主线：以原先收集目的之外的方式使用行为数据，或收集了超出运营功能所必要的数据。监管机构并不会因为你的意图是改进模型而非投放广告就网开一面——尽管工程师们往往这样以为。

典型的 AI 团队在面对合规性时的经历通常是这样的：智能体（Agent）已经上线，用户非常喜欢，然后法务部门转来一封邮件，询问系统是否符合 HIPAA 标准。被指派回答这个问题的工程师发现，上下文窗口（context windows）包含 PHI，没有足够粒度的审计日志，LLM 提供商没有签署商业伙伴协议（BAA），而且智能体的工具权限超出了最低必要标准所允许的范围。修复工作需要三个月，并且需要重写部分代码。

这种模式并非特例。根据 2024 年的一项行业调查，78% 的企业高管无法在 90 天内通过 AI 治理审计，而 2025 年有 42% 的公司放弃 AI 项目主要是由于合规性和治理失败——而非技术原因。所构建的内容与合规性实际要求之间的差距是架构层面的，并且在第一轮迭代（sprint 1）中就已经形成。

你的工程师每天都在交付 AI 生成的代码。你的审计人员正在审查变更管理控制——而这些控制是为一个"每行代码都由审批人亲自编写"的世界设计的。两件事同时成立，如果你所在的是受监管行业，这一缺口就是一种你可能尚未充分估量的法律风险。

AI 生成代码的合规认证问题，并非供应商问题——你的 AI 编码工具的 SOC 2 报告并不覆盖你的变更管理控制。这是一个流程认证问题：SOC 2 CC8.1、HIPAA 安全规则变更控制以及 PCI-DSS 第 6 节背后的根本假设是，审批代码变更的人理解代码内容。这一假设已不再成立。

一个 AI 系统将某份求职申请标记为低优先级。候选人提出申诉。法务部门向工程团队询问："请展示模型当时看到的确切内容、检索的文档、触发的策略规则以及生成的置信度分数。"工程师打开日志，发现的是：时间戳、HTTP 200、响应体，以及延迟指标。其余的信息已经消失。

这不是日志记录的失败。按照所有传统标准，日志是完整的。问题在于，应用日志从来就不是为记录推理过程而设计的——而 AI 系统不只是在执行代码，它们做出的是依赖上下文的概率性决策，只有给定决策时刻存在的完整输入上下文，才能被理解。

你的 AI 系统在上午 9 点将一条患者查询路由到了自托管模型。上午 11 点，该模型的 Pod 在部署时重启。请求队列积压，路由器检测到超时，随即回退到你用于通用查询的云端 LLM。请求成功完成，没有告警触发，监控面板一片绿色。而就在这次交互中，受保护的健康信息悄然流向了一个你根本没有签署《业务伙伴协议》的供应商。

这不是假设，而是几乎所有未经专门设计来防范此类问题的 AI 路由栈的默认行为。

当法务团队问"AI 为什么拒绝了这笔贷款申请？"时，你的思维链追踪并不是正确答案。就算你有 1200 个 token 的逐步推理过程也没用。他们需要的是一句能在庭审中站得住脚的话——而现在，大多数工程团队根本不知道如何生成这样的解释。

这就是利益相关者解释鸿沟：工程师对模型行为的理解，与监管机构、高管和法律团队完成工作所需的信息之间的距离。弥合这一鸿沟需要一个独立的架构层——而大多数生产 AI 系统从未构建过这一层。

工程师为多区域 AI 部署做预算时，通常只考虑两个变量：每个区域的基础设施成本和复制开销。而真正被严重低估的，是上线之后才会暴露的三类成本：模型版本不一致导致欧盟集群与美国集群产出不同结果、KV 缓存隔离使 GDPR 区域内每个 token 的生成成本更高，以及重试逻辑将法国用户数据悄悄路由到弗吉尼亚时触发的静默合规违规。

一家德国银行为满足 GDPR 要求，花了 14 个月将一个大型开源模型部署在本地。这并不罕见。真正罕见的是，提出该架构方案的工程师从一开始就理解了合规约束。大多数团队直到事故报告出现才被迫面对这个问题。