很多团队接 AI 工具时只关心模型好不好用，等出事才发现：有人把客户名单粘进对话框、有人把内部文档丢给中转站、有人拿个人账号跑公司数据。真出事之后往往既说不清泄露了什么，也不知道该先停哪一步。这篇不讲概念，而是按案例类型拆开讲：哪类场景最容易翻车、事前怎么自查、发现苗头后按什么顺序处理，并告诉你哪些结论要回站内页面核对当时的数字与口径。
很多团队接 AI 工具的时候，关注点全在模型好不好用、回答快不快，真正出事才发现问题根本不在模型上。有人把客户名单粘进对话框，有人把内部文档丢给来路不明的接口，有人拿自己的个人账号跑公司数据。真出事以后，常见状态是两句话：说不清到底泄露了什么，也不知道该先停哪一步。
这篇不绕概念，按案例类型拆开讲：哪几类场景最容易翻车、事前有哪些能看到的信号、发现苗头后按什么顺序处理。涉及具体数字和口径的地方，一律让你回站内相应页面核对当时的版本，因为这类信息变得快，写死在文章里反而误导人。
案例翻车都集中在哪几类场景
把公开可见的泄露与违规案例归归类，会发现绝大多数不是被黑客攻破，而是内部人一次顺手操作。区别只在于：数据发出去之后，你有没有能力发现、有没有能力收回。下面按场景列，重点是判断标准，不是罗列故事。
- 把能直接定位到人的原始数据（客户名单、合同扫描件、身份证件信息）粘进对话窗口：风险不在于模型会不会记住，而在于这条数据已经离开你可控范围，回不来了。
- 把内部代码、架构图、财务口径丢给来路不明的第三方接口：问题出在传输链路和对方的留存策略你无法验证，接入前先去 /sites 看这个中转站的可信度口径再决定。
- 员工用个人账号处理公司活：出事时既没有审计记录，也拿不到账号控制权，交接和离职环节最容易断链，可对照 key-rotation-least-privilege 做权限拆分。
- 把 AI 生成的内容不加核对直接对外发布：这属于合规型翻车，跟数据处理风险是两码事，别混进同一次排查里。
| 场景 | 主要风险点 | 接入前该确认什么 |
|---|---|---|
| 原始客户数据贴进对话框 | 数据离开可控范围 | 这类数据能不能进提示词，先定死 |
| 内部代码发给第三方接口 | 传输与留存不可验证 | 去 /sites 看可信度口径 |
| 个人账号干公事 | 无审计、无控制权 | 账号归属与权限边界 |
| AI 内容直接对外发 | 合规与事实性风险 | 发布前的核对责任人 |
事前能看到的早期信号
大部分事故不是毫无征兆，而是信号出现了没人当回事。把信号分成现象、技术、组织、外部四层来看，会更容易定位到该找谁。下面这份是排查起点，不是完整清单。
- 现象层
- 某个工具突然被大量同事同时使用，但没人说得清数据发到哪去了，先按 data-boundary-audit 的思路把提示词到日志的链路走一遍
- 技术层
- 本地日志、上报系统、埋点里出现不该出现的字段，先看 log-redaction-retention 里列的日志红线，别等审计来了才删
- 组织层
- 没人负责回答「这份数据能不能发出去」，说明缺一个明确的判断入口，建议直接把 data-masking-privacy-limits 当内部讨论底稿
- 外部层
- 合作方或平台侧通知你账号异常、调用异常，先按 api-error-triage-order 的排除顺序确认是不是自己的问题
判断标准很简单：这四层里任意一层出现了你答不上来的问题，就说明当前没有可用的数据边界，先别急着扩大使用范围。如果你所在团队本来就没有专职安全岗，这四层可以先由技术负责人兼任，但必须指定到人。
按这个顺序做一次自查
自查最怕东一榔头西一棒子，今天查账号明天查工具，最后什么都没结论。建议按「数据—入口—账号—流程」这个顺序走，因为后面的判断依赖前面的结论。下面每步都给了验证方式。
- 盘数据把公司数据分成「绝对不能外发」「脱敏后可外发」「公开可用」三档，分类标准参考 key-safety 里对数据边界的划分；验证方式是随便挑三条真实数据，看能不能被两个不同的人分到同一档
- 盘入口列出团队在用的所有 AI 工具和接口，逐个确认走的是官方还是中转；官方部分去 /official-api 核对口径，中转部分去 /sites 看收录情况；验证方式是名单里有没有人答不上来自己用的哪个
- 盘账号谁手里有 Key、谁在用个人账号干公事，对照 key-rotation-least-privilege 做一次最小权限和轮换梳理；验证方式是尝试收回一个离职或转岗同事的权限，看要几步
- 盘流程把上线前的检查动作固定成清单，可直接用 prelaunch-security-checklist；验证方式是让没参与制定的人照着清单走一遍，看会不会卡住
这四步不需要一次做完，但顺序别乱。先盘数据再盘入口，是因为你只有知道哪些数据敏感，才能判断某个入口该不该留。
发现苗头后的隔离顺序
发现异常之后，最常见的错误是边查边停，顺序颠倒。下面这套顺序的核心原则是先切断再取证，取证留痕的具体做法可以参考 dispute-evidence-keep。按影响面分优先级，别平均用力。
- 先切断再取证：停掉可疑 Key、收回共享账号、暂停相关工具接入，再回头留证据，顺序反了容易把可追溯的记录冲掉。
- 按影响面分优先级：先处理能直接对外的客户数据，再处理内部文档，最后处理代码和配置。
- 把「谁通知谁」写死：技术侧、法务侧、业务侧各自要知道什么、什么时候知道，避免消息只停在一个群里。
- 把时间点记下来：什么时候发现、什么时候停的、谁做的决定，这些在后续说明情况时比事后回忆靠谱得多。
把案例变成日常习惯
案例看完就忘，是这类文章最没用的地方。真正有价值的做法是把案例压缩成几个可以反复用的动作，接新工具时问一遍，季度复盘时推一遍。下面这几条门槛低，团队小也执行得起。
- 新工具接入前固定问三个问题：数据发到哪、对方怎么存、出事谁负责，答不上来就先别接。
- 每季度挑一条本文里的案例类型做一次桌面推演，比念一遍制度文件有用，推演的结论要落到具体责任人和动作上。
- 把站内 /safety 当常驻入口，新政策和新口径优先看那里，而不是靠群里转发的截图。
- 明确不适用边界：这套自查面向办公与研发场景的常规使用，涉及受监管行业数据处理时，仍要以行业主管部门要求为准。
判断这套习惯有没有落地，看一个指标就够：团队里随便找个人，能不能在三十秒内说出自己手头这份数据属于哪一档、能不能外发。说不出来，说明前面几步还停在纸面上。
下一步先别急着改流程，花十分钟到站内 /sites 把你团队正在用的中转站逐个过一遍，确认可信度口径；再对照 /official-api 看官方部分的口径差异。这两页的信息会更新，遇到具体数字和收录变化，以当时页面为准。→常见问题
我们公司规模小，也需要看这些案例吗？
需要。小团队的问题往往不是制度缺失，而是没人专门管这件事，一个人顺手把数据发出去就没人拦得住。哪怕只有几个人，也建议把「哪些数据绝对不能外发」写成一句话贴在群里，再指定一个人负责回答能不能发。
案例里说的这些泄露，靠脱敏是不是就没事了？
不一定。脱敏能降低直接识别到人的风险，但拼接口径、上下文信息、时间戳组合起来仍可能反推身份，而且脱敏后的数据一旦外发你同样失去了控制权。具体能解决哪些、还剩哪些风险，可以对着 data-masking-privacy-limits 逐条过。
发现数据可能外发了，第一件事该做什么？
先止损，再复盘。停掉可疑账号和 Key、暂停相关工具接入，然后立刻固定证据：调用记录、时间点、涉及的数据范围。顺序反了容易把可追溯的记录覆盖掉。技术侧动作可参考 key-leak-response-runbook，举证部分看 dispute-evidence-keep。
