数据出境安全评估主要针对的是

很多企业卡在同一个问题上：我们只是调用海外模型接口、只是把日志同步到境外、只是让海外同事看一下数据，这算不算要申报数据出境安全评估？网上说法互相打架，业务又等不起。这篇不谈法条背诵，只给一套可执行的判断顺序：先看你是不是适用主体，再看数据流向是不是出境，最后看触发条件和豁免空间，并说明什么情况下这套判断不适用。

很多企业卡在同一个问题上：我们只是调用海外模型接口、只是把日志同步到境外、只是让海外同事看一眼数据，这算不算要申报数据出境安全评估？网上说法互相打架，业务又等不起。这篇不谈法条背诵，只给一套能照着走的判断顺序。

顺序分五步：先看你是不是适用主体，再看数据流向是不是出境，接着看数据属于哪一类，然后对照触发条件，最后看有没有豁免空间。每一步都给判断标准和落地动作，末尾说明什么情况下这套自查不成立。

先分清：评估针对的是「谁」

评估不是按公司规模一刀切，而是按你在这条数据链路里扮演的角色分。同一个业务，研发团队、云服务商、境外母公司各自被问的问题可能完全不同。先把自己归类，再谈后面的事。

数据处理者

自主决定数据处理目的和方式的境内主体，绝大多数做 AI 业务的公司先归到这一类

关键信息基础设施运营者

被认定属于关键信息基础设施的运营方，门槛和关注度比一般数据处理者更严

受境外控制或影响的境内主体

股权、决策、数据调取上受境外机构实际影响的主体，容易被纳入更宽的审视范围

境外接收方

真正拿到数据的那一头，是子公司、母公司、外包商还是云厂商，定性差别很大

• 纯境内闭环、从不向境外提供任何数据、境外也无法远程调取的团队，通常不落入评估范围，但仍要留意后续业务变化
• 境外有子公司、有外包标注团队、有云上跨区同步的，别只看签约主体在不在境内，要看数据实际流向谁
• 渠道商、代理商代为对接境外服务的，也要把最终接收方找出来，中间多一层不代表责任转移
• 被收购或引入外资后架构变了的主体，建议重新走一遍角色判定，不要沿用旧结论

再分清：什么动作才算「出境」

「出境」不只是把文件传到境外服务器。物理存储在境内、但境外主体能访问或调用，也可能被算作出境。这一节的判断标准只有一条：数据有没有被境外主体实际获得或可能获得。

这里有个常被忽略的边界：用户主动把内容发到境外工具，和企业系统自动传出去，定性并不一样。前者更接近个人自主行为，后者是企业数据处理行为。但如果你在产品里默认接了境外服务、用户只是点了下按钮，那就别拿「用户自己发的」当挡箭牌。这类边界要结合具体业务去核对。

第三层：哪些数据被划进敏感范围

同样是出境，传一条测试文本和传一整年的对话日志，量级完全不同。判断时按三条线分别看：个人信息规模、是否含敏感个人信息、是否涉及重要数据。三条线里有一条踩中，后面的操作就要更谨慎。

• 个人信息规模：按涉及的自然人数量分级，不是按文件大小，去 指南中心（/guides） 对照当时的口径
• 敏感个人信息：生物识别、医疗健康、金融账户、行踪轨迹这类，单独出现就要单独评估
• 重要数据：看行业目录和主管部门要求，不能自行认定「我们不算重要数据」
• 匿名化与去标识化：处理过不等于一定不算，要看能不能被重新识别、结合了哪些辅助信息
• 接收方所在地：同样一批数据发往不同法域，后续义务可能不同

给一个自查表结构，横向三列就够用：数据类型、数量级、接收方所在地。每一行填一个实际的数据流，别用「大概」「一部分」这种模糊词，填不出具体数字就说明链路还没摸清。

典型触发场景清单

AI 类业务绕不开下面几条路径，先用清单做初筛。要说明的是，清单只用于初筛，最终口径要去站内安全与合规分区逐项核对，不要拿这张表当结论。

1. 路径一：调用海外模型 API确认请求体里带了哪些字段、对方是否用于训练、有没有留存策略、能不能走不开留存的通道。
2. 路径二：使用海外向量库或托管平台确认数据的物理存储区域、备份策略、索引里是否含原始文本，以及平台方能否被境外调取。
3. 路径三：境外团队标注与质检确认人员归属、访问方式、是远程访问境内系统还是数据先落地境外，两者定性不同。
4. 路径四：把会话日志做全球分析确认日志里有没有个人信息、聚合程度、分析平台在哪、导出后是否还能还原到个人。

每条路径至少要能答出三个问题：接收方是谁、传输通道是什么、有没有留存。答不出来的，就先把链路审计补上，别急着下结论。

可豁免、可不适用的情况怎么写清

豁免是最容易出事的地方。很多人把「我以为不用」当成豁免，结果被问的时候拿不出任何依据。写豁免时，前提条件和反例要一起写，缺一个都别当成成立。

一套可照做的自查顺序

把前面几节收成一条线，按顺序走，不要跳步。跳步最常见的后果是：结论下得太早，后面发现问题又得推翻重来。

1. 第一步：画数据流图从输入到落库，标出每个环节的所在地、参与方、传输方式，画不出图就说明链路没摸清。
2. 第二步：标注数据类别与数量级逐条数据流打标签，区分个人信息、敏感个人信息、重要数据，数量级写具体区间。
3. 第三步：判定接收方主体属性接收方是境内还是境外、是子公司还是第三方、有没有被境外调取的可能。
4. 第四步：对照触发条件初判把前面信息套进判断线，得出「需要评估」「需要进一步确认」「暂不适用」三类结论中的一类。
5. 第五步：写成内部备忘把结论、依据、未决问题、负责人写成一页纸，随业务变化更新，别只留在某个人脑子里。

想让这套顺序更好用，可以先到 中转站导航（/sites） 和 指南中心（/guides） 把常用服务的接入方式和数据流向资料看一遍，对着自己的链路逐项打勾。

什么情况下这套判断帮不上忙

有几种情况，内部自查只能作为输入，不能当最终意见。提前说清边界，比事后补救省事。

• 业务横跨多个法域、需要当地律师出具正式意见的，自查结论只能喂给律师当背景材料
• 监管口径更新、行业另有专门要求的，以主管部门和站内最新资料为准，别拿旧结论套新业务
• 数据流本身没画清楚、连谁在什么时候拿到什么都说不清的，先补链路审计，不要急着判适用性
• 涉及重大合作、并购、对外披露的场景，内部备忘不能替代正式合规意见

换句话说，这套顺序的定位是「帮你把问题问对、把材料备齐」，不是「替你回答所有问题」。如果需要横向比较不同服务商在数据流向和接入方式上的差异，可以到 排行榜（/rankings） 和 价格追踪（/price-watch） 核对当时的公开信息，作为内部讨论的参考。

留痕与持续复核

数据流不是一成不变的。接了新服务、业务量涨了、组织架构调了，原来的结论就可能不成立。所以留痕的目的有两层：一是内部管理有据可依，二是被问到时能自证过程。

模板不用复杂，一张表加一份流程图就够用。关键是每次业务变化都要有人主动去改，而不是等被问到了才回头补。留痕的用途是对内管理和应对问询，不是对外承诺，写的时候注意分寸。