调用海外大模型 API 的数据出境合规注意事项

2026-08-05

调用境外大模型 API 时，请求体中的内容会传输至境外服务器，这在中国现行法规框架下构成数据出境行为，可能触发相应的合规义务。理解这一点是企业合规接入的前提。

数据出境合规的法规基础

中国对数据出境的监管覆盖多部法律，核心如下：

法规	核心约束	主要适用场景
《数据安全法》	重要数据出境须经安全评估	所有数据处理主体
《个人信息保护法》第 38–40 条	个人信息出境须满足安全评估/标准合同/认证三选一	处理个人信息的企业
《数据出境安全评估办法》	规定申报触发阈值与评估流程	达到规模阈值的主体
《促进和规范数据跨境流动规定》（2024）	细化免评估情形与负面清单	同上，对中小企业有一定松绑

法规持续更新，以上仅为参考，请以最新官方文件为准，并咨询专业法律顾问。

这里有个坑我见过不少团队踩：把”我们规模小、不是大厂”当成不用管的理由。《个人信息保护法》第 38 条的适用逻辑不是”你多大”，而是”你处理了什么、出境了多少”。哪怕是一个十几人的创业团队，只要你的产品往境外大模型 API 发送的请求里带了用户手机号、订单地址这类信息，且累计处理量达到申报办法里定的阈值，一样要走安全评估。规模小只能让你在”是否达到阈值”这一步大概率不达标，但不能豁免”要不要判断”这个动作本身。

三条合规路径怎么选

个人信息出境目前主要走三条路，选错路径最直接的后果就是流程走到一半发现不适用，白白浪费几个月时间。拿不准的时候先按下面这张表粗筛一遍，再找法务确认：

路径	适用场景	大致耗时	复杂度	适合谁
安全评估申报	达到规模阈值，或涉及重要数据/关键信息基础设施运营者	较长（涉及主管部门审核，具体以官方流程为准）	高，需准备风险自评报告等材料	大规模处理个人信息的平台型企业
标准合同备案（SCCs）	未达申报阈值，但仍处理个人信息出境	相对短	中，需与境外接收方签署标准合同并备案	中小企业、多数 SaaS 场景
个人信息保护认证	集团内部数据流动、跨境关联公司间传输等场景	中等	中，依赖专业认证机构	有集团架构或长期稳定跨境业务的企业

实操中我的建议是：先做”数据分类”和”规模判断”这两步（下文自查清单里有），大概率能把自己筛到”标准合同”这条路上——这也是目前中小团队接入海外大模型 API 最常走的路径，因为流程相对可控、时间成本更低。真到了需要安全评估申报的规模，说明业务体量已经不小，这时候该配的法务合规团队也该跟上了，不能再让技术团队自己扛。

哪些数据出境风险最高

并非所有请求都有同等合规风险，关键在于请求体中的数据类型：

高风险（通常需要完成合规程序才能发送）

用户姓名、手机号、身份证号、位置信息等个人信息
行业监管认定的重要数据（金融、医疗、电力等行业的敏感业务数据）
国家核心数据（原则上不得出境）

中等风险（建议法务确认后再上线）

用户行为数据、设备信息等间接标识符
企业内部业务文档（视行业和内容而定）

相对低风险（仍需评估，但合规负担通常较轻）

纯技术内容（代码、算法描述）且不含个人信息
公开信息的摘要处理
开发测试阶段使用的模拟/匿名数据

判断一条数据落在哪个档位，光看”是不是个人信息”这个二元问题还不够，实操中我通常会再叠加两个维度一起看：

是否可被单独识别到具体自然人：手机号、身份证号这类肯定是；但像”用户在某天下午 3 点访问了某个页面”这种行为片段，单独看很难识别到人，一旦和设备 ID、账号体系拼起来就可能识别到人——所以脱敏要看的是”拼接后能不能识别”，不是单条字段。
是否属于行业主管部门认定的重要数据目录：这个坑在于”重要数据”没有一份全国统一的清单，而是由行业主管部门分别发布认定规则和目录（金融、电信、工业和信息化等领域已陆续有相关规定）。你所在行业如果有主管部门发布的数据分类分级指南，务必对照检查，不要只套用通用的个人信息判断逻辑。

企业合规自查要点

在将业务请求发往境外 API 之前，建议逐项确认：

数据分类：梳理每个 API 调用场景，明确请求体中会包含哪类数据
脱敏评估：是否可以在发送前去除或假名化个人信息？脱敏标准需满足”不可再识别”要求
规模判断：对照《数据出境安全评估办法》，判断是否达到需要申报的数量阈值
合同路径：未达申报阈值但含个人信息的场景，是否已与境外服务商签署标准合同（SCCs）
用户告知：隐私政策是否告知用户数据可能出境处理
日志审计：是否建立调用日志，可追溯哪些数据经过境外服务器处理

这六项自查建议落成一份实际可跑的清单，而不是开会讨论完就束之高阁。我见过比较扎实的做法是：把每个调用海外 API 的业务模块拉个清单，每一行对应一个调用场景，列出”字段清单""是否含 PII""脱敏方案""合规路径""责任人”五列，季度复审一次。这个清单本身不需要多复杂的工具，一张共享表格就够用，关键是要有人真的按季度去核对——很多团队的合规风险不是出在”没做评估”，而是出在”半年前评估过，业务改了字段，评估没跟着更新”。

降低出境风险的技术手段

在完成合规评估的同时，以下技术手段可以降低风险敞口：

最小化原则：只发送模型完成任务必需的最少数据，剔除非必要字段
客户端脱敏：在请求发出前对 PII（个人可识别信息）做正则替换或假名化
本地 embedding + 境外推理分离：将文档向量化在境内完成，只将语义向量发送给境外模型（适合部分 RAG 场景）
使用国内云厂商托管版：数据不出境，合规负担最低（见合规接入路径）

客户端脱敏怎么落地，别只做”删字段”

很多团队一提脱敏就是”把姓名字段删掉”，这远远不够——请求体里经常藏着姓名、手机号出现在自由文本里的情况（比如客服工单描述、用户填的备注），只删结构化字段等于没删。一个更靠谱的思路是在请求发出前跑一层正则 + 规则的联合过滤，示例：

import re

PATTERNS = {
    "phone": re.compile(r"1[3-9]\d{9}"),
    "id_card": re.compile(r"\d{17}[\dXx]"),
    "email": re.compile(r"[\w.-]+@[\w.-]+\.\w+"),
}

def desensitize(text: str) -> str:
    for label, pattern in PATTERNS.items():
        text = pattern.sub(f"[{label.upper()}_MASKED]", text)
    return text

这段代码只是起点，实际用起来要注意三个坑：

正则覆盖不了姓名：中文姓名没有固定格式规律，靠正则基本抓不住，得配合命名实体识别（NER）模型或者维护一个内部人名词库做辅助匹配，纯正则方案在姓名这块必然有漏检。
过度脱敏会破坏模型效果：如果你的业务场景需要模型理解地址做物流类推理，把地址整体打码会导致输出质量下降，这时候可以考虑只脱敏门牌号/详细地址，保留到区县级别，具体粒度需要和法务一起权衡”够不够低风险”与”够不够可用”。
脱敏是发送前最后一道闸，不是唯一一道：脱敏函数本身也可能有 bug（比如正则漏配某个手机号段），所以调用日志里必须留痕，方便事后回溯查漏，这就引出下一个环节。

调用日志该记哪些字段

日志审计不是简单地把请求体全量存下来——那样反而制造了新的数据留存风险。比较合理的做法是只记录”结构化的元信息”而不是原始内容：

调用时间、发起该请求的业务模块/服务名
是否命中脱敏规则、命中了哪几类（phone/id_card/email 等标签，而不是具体值）
目标 API 服务商与调用地区（境内代理转发还是直连境外）
请求体大小、是否走了本地 embedding 分离等技术手段

这样一份日志既能在监管问询或内部审计时说清楚”我们处理了什么类型的数据、走了什么合规路径”，本身又不会因为存储了大量原始 PII 而变成新的风险点。

常见误区

误区一：接入的是合规聚合平台，企业就没有合规责任了
即使通过合规聚合平台接入，企业自身作为数据控制者的义务（用户告知、数据分类、应急预案等）并不转移。平台只能分担技术层面的部分责任。

误区二：数据脱敏后就不算个人信息出境了
有效脱敏确实可降低或消除个人信息出境风险，但”有效”的标准很严格。简单删除姓名字段不等于有效脱敏，需通过专业评估确认不可再识别性。

误区三：只要境外服务商有 ISO 27001 认证，中国合规就满足了
境外安全认证与中国数据出境合规是两套体系，前者不能豁免后者的义务。

误区四：走的是国内代理/中转服务，请求就不算出境了
这是我遇到过争议最大的一个误区。判断出境不是看”谁帮你转发”，而是看数据最终有没有到达境外的服务器并被处理——如果代理只是做转发，请求内容最终仍进入海外大模型的服务端进行推理，这依然构成数据出境，代理本身并不改变这个事实。真正能让数据不出境的，是模型的推理服务本身部署在境内（比如国内云厂商托管的模型实例），而不是转发链路上多加了一层国内节点。

常见问题

内部员工使用工具调用境外 API，需要做数据出境合规吗？
需要。《个保法》的适用不以是否对外服务为标准，只要员工个人信息经由系统出境，即可能触发合规义务。

标准合同（SCCs）和安全评估申报哪个更快？
标准合同路径通常更快，适用于未达申报阈值的个人信息出境场景。2024 年新规对部分情形有豁免，建议与法务早期介入确认适用路径。

开发测试阶段用真实用户数据测 API，有合规风险吗？
有。建议测试阶段使用脱敏或合成数据，避免将真实用户数据发往境外服务器。

如果当前业务规模小，以后扩大再做合规可以吗？
不建议。合规流程（尤其是安全评估申报）周期较长，业务规模扩大后再补做可能面临已产生违规行为的风险。建议在产品设计阶段就引入合规评估。

用境外大模型 API 做多轮对话，聊天历史要不要一起算出境数据？
要算。多轮对话场景下，很多接入方式默认会把之前几轮的上下文一起打包发给模型，这意味着哪怕第一轮没有敏感信息，只要后续某一轮用户提到了姓名或联系方式，整段上下文（包括之前看似”干净”的轮次）在这次请求里都一起出境了。做自查的时候不能只看单轮请求体，要看拼接后的完整上下文窗口。

同一个境外模型服务商，直连和走它在亚太的备份节点，合规义务有区别吗？
从数据出境的判断逻辑看没有本质区别——只要服务器物理位置在境外（不论是主节点还是亚太备份节点），数据同样构成出境。企业该做的合规动作（分类、脱敏、路径选择）不因为对方节点距离近就可以省略，节点距离近带来的只是延迟上的差异，不是合规责任上的差异。

本文仅作技术与合规科普，不构成法律意见。企业请通过合规渠道接入海外模型，具体合规方案请咨询专业法律顾问，并遵守国家数据出境相关规定。