作者：王红燕 沈杨雨岚 汪媛雅 刘珂诗 章雨璐 张轩诚
《中国人工智能企业出海百问百答》第四部分
三十一、如何选择海外云服务商（AWS、Azure、GCP）以满足数据驻留要求？
【风险等级提示：绿线问题】
数据驻留（Data Residency）是指数据处理者基于法律法规、行业监管或业务合规要求，将数据限定在特定地理区域或司法管辖区内进行存储与处理的合规安排。在全球数据主权竞争加剧、各法域跨境监管日趋严格的背景下，为跨境企业客户提供云架构合规意见时，选择境外云服务商须置于我国数据跨境监管体系之下审慎评估。
一、明确服务商的地理区域分布与“数据边界”承诺
满足数据驻留的首要前提，是云服务商在目标司法管辖区具备成熟的本地数据中心，并能在合同与架构层面提供严格的“数据不出域”承诺。AWS全球节点覆盖最广，适合多国复杂合规需求；Azure在欧美合规布局深厚，适合GDPR要求较高的业务；GCP以AI/大数据能力见长，在欧美、亚太布局完善。
由于我国对增值电信业务实行外资准入限制，AWS、Azure、GCP均未以境外主体身份直接在中国大陆运营公有云服务，而是通过与本地持牌运营商合作的方式落地：亚马逊云科技由光环新网、西云数据分别运营北京、宁夏区域，Azure由世纪互联运营世纪互联区域[1]。
企业选择“中国区域”实质上是与境内运营实体而非美国母公司订立服务协议，这一安排对数据处理者身份认定、合同管辖及CLOUD Act的可及性均有实质影响，是评估数据驻留方案时不可忽略的关键环节。
二、评估长臂管辖风险与美国《云法案》的穿透应对
AWS、Azure和GCP的母公司均设于美国，不可避免地受到美国《澄清域外合法使用数据法》（CLOUD）的管辖[2]。根据该法案，即使数据物理存储在欧盟、新加坡或东南亚，美国执法机构在特定条件下仍有权要求母公司调取其控制下的境外服务器数据。为降低此类长臂管辖冲突风险，企业在选型时应重点审查厂商的技术隔离与法律防护机制。
建议优先选择支持“客户自持密钥”（BYOK）及端到端密文存储的架构，使云厂商即便被迫响应执法调取，也仅能提供无法解密的密文，从而在技术层面建立有效抗辩。同时，建议审查云服务商在特定地区是否采取与当地机构合资或由独立本土实体运营的模式，以隔断直接的司法管辖链条。
三、审查数据处理协议（DPA）与跨境传输合法化机制
数据驻留并不意味着完全杜绝数据的跨境访问，日常运维、跨国协同或故障排查中极易发生“远程调阅视同数据出境”的情形，因此云服务商合同体系对跨境传输机制的支持至关重要。
就GDPR而言，若业务触及欧盟居民数据，需确认云服务商DPA中是否内嵌欧盟委员会新版标准合同条款（Commission Implementing Decision (EU) 2021/914），并审查其是否落实了欧洲数据保护委员会在Schrems II判决后发布的《补充措施建议》[3]。
就中国法而言，若涉及将境内收集的数据交由境外区域处理，或境外云服务需远程访问境内数据，企业须依据《数据安全法》第二十一条建立的数据分类分级制度识别是否触及“重要数据”，并结合《个人信息保护法》第三十八条、第四十条及《促进和规范数据跨境流动规定》[4]，判断是否落入安全评估、标准合同备案或个人信息保护认证的适用范围，同时留意该规定对非CIIO年累计向境外提供不满10万人个人信息等情形的豁免安排。企业在签署服务协议及DPA时，应明确约定数据存储与处理的具体Region，并在架构上禁用跨区域的自动备份、灾备复制及日志异地传输功能。
三十二、在多云架构下，如何确保数据在不同云平台间的流转符合当地法规？
【风险等级提示：绿线问题】
数据从云A复制、备份、日志汇聚等至云B，或境外运维人员远程查询境内实例，都可能构成提供或传输数据。建议企业建立以“数据流”为对象的治理机制，具体而言：
第一，绘制动态数据地图。[5]按数据来源地、数据主体所在地、类别敏感度、处理目的、存储区、访问地点、接收方、分处理者，逐条登记云间API、消息队列、对象存储复制、模型训练集、提示词、日志和向量库流向等；对个人信息、重要数据、金融医疗等受监管数据设置标签和禁止路由。适用法不能只按服务器所在地判断，还应同时审查域外适用和行业规则。
第二，对每条流转建立法律依据和传输工具。受GDPR约束的个人数据离开欧洲时，需适用充分性决定、标准合同条款或约束性公司规则等，并控制后续转移；必要时开展传输影响评估并采用补充措施。[6]中国境内数据流向境外云或被境外远程调用，应判断是否触发安全评估、标准合同或认证，并完成告知、单独同意和个人信息保护影响评估；云区、接收方、用途或保存地改变时，应重新评估或备案。[7]新加坡等法域则要求境外接收方提供可比保护。[8]
第三，把规则固化到架构与合同。采用“区域化数据平面+全球化控制平面”，默认本地存储和本地推理；[9]跨云传输经合规网关，执行目的校验、最小化或脱敏、传输加密、客户持有密钥、DLP、访问审批和不可篡改日志。云合同应锁定可用区域、分处理者名单和变更通知，约定未经授权不得跨区或再转移、政府调取通知、审计权、事件通报、返还删除和退出验证等，并统一各云安全基线。
第四，实施持续控制。以“策略即代码”阻断违规部署，定期核对实际流量与备案、合同和隐私告知，开展跨云灾备演练与删除验证；监管规则、云区域、分处理者或模型数据用途变化时自动触发复评。[10]无法通过合法传输机制、合同和技术措施满足当地要求的，应停止该数据路径，而不能仅以“已经加密”替代合规判断。[11]
三十三、 针对欧盟《数字运营弹性法案》（DORA），AI金融科技企业需要做哪些系统准备？
系统准备不应停留在制度文件，而应转化为以下可验证能力：
企业可按“30天完成适用性判断与资产盘点、60天补齐日志和事件手册、90天完成一次全链路恢复演练”的节奏推进。DORA合规的核心，不是增加一套纸面制度，而是确保AI系统在故障、攻击或供应商中断时仍可被识别、隔离、恢复，并能够向管理层和监管机构说明。
三十四、如何在系统架构设计阶段实现“隐私设计”（Privacy by Design）？
【风险等级提示：绿线问题】
隐私设计（Privacy by Design，PbD）由安·卡沃基安于上世纪90年代提出[19]。GDPR第25条将其中的“数据保护通过设计及默认设置”上升为法定要求，PbD由此从最佳实践转变为强制性义务。该条要求控制者在确定数据处理方式时采取适当的技术与组织措施（如假名化），落实数据最小化等数据保护原则，并确保默认情况下仅处理实现特定目的所必需的个人数据。违反GDPR第25条可能依据GDPR第83条第4款被处以行政罚款，同时企业落实隐私设计的情况亦将影响监管机关对整体合规成熟度及处罚幅度的评估[20]。对出海AI企业而言，在系统架构设计阶段嵌入隐私设计，既是法律合规要求，也是降低后续整改成本的重要手段。
数据最小化。 架构设计初期即应评估各功能模块是否确有必要收集个人数据，仅收集实现特定目的所必需的信息，非必要字段不予采集，额外信息宜采用“可选填”方式获取，并尽可能降低数据精度。例如，仅需判断用户是否年满18岁时，无需收集完整出生日期，可采用二元判断逻辑。
假名化与匿名化。 GDPR第25条将假名化列为典型措施。架构设计时应考虑用户标识符分离存储、令牌化处理、日志脱敏及差分隐私等技术，并注意区分“假名化”（仍属于个人数据）与“匿名化”（原则上不再适用GDPR）的法律边界[21]。
数据加密。 除传输层（TLS）和存储层加密外，可结合业务场景对邮箱、手机号等字段实施列级加密，并加强密钥管理；AI产品处理训练数据或推理数据时，可评估客户端加密等方案，降低服务端直接读取明文数据的风险。
访问控制与审计日志。 系统应建立基于最小权限原则的访问控制机制（如RBAC、ABAC），确保仅授权必要人员访问个人数据。审计日志应记录访问主体、时间及行为，并尽量避免记录个人数据。GDPR第30条要求控制者建立数据处理活动记录，企业可结合系统日志实现自动化管理。
数据主体权利响应。 架构设计阶段即应预留数据主体权利响应接口，支持数据导出、更正、删除及撤回同意等功能；删除操作应覆盖业务数据库，并结合备份系统、日志系统及第三方处理方建立相应的数据删除或清理机制[22]。
数据生命周期管理。 应在架构设计阶段明确各类数据的保存期限，对用户上传数据、对话记录及注销账号数据建立自动清理机制，并确保备份数据保留期限与整体数据治理策略保持一致。
第三方集成。 集成云服务、大模型API或分析工具时，应通过合同明确第三方的数据访问范围、安全措施及责任分工，并通过API过滤等机制确保仅传输必要数据；涉及欧盟个人数据跨境传输的，还应落实SCCs或充分性认定等合法传输机制。
可参考的技术标准。 ISO/IEC 31700-1:2023《消费者保护——产品与服务的隐私设计》为系统开发生命周期嵌入隐私设计提供了可操作框架，企业可据此建立内部研发流程[23]。
三十五、海外业务是否需要独立部署机房？本地化部署与SaaS模式在合规成本上差异多大？
【风险等级提示：绿线问题】
随着企业数字化业务向海外市场拓展，系统架构与云基础设施的合规问题逐渐成为跨境经营的重要法律议题。实践中，企业常面临“是否必须在境外独立部署机房”以及“本地化部署与SaaS模式何者更具成本优势”的选择。就多数法域而言，数据合规的核心并非数据物理存储地点，而是数据跨境传输是否合法、数据处理活动是否具有适当的法律依据，以及企业是否采取充分的安全保障措施。因此，在不存在强制数据本地化要求的情况下，“SaaS模式+区域化云部署”通常是兼顾合规性、成本与业务扩张效率的最优路径。
一、海外业务并不当然要求独立部署机房
从涉外合规角度看，企业是否需要在海外独立部署机房，应根据目标市场的数据保护法律、行业监管规则、客户合同要求以及数据类型进行具体判断，而不能将“海外运营”与“数据本地化”直接等同。
以欧盟为例，《通用数据保护条例》（GDPR）并未普遍要求个人数据必须存储于欧盟境内。企业可以将个人数据传输至第三国，但应满足充分性决定、标准合同条款（SCC）或其他合法跨境传输机制，并履行相应的数据保护义务。由此可见，欧盟监管逻辑主要强调“跨境传输的合法性与保护水平”，而非单纯要求数据物理存储于欧盟境内[24]。
新加坡《个人数据保护法》（PDPA）同样采取风险与保护水平导向的监管模式。企业向境外传输个人数据时，应确保境外接收方提供与PDPA相当的保护水平，但法律并未一般性要求企业必须在新加坡境内设置独立服务器或机房[ 25]。
因此，对于一般性互联网产品、AI软件或企业SaaS服务而言，若云服务商能够提供适当的数据区域隔离、加密、访问控制及跨境传输机制，企业通常无需为每一个海外市场单独建设物理机房。
二、本地化部署与SaaS模式的合规成本差异
从成本与合规管理角度观察，全球统一SaaS、区域化云部署和客户本地化部署分别对应不同的风险与成本结构。
SaaS模式具有基础设施集中管理的优势，企业可以统一实施数据保护政策、安全管理制度、DPA、SCC及供应商管理机制，因而初始投入及持续运营成本相对较低。但其主要风险在于数据跨境传输、境外远程运维、第三方子处理者以及日志、备份数据的跨境流动。
区域化云部署则在全球统一架构基础上，将数据按照欧盟、亚太、中东等区域进行隔离，可以在降低跨境传输频率的同时保持云基础设施的规模效应。其合规成本高于统一SaaS，但通常低于完全本地化部署。
本地化部署的合规优势在于能够最大程度降低跨境数据传输风险，尤其适用于金融、医疗、政府及关键基础设施等高监管行业。然而，企业需要承担当地云资源、灾备体系、安全认证、运维团队及监管审计等持续成本，且不同国家的技术架构可能形成“合规孤岛”，显著增加长期运营复杂度。
此外，欧盟《数据法案》进一步强化云服务的可迁移性与降低供应商锁定要求，并推动数据及应用迁移成本下降。这意味着企业在选择SaaS服务时，还应将数据可迁移性、退出机制和供应商锁定风险纳入合规与商业决策[26]。
编辑|王佳佳
[1]参见亚马逊云科技、微软Azure中国区官方运营说明；
[2]18 U.S.C. § 2713；CLOUD Act（2018年3月23日生效）；
[3] 欧委会2021/914号执行决定；EDPB Recommendations 01/2020；
[4]《数据安全法》第二十一条；《个人信息保护法》第三十八条、第四十条；《促进和规范数据跨境流动规定》（2024年3月22日施行）；
[5]https://www.finereport.com/blog/article/69210cb1d2527e0eb776a2b3
[6]参见 Regulation (EU) 2016/679 (GDPR), arts. 28, 32, 44-49；European Commission, “Rules on international data transfers”；
[7]参见《中华人民共和国个人信息保护法》第38、39、55条；《促进和规范数据跨境流动规定》第7-11条；
[8]Personal Data Protection Commission Singapore, Advisory Guidelines on Key Concepts in the Personal Data Protection Act, Chapter 19 (Transfer Limitation Obligation), revised 1 October 2021；
[9]https://developer.baidu.com/article/detail.html?id=7091016；
[10]https://www.php.cn/faq/1587636.html，https://blog.csdn.net/FuncInk/article/details/159366714；
[11] https://www.cnetsec.com/dfaq_wordpress/?p=43336；
[12]Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector（下称“DORA”），规定自2025年1月17日起适用，OJ L 333, 27.12.2022, p. 1；ELI: http://data.europa.eu/eli/reg/2022/2554/oj；
[13]DORA, Articles 2(1)-(2), 3(19), 3(21), 3(23) and 31-44。DORA将支付机构、电子货币机构、投资公司、加密资产服务提供商等列为“金融实体”，并将提供持续数字及数据服务的企业纳入ICT第三方服务商范畴。普通ICT供应商通常通过金融机构依据Article 30提出的合同、审计、事件协助及退出要求承担义务；被依Article 31指定为关键ICT第三方服务商后，方进入欧洲监管机构的专项直接监督框架；
[14]DORA, Articles 5(2), 6, 8, 11 and 12；Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, Articles 2-16 and 24-26，OJ L, 2024/1774, 25.6.2024；ELI: http://data.europa.eu/eli/reg_del/2024/1774/oj。DORA第3条将“信息资产”界定为值得保护的信息集合，并将“ICT资产”界定为金融实体使用的软件或硬件资产，因此将模型、数据集、接口及云组件纳入统一资产与依赖关系管理，属于对AI技术栈的具体化适用。
[15]DORA, Articles 17-20；Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024（重大ICT事件分类标准及实质性阈值），ELI: http://data.europa.eu/eli/reg_del/2024/1772/oj；Commission Delegated Regulation (EU) 2025/301 of 23 October 2024, Article 5（初始通知：重大事件认定后4小时内且最迟自知悉事件后24小时内；中期报告：初始通知后72小时内；最终报告：中期报告或最近一次更新报告后一个月内），ELI: http://data.europa.eu/eli/reg_del/2025/301/oj；Commission Implementing Regulation (EU) 2025/302（统一表格、模板及程序），ELI: http://data.europa.eu/eli/reg_impl/2025/302/oj。
[16]DORA, Articles 24-27。Article 24(6)要求至少每年对支持关键或重要职能的全部ICT系统和应用开展适当测试；Article 25列举漏洞评估、源代码审查、情景测试、性能测试、端到端测试及渗透测试等方式。威胁导向渗透测试的识别标准和实施要求另见Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025；ELI: http://data.europa.eu/eli/reg_del/2025/1190/oj。
[17] DORA, Articles 28(3)-(4) and 30；Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024（ICT第三方合同信息登记册标准模板），ELI: http://data.europa.eu/eli/reg_impl/2024/2956/oj；Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024（支持关键或重要职能的ICT服务合同政策），ELI: http://data.europa.eu/eli/reg_del/2024/1773/oj；Commission Delegated Regulation (EU) 2025/532 of 24 March 2025, Articles 4-6（分包监测、重大变更通知、异议及终止机制），ELI: http://data.europa.eu/eli/reg_del/2025/532/oj
[18]Commission Delegated Regulation (EU) 2024/1774, Articles 15-17。Article 16要求ICT系统在首次使用及维护后进行测试和批准，并对生产环境中的非故意更改或恶意操纵采取控制；Article 17要求所有软件、硬件、固件、系统及安全参数变更均经过记录、测试、评估、批准、实施和验证，并设置回退程序及紧急变更的事后复核机制。
[19]Cavoukian, A., Privacy by Design: The 7 Foundational Principles (2011), https://www.ipc.on.ca/wp-content/uploads/Resources/7foundationalprinciples.pdf
[20]Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (General Data Protection Regulation), Arts. 25, 28, 30 & 83, https://eur-lex.europa.eu/eli/reg/2016/679/oj
[21]European Data Protection Board (EDPB), Guidelines 01/2025 on Pseudonymisation (public consultation draft), https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en
[22]Information Commissioner's Office (ICO), Designing products that protect privacy, https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/designing-products-that-protect-privacy/
[23]ISO/IEC 31700-1:2023, Consumer protection — Privacy by design for consumer goods and services — Part 1: High-level requirements, https://www.iso.org/standard/84977.html
[24]European Commission, What rules apply if my organisation transfers data outside the EU?，https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/obligations/what-rules-apply-if-my-organisation-transfers-data-outside-eu_en；
[25]Personal Data Protection Commission Singapore, Data Protection Obligations，https://www.pdpc.gov.sg/overview-of-pdpa/the-legislation/personal-data-protection-act/data-protection-obligations；
[26]European Commission, Data Act Explained，https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained；
本文版权归「科技法全球合规观察」所有，如需转载，请联系下方秘书号洽谈授权。
如果您有相关法律咨询需求，
欢迎添加团队秘书号：
