60 篇博文 含有标签「compliance」

影子 IT 曾经意味着营销团队报销 SaaS 订阅，或者工程师私自创建 S3 存储桶。这很烦人，是采购方面的头疼问题，但大部分情况下是可以承受的。影子 AI 也是出于同样的本能——绕过缓慢的官方路径——只不过爆炸半径更大，且进入门槛几乎降至为零。

一名工程师可以在一个下午将 LLM API 调用接入生产工作流。一名支持主管可以在午饭前搭建一个无代码的分流智能体。一名数据分析师可以将一个季度的客户记录粘贴到聊天窗口中，以“快速总结一下”。这些都没有经过审查，没有出现在架构图中，而且你的治理计划无法保护一个它根本不知道存在的系统。

令人不安的是规模。2025 年 UpGuard 的一项调查发现，超过 80% 的员工——以及近 90% 的安全专业人员——在工作中使用未经批准的 AI 工具。你的安全团队在用，你的高管也在用。问题不在于你是否有影子 AI，而在于你是否能看到它。

打开你的智能体产品，开启 VoiceOver，然后发送任意提示词。如果你使用的是典型的带有内联推理过程的流式 UI，那么你在接下来的 30 秒内听到的内容并非你的产品。那是一股汹涌的局部 token 流、单词中间的重排、无人播报的状态变化，以及一段视力正常的用户选择查看、但盲人用户却无法逃避的推理独白。在舞台上演示效果极佳的界面，对于屏幕阅读器来说，是一场以语音形式发起的拒绝服务攻击。

这是 AI 团队中没有人会运行的审计。设计评审批准了流式动画。评估套件测量了回答质量。延迟仪表盘追踪了首个 token 响应时间。但这些工具都没有注意到，让某一群体感到产品快速且贴心的功能特性，却让另一群体完全无法使用。这种疏忽正开始出现在亲自诉讼申请中——过去十年一直在处理针对电商网站无障碍投诉的联邦法院，现在看到的 AI 界面相关投诉正急剧增加，据一家追踪机构报告，仅在 2025 年，同比增幅就达到了 40%。

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。

一个 Prompt 回归在上午 9 点上线。在 Web 应用上，工程师在午饭前就回滚了系统 Prompt，追踪日志随之恢复平静。在 iOS 上，同样的回归存在于 App Store 三周前审核通过的二进制文件中——团队现在必须在两种方案中做出选择：要么在服务端替换 Prompt（这会使商店对用户实际行为的审核失效），要么申请加急审核（这需要花费 24-48 小时，还要消耗一点与平台团队积攒的人情值）。哪种方案都不在操作手册（runbook）里。

这就是部署节奏冲突（deploy cadence collision）：Web AI 功能按照团队的时钟迭代，而移动端 AI 功能则按照平台的时钟迭代。大多数发布流程（release trains）在有人想到“Prompt 是否应该与二进制文件绑在同一辆列车上”之前就已经确定了。结果是税收在悄然累积——审核延迟、不对称的回滚延迟、在重新提交时无法通过隐私审核的未披露 AI 界面，以及一整类移动端工程师修复速度仅为 Web 同行十分之一的 AI Bug。

我最近交流过的一个团队向一家财富 500 强公司的内部法务办公室出售了他们的法律 AI 产品，并在系统提示词中增加了一行：“每一个事实性陈述必须包含对检索源的内联引用。”产品路线图为这种新行为分配了 5% 的 Token 预算缓冲。在该受监管租户上线 60 天后，财务部门标记了每月推理支出激增了 34%。没有人搞坏产品。没有人发布新功能。这项促成交易的合规要求，也悄然改写了其背后的单位经济效益。

这就是检索引用税，几乎每个服务于受监管行业——法律、医疗、金融、有审计约束的企业——的 RAG 系统最终都要支付这笔费用。这笔税收是结构性的，而不是 Bug。它源于引用纪律迫使模型进入了一种不同的生成模式，而且它在客户签署的采购规范中无处可寻。

针对你的智能体记忆层的第一次合规升级，几乎从不以监管机构信函的形式出现。它往往是以你企业级销售工程师发来的一张 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）中就已经形成。