作者：王红燕 沈杨雨岚 汪媛雅 刘珂诗 章雨璐 张轩诚
《中国人工智能企业出海百问百答》第四部分
三十六、针对网络中断风险，如何设计灾备机制以满足目标国的业务连续性要求？
大模型与AI服务跨境落地过程中，网络中断不仅会导致服务停摆，还可能因未满足目标国对“网络韧性”（Cyber Resilience）的监管要求而面临行政处罚或违约诉讼。建议从合规指标、技术架构、数据跨境备份、演练通报四个维度统筹设计灾备（DR）机制，具体如下：
一、明确法定合规指标：RTO与RPO
目标国法规通常会对关键业务或AI基础设施的中断时长设定硬性指标，企业须据当地要求确定恢复时间目标（RTO）与恢复点目标（RPO）：
(一）关键领域（金融、医疗AI等）：需根据监管强制义务达到RTO/RPO接近于零的“实时容灾”或“双活”级别[1]。
二、部署“多云+边缘”的弹性技术架构
为防止出口带宽中断或单一供应商宕机导致系统瘫痪，架构应具备自动故障转移与降级能力：
三、规范数据本地化备份与跨境同步
灾备的核心在于数据恢复，但备份链路必须兼顾目标国的数据主权要求：
四、落实定期演练与法定通报义务
(一）定期灾备演练：制定业务连续性计划（BCP），至少每年开展一次实战化网络中断切换演练，留存完整日志（结合WORM存储）作为合规审计证据。1.向监管机构报告：中国《关键信息基础设施安全保护条例》第十八条要求运营者发生重大网络安全事件时向保护工作部门、公安机关报告[5]；DORA第19条要求金融实体向主管机构报告重大ICT相关事件，遵循“初报-中期报告-最终报告”的分级流程[6]。
2.向受影响用户通知：上述条文均不涵盖用户通知义务，需另行援引《个人信息保护法》第五十七条或GDPR第33及34条[7]。
五、小结
灾备机制设计应以“目标国最严标准”为基准，在合规指标层面区分关键、普通业务，在技术架构层面兼顾冗余与离线降级能力，在数据层面确保本地化与出境合规前置，并在演练与通报层面区分“监管报告”与“用户告知”这两条独立的法定路径。
三十七、使用开源模型（如Llama）进行商业化部署，如何遵守开源协议（如GPL、Apache 2.0）的传染性风险？
【风险等级提示：绿线问题】
使用开源模型进行商业化部署时，企业应先区分模型权重、推理代码、训练框架、数据集及部署组件，不能因项目被称为“开源”便推定各部分均可自由商用。例如，Llama系列通常适用Meta自行制定的社区许可证，并非当然适用GPL或Apache 2.0；不同版本可能设置署名、再分发、用途和衍生模型等条件，因此应以实际版本的许可证为准，建立逐项许可清单。大模型涉及代码、参数和数据等多类客体，传统软件许可证难以当然覆盖全部要素。[8]
所谓“传染性”，主要指GPL的著佐权机制：当企业修改GPL代码，或将其与自有代码结合形成衍生程序并对外发布时，可能需要继续以GPL许可相应程序，提供对应源代码，并保留版权、修改及许可证声明。最高人民法院相关研究认为，GPL的效力原则上及于受保护程序本身以及其修改、衍生程序，但不当然扩张至仅与其进行数据交换的独立程序。[9]在“罗盒案”中，法院亦根据代码能否独立、是否构成整体发布等因素判断GPL适用范围。[10]因此，企业不能机械地认为采用动态链接、API调用或容器隔离即可排除风险，而应结合代码修改程度、模块独立性及交付方式进行实质审查。
Apache 2.0属于宽松型许可证，通常允许闭源商用，不要求企业将自研代码公开；但再分发时仍应提供许可证副本，标明原文件修改，保留版权、专利、商标及归属声明，并按要求处理NOTICE文件；同时，其授予专利许可，并规定提起特定专利诉讼时相关专利许可可能终止。[11]
实践中，企业应建立模型及软件物料清单，记录来源、版本、许可证、修改情况和交付场景等；在立项、集成和发布前开展许可证兼容性审查，对GPL等强著佐权组件与闭源核心模块设置清晰边界；[12]在采购、外包及合作合同中至少约定开源披露、侵权保证、整改和审计责任。对于微调权重、蒸馏模型等，还应结合具体许可证判断其是否属于衍生成果，避免直接套用传统软件规则。[13]
三十八、 海外系统的日志留存期限应设置为多久？不同国家（如欧盟、日本）对日志存储期限有何规定？
【风险等级提示：绿线问题】
日志是系统安全审计、威胁溯源和数据合规的重要依据，但“存多久”并非越长越好——留存过短可能导致安全事件无法追溯，留存过长则可能违反隐私保护法中的数据存储限制原则。不同类型日志（如访问日志、安全日志、审计日志等）承担的功能不同，其留存期限通常也应区别设置。海外系统面对多法域管辖，日志留存期限的设置需要在网络安全合规与个人数据保护之间取得平衡。
欧盟：GDPR的“必要期限”原则，无固定时长。GDPR第5条第1款(e)项规定，个人数据的保存形式应允许识别数据主体的时间不超过处理目的所必需的时间。换言之，日志中包含IP地址、用户ID等个人数据的，其留存期限必须与留存目的相匹配——安全审计、故障排查、法律合规等不同目的对应不同的保存期限，超过必要期限即可能违反GDPR。[14]荷兰数据保护机构亦指出，GDPR并未规定统一的日志留存期限，企业应根据处理目的自行确定合理期限，无明确期限或无限期保存均可能违反存储限制原则。[15]实践中，企业通常根据日志类型和处理目的实行差异化留存策略，访问日志一般短于安全审计日志。
美国：行业监管与安全框架并行，无统一联邦标准。美国联邦层面并无统一的日志留存期限规定，具体要求主要取决于行业法规和安全框架。FTC《保障措施规则》要求受监管金融机构自记录创建之日起至少保存两年；[16]《健康保险可携性和责任法案》要求相关记录保存至少六年；NIST SP 800-171等安全框架则建议企业根据风险评估制定日志保留策略，实践中不少组织将90天以上作为安全运营的基准。[17]
新加坡：《网络安全法》要求至少三年。 新加坡《网络安全法》第29条规定，关键信息基础设施运营者及其他适用主体应保存与网络安全事件相关的记录，自事件发生之日起不少于三年。2024年修订后的《网络安全法》进一步扩展了监管范围，加强了对云服务及供应链安全的监管要求。[18]
日本：无统一法定期限，遵循必要原则。 日本《个人信息保护法》（APPI）未对系统日志设定统一的法定留存期限，企业应根据处理目的确定合理的保存期限，并在目的实现后及时删除或匿名化处理。对于第三方提供记录等法律要求保存的记录，个人信息保护委员会（PPC）规定原则上应保存一年。[19]
韩国：依据处理规模区分1至2年。 韩国《个人信息保护法》要求个人信息处理系统的访问记录保存一年以上；处理5万人以上数据主体信息或处理敏感信息的，应保存两年以上。[20]
综上，日志留存期限不存在统一标准，企业可从以下方面综合确定：一是识别日志是否包含个人数据（如IP地址、用户ID等），据此适用GDPR等隐私法的存储限制原则；二是满足目标市场的最低法定要求（如中国不少于6个月、新加坡不少于3年、韩国1至2年等）；三是结合安全运营需要合理确定留存期限，对访问日志、安全日志、审计日志等实施分类管理；四是建立自动删除或匿名化机制，在达到保存期限后及时清理相关数据。建议通过日志管理制度、数据保留政策及数据处理活动记录（RoPA）统一明确各类日志的留存期限，并定期开展审查和更新。
三十九、如何防止通过云服务商的控制台操作被当地监管认定为“非法远程维护”？
【风险等级提示：绿线问题】
云服务控制台同时承载账号权限、系统控制和数据访问功能。境内技术人员通过控制台查看日志、调用密钥、导出备份或修改安全策略，可能已实际取得对境外系统和数据的访问、复制或控制能力。
因此，监管判断通常不只关注数据存储地点，还会审查境外登录人员的身份、账号权限范围及其是否能够改变系统运行状态。控制台权限一旦覆盖数据库快照、日志、密钥、备份或安全策略，相关操作便可能同时触发数据跨境和网络安全义务，并进一步引发监管处罚风险。
以欧洲规则为例，境外集团公司或服务商被允许访问当地个人数据，可能构成向第三国“提供数据访问”；但同一控制者的员工临时在境外登录，并不当然构成跨境传输。关键不是登录地点，而是访问者是否属于另一个控制者或处理者。[21]英国监管机构也明确将允许境外组织远程访问英国系统中的个人信息视为受限制传输。[22]
企业不能只靠“仅用于技术支持”声明免责，至少应建立四道控制。
第一，账号隔离。当地公司、集团总部和云服务商应分别建号，禁止共用Root或全局管理员账号。
第二，工单先行。高权限操作必须绑定故障编号、审批人、操作目的和有效时段，采用JIT临时授权，到期自动回收。欧盟针对部分NIS2适用主体的实施规则已经要求，对服务商远程接入设置控制，并原则上仅在获得授权、限定维护期间后开放。[23]
第三，数据面隔离。运维人员默认只能查看脱敏指标，不得直接读取业务明文、导出日志或下载快照；确需访问时，应另行完成跨境评估和传输安排。
第四，证据留存。企业应保存登录IP、地理位置、命令记录、屏幕录像、审批工单和处置结果，确保能够还原每一次操作的人员、目的、范围和持续时间。
即使没有实际下载数据，只要境外账号长期具备读取、复制或修改能力，企业就很难证明远程维护受到有效约束。合规设计的目标，不是事后解释“没有滥用权限”，而是让权限架构和操作记录共同证明：未经授权，任何人都无法进入系统。
四十、系统架构如何支持“数据主权”功能（例如，沙特的数据必须在境内处理，无法出境）？
【风险等级提示：绿线问题】
随着中国企业通过SaaS、云计算、人工智能等数字化服务拓展海外市场，数据主权（Data Sovereignty）已成为跨境业务合规的重要问题。所谓数据主权，是指国家基于管辖权要求，对境内产生的数据在收集、存储、处理、访问及跨境传输等环节实施控制。对于沙特等数据监管趋严的国家而言，中国企业不能仅依靠传统全球化IT架构开展业务，而需要通过系统架构设计确保当地用户数据在境内完成存储和处理，避免因数据库同步、云服务调用、人工智能模型处理、日志上传或远程运维等环节造成未经授权的数据出境。沙特《个人数据保护法》(PDPL)明确要求个人数据处理活动应采取必要安全措施，并对个人数据向境外传输设置限制条件[24]。
从系统架构角度，企业可参考云计算领域广泛采用的“控制平面（Control Plane）与数据平面（Data Plane）分离”的架构理念。该架构中，控制平面主要负责系统整体管理、身份认证、软件发布等非数据处理功能；数据平面则负责应用运行以及用户数据的存储和计算。云计算平台通常通过控制平面与数据平面的逻辑分离，实现全球统一管理能力与区域化资源隔离能力的结合[25]。具体而言，中国企业总部可以保留全球统一的软件版本管理、产品配置及技术研发能力，但沙特用户产生的数据应进入独立的沙特数据区域，包括位于沙特境内的应用服务器、数据库、备份系统及日志系统。例如，当用户注册地或服务区域被识别为沙特时，系统应自动将相关个人数据存储至沙特境内节点，并通过访问控制策略禁止数据库复制、备份同步或日志传输至中国或其他境外服务器。该区域化架构符合沙特云计算监管规则对于数据存储位置、安全控制以及访问管理的要求[26]。
除数据库存储外，企业还需重点关注人工智能服务、日志管理和运维访问等隐性数据跨境风险。对于包含个人信息的AI应用场景，例如智能客服、文本分析、人脸识别等，如果用户输入数据被传输至境外模型进行推理，即可能构成个人数据跨境处理。因此，企业应优先采用本地化AI架构，即在沙特部署AI计算节点，仅允许模型参数或软件能力进行同步，禁止包含个人数据的输入内容离开沙特。同时，企业应确保应用日志、错误报告、监控数据不自动上传至境外分析平台，对于必须由中国总部提供技术支持的场景，应采用数据脱敏、权限审批和操作审计机制，确保境外人员无法直接访问原始个人数据。相关安全控制要求亦符合国际信息安全管理标准ISO/IEC2700及隐私信息管理标准ISO/IEC2770的要求。
在跨境业务运营层面，中国企业还需要建立数据访问治理机制，以解决“数据留在当地，但总部仍需运营管理”的现实需求。通常情况下，企业可以允许中国总部访问系统运行状态、服务指标、错误代码等非敏感信息，但不得直接访问沙特用户数据库。对于确需访问的数据，应通过审批流程、最小权限控制、匿名化处理以及完整审计记录实现合规管理。例如，中国研发团队可以查看经过脱敏处理后的系统日志，但不得直接查询包含姓名、身份信息、联系方式等个人数据的数据库记录。对于金融、医疗、政府等高度监管行业，企业还应考虑采用沙特本地主权云、本地数据中心或混合云架构，以降低监管风险[27]。
编辑|王佳佳
[1]Regulation (EU) 2022/2554 (DORA), Articles 11–12.；
[2]ISO/IEC 27031:2011, Guidelines for information and communication technology readiness for business continuity；
[3] ISO 22301:2019,Business continuity management systems；
[4]NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems；
[5]《关键信息基础设施安全保护条例》（国务院令第745号）第十八条;
[6]Regulation (EU) 2022/2554 (DORA), Article 19；
[7]《中华人民共和国个人信息保护法》第五十七条；General Data Protection Regulation (GDPR), Articles 33–34.；
[8]薛熠：《大模型时代的开源许可证：从GPL到开放权重，代码、数据与模型输出的法律边界》，中伦律师事务所，https://mp.weixin.qq.com/s/M-f2Sfbk45kLLeczTICbog；
[9]罗瑞雪：《开源协议适用范围及其对软件著作权侵权判定的影响》https://ipc.court.gov.cn/zh-cn/news/view-842.html?utm_source=chatgpt.com;
[10]广州知识产权法院（2019）粤73知民初207号民事判决书，https://ipc.court.gov.cn/zh-cn/news/view-1823.html?utm_source=chatgpt.com；
[11] 丁华、陈岱源：《开源软件项目中Apache许可证合规问题探析》，上海市锦天城律师事务所，https://mp.weixin.qq.com/s/gWwK4McR4Sr2nhQC8YUkWQ；
[12]段志超、鲁学振、高航：《“开源合规”系列之二——企业应如何构建开源合规制度？》，汉坤律师事务所，https://mp.weixin.qq.com/s/bb82WrmWjpMgDSBryVsAug；
[13]杜微科、张平、孙海龙、陈兵、王鑫、辜凌云：《人工智能时代开源治理的法律回应（上）》，最高人民法院知识产权法庭圆桌论坛，https://ipc.court.gov.cn/zh-cn/news/view-5767.html?utm_source=chatgpt.com；
[14]Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (General Data Protection Regulation), Art. 5(1)(e), https://eur-lex.europa.eu/eli/reg/2016/679/oj;
[15]Dutch Data Protection Authority (Autoriteit Persoonsgegevens), Retention of personal data, https://autoriteitpersoonsgegevens.nl/en;
[16]FTC, Standards for Safeguarding Customer Information (Safeguards Rule), 16 C.F.R. Part 314, https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314;
[17] National Institute of Standards and Technology (NIST), Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (SP 800-171 Rev. 3), https://csrc.nist.gov/pubs/sp/800/171/r3/final.
[18]Singapore Cybersecurity Act 2018, s. 29, https://sso.agc.gov.sg/Act/CA2018
[19]Act on the Protection of Personal Information (Japan); Personal Information Protection Commission (PPC), https://www.ppc.go.jp.
[20]Enforcement Decree of the Personal Information Protection Act (Korea), https://www.law.go.kr
[21]European Data Protection Board（EDPB），Guidelines 05/2021 on the Interplay between the Application of Article 3 and the Provisions on International Transfers as per Chapter V of the GDPR，第20-21段及示例8、9、11。官方原文链接：https://www.edpb.europa.eu/system/files/2023-02/edpb_guidelines_05-2021_interplay_between_the_application_of_art3-chapter_v_of_the_gdpr_v2_en_0.pdf
[22]UK Information Commissioner’s Office（ICO）,Are We Making a Restricted Transfer?。ICO明确，向英国境外的独立组织开放英国境内系统中的个人信息，包括允许其远程访问系统，可能构成UK GDPR项下的受限制传输；其指引特别列举了境外IT服务商通过VPN访问英国服务器开展维护的情形。官方原文链接：https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/international-transfers/a-guide-to-international-transfers/are-we-making-a-restricted-transfer/
[23]Commission Implementing Regulation (EU) 2024/2690，附件第6.7.2（d）、（h）项。官方原文链接：https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202402690
[24]Personal Data Protection Law,article29
https://sdaia.gov.sa/en/SDAIA/about/Documents/Personal%20Data%20English%20V2-23April2023-%20Reviewed-.pdf；
[25]Kubernetes Documentation，Concepts-Overview-Kubernetes，
https://kubernetes.io/docs/concepts/overview/components/；
[26]Cloud Cybersecurity Controls, CCC，National Cybersecurity Authority, NCA，https://cdn.nca.gov.sa/ar/cloud_cybersecurity_controls_draft_en.pdf;
[27]Cloud Computing Regulatory Framework，Saudi Central Bank (SAMA), https://rulebook.sama.gov.sa/en/343-cloud-computing-0
本文版权归「科技法全球合规观察」所有，如需转载，请联系下方秘书号洽谈授权。
如果您有相关法律咨询需求，
欢迎添加团队秘书号：
