摘要：当员工将商业秘密上传至云端大模型，或在本地用大模型读取保密数据，是否构成商业秘密“秘密性”的丧失？本文从中国法的秘密性认定标准出发，结合美国Trinidad v. OpenAI等最新判例和欧盟制度回应，区分云端公共平台上传、本地离线读取、本地Agent搭配远程闭源模型API的混合架构、企业级AI服务四种场景展开分析。核心结论是：秘密性是否丧失取决于数据是否实质离开权利人控制域，以及接收方是否承担保密义务。将商业秘密输入不负保密义务的公共AI平台，存在丧失秘密性的重大风险；本地部署开源模型完全离线运行，秘密性不受影响；混合架构中数据经API离开控制域，风险与云端上传实质相同；企业级AI服务在有效合同保密安排下秘密性得以保留。
关键词：商业秘密；秘密性；大模型；生成式人工智能；数据控制域；保密义务；Agent
引言
2023年3月，三星电子引入ChatGPT仅20天，便连续发生三起泄密事件。工程师将半导体设备测量数据、源代码、产品良率报告粘贴进对话框，请求AI帮助纠错和优化。这些内容进入OpenAI的服务器后无法撤回。三星随即全面禁止员工使用该工具。① 此事并非孤例。2024年8月，国家安全部通报多起涉密人员将素材输入AI写作小程序导致国家秘密泄露的事件。② 这些案例将一个迫切的法律问题推到了企业面前：当员工把商业秘密上传至云端大模型，或者在本地电脑上用大模型读取保密数据，秘密性是否就此丧失？
这一问题的紧迫性，在2026年初的美国司法实践中得到了正面回应。加州北区联邦地区法院在Trinidad v. OpenAI案中，第一次明确判定：将信息输入ChatGPT开发所谓“专有框架”，属于向不负保密义务的第三方自愿披露，该信息不再受《保护商业秘密法》（DTSA）保护。③ 几乎同一时间，纽约南区联邦地区法院在United States v. Heppner案中指出，通过公共AI平台输入的信息因平台用户条款保留再披露权而丧失保密性。④ 两份裁判从商业秘密和律师特权两个路径，指向同一个结论：信息一旦进入不受保密义务约束的公共AI平台，法律意义上的“秘密”属性可能就此终结。
大模型的使用方式多元。云端上传与本地读取，在数据流转路径上存在本质差异，由此带来的法律评价也截然不同。本文从中国法的秘密性认定标准出发，结合美国判例和欧盟制度回应，区分多种场景展开分析，以期为企业提供一面可参照的法律镜鉴。
一、秘密性的认定标准与“公众”的范围
商业秘密的秘密性，核心在于“不为公众所知悉”。《中华人民共和国反不正当竞争法》（以下简称《反不正当竞争法》）第十条第四款将商业秘密界定为“不为公众所知悉、具有商业价值并经权利人采取相应保密措施的技术信息、经营信息等商业信息”。该定义包含三个要件：不为公众所知悉即秘密性，具有商业价值即价值性，采取相应保密措施即保密性。三者缺一不可，其中秘密性是首要门槛。最高人民法院《关于审理侵犯商业秘密民事案件适用法律若干问题的规定》（法释〔2020〕7号）第三条将“不为公众所知悉”具体化为“权利人请求保护的信息在被诉侵权行为发生时不为所属领域的相关人员普遍知悉和容易获得的”。⑤ 该规定的第四条则从反面列举了“为公众所知悉”的五种情形，包括信息已在公开出版物或媒体上公开披露、已通过公开报告会或展览公开、所属领域人员可从其他公开渠道获得等。⑥ 这一双向界定确立了秘密性认定的基本框架。
上述标准中，“公众”的范围是决定性变量。有观点指出，传统司法实践倾向于将“公众”理解为不特定多数人，而数据流转环境的复杂化要求转向以保密义务为核心的界定标准。具体而言，信息接触者是否承担保密义务，应作为判断其是否属于“公众”的决定性因素。即使信息在多个外部主体之间流转，只要处于有效保密控制之下，就不应轻易认定其已为“公众所知悉”。⑦ 这一思路将第三方分为合同关系型、监管关系型、中介服务型三类，只要接触者基于合同、法定职责或职业道德负保密义务，便被排除在“公众”范畴之外，与欧盟《商业秘密保护指令》的规则相一致。有观点进一步区分了数据条目与数据集合两个层面：前台公开的数据条目失去秘密性，但后台受访问密码等有效保密措施控制的数据集合整体，依然满足秘密性要求。⑧ 这一“整体秘密性”思路，对判断大模型场景下的信息状态有直接参考价值。
二、云端上传：数据控制权的转移
当员工将商业秘密粘贴进ChatGPT、Kimi、文心一言等公共AI平台的对话框，信息的物理位置便从企业内网迁移至平台服务器。这一动作的法律含义，需要从三个层面拆解。
第一个层面是公共AI平台的用户条款是否构成“保密义务”。以OpenAI为例，其消费者版本的使用条款保留了审查用户输入的权利，并允许将输入内容用于模型训练。用户在注册时同意该条款，意味着接受信息可能被用于训练、审查乃至向第三方披露的安排。在此种安排下，平台并不对用户输入承担商业秘密法意义上的保密义务。Trinidad案中，法院正是基于这一逻辑，认定原告“接受OpenAI使用条款并用ChatGPT开发框架”的行为构成自愿披露，并援引Ruckelshaus v. Monsanto Co.案的原则指出，当事人将商业秘密披露给不负保密义务的他人时，该信息的财产权即告消灭。⑨
第二个层面是信息进入训练数据后是否构成“为公众所知悉”。即便平台承诺不将用户输入用于训练，信息仍可能因后台人工审查、安全漏洞或数据泄露而被不特定人获取。2023年ChatGPT的Redis缓存漏洞曾导致部分用户聊天记录和支付信息暴露给其他用户。⑩ 如果信息被纳入模型训练数据集，理论上可能通过精心设计的“提示词注入”攻击从模型输出中提取出来。马萨诸塞州联邦地区法院2025年2月受理的OpenEvidence v. Pathway Medical案，正是一起通过恶意提示词攻击提取AI平台系统提示词的商业秘密侵权案件。⑪ 按照法释〔2020〕7号第四条第五项“所属领域的相关人员从其他公开渠道可以获得该信息”的精神，一旦获取渠道在技术上具备可行性，秘密性便可能受到动摇。
第三个层面是“合理保密措施”要件是否被破坏。法释〔2020〕7号第六条列举了七种保密措施类型，其中包括对能够接触商业秘密的各类计算机设备、网络存储介质及软件系统等，采取禁止或限制使用、访问、存储、复制等措施。⑫ 将保密信息上传至不受控的外部服务器，与这一要求明显背离。Trinidad案的法院直言，将核心方案输入公共生成式AI，在“秘密性和合理保密措施”这一要件上首先失守。④ 从中国法角度审视，权利人若明知或应知公共平台不对输入信息承担保密义务，仍主动将商业秘密输入其中，其保密措施的“合理性”将受到严峻质疑。综合以上三个层面，将商业秘密上传至未签订保密协议且用户条款允许数据用于训练或审查的公共AI平台，在中国法框架下存在丧失秘密性的重大风险，美国司法实践已经给出了明确的信号，这一判断路径对中国法院具有参考价值。
三、本地读取：控制域内的信息处理
与企业版API或公共网页版不同，在本地电脑上部署开源大模型读取企业数据，信息的物理位置始终处于用户设备之内，不存在向外部服务器传输的行为。这一场景与使用本地安装的传统办公软件处理保密数据没有本质区别。信息是否离开了权利人的控制域，是判断本场景秘密性的核心问题。本地部署的开源模型运行在用户自有的硬件设备上，数据读写操作在本地内存和磁盘中完成，不产生任何网络通信。信息的物理状态与权利人将商业秘密存储在本地加密硬盘并使用专用软件处理的状态相同。有观点提出的“受控流转”认定方式，即信息在有效保密控制下的流转不丧失秘密性，在此可以适用。⑦ 只要企业对本地设备采取了合理的物理和数字保密措施如磁盘加密、访问权限控制、操作审计日志，在本地模型中读取商业秘密，与在本地软件中分析客户名单的法律效果并无不同。
关于本地模型是否存在特殊安全风险的问题，有观点认为提示词注入、插件污染、高权限误操作等“对抗性机器学习风险”同样可能影响本地模型，美国国家标准与技术研究院和OWASP均将提示词注入列为生成式AI应用的首要风险之一。⑬ 然而，这些风险与秘密性的关系需要澄清。提示词注入攻击针对的是模型行为，即诱导模型执行非预期操作，而非直接将信息向不特定人公开。在本地环境中，即使模型被提示词注入，所读取的保密数据仍然停留在本地设备上，不产生“为公众所知悉”的效果。除非攻击者能够通过网络远程操控该设备并导出数据，此时问题已经转化为网络安全事件，而非秘密性的认定问题。
在纯粹的本地部署、本地读取场景下，商业秘密的秘密性原则上不受影响。信息未离开权利人的控制域，不存在“为公众所知悉”的客观基础，保密措施的“合理性”也未被削弱。这一结论有前提：企业对本地设备实施了与信息密级相匹配的保密措施如加密、权限控制、审计日志，且模型确实完全离线运行，不存在向外部服务器发送数据的隐蔽通道。
四、混合架构：本地Agent与远程闭源模型
当企业部署本地Agent框架处理保密数据时，可能出现一种容易被误判安全性的技术架构：Agent程序在本地运行，负责读取文件、编排任务、调度工具，但模型的推理能力由远程闭源大模型通过API提供。LangChain、Dify、AutoGPT等主流Agent框架均支持这种本地编排加远程推理的混合模式。需要说明的是，近年来涌现的成品Agent应用虽然不以“框架”形式呈现，但其技术架构与上述混合模式一致。以Claude Code、OpenAI Codex CLI、WorkBuddy等编程或办公辅助工具为例，Agent编排在本地终端执行，模型推理由远程闭源模型经API完成，数据同样作为提示词内容被发送至模型提供商服务器。判断数据是否离开控制域的标准，对框架与成品应用并无二致。阿里研究院人工智能治理中心主任傅宏宇指出，在模型通过API接口接受或调取用户数据的场景中，用户输入数据和模型调用的补充数据被发送至远程服务器，连同模型输出数据一起存储于模型服务域的交互数据存储之中。⑯ 这一技术路径的数据流与本地离线模型存在本质差异，需要单独分析。
从数据流转的技术原理来看，Agent在本地读取商业秘密文件后，需要将文件内容或摘要封装为提示词，通过HTTPS请求发送至闭源模型提供商的推理服务器。以OpenAI的API为例，API输入和输出数据默认保留30天用于滥用监测，30天后自动删除。⑰ 消费者版API的数据可能被用于模型训练，用户需手动关闭数据共享选项。企业版API和ZDR端点承诺不用于训练且不留存数据，但仍无法改变数据在传输和处理阶段短暂停留于远程服务器的事实。金杜律师事务所在分析API接入大模型的法律合规问题时明确指出，数据需传输至第三方处理导致控制权减弱，是企业选择API调用接入方式的主要局限性之一。⑱ 从数据流转角度看，Agent在本地并不能改变数据离开控制域的客观事实。信息的物理位置在API调用过程中发生了迁移，从本地设备经过网络链路进入远程服务器内存。这一迁移与用户在浏览器中手动粘贴信息至ChatGPT对话框的实质区别，仅在于操作由程序自动完成而非人工逐字输入。
法律层面的评价取决于两个变量：模型提供商是否承担保密义务，以及API数据留存策略是否构成“为公众所知悉”的风险。如果企业使用的是闭源模型的消费者版API且未签署数据处理协议，数据将被传输至不负保密义务的第三方服务器并可能被用于模型训练，其法律效果与第二节分析的云端公共平台上传基本一致，信息脱离权利人控制，秘密性面临丧失风险。Trinidad案的裁判逻辑同样适用于此：自愿将保密信息发送给不负保密义务的第三方，构成“披露”。如果企业与闭源模型提供商签署了包含ZDR条款的数据处理协议，服务商承诺不留存、不训练、不向第三方披露输入数据，则按照以保密义务为核心的认定标准，服务商会排除在“公众”范畴之外，秘密性原则上得以保留。实践中最危险的情况是员工或部门自行部署开源Agent框架，搭配个人API Key调用闭源模型处理公司保密数据。Agent的本地化部署形态制造了一种安全错觉，使用户误以为数据没有离开控制域。实际上每一次API调用都在将商业秘密的片段通过加密通道发送至远程服务器。⑲ 企业IT部门往往对此缺乏监控，Agent框架的网络通信日志分散在员工终端上，不同于网页版AI的使用行为难以被传统DLP系统识别。⑳
五、第三条道路：企业级AI服务
公共平台与企业自建本地模型之间，还存在一类中间形态：企业级AI服务。OpenAI的ChatGPT Enterprise、Microsoft 365 Copilot、Azure OpenAI Service等企业版产品，明确承诺不将客户输入用于训练基础模型，并通过数据加密、访问控制和企业账号体系构建受控环境。⑬
从秘密性认定角度，企业级AI服务的法律地位取决于服务协议中的保密安排是否构成有效的“保密义务”。按照林瑜琳提出的以保密义务为核心的判断标准，以及法释〔2020〕7号第六条第一项“签订保密协议或者在合同中约定保密义务”的精神，如果企业与AI服务商签订的合同中包含明确的保密条款，服务商承诺不将客户数据用于模型训练、不向第三方披露、采取行业标准的安全措施，则服务商不属于商业秘密法意义上的“公众”。在这一前提下，企业员工通过企业级API上传保密信息进行分析，不应被认定为秘密性丧失。
企业级服务的保密承诺必须落实到合同条款层面，不能仅依赖服务商的营销宣传或隐私政策。Trinidad案的教训之一，就是法院严格审查用户条款的实际内容，而非用户的主观期待。企业在采购AI服务时，应以书面合同明确以下要素：数据所有权不转移、服务商不获得数据的衍生使用权、数据在服务终止后须删除、服务商承担违约赔偿义务。只有将这些条款固定下来，才能在法律层面构建起与本地部署相近似的保密效果。
六、比较法视角的呼应
美国和欧盟在面对同一问题时，给出了不同路径的回应。美国法层面，DTSA要求权利人采取“合理措施”维持信息的秘密性。Trinidad案和Heppner案确立了基本规则：向公共AI平台输入信息等于向不负保密义务的第三方自愿披露，秘密性消灭。但对于企业级AI服务或本地部署，美国法院尚未有直接判例。学术讨论中有一种值得关注的观点：如果生成式AI能从公开数据中重建某项商业秘密，该信息可能被认定为“容易获得”从而丧失秘密性。⑨ 这一观点暗示，AI技术的发展本身可能在抬高秘密性的认定门槛。
欧盟法层面，EU Trade Secret Directive第2条将商业秘密定义中的“秘密”限定为“不为通常处理该类信息的人所普遍知悉或容易获得的”，这一标准与中国法相似。欧盟同时在《人工智能法案》（EU AI Act）中设置第78条保密条款，要求AI系统的监管参与者尊重知识产权和商业秘密，仅可索取风险评估所必需的数据，并须采取网络安全措施予以保护。⑭ 不过，这一条款规范的是监管者与被监管者之间的关系，不直接调整企业用户与AI平台之间的民事法律关系。欧盟在2025年底已开始推动为AI Act和GDPR“松绑”，将部分高风险AI系统的合规义务推迟至2027年底，⑮ 表明其正在重新平衡AI监管与产业发展之间的关系。
欧盟法对中国企业的直接启示在于：《商业秘密保护指令》明确将负有保密义务的第三方排除在“公众”之外。只要企业与AI服务商之间建立了有效的保密安排（合同约定加技术措施），使用AI工具处理商业秘密本身并不导致秘密性丧失。如果使用的是无保密承诺的公共版本，风险则与美国法下的结论一致。
七、监管义务能否替代保密义务
前文分析建立在一条核心逻辑链上：公共AI平台不负保密义务，信息一旦上传便脱离权利人控制，秘密性面临丧失。一个自然的反论随即出现：国内大模型服务提供者并非法外之地。国家网信办等七部门联合发布的《生成式人工智能服务管理暂行办法》（2023年8月15日施行）第四条第一款第三项明确要求提供者“尊重知识产权、商业道德，保守商业秘密”。㉑ 同办法第十一条进一步规定，提供者对使用者的输入信息和使用记录“不得非法留存”能够识别使用者身份的信息，“不得非法向他人提供”。㉒ 第十九条第二款要求参与安全评估和监督检查的机构和人员对知悉的商业秘密依法予以保密。2025年1月1日施行的《网络数据安全管理条例》第十九条也规定了生成式AI服务提供者对训练数据的安全管理义务。
既然法律已经强制要求大模型提供者清洗数据、保守秘密、不得非法留存和提供用户输入，信息实际上不可能进入公众领域，秘密性岂不是得以保留？这一反论的思路有一定说服力，但需要区分两个层面。
第一个层面是行政监管义务与民事保密义务的性质差异。《暂行办法》和《网络数据安全管理条例》设定的义务，属于行政管理法层面的合规要求，其规范对象是提供者的数据处理行为是否合法，违反后果是行政处罚、责令整改乃至吊销许可。商业秘密法意义上的“保密义务”则解决另一个问题：信息接收方在民事法律关系中是否对权利人承担不披露、不使用的私法义务，违反后果是承担损害赔偿责任。两类义务在主体、内容和救济方式上均不相同。行政监管义务约束的是提供者与监管部门之间的纵向关系，不直接产生提供者与用户之间的保密合同关系。以保密义务为核心的认定标准中，合同关系型保密义务来源于双方的明示约定，监管关系型保密义务来源于法定职责针对特定主体的履行。⑦ 大模型提供者依据《暂行办法》对全体用户一视同仁地履行数据处理义务，这种义务并非针对某一特定权利人的商业秘密所承担的保密职责，难以直接等同于商业秘密法意义上“针对特定信息的保密义务”。
第二个层面是“非法”一词的解释空间。第十一条的核心限制语是“不得非法留存”和“不得非法向他人提供”。这里的“非法”以何为判断基准，直接决定义务的覆盖范围。如果“非法”指的是违反法律明文禁止性规定，则提供者将用户数据用于自身模型优化、内部安全审查或经用户默示同意的数据共享，可能不构成“非法”，但仍足以使信息脱离权利人的控制。中国境内大模型厂商的实践也印证了这一隐忧。以百度文心一言、阿里通义千问、月之暗面Kimi及字节跳动豆包等产品为例，其用户协议普遍规定了用户授予服务方对输入内容进行存储、分析及改进服务的权利。㉓ 换言之，法律要求提供者“不得非法留存”，但提供者通过格式合同获得了留存和使用用户数据的合法性基础。在用户点击同意的前提下，这些操作不违反第十一条，但商业秘密已经离开了权利人的控制域，进入了服务方的存储和处理系统。
第三个层面是监管规定的执行效力与举证现实。《暂行办法》和《网络数据安全管理条例》规定了行政处罚措施，但未赋予商业秘密权利人就提供者的数据违规行为主张民事赔偿的直接请求权。如果权利人主张信息因上传至大模型而丧失秘密性，在诉讼中面临举证困境：难以证明提供者是否实际留存了该项特定信息，难以证明信息是否被用于训练，更难以证明信息已经为“所属领域的相关人员”所获取。法释〔2020〕7号第四条规定的“为公众所知悉”要求信息处于客观上可被相关领域人员获得的状态，而非要求实际已被获取。⑥ 大模型服务方即便严格遵循了数据清洗和销毁义务，信息在API调用或网页交互过程中短暂停留于服务器内存的事实本身，是否已经构成了“容易被获得”，存在争议。在缺乏明确司法先例的情况下，权利人难以仅凭监管规定的存在即推翻“信息已脱离控制域”的客观判断。
综合以上分析，国内监管规定为大模型服务提供者设定了数据处理的基本合规框架，在一定程度上降低了用户数据被随意传播的风险，这一事实应当被承认。但监管义务不能替代商业秘密法意义上的保密义务，主要原因在于：行政合规义务不直接产生针对特定权利人的民事保密关系，“不得非法”的措辞为合法框架内的数据利用留出了空间，举证责任在权利人一方。从风险防范角度，企业将商业秘密上传至国内大模型的公共版本，秘密性丧失的风险虽有缓解但并未消除。真正可靠的路径，仍然是与企业级服务方签订包含明确保密条款的数据处理协议，使保密义务从行政合规层面提升至合同法层面，从而在“以保密义务为核心”的认定框架下锁定秘密性的保留。
八、企业使用AI的风险分层
基于以上分析，企业使用大模型处理商业秘密的法律风险可以归纳为四类。
第一类是高风险区：员工使用个人账号在公共AI平台输入源代码、配方、客户名单、财务模型或战略规划等保密信息。此时信息离开企业控制域，进入不负保密义务的第三方服务器，存在丧失秘密性的实质风险。三星事件和Trinidad案分别从事实和法律两个层面给出了警示。企业应通过制度明确禁止此类行为，并通过DLP数据防泄露系统等技术手段监控和拦截。
第二类是中风险区：企业采购企业版AI服务，如ChatGPT Enterprise、Azure OpenAI或阿里通义千问企业版，合同中包含保密条款且服务商承诺不用于训练。此时信息虽离开企业控制域，但接收方承担合同保密义务，按照“以保密义务为核心”的认定标准，秘密性原则上得以保留。风险在于服务协议的条款不够严密、服务商的实际执行难以验证，或服务商发生安全事件导致数据泄露。企业应定期审查服务协议，要求服务商提供安全审计报告，对高密级信息采取脱敏后再上传的措施。
第三类是隐蔽高风险区：员工或部门在本地部署Agent框架，搭配闭源模型的API处理公司保密数据。Agent的本地运行形态造成数据没有离开控制域的错觉，实际上每次API调用都在将保密信息的片段发送至远程服务器。⑲ 此类风险隐蔽性最强，IT部门难以通过传统手段监控。企业应将Agent框架的网络通信行为纳入安全审计范围，要求所有使用闭源模型API的场景必须经IT部门审批和登记，优先使用已签署数据处理协议的企业级API Key，禁止员工使用个人API Key处理公司数据。
第四类是低风险区：企业在本地服务器或员工终端上部署开源大模型，完全离线运行，处理本地存储的保密数据。此时信息始终处于权利人的物理控制之下，与使用本地办公软件无异，秘密性不受影响。“本地部署”必须经技术团队确认模型确无网络通信行为，且本地设备已采取与信息密级相匹配的加密和权限控制措施。员工在个人终端上未经IT部门许可擅自部署开源模型处理公司数据的行为，不属于此类别，应纳入第一类高风险区管理。
结语
回到标题中的问题：将商业秘密上传至大模型，是否意味着秘密性的丧失？答案取决于数据流转的具体路径，不能一概而论。云端公共平台上传，信息进入不负保密义务的第三方领域，秘密性面临丧失风险，美国法院已经给出了裁判先例。本地部署开源模型、离线读取，信息未离开控制域，秘密性不受影响。本地Agent搭配闭源模型API的混合架构，是容易被忽视的风险盲区：Agent在本地运行制造了安全错觉，而实际数据流与云端上传并无实质区别。企业级AI服务在有效合同保密安排下，秘密性得以保留。
对企业而言，真正的风险不在于AI技术本身，而在于使用方式的选择。审慎评估每一次数据输入的流向，在合同层面固定保密义务，在技术层面确保控制域的完整性，这些做法与AI时代之前并无本质不同。变的只是工具，不变的是商业秘密保护的基本逻辑：谁控制信息，谁就保有秘密。
注释
① 参见《三星员工将机密代码输入ChatGPT，公司紧急限制使用》，澎湃新闻，2023年3月报道。网页检索，访问日期2026年8月6日。
② 参见国家安全部2024年8月通报。来源：澎湃新闻“保密微课”栏目。
③ Trinidad v. OpenAI, Inc., 2026 U.S. Dist. LEXIS 1129 (N.D. Cal. Jan. 5, 2026).
④ United States v. Heppner, S.D.N.Y., Feb. 17, 2026. 参见Peter J. Toren《Navigating Recent Developments in Generative AI and Trade Secret Protection》，载IPWatchdog，2026年4月5日。
⑤ 最高人民法院《关于审理侵犯商业秘密民事案件适用法律若干问题的规定》（法释〔2020〕7号）第三条。
⑥ 法释〔2020〕7号第四条。
⑦ 参见林瑜琳《数据时代企业数据商业秘密“秘密性”认定标准的完善研究》。
⑧ 参见崔国斌《新酒入旧瓶：企业数据保护的商业秘密路径》。
⑨ 参见前注④，Toren文。Ruckelshaus v. Monsanto Co., 467 U.S. 986 (1984)。
⑩ 参见《Your Employee Just Pasted Your Trade Secrets into ChatGPT》，LinkedIn X Insights，2025年。
⑪ OpenEvidence, Inc. v. Pathway Medical, Inc., No. 1:25-cv-10471 (D. Mass. Feb. 26, 2025). 参见Professor Camilla Hrdy分析，载PatentlyO，2025年3月。
⑫ 法释〔2020〕7号第六条第五项。
⑬ 参见柳沈律师事务所《OPENCLAW的警示：AI时代企业信息安全风险与合规建设》，2026年6月11日。
⑭ EU AI Act Article 78. 参见https://artificialintelligenceact.eu/article/78，访问日期2026年8月6日。
⑮ 参见《松绑数字监管，欧盟陷入两难》，通信新闻，2026年1月19日。
⑯ 参见傅宏宇《当deepseek们走向端侧：用户数据安全成必答题》，载21世纪经济报道，2025年2月12日。
⑰ 参见OpenAI企业隐私政策关于API数据留存的规定，https://openai.com/enterprise-privacy，访问日期2026年8月6日。
⑱ 参见金杜律师事务所《企业接入第三方开源模型：法律合规“全攻略”（上）》。
⑲ 参见前注⑳，柳沈律师事务所文（关于“本地化部署的安全错觉”部分）。
⑳ 参见《企业AI应用安全红线：大模型部署前必须解决的五大风险》。
㉑ 《生成式人工智能服务管理暂行办法》（2023年8月15日施行）第四条第一款第三项。检索数据库：北大法宝（pkulaw），MCP核验一致。
㉒ 《生成式人工智能服务管理暂行办法》第十一条。同上。
㉓ 参见百度文心一言、阿里通义千问、月之暗面Kimi、字节跳动豆包等主流国产大模型产品用户协议中关于用户内容授权的格式条款。各产品协议均规定用户授予服务方对输入内容进行存储、分析、改进服务的权利。网页检索，访问日期2026年8月6日。