你多半是在两种情况下翻到这篇的：一是团队有人问「把客户资料贴进对话框算不算出事」，二是真出了事想找个参照物，看看别人当时是怎么被发现的、怎么收场的。这篇不给你打包票式的结论，只把有代表性的几类案例拆成「起因—暴露路径—代价—当时的纠正动作」四段，再给你一份自查清单和出事后头两小时的处置顺序。数字类的部分一律引导你去站内页面看当时的行情和口径。
你多半是在两种情况下翻到这篇的：一是团队里有人问「把客户资料贴进对话框算不算出事」，二是真出了事想找个参照物，看看别人当时是怎么被发现的、怎么收场的。这篇不给你打包票式的结论，只把有代表性的几类案例拆成「起因—暴露路径—代价—当时的纠正动作」四段，再给你一份自查清单和出事后头两小时的处置顺序。
先把话说在前面：所谓「著名案例」，重要的不是记住谁翻了车，而是记住翻车的形状。同样是「AI 泄露了我的数据」，落到训练语料、对话留存、插件链路、员工误操作哪一类，决定了你该找谁、先关哪个开关、留哪份证据。数字类的部分一律引导你去站内页面看当时的行情和口径，本文不写死任何具体数值。
先分类：AI 隐私争议到底有哪几种
很多人一上来就问「有没有出过事」，这个问题没有信息量。有用的问法是「如果出，会从哪个口子出」。按暴露路径分，常见的就是下面四类，同一句抱怨落进不同类别，处置动作完全不同。先把类别认清楚，再谈案例，否则你只是在收集恐慌。
| 暴露路径 | 典型起因 | 你该找谁 | 止损难度 |
|---|---|---|---|
| 训练语料抓取 | 公开数据被抓进训练集 | 模型供应方 | 高，撤回几乎不可能 |
| 对话内容被留存或审阅 | 默认开启的改进计划、人工标注 | 服务提供方与你的账号设置 | 中，可关闭但要先找到入口 |
| 第三方插件与中转链路 | 工具、插件、转发服务经手数据 | 你的集成方与中转方 | 中，切断链路即可 |
| 内部把敏感数据贴进对话框 | 图省事直接粘贴 | 你自己的团队 | 低，可控但最容易复发 |
按后果又能分三层：只涉及可识别个人信息、涉及商业机密与合同条款、涉及监管问询或集体投诉。前两层基本靠内部止损和谈判解决，第三层就要靠台账和记录说话，没留痕的一方往往吃亏。判断标准很简单——这件事如果被写进邮件发给客户，你会不会心虚；会，就至少属于第二层。
案例是怎么被发现的：几条常见的暴露路径
翻这些案例会发现，真正「被外部发现」的其实是少数，大多数是先在自己人眼皮底下露出来的。发现路径本身就能反推出你该布哪些检查点。下面按被发现的先后顺序排，越靠前的越隐蔽，也越值得优先排查。
- 先出现在日志里：提示词、报错堆栈、缓存内容被写进不该写的地方，然后被有权限的人看到；这是最容易被忽略、也最容易修的一条
- 第三方先发现：合作方、外包标注团队、插件开发者比你先看到内容；一旦跨出你的账号边界，追责和召回都变难
- 公开可检索：内容进了公开仓库、公开分享链接或公开训练集；这类只能靠事后撤销，而且经常撤不干净
- 客户或员工先投诉：这种发现方式最慢，往往等你知道时，影响面已经扩散了一轮
排查顺序建议从「谁有权限看这条链路」倒推，而不是从模型那边查起。模型是不是记性太好，你几乎查不出来；但谁能在后台看到你的内容、插件把数据转发到了哪里，是能查清的。查不清的部分，本身就说明你不该往那条链路里发这类数据。
代价从哪几块来，以及当事人当时做了什么
代价通常不是一次性的。它至少分三块，而且时间尺度完全不同：合同违约与客户流失是短周期，监管问询与整改期是中周期，内部信任修复是长周期。只算第一块的人，往往在第二块上被打得措手不及。所以别问「赔多少」，要问「要花多久才算翻篇」。
复盘这些案例，纠正动作有明显共性，基本都是四件事：第一，立刻切断数据流；第二，扩大范围排查同类调用，别只处理被曝光的那一次；第三，补一份数据流向台账；第四，把「谁有权批准把这类数据发出去」写进流程，并且指定到具体角色。前三件是止血，第四件才是防复发。
如果你已经隐约觉得自家可能踩线，但说不清属于哪一类，先到 /safety 看分区口径，把监管和合规的判断标准对齐；再拿着 /data-boundary-audit 一份一份对照整条链路。别凭印象拍脑袋判断，印象在事后复盘里最不值钱。
对照自己的场景做一遍自查
- 列入口把最近一个月里所有「数据被发进外部模型接口」的入口列出来，包括插件、IDE 补全、客服机器人、翻译工具、会议纪要工具这些不显眼的入口。验证方法：随便找一天，看浏览器历史和后端出站日志，比凭记忆列的全。
- 标边界凡是能定位到具体个人、能拼出完整业务信息、或者带合同条款的内容，一律按「需要批准」处理，不按「顺手就发」处理。验证方法：挑三条最近发过的内容，问自己能不能说出批准人是谁。
- 留台账把每次对外发送的数据类别、用途、批准人、时间记成一页台账。验证方法：让另一个同事不看聊天记录，只靠这页纸复述一遍发生过什么。
- 定例外纯公开素材、已通过脱敏流程且不可复原的数据，可以走简化流程，但要有脱敏记录支撑。验证方法：随机抽一份走简化流程的数据，看它有没有对应的脱敏记录。
这套自查不适用的情况也要说清楚：如果你的团队根本不对接任何外部模型接口，全部自建自用，那重点就不在「入口」，而在内部权限和日志保留，自查表要换一张。别照搬别人的清单。
真出事了：按这个顺序走，别乱
出事当下的反应，往往比事情本身更影响结局。最常见的错误顺序是先开会追责、后处理数据，等口径统一完，能关的东西已经被扩散了。下面这个顺序是止血优先，责任问题往后放。
- 第一步是止血而不是追责：先停掉对应调用通道与共享链接，再谈是谁发的
- 第二步是圈定范围：时间区间、账号、数据类别、可能的接收方，四要素写清楚，方便后面每一步复用
- 第三步是留证而不是清理：截图、会话记录、账单、审批记录按 /dispute-evidence-keep 的口径留存，别急着删
- 第四步才是对外沟通：先内部对齐口径，再决定是否通知合作方或走监管申报
出事头两小时，删东西是最贵的动作，关开关是最便宜的动作。
关于是否要对外通知、按什么口径通知，各家监管和场景差别很大，不建议照抄别人的做法。判断标准到 /safety 分区相关页面核对当下的口径，把监管申报和合作方通知拆成两个独立决定来做。
下一步想知道自己常用的服务在数据留存和调用链路上大致是什么风格，可以先看站内的对照与检测页面，再回头改自家的自查清单，比空想有效。→常见问题
我用了中转站或者第三方客户端，会不会更容易被记录？
风险点不在「是不是中转」，而在链路上多了几个能看你内容的人。判断方法是把请求路径画出来，标出每一跳谁持有密钥、谁能读日志。到 /relay-api-security 和 /data-boundary-audit 对照一遍，比笼统担心有用。
模型厂商说不用我的数据训练，就可以放心贴吗？
这句话一般只覆盖训练用途，不等于不记录、不人工抽检、不保留一段时间用于风控。要看的是留存期限、人工审阅范围、以及是否与你所在行业的合规要求冲突。判断标准去 /safety 分区和 /key-safety 看当时的说明。
出了事我该先删记录还是先截图？
先截图留证，再按流程清理。记录一删，责任边界和损失范围都说不清，后面申诉、理赔、对客户解释都会被动。留存口径参考 /dispute-evidence-keep，处置顺序走 /data-security-incident-response。
