用大模型API调用国内模型、数据链路全在境内，还算不算数据出境？

用大模型API是否涉及数据出境，取决于请求最终落在哪个区域的推理节点，而不是取决于你是否用了API这种调用方式。如果API中转服务商与模型推理节点都部署在境内、请求和返回内容不经过境外服务器、日志也留在境内，就不构成向境外提供数据；一旦路由指向境外模型或境外节点，无论中间隔了几层中转，都属于数据出境。 数据安全和数据出境是两道不同的题，不能互相替代。数据安全问的是数据会不会泄露、滥用、被越权访问，考验的是加密、权限、日志与供应商管理；数据出境问的是数据有没有被传输、存储到境外，或者被境外机构实际访问到，考验的是链路位置与合规申报。一个平台可能安全做得很好却仍然构成出境，也可能链路全在境内但权限管理很差。 判断出境的法定口径是“是否向境外提供”，而不是服务器物理位置看起来像不像国外。按照《个人信息保护法》和《数据出境安全评估办法》的思路，个人信息被传输到境外、存储在境外，或者虽存放在境内但境外主体可以访问，都要按出境处理；纯境内闭环的采集、传输、计算与存储不触发出境安全评估。是否达到申报门槛，还要看主体类型、数据量级与行业监管要求。 典型链路里只有一类不涉及出境。客户端直连境外模型API是最直接的出境；客户端先到境内中转、再由中转转发给境外模型，仍然是出境，中转只是多了一跳；客户端到境内中转、再由中转把请求分发到境内模型，整条链路闭环在境内，不涉及出境。选型时该画的应该是这张链路图，而不是合同里的承诺措辞。 只聚合国内模型、把路由表限制在境内节点，是从架构上降低出境风险的做法，但它成立有前提。“模型厂商在国内”不等于“推理节点在境内”，同一家厂商可能同时有境内机房和海外节点，部分聚合平台也会把请求调度到海外机房做容量补充，或者把日志同步到境外灾备。核验时要看实际落点与调度策略，而不是只看模型归属地。 中转服务商自己是数据处理链条上的一环，这决定了即使判定不出境也要审它。请求内容、调用的模型名、时间戳、Key 与账号信息都会在你和中转平台之间流转，因此需要确认日志存在哪个区域、留存多久、是否用于训练或二次分析、能否按需删除。链路不出境只解决了出境问题，日志被随意取用属于另一类风险。 数据本身的敏感程度决定另一半合规义务，这一半不因链路在境内而消失。上传身份证号、手机号、病历、金融账户、员工信息等个人信息，即便模型推理全程在境内，也要满足告知同意、最小必要、目的限定等要求；涉及重要数据或受行业监管的数据，还要先看主管部门是否允许经由第三方API处理。 使用 OpenAI 兼容协议只说明接口格式一致，与数据是否出境没有必然联系。兼容协议的价值在于迁移成本低、SDK 与工具链可以复用，换供应商时不必重写调用层；但如果请求最终被打到境外端点，出境风险照旧存在。反过来，兼容格式指向国产模型的境内端点，也不会因为写了“兼容”两个字就变成出境。 多模型路由是出境风险最容易失控的环节。平台如果允许同一个 Key 同时调用境内外模型，就必须给出显式的路由约束，例如模型白名单、按请求标签区分、按环境隔离，让处理敏感数据的业务只能命中境内模型；否则一次自动降级、重试或故障切换，就可能在你不知情的情况下把请求送出境外，事后连审计记录都对不上。 企业核验是否涉及出境，问三个问题就够：推理节点在哪个区域、中转与日志服务器在哪个区域、链路上有没有任何跨境路由或数据同步。愿意给出节点说明、签署数据处理协议、提供调用日志审计的供应商，才能把“不出境”从口头承诺变成可验证的事实，也才经得起内部合规和外部问询。 既要用境外模型能力又要控风险的团队，通常把策略放在网关层而不是靠人工约束。敏感字段在到达中转前先脱敏或做本地替换，只有非敏感任务才允许走跨境模型，同时对每一次调用记录去向、模型与数据标签，便于事后还原哪些数据去了哪里。这样做不能免除出境合规义务，但能把暴露范围压到可控的一段。 只聚合国内模型就不算出境这个结论有明确边界。它不适用于业务主体本身部署在境外、不适用于必须调用境外模型能力的场景，也不适用于把境内数据同步到境外做备份或分析的做法。把这些边界写进选型标准与验收条款，比事后争论某次调用算不算出境更省成本，也更容易在监管问询时拿出证据。