老板问「我们到底有什么安全风险」，安全同事给的答案往往是一串技术名词，听完还是不知道先干什么。这篇换个顺序：先按「谁在动我们的东西、动的是哪一层、出事以后能不能查出来」把风险分成几类，每类给你一个判断标准和一两个可立刻执行的动作，最后配一份自查与留证清单，方便你拿去做成部门任务。
老板问「我们到底有什么安全风险」，安全同事给的答案往往是一串技术名词，听完还是不知道先干什么。这篇换个顺序：先按「谁在动我们的东西、动的是哪一层、出事以后能不能查出来」把风险分成几类，每类给你一个判断标准和一两个可立刻执行的动作。
最后配一份自查与留证清单，方便你直接拆成部门任务。判断标准是用来提问的，不是用来打分的；动作是先做哪一步，不是做完就万事大吉。
先换一个看法：风险不是列表，是分层
把风险按「入口—载体—人员—外部依赖」四层拆开，比按病毒、钓鱼、泄密这种老分类更好排查。原因是老分类按事件命名，出一次新事件就要加一类；分层按责任归属命名，层不变，新事件只是落到某一层里。
同一件事在不同层里叫法不同，管理者只需关心它最后落在哪一层、能不能被现有制度覆盖。比如「员工把文件发到个人网盘」，在入口层是账号权限问题，在载体层是数据流向问题，在人员层是审批缺失问题，三层都要有人认领。
账号与权限：最常见的入口，也最容易被忽略
典型表现：多人共用一套账号、离职后账号还活着、第三方工具拿着长期有效的密钥。这三件事都不算「被黑」，但任何一件都可能让后面所有防护失效，因为出事时你连「是谁干的」都答不上来。
判断标准很简单：能不能在三分钟内回答「谁在什么时间用哪个账号做了什么」。答不上来，说明账号和日志至少有一头是断的，先补断的那一头。
- 拉账号清单把所有能登录系统、能调接口的账号列出来，重点标出管理员类和长期有效的密钥，不用追求格式好看。
- 做权限对照拿清单和实际权限对一遍，看有没有「早就不该有这个权限」的账号，逐个确认保留理由。
- 定清理节奏约定离职、转岗、项目结束时谁来停账号、多久内停完，写进流程里，别靠记得。
不适用的情形：纯内部、无对外接口的小团队可以简化流程，但共用账号这条底线别破，因为它是后面所有排查的前提。
数据流与边界：东西到底发到哪去了
风险不在于「用了外部服务」，而在于不知道自己发了什么、发给了谁、对方留多久。很多团队能说出用了哪几个工具，却说不清每次调用带出去哪些字段，这就是边界失守的起点。
排查顺序：从提示词、上传附件、日志、缓存的顺序走一遍，标出哪些字段是不该出现的。顺序不能反，因为先看缓存容易漏掉源头，先看源头才能判断哪一段该拦。
| 环节 | 要问的问题 | 判断标准 |
|---|---|---|
| 提示词 | 里面有没有客户名、联系方式、内部编号 | 能不能说清哪类内容禁止写进去 |
| 上传附件 | 附件是不是必须整份外发 | 有没有可以只发字段不发全文的做法 |
| 日志 | 日志里有没有记录原始内容 | 留存多久、谁能看、能不能导出 |
| 缓存 | 外部服务方是否留存、留多久 | 对方的条款和你的预期是否一致 |
把「什么能发什么别发」当原则问题单独看，别混在操作细节里。原则层面定不下来的团队，往往会在具体工具上反复纠结，最后谁都不满意。
不适用：数据本身完全公开的场景，可以把重点放在可用性和成本上，到站内价格与模型资料库核对当时的数字即可，不必套用上面的字段级管控。
外部依赖与供应链：你控制不了的那部分
包括中转服务、插件、SDK、外包开发和托管平台，风险点是变更不通知、口径不一致。你这边按旧口径配的策略，对方一改，可能就落空了，而你还以为一切正常。
判断标准：对方换域名、换模型、改条款时，你这边多久能知道，谁负责知道。如果答案是「等出问题才知道」，那这条依赖就属于无人看管状态。
- 给关键外部依赖列清单，写清对接人、变更通知渠道、备选方案
- 把「变更后多久内复核」写进对接约定，不依赖对方主动提醒
- 对涉及数据往来的依赖，定期核对对方条款和你的实际用法是否一致
- 对只用来做测试、无数据往来的工具，降低管理成本，别一视同仁
不适用：一次性、无数据往来的试用型工具，不值得投入同等管理成本；但一旦开始稳定使用并带上业务数据，就该补进清单。
人与流程：制度写没写，写了做不做
常见断点：制度有、培训没做；培训做了、审批还在聊天工具里口头走。问题不在员工不守规矩，而在于规矩没有落在动作上，谁也没法证明自己守了。
判断标准：随便挑一件上周发生的数据外发，能不能调出记录和审批痕迹。调不出来，说明流程还停留在文档里，遇到抽查或纠纷时帮不上忙。
动作：把高频动作（导出、外发、开权限）变成有记录的动作，不必一步到位上系统，先用表单加留痕的方式跑通，再考虑工具化。小团队最容易在这里省钱，也最容易在这里出事。
可发现性：出事之前你能不能先看到
很多风险不是没发生，是发生了没人发现；所以要先问「我们靠什么发现」。这个问题不解决，前面几层的管控都是在假设「不会出事」的前提下运转。
| 观察对象 | 看什么变化 | 先定什么 |
|---|---|---|
| 登录 | 异常时间、异常地点、失败次数 | 由谁复核、多久内响应 |
| 调用量 | 突增、突降、非工作时段 | 阈值大致区间、谁接收提醒 |
| 数据访问 | 批量导出、集中下载 | 哪些操作必须留痕 |
| 外部访问 | 来源是否符合预期 | 发现异常后先联系谁 |
指标不是越多越好，先选出三到五个能持续看下去的。看不过来的仪表盘等于没有，选指标时说清楚「谁看、多久看一次」比选什么指标更重要。
不适用：没有日志留存能力的团队，先解决留存，再谈检测；否则设了阈值也复盘不了，只能看到「有异常」却说不清范围。
留证与响应：别等出事才想顺序
先定角色：谁拍板、谁对外沟通、谁负责留证，别默认是技术负责人一个人扛。一个人同时做三件事，往往三件都做不好，尤其是对外沟通最容易被耽误。
留证范围：会话记录、账单、审批单据、监控截图，重点是带时间和主体信息。没有时间和主体的截图，事后很难被当成有效材料，等于白留。
- 止血先切断还在持续的损失，比如停用账号、断开某条外部依赖，动作要可回滚。
- 确认范围搞清涉及哪些数据、哪些账号、哪些时间点，范围没定之前别急着对外下结论。
- 对外口径由指定的人统一说明，内容以已确认的事实为限，不确定的部分明确说还在核实。
- 复盘把这次暴露出的断点落回前面几层，写成可执行的改进项，而不是一份情绪化的总结。
响应顺序别反过来：一上来就删日志、清账号，会把判断范围所需的材料一并删掉。相关操作细节已经在别的文章里展开，这篇只负责让你知道什么时候该去翻它。
一份可以这周就用的自查清单
下面这份清单按四类整理，建议直接拆成四条任务分给具体的人。不要一次全铺开，按四类各挑一条最扎眼的先改，改完再回来抽查。
- 账号：管理员账号数量、共用情况、离职清理记录
- 数据：外发渠道清单、必脱敏字段、日志里出现过什么
- 外部依赖：关键供应商、变更通知方式、备选方案
- 发现与留证：监控阈值、日志留存时长、留证责任人
- 复盘：上一件数据外发能不能调出记录和审批痕迹
抽查时不用追求全对，重点看有没有「查不出来」的项。查不出来的项就是下一轮要补的断点，比任何评分都更能说明问题。具体数字和对照口径，可以到站内相应页面核对当时的记录。
下一步把这份清单变成一次具体排查：先看账号和外部依赖两类，再回到数据流和留证。站内指南中心有对应的操作步骤和往期文章，按你当前最扎眼的那一层去翻，比从头读一遍更省时间。→常见问题
我们公司不大，这些风险是不是离我们很远？
规模小不等于没人惦记。小团队反而常出现共用账号、没有离职清理、密钥长期不换这几类问题，一旦出事，往往连「谁在什么时候做了什么」都答不上来。起点不用高：先把账号清单和密钥归属理清楚，再按需补日志留存。
网络安全和数据安全是不是一回事？
不是。网络安全更偏「系统能不能被攻进来、通信有没有被截」，数据安全更偏「数据在哪、谁能看、留多久、怎么证明」。两者会重叠，但排查时的动作不一样。概念上的区别站内已有专门梳理，这篇按企业排查顺序来讲，不重复辨析。
用外部 AI 服务就一定不安全吗？
关键不在用不用，而在你发了什么、对方怎么存、能不能删。把不该发的字段挡在入口，比一刀切禁用更现实。具体哪些内容算不该发，属于另一篇的原则问题，操作层面可以先从「上传前看一眼附件和提示词」开始。
要不要先买一套安全产品再谈管理？
不建议。先搞清账号、数据流向和外部依赖清单，再决定缺哪一环用什么补，否则很容易买了工具却没人看告警。工具类目和价格那类信息站内有专门页面，需要时再去核对当时的数字。
出事了第一步该做什么？
先止血再查原因：切断还在外传的通道、改掉可能已泄露的凭据，然后固定证据，最后才是对外沟通。最忌讳的是第一时间删日志、删文件，把能证明问题的材料自己清掉了。
