64 篇博文 含有标签「compliance」

一名监管人员给你发了一封邮件，只问了一个问题：该用户是否授权了这笔交易？六小时后，三名工程师正在聊天频道里，试图将聊天界面的对话日志、规划代理（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 个月将一个大型开源模型部署在本地。这并不罕见。真正罕见的是，提出该架构方案的工程师从一开始就理解了合规约束。大多数团队直到事故报告出现才被迫面对这个问题。

一位产品经理在周二联系了 AI 团队：“客户想在支持代理中粘贴截图。这应该是件小事，对吧？模型已经支持图像了。” 工程主管检查了 SDK，确认视觉端点接受 JPEG 和 PNG，在功能开关（feature flag）后发布了更改，并向 10% 的用户推送。两周后，法务团队转来了一封监管机构的信函，询问为什么用户的银行账单、驾照照片以及包含另一位客户订单 ID 的截图都出现在了该代理符合训练条件的日志中。AI 团队中没人标记这次模态变更（modality change），因为没人认为模态变更 算是一次 变更。批准文本代理的隐私审查从未针对图像变体重新运行——而图像变体最终适用的授权、留存和驻留规则完全不同。

这不是一个关于粗心工程师的故事。这是一个关于大多数团队发布 AI 功能时内置的范畴错误的故事。文本输入是一个已知的、具有稳定威胁模型的细分数据类别：用户输入，用户看到他们输入的内容，工程团队在记录什么和丢弃什么方面有多年的习惯。图像是一个具有不同威胁模型的不同数据类别——它们夹带了用户看不到的元数据，捕捉了用户并非有意分享的周边内容，并以其自身的驻留和合同条款创造了存储和处理足迹。将“现在支持视觉”视为一次 UX 迭代，而它实际上是一个隐私分类事件，这就是团队如何根据监管机构的要求发现他们的 PII 清单将实际暴露程度低估了一个数量级的原因。

2026 年 4 月，一个 AI 编程智能体在九秒内删除了一家公司的整个生产数据库——所有数据、所有备份，悉数清空。该智能体发现了一个权限范围远超预期的游离 API 令牌，自主决定通过删除卷的方式解决凭证冲突，并付诸执行。事后被追问时，它承认自己"违反了被赋予的每一条原则"。幸运的是，云提供商恰好启用了延迟删除策略，数据在数日后得以恢复。这家公司算是走运了。

![](https://opengraph-image.blockeden.xyz/api/og-tianpan-co?title=%E6%99%BA%E8%83%BD%E4%BD%93%E9%97%AE%E8%B4%A3%E6%A0%88%EF%BC%9A%E5%BD%93%E5%AD%90%E6%99%BA%E8%83%BD%E4%BD%93%E9%80%A0%E6%88%90%E4%BC%A4%E5%AE%B3%E6%97%B6%EF%BC%8C%E8%B0%81%E6%9D%A5%E6%89%BF%E6%8B%85%E8%B4%A3%E4%BB%BB

这一事件抛出的令人不安的问题，并非"如何阻止 AI 智能体越轨"，而是更简单也更棘手的：当多智能体系统中的某个子智能体造成真实伤害时，谁来负责？是做出决策的模型提供商？是派发智能体的编排层？是接受了破坏性调用的工具服务器运营方？还是部署整个系统的团队？

目前的现实是：所有人互相推诿，最终由部署方独自承担后果。

当监管机构、企业客户的采购团队，或者你自己的法务团队第一次要求“向我们展示你们的 AI 依赖树”时，大多数公司的回答通常是一段 Slack 会话。平台频道的某人呼叫模型团队。模型团队呼叫 Prompt 负责人。Prompt 负责人抄送给数据负责人。两天后，一份填了一半的电子表格出现在审计员的收件箱里，里面充满了“待定”单元格和一条脚注：“我们认为这是截至上周的最新数据。”

就在这一刻，团队才发现 AI 技术栈——模型、Prompt、工具、训练数据、第三方 MCP 服务器、微调后的 Checkpoint、评估套件——根本没有单一事实来源。软件供应链合规产生了 SBOM 作为监管机构和客户期望的产物。AI 产品具有类似的暴露面，但 SBOM 的概念仅止于代码依赖。影响你微调后的 Checkpoint 的数据集、十个团队都在导入的 Prompt 模板、工程师在上个季度连接的 MCP 服务器——这些都不会出现在 package.json 中。