AI Agent 数据行为审计与合同条款 2026：出境、留存、审计权怎么落进 RFP

发布日期：2026-09-21 · 算数科技采购与合规研究组。本文为管理视角整理，不构成法律意见。

一、ZCode 事件给采购方的三记提醒

提醒一：签约主体 ≠ 数据控制者

据公开报道，ZCode 客户端的网络请求指向 zcode.z.ai 与 cdn-zcode.z.ai；而 Z.AI 平台的缔约主体及个人数据控制者为注册于新加坡的 JINGSHENG HENGXING TECHNOLOGY PTE.LTD，其隐私政策载明"服务通常自新加坡提供""个人数据通常在新加坡处理"。据智谱招股书信息，该公司为智谱 2023 年 11 月在新加坡注册的间接全资子公司。

与之并存的是另一套表述：中文版 ZCode 用户协议规定的服务提供方是"北京智谱华章科技股份有限公司"，隐私政策规定数据处理者亦为"北京智谱华章"，并称在中国境内运营中收集、产生的个人信息存储于中国境内，不会跨境传输或存储；如需跨境传输或存储，除法定免告知情形外将事先告知并征得用户同意。

对采购方的启示很直接：看协议主体的中文版还是英文版，可能得出完全不同的数据流向结论。合同评审必须把"实际数据处理主体是谁、数据在哪里处理"写成需要供应商书面确认的条款，而不是从隐私政策里自行推断。

提醒二："承诺不训练"不等于"不上传"

"你的数据不会被用于训练"是很多企业愿意签约的理由。但本次争议的核心恰恰不是训练，而是上传行为本身及其范围。需要强调：目前没有证据表明相关数据被用于模型训练——这句话本身就说明，"有没有被用"不能靠信任，必须由可验证机制来回答。

采购侧的对应动作是把问题拆成三层，分别要证据：传不传（出口声明）→ 传多少（范围与忽略清单）→ 留多久（留存与删除证明）。

提醒三：同意的人不是承担后果的人

在这类工具里，点下"同意"按钮的往往是开发者个人；而承担数据泄露后果的，是他的雇主与客户。后者从头到尾没有出现在任何同意流程里，也无从知道自己的代码曾被打包上传。这意味着企业不能用"员工已同意"来免责，必须通过采购合同 + 端点策略 + 审计权来重建授权链条。

二、出境合规：三条路径与两道告知

如果境内企业数据确实经由境外主体处理，依据《个人信息保护法》需要正面回答两个问题：

"网络主体在新加坡、签约主体在北京"这类结构，正是合规审查中最容易出问题的形态：用户以为自己在和境内主体签约，数据却可能由境外主体处理。因此合同里应要求供应商列明全部可能接触数据的法律主体及其所在地，并约定主体变更的告知义务。

三、合同里要写死的 6 类数据行为条款

这六条与我们在 三道防线落地指南 中的技术措施是一体两面：技术负责能拦住，合同负责可追责。缺任何一面，都会在事故发生时陷入"无法举证、无法索赔"的被动。

四、RFP / 合同附件 12 条（可直接抄）

1. 列明全部数据处理主体（含境外关联公司）及其所在地与角色；
2. 提供完整出口域名/端点清单，变更需提前书面通知；
3. 明确本企业数据不用于模型训练，并提供可验证的 opt-out 机制；
4. 明确留存期限，覆盖备份、缓存与衍生数据；
5. 承诺可出具删除证明，并接受第三方审计；
6. 提供可读、可导出的外传日志（时间、体积、目的地、数据类别）；
7. 涉及数据出境时，提供第 38 条适用路径的证明（评估/认证/标准合同）；
8. 涉及个人信息出境时，配合完成第 39 条告知并取得单独同意；
9. 提供子处理者清单（含云存储、插件与 MCP 供应链）；
10. 承诺客户端的安全开关真实约束行为，且不擅自默认开启外发功能；
11. 提供私有化/内网部署或自定义模型端点选项；
12. 约定违约救济与数据迁移/退出安排，保障不被锁定。

第 1、2、6、10 条是本次事件直接命中的缺口，建议作为签约前置项而非"后续完善项"。

五、可用的标准锚点（验收时的客观依据）

把"供应商说自己安全"变成"对照标准可验收"，需要引用公开标准：

实操建议：把这四个文件写进 RFP 的"合规性应答"章节，要求供应商逐条说明符合性，而不是笼统回复"符合国家相关标准"。

六、追责路径的现实参考

本次事件中，太原承明科技发出的法函号为"承明〔2026〕法函字第 1 号"，提出十余项要求，包括：彻底删除已上传数据及其衍生数据、缓存、备份并出具证明；说明数据去向、是否共享第三方、是否用于训练、是否跨境；公开私钥保管方式与访问、下载记录；并要求于 10 月 10 日前书面答复，同时保留索赔、向监管投诉举报与提起诉讼的权利。

这份清单几乎可以直接当作企业事故应对模板。它示范了三件事：① 以书面函件固定诉求与时限；② 把"删除证明"与"私钥保管"作为核心诉求（而非只问"有没有泄露"）；③ 明确保留行政投诉与司法救济路径。

对尚未发生事故的企业，更有价值的做法是把这些诉求前置写进合同——等事故发生后再提，谈判地位完全不同。

七、常见问题 FAQ

Q1：供应商说"数据用完即销毁"，我还需要要删除证明吗？
需要。"销毁"涉及对象存储、备份、日志、衍生索引等多个位置，只有书面删除证明 + 第三方核查才能构成可审计的闭环。

Q2：合同里签"境外主体"，是不是一定不合规？
不是一定不合规，但需要走完对应路径：第 38 条的三选一 + 第 39 条的告知与单独同意。风险在于用户不知情——中文协议写境内主体、英文协议写境外主体，这种不一致本身就是问题。

Q3：我们是采购低代码平台，也需要条款吗？
同样需要。低代码平台的 AI 连接（MCP）可让第三方 AI 读写业务数据，出口属性与代码工具一致，建议使用同一套台账与条款口径。

Q4：怎么验证供应商说的出口清单是真的？
两点：一是要求提供可导出的外传日志；二是保留独立抓包验证的权利（例如用标准网络抓包工具在企业侧复核）。本次事件最初正是靠开发者自行抓包与逆向才被发现。

对照工具页：AI 编程工具选型器 → · 私有化部署对比 →

算数科技观点

「AI 采购合同的本质，是把不可见的云端行为，翻译成可举证的责任条款。」 本次事件之后，企业评审 AI 工具时应当默认带上三个问题：数据由谁控制、出口有哪些、删除怎么证明。 回答不了这三问的产品，即便功能再强，也不适合进入核心研发链路。

算数科技（上海思扬信息科技）11 年企业数字化经验，提供 AI 工具选型对比、合规条款评审、私有化/信创部署支持。咨询 400-678-7857 / 18016313342（微信同号）。

本文法规条款引用《中华人民共和国个人信息保护法》第三十八条、第三十九条；标准信息来自全国标准信息公共服务平台与国家数字标准馆公开页面；不构成法律意见。

八、可以直接抄的条款措辞（四段）

合同评审最耗时的是"把要求翻译成可执行措辞"。以下四段可作为附件基准条款改造使用（具体表述请由法务定稿）：

① 数据行为与出口声明

供应商应在本协议附件中完整列明服务运行过程中可能发起数据传输的域名、端点与数据类别；上述清单发生变更的，应至少提前 15 个自然日书面通知甲方。供应商承诺不通过未列明渠道传输甲方数据。甲方有权通过企业侧网络设备对出口行为进行独立验证。

② 留存、删除与证明

供应商对甲方数据（含由甲方数据生成的索引、缓存、快照及任何衍生数据）的留存期限不超过 <X> 日；服务终止或甲方书面要求后 <Y> 个工作日内完成删除，删除范围覆盖生产环境、备份、日志与衍生数据，并向甲方出具书面删除证明；甲方有权要求第三方机构对删除结果进行核查。

③ 训练使用与退出机制

供应商承诺不将甲方数据及其衍生数据用于任何模型的训练、微调、评测或人工标注；如提供可选的改进计划，应默认关闭，且关闭后应确保相关数据链路终止并可被验证。

④ 审计权与日志

供应商应向甲方提供可读、可导出的数据传输日志，至少包含时间、数据类别、传输体积与目的地；并在甲方合理要求时提供由独立第三方出具的安全审计报告。涉及个人信息出境的，供应商应配合甲方完成相应合规程序。

这四段的共同特征是要求"可验证的证据"而非"承诺"：出境声明可被网络验证，删除可被第三方核查，日志可被读取出，训练承诺可被审计报告覆盖。

九、出境路径怎么选：三类机制的适用对照

采购动作是先判定"是否出境"，再索取对应路径的证明。判定依据不能只看合同签约主体，还要看实际处理数据的法律主体与处理地点——本次争议的核心正在于两者可能不一致。此外，第 39 条的告知与单独同意是独立义务：即使走了上述任一机制，仍需完成告知并取得单独同意。

十、事故应对：前 72 小时的六件事

顺序中最容易被搞反的是第 ① 与第 ② 步：很多团队第一反应是"赶紧把客户端卸了、目录删了"，结果把自己唯一的本地证据销毁了。正确做法是先留存副本再清理。

十一、把这次的教训变成常态机制

AI 工具的迭代速度决定了"一次整改"不可能长期有效。建议把下面三件事做成常态节奏：

• 季度出口复核：每季度核对一次已授权 AI 工具的实际外发域名与出口声明是否一致，不一致即暂停使用；
• 版本变更前置评审：客户端大版本更新前，要求供应商提供变更说明，说明是否新增数据外发链路；
• 台账与合同联动：新增 AI 工具必须同时完成两件事——进台账、进合同附件；缺一项不予放行。

本次事件之所以能迅速上升到"企业发函 + 第三方审计"，正是因为企业侧保留了独立取证能力。保留验证能力，本身就是最重要的合同权利。

十二、RFP 应答评审打分表（可直接用）

有了条款还需要可比较的评审机制。建议把"数据行为"独立成一个评审维度，并给予与功能同级的权重——否则在实操中一定被功能分淹没：

使用要点：凡是一项只有"承诺"而没有"证据"，该项按半分计。这条规则能有效筛掉"我们非常重视数据安全"式的应答。

十三、谈判策略：怎么让供应商接受审计权

审计权往往是最难谈的一条，供应商的常见抗辩是"商业秘密""技术限制"。实务中可以用三种方式降低对方的抵触：

• 分层审计：不要求随时现场审计，而是接受①年度第三方审计报告 + ②事件触发时的专项核查 + ③标准化日志导出。对供应商成本可控，对甲方足以举证；
• 以标准为锚：把要求表述为"符合公开标准的要求"而非"甲方特殊要求"，例如对照信通院规范与相关团体标准的条款逐项说明符合性，让让步变成"对标"；
• 对价交换：把审计权与采购规模、续约期限挂钩，作为商务条件而非单方面合规要求——这在大型采购中通常最有效。

需要强调的是：接受审计的意愿本身就是一个重要的安全信号。本次事件中厂商选择开源并邀请第三方机构审计，正是这一类信号；相反，对出口清单、日志与审计全部回避的供应商，其风险应当被显著上调。

十四、长期机制：年度复核与"三条红线"

把一次采购的正确动作固化为制度，才不至于每年重演。建议设定三条不可越过的红线与一套年度复核动作：

三条红线

• 红线一：密钥、凭据、证书不进入任何 AI 请求或索引范围（任何部署形态）；
• 红线二：核心算法与未公开商业计划仅在私有化/内网环境处理；
• 红线三：任何 AI 工具的出口清单与账号授权未登记不得使用。

年度复核清单

1. 核对每个已授权工具的出口域名清单是否与一年前一致，差异是否经过评审；
2. 复核账号与授权：离职、转岗人员的授权是否回收，闲置订阅是否关闭；
3. 检查日志可用性：随机抽取一个月，确认能还原"谁在何时传输了哪类数据"；
4. 更新合同附件：结合新版本功能与监管要求，补充或修订数据行为条款；
5. 组织一次桌面演练：模拟"某工具被曝静默上传"，检验取证、轮换与函询流程能否在 72 小时内跑通。

这套机制的成本很低，但它决定了下次事件来临时，企业是在几小时内拿出发言口径，还是在几天里手忙脚乱地猜自己丢了什么。

十五、延伸 FAQ（法务与采购高频问题）

Q5：供应商在海外有实体，但合同由境内主体签，算出境吗？
判定看实际处理数据的法律主体与处理地点，不是看合同签的是谁。若数据由境外主体处理或存储，通常构成出境，需要相应合规路径。这正是本次争议的焦点，应在合同中要求供应商书面确认。

Q6：员工个人注册的工具账号，公司能追责供应商吗？
合同关系通常不存在，追责难度很大。可行路径是：① 明确禁止用个人账号处理公司项目；② 对已发生的泄露，从个人信息保护与不正当竞争/商业秘密角度评估；③ 通过平台方（如应用商店、云服务商）渠道反映。这也是强调"企业统一采购"的原因之一。

Q7："数据不用于训练"的承诺需要什么证据？
至少三样：① 合同中的明确条款；② 产品中默认关闭且可验证的 opt-out 设置；③ 第三方审计报告或独立的日志/流量证据。单独的隐私政策表述不足以支撑索赔。

Q8：删除证明由谁出具才算有效？
供应商的书面确认是基础；涉及重大风险时，建议要求第三方机构核查（本次事件即采用信通院 + 安全厂商双机构核查的形式）。核查范围应写明覆盖生产、备份、日志与衍生数据。

Q9：如果供应商拒绝提供日志导出，怎么办？
把"日志导出能力"设为准入条件而非可选项；已采购的，可在续约时作为商务条件提出，或通过企业侧网络日志替代（这也是保留独立抓包能力的重要性）。

Q10：采购低代码平台的 AI 能力，条款可以简化吗？
不建议简化。低代码 AI 连接通常可读写业务数据（客户、订单、财务），敏感度可能高于代码。应与代码工具使用同一套条款框架。

十六、速查：签约前 10 分钟能核完的清单

1. 供应商是否提供了书面出口清单（域名/端点 + 数据类别）？
2. 外发类功能是否默认关闭？
3. 是否有日志导出样例（字段是否够用）？
4. 删除是否覆盖备份、缓存与衍生数据？能否出证明？
5. 训练使用是否有明确条款与 opt-out？
6. 是否接受第三方审计？有无既有报告？
7. 全部数据处理主体（含境外关联方）是否列明？
8. 涉出境时，第 38 条适用路径的证明材料是否齐备？
9. 是否支持私有化或自定义模型端点？
10. 是否有数据迁移与退出条款，避免锁定？

十项中若有超过三项无法给出书面答案，建议在商务上把该供应商的风险等级上调，并将缺失项写入合同整改期条款而不是口头承诺。

十七、要点回顾与相关阅读

三篇专题的分工

相关阅读：AI 编程工具选型器 · 私有化部署对比 · 国产工具 20 维评测