多数团队不是没做安全，而是不知道自己漏了哪一块：模型 API 在谁手里、数据发到了哪、离职后 Key 还在不在。这份清单不给结论只给动作，按顺序走一遍就能定位缺口；看完能判断哪些项必须立刻补、哪些项可以排队做。
多数团队不是没做安全，而是不知道自己漏了哪一块：模型 API 的 Key 在谁手里、业务数据发到了哪个服务、有人离职后那把 Key 还在不在跑。这些问题单靠问人往往问不齐，得按顺序对照着查一遍。
这份清单不给结论，只给动作。从资产盘点开始，到数据边界、权限日志、事件响应，四步走完基本能定位缺口。看完你至少能判断：哪些项必须本周补掉，哪些项可以排队做，以及哪些项在你的场景里根本不用做。
第一步：先把资产和责任人盘出来
没有资产清单，后面的检查项全部落不了地。你要盘的不是一份清单，而是三张能互相对上的表：在用的模型服务与中转站、实际持有 Key 的人和系统、存了业务数据的内部系统。任一张缺失，就先补这张再往下走。
- 在用的模型服务与中转站：每个服务写清用途、调用方、谁在用；
- 持有 Key 的人与系统：人、服务账号、CI 流水线都算持有者；
- 存了业务数据的内部系统：知道数据在哪，才能判断它有没有可能被送出去。
每张表都要有责任人和复核周期，只写团队名不算数——离职、转岗、换供应商是这张表最常见的失效点。如果问不出完整清单，别急着上技术手段，先按付款记录反查：谁在为什么服务付钱，通常比逐个问人更快补齐。盘完之后，到 中转站目录（/sites） 和 厂商与平台目录（/providers） 核对在用的服务是否都在册，没在册的单独标记。
第二步：确认数据边界，别只看合同
数据边界不是一句「我们签了保密协议」就完事，落点是「谁在什么条件下能看到这条数据」。判断标准跟用了哪家服务关系不大，换供应商不代表风险消失，只是换了暴露面。
| 数据类型 | 能否出内网 | 能进哪类服务 | 默认判断 |
|---|---|---|---|
| 公开资料 | 可以 | 任意可用服务 | 低风险 |
| 内部文档 | 视情况 | 仅内部或已评估的服务 | 需写清条件 |
| 客户数据 | 原则上不出 | 走单独评审流程 | 高风险 |
| 个人敏感信息 | 不出 | 不进入外部调用 | 直接标红 |
重点核对两个常被忽略的出口：日志和缓存。很多泄漏不是模型看到了什么，而是中间层把请求体记下来了。所以查边界时要顺着链路走：请求从哪发出、经过哪几跳、哪一跳落盘、落盘的东西谁能看。
涉及跨境或境外服务的，先到 安全与合规术语对照（/ai-dict/category/safety） 把口径对齐，再去问法务，否则双方说的「出境」可能不是一件事。至于具体哪些服务在什么条件下符合要求，这块没有静态答案，按站内资料库当时的记录去核对。
第三步：权限最小化与日志留痕
权限和日志是清单里最容易被做成形式的两项。判断标准很直接：一把 Key 是不是只做一件事，日志能不能回答「谁调的、调了什么类型的数据、什么时候」。
- 拆 Key按项目、按环境拆开，共用一把的直接标红。拆完检查一件事：任意一把 Key 泄露，影响面是否可控。
- 换人流程离职或转岗时，先建新 Key 并验证服务正常，再吊销旧 Key，最后核对账单有没有异常调用。顺序反过来容易断服。
- 日志三问拿一条真实调用记录去问：谁调的、调了什么类型的数据、什么时候。答不上来的项算未通过。
- 定留存周期留存多久没有统一答案，取决于你的行业与合同要求；写清楚依据，别抄别人的数字。
如果你的日志系统只能看到调用次数和耗时，看不到调用主体和数据敏感度，那它在事件响应里的价值非常有限。这种情况优先补的是标记字段，而不是换一套更贵的日志平台。
第四步：出事前先演练一遍
事件响应不是写一份厚厚的预案，而是验证一件事：半夜发现问题时，能不能在一小时内找到能拍板的人，并知道先关什么。判断标准是「这套流程能不能复述给不在场的同事」，讲不清就说明分工没定死。
- 把「发现异常→确认范围→吊销与切换→对外沟通」写成带责任人和时限的短流程，贴到能随手看到的地方；
- 演练只走前两步也算有效，重点是验证找人链路通不通，而不是流程有多完整；
- 提前约定留什么证据：调用记录、账单、会话截图，事后补通常补不全；
- 每季度或每次人员变动后跑一遍，没人跑就等于没有这套流程。
什么情况下这份清单不适用
这份清单默认你有一套对外调用模型服务的业务。如果你的情况不在这个范围里，照单全做是浪费，甚至会把精力压到不重要的项上。
- 纯个人使用、不涉及客户或员工数据的场景，全量走这套没必要，挑权限与日志两项即可；
- 已经有成熟等保或行业审计流程的团队，把这份当交叉核对表用，冲突处以你已通过的审计口径为准；
- 完全离线私有化部署的内部系统，数据边界那一节的多数项可以跳过，但权限与事件响应仍然要做；
- 还没开始用任何外部模型服务的团队，先盘资产，边界和日志可以等有实际调用再补。
需要说明的是，合规要求会随行业和地区变化，清单里给的是动作顺序，不是合规结论。真正的判断依据要结合你所在行业的监管口径，以及合同里对数据处理的约定。具体到某个服务的当前定价、限流和数据处理规则，去 价格与变更追踪（/price-watch） 核对当时的数字，别用记忆里的版本做决策。
下一步把这四步里你答不上来的那一项挑出来，先去 指南中心（/guides） 找对应的排查顺序，再回到 中转站目录（/sites） 核对在册服务，通常一轮就能定位最容易出问题的环节。→常见问题
这份清单多久跑一次比较合适？
常规项按季度过一遍，权限与责任人表在每次人员变动后单独复核一次。频率不是关键，关键是每次结果有记录、能对比上一次，否则跑十遍也看不出变化。
自查发现漏了，要不要先停服务？
先判断数据是「已经流出去」还是「有机会流出去」。前者按事件响应走，后者通常可以在正常节奏里修补，不必一刀切停服。拿不准的时候先按高风险处理，代价通常更小。
没有专职安全岗的小团队怎么落地？
把五节拆开分给不同的人各领一节，谁领谁签字，比一个人全包更容易执行。清单本身不做技术检测，靠的是问答和翻记录，不需要专业工具。
