AI助手伸进代码仓库:拿走的是什么,＂默认开启＂能算同意吗

说明：本文以2026年9月一起AI编程工具数据上传争议为引子。事实部分仅依据官方媒体报道及当事企业自行发布的公开信息；分析部分为类型化讨论，在假设前提下展开，不对任何特定主体的行为作法律定性。

· · ·

一、事件始末

2026年9月18日，有开发者公开反映，一款AI编程工具在用户登录状态下，会将本地工作区打包、加密后上传至云对象存储，上传内容包含完整的Git版本历史。

当日，厂商通过官方社群向用户致歉并说明：问题源于一项名为"代码库索引"的功能，该功能上线初期为默认开启状态，生成文档页面时可能触发数据上传，上传数据于页面生成后即行销毁。此后数日，厂商推送修复版本、将源代码开源，并邀请第三方机构进行核查。

据央广网9月23日报道，厂商向记者表示已完成整改并向用户致歉，第三方核查确认相关云存储桶处于零数据状态、数据对象及存储桶均已删除；该报道同时指出，两家机构的核查报告全文尚未在公开渠道披露。在此期间，一家企业用户曾公开函件质疑数据流向，随后发布澄清说明，称其函件内容存在"举证错误、表述不严谨及措辞过度"等问题，撤回函件及所列主张。

这起争议本身已有大量讨论。对法律人而言，更值得留下的是它引出的问题——这些问题不会随个案平息而消失，只要AI工具持续深入开发流程，就会反复出现。以下两篇，讨论四个问题。

二、第一个问题：被上传的到底是什么

讨论合规，起点不是"数据"这个笼统概念，而是究竟传上去的是什么。在这类情形中，一个打包文件内往往叠放着三类法律属性完全不同的内容，各自对应不同的规范与责任基础。

第一类是源代码本身。 企业的自研代码通常同时受两套规则保护：作为未公开的作品受著作权法保护；在满足"不为公众所知悉、具有商业价值并经权利人采取相应保密措施"三个要件时，构成《反不正当竞争法》上的商业秘密。

《反不正当竞争法》（2025年修订）第十条列举的侵权行为中，"以盗窃、贿赂、欺诈、胁迫、电子侵入或者其他不正当手段获取"与"违反保密义务或者违反权利人有关保守商业秘密的要求，披露、使用或者允许他人使用"两项，是评价此类情形的直接落点。该条同时明确，经营者以外的其他自然人、法人和非法人组织实施上述行为的，也视为侵犯商业秘密。

第二类是Git版本历史。 这一层最容易被忽略。每一次代码提交都会在仓库中留下提交人的姓名与电子邮箱，完整的版本历史因此成为一份连续记录特定自然人工作轨迹的信息集合。

按照《个人信息保护法》第四条，个人信息是"以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息"，姓名加工作邮箱的组合可以识别到人。公众常有"源代码不是个人信息，所以不受《个人信息保护法》调整"的误解，但法律评价的从来不是载体形式，而是载体中是否承载了可识别的自然人信息。当测试数据、日志文件、内部通讯记录被一并打包时，个人信息的密度会显著上升。

第三类是运行环境与配置。 大文件缓存、操作日志、全局开发配置，可能包含访问密钥、数据库连接串、内网地址与服务拓扑。这些内容既非商业秘密的典型样本，也未必构成个人信息，却往往是企业在数据泄露情形中最先受损的部分。

分层之所以必须先做，是因为它决定了维权路径的分岔：主张商业秘密，须自行证明三要件成立并已采取保密措施，对应的是《反不正当竞争法》第三十九条确立的举证责任转移规则；主张个人信息权益，得以"处理行为未取得有效同意"为切入点，适用《个人信息保护法》第六十九条的过错推定；主张企业资产受损，通常走合同路径。三者可以并行主张，但不能相互替代。笼统地说"泄露了数据"，在法律上不构成一项能够成立的请求——它既无法确定请求权基础，也无法确定举证责任的分配。

三、第二个问题："默认开启"能算同意吗

个人信息处理的合法性基础有七项，《个人信息保护法》第十三条第一款第一项是"取得个人的同意"。其余六项或基于合同必需、或基于法定义务、或基于公共利益，各有特定适用场景。

对AI编程工具而言，被上传的是用户保存在自己电脑上的工程文件——不是用户主动提交给模型处理的一段对话，也不是为履行合同所必需的交付物。厂商若要主张"为订立、履行个人作为一方当事人的合同所必需"，需要论证：把整个工作区连同完整版本历史打包上传，是提供编程辅助服务所不能缺少的环节。这个论证很难成立，因为业界已有大量纯本地索引与本地快照的实现。

也就是说，这条路只能走"同意"。而同意是否有效，需要依次通过四关。

第一关是告知。 《个人信息保护法》第十七条要求处理者在处理前，以显著方式、清晰易懂的语言，真实、准确、完整地告知处理目的、处理方式、个人信息的种类与保存期限；《网络数据安全管理条例》第二十一条进一步要求，个人信息处理规则应当集中公开展示、置于醒目位置，向其他处理者提供个人信息时应当以清单形式列明接收方信息。一条藏在二级页面、以"为改善服务体验"一语带过的说明，难以满足"真实、准确、完整"的要求。

第二关是同意的实质要件。 《个人信息保护法》第十四条要求同意由个人"在充分知情的前提下自愿、明确作出"。实践中可能出现的设计是：某项功能默认开启，客户端不提供独立、明显的关闭选项，数据包由服务端密钥加密，用户既无法查看也无法解密。若这一情形成立，则默认开启意味着用户从未作出任何积极的意思表示；无法关闭与无法查看则意味着，用户即便阅读了全部提示，也无法在事实上控制处理行为。这种设计之下，同意不是被取得的，而是被推定的。

《网络数据安全管理条例》第二十二条对此有直接回应：不得"通过误导、欺诈、胁迫等方式取得个人同意"；收集个人信息应当限于提供产品或服务所必需，不得超范围收集。同一逻辑在《个人信息保护法》第六条体现为最小必要原则——处理应当具有明确、合理的目的，与处理目的直接相关，并采取对个人权益影响最小的方式。

第三关是向第三方提供。 上传至云对象存储，涉及第三方角色。《个人信息保护法》第二十三条要求，向其他个人信息处理者提供个人信息时，应当告知接收方的名称、联系方式、处理目的、处理方式与信息种类，并取得个人的单独同意。

这里有一个前置判断：云服务商是受托方，还是独立的接收方？若其仅按指令存储，属于委托处理，厂商应依该法第二十一条与其约定处理目的、期限、方式、保护措施，并对受托人的处理活动进行监督，未经同意不得转委托；若其可自主决定处理目的与方式，则构成独立的接收方，须取得单独同意。这一区分在实践中常被模糊处理，但它直接决定了程序是否履行、由谁履行。需要注意的是，即便是委托处理，也未豁免厂商的告知义务。

第四关是事前评估。 《个人信息保护法》第五十五条将"委托处理个人信息、向其他个人信息处理者提供个人信息"列为应当事前进行个人信息保护影响评估并对处理情况进行记录的情形。此类评估文件是否编制，往往成为事后判断合规基础的关键证据。它的意义不在于形式，而在于：如果真做过评估，评估过程中必然会遇到"上传范围是否超出必要限度""保存期限如何设定""用户能否有效控制"这些问题——而这些问题一旦被认真回答，功能设计本身就会不同。

四关下来可以看出：形式上或许存在一个"隐私开关"，但实质上未必构成有效的同意。问题的性质不在功能是否可用，而在合规架构是否搭建。

下一篇讨论另外两个问题：数据到底去了哪里，以及出了这样的事，责任由谁承担。

· · ·

本文仅为法律信息分享，不构成正式法律意见。具体项目请咨询专业律师。

· · ·

AI合规实务手记｜关注AI行业的法律问题，侧重AI企业的交易结构、数据合规与资本化路径。

作者　黄冬梅，国浩律师（重庆）事务所合伙人，主要从事并购重组、资本市场与数据合规业务。邮箱：huangdongmei@grandall.com.cn　本文仅代表个人观点。

—— 下篇：《代码上传之后：数据去了哪里，责任由谁承担》

· · ·

本篇事实来源

1. 央广网（央广财经）《智谱股价三个交易日累计跌逾16%，公司回应ZCode数据上传争议》，2026年9月23日。

2. 智谱及ZCode通过官方社群发布的情况说明、整改与开源公告（2026年9月18日至21日，经官方媒体转述）。

3. ZCode 源代码开源仓库（GitHub，Apache-2.0 许可）。

4. 中新经纬（中国新闻社主办）《智谱回应AI编程工具ZCode隐私争议》，2026年9月21日。

5. 证券时报（人民日报社主管）《智谱开源ZCode 正式回应代码数据争议》，2026年9月21日。