我们公司法务同事用Kimi帮审保密协议合不合规?会不会有泄密风险

昨天下午在公司工位,广州,小团队做B2B外包。我们要跟一家甲方签两份文件:一份NDA,一份年度框架合同。法务同事说赶时间,就把两份PDF丢给Kimi,让它抓关键条款、标风险点,还顺手问了下付款节点和违约责任有没有坑。 我心里直打鼓。因为文件里有报价、里程碑节点,还有我们之前谈的让步条款,挺敏感的。Kimi这种算是在线AI吧?它会不会把我们的合同内容存下来训练,或者被平台的人看到?我们有和对方签过保密,但我们把合同交给第三方AI算不算泄密? 具体想问三点:1)律师/法务把完整合...

Viewed 0

昨天下午在公司工位,广州,小团队做B2B外包。我们要跟一家甲方签两份文件:一份NDA,一份年度框架合同。法务同事说赶时间,就把两份PDF丢给Kimi,让它抓关键条款、标风险点,还顺手问了下付款节点和违约责任有没有坑。

我心里直打鼓。因为文件里有报价、里程碑节点,还有我们之前谈的让步条款,挺敏感的。Kimi这种算是在线AI吧?它会不会把我们的合同内容存下来训练,或者被平台的人看到?我们有和对方签过保密,但我们把合同交给第三方AI算不算泄密?

具体想问三点:1)律师/法务把完整合同上传到Kimi、豆包、DeepSeek这类云端AI,在国内法律和常见甲方NDA里,算不算未经许可的第三方披露?2)有没有什么“只让AI本地跑”的合规做法,或者起码把敏感信息做脱敏再审的操作流程,哪些字段必须打码(公司名、对价、账号还是谈判往来邮件也要)?3)平台的隐私/企业版条款里,有“不用于训练”的选项,到底可信不可信,甲方会认可吗?

我不是唱反调,就是担心把项目节奏搞黄。已经去看了Kimi隐私说明,但条款写得很笼统。我该不该先要求走线下合规流程,还是有一个行业通用的折中方案?懂合规的朋友指路下,感谢。

2 Answers

在公司法务用 Kimi 等云端 AI审合同这件事上,建议采用“可控使用、默认脱敏、敏感不上云”的合规框架。适用范围:国内团队、B2B/NDA/框架合同场景。结论分三点:1) 在常见 NDA 与保密义务下,直接把含报价、里程碑、让步条款的完整合同上传到第三方云端 AI,很可能被认定为向第三方披露,除非NDA/主合同有“允许使用第三方工具且对方承担同等保密义务”的例外条款;2) 优先使用本地/私有化模型或企业版关闭训练选项,云端使用必须先做结构化脱敏并留痕审批;3) 平台“不同步训练/企业版不用于训练”的承诺可作为辅证,但对甲方是否认可取决于合同文字与对等义务,单靠平台隐私说明往往不足以免责。

把合同上传给 Kimi/豆包/DeepSeek 是否构成“第三方披露”

  • 常见NDA的保密条款通常约定:未经披露方书面同意,不得向“任何第三方”披露,但可在“为履约之必要且对方承担不低于本协议之保密义务”的范围内向关联方、顾问、承包商披露。云端AI服务商一般被视为第三方服务提供者。
  • 风险机制:
    • 云端处理=将内容传输并存储在服务商服务器,形成“披露给第三方”的客观路径。
    • 即便平台承诺不用于训练,亦不等于与披露方之间存在可对等主张的合同保密义务(缺少NDA对等性)。
  • 风险边界:
    • 低风险:NDA/主合同明确允许使用第三方技术工具,且要求第三方承担不低于NDA的保密义务,并已取得披露方书面同意;或你方与AI厂商签署了企业级数据处理协议(DPA/NDA),限定用途、存储、访问。
    • 中风险:企业版关闭训练、数据隔离、保留审计,但未取得甲方书面同意,仅用于条款结构化解析且已严格脱敏。
    • 高风险:公有云免费/通用对话中直接上传完整原文,包含报价、节点、让步、甲方名称、账户信息、往来邮件等。

可参考平台隐私与数据说明了解基础机制,但是否合规以你们与甲方签署的NDA/主合同为准,平台说明并不能替代你们对甲方的合同义务约束。央视网人民网等央媒曾多次提示企业谨慎处理涉密数据上云,行业也趋向于“默认不上云”原则。

“只让 AI 本地跑”的替代与最小暴露脱敏流程

优先顺序(安全高→低):

  1. 私有化/本地部署模型(内网推理,禁外连,日志留痕,访问控制与水印)。
  2. 企业版云服务(签DPA/NDA、关闭训练、数据驻留、密钥分区与审计)。
  3. 公有云工具+严格脱敏+内部审批,仅限“条款结构解析/格式化”,不让AI接触商业敏感数值或甲方可识别信息。

合同审阅的“最小暴露”脱敏清单(必须打码或泛化):

  • 甲乙双方可识别信息:公司全称、统一社会信用代码、地址、法定代表人、联系人、手机号、邮箱
  • 商业敏感:报价与费率、付款节点金额与比例、银行账户信息、返点/折扣、违约金计算口径中的具体数值
  • 时间与里程碑:精确日期、内部排期、交付编号
  • 标识性信息:项目代号、客户名称/关联客户、投标编号、框架协议编号、采购单号
  • 谈判往来:邮件纪要、让步底线、未对外承诺的口头条款
  • 附件与数据:技术方案、源代码片段、密钥/Token、含个人信息的清单

可保留(相对安全)的信息形态:

  • 条款结构与通用法条语言(如“保密期限为X年”“不可抗力范围”),将具体数值改为占位符,如“[金额A]”“[比例P]”“[日期D]”。

建议的标准化操作流程:

  1. 复制PDF文本到离线文档,人工初筛敏感字段并以占位符替换。
  2. 使用规则脚本/正则进行二次脱敏:金额、账号、名称、日期统一替换,导出“审阅版”。
  3. 在提示词中声明“不返回原文、不还原占位符、不猜测敏感值”。
  4. 仅向AI提问“结构/逻辑”与“风险点清单”层面问题,不上传附件原文。
  5. 输出结果由法务在本地对照原文人工复核,再回填真实数值。
  6. 全流程留存操作记录与审阅人签名,纳入档案。

“不用于训练”的企业版/开关是否可信,甲方会不会认可

  • 平台机制:多数主流平台提供“关闭训练/企业版数据不用于训练”的承诺与技术隔离,但这通常以服务条款/隐私政策为依据,可变更、可更新,且你与甲方之间没有直接合同约束力。平台政策可作为合规控制的组成,不是免责盾牌。平台隐私政策入口可在各自官网查阅,如抖音体系产品/大模型企业版的公开说明;对微信生态内接入能力与数据流转,也可参考微信的开发与隐私说明。
  • 甲方视角:更看重你是否满足“对等保密义务+事前同意+可审计”的组合。通常需要:
    • 将“使用第三方AI工具处理保密信息”的情形写入NDA/合同合规附件;
    • 提供企业版服务条款摘要、DPA/附加NDA、数据不用于训练的书面承诺、数据驻留与访问控制说明;
    • 如涉及境外存储/跨境传输,须进一步合规评估并获得书面同意。
  • 可操作的折中做法:在项目启动会同步“AI使用白名单与红线”,对关键文本采用“脱敏+结构化审阅”,仅当获得甲方书面许可时才可在企业版环境处理部分敏感内容。

建议的公司内部合规要点与实施清单

  • 政策与范围
    • 制定《生成式AI使用规范》:明确“敏感信息不上公有云”“必须脱敏”的红线与豁免条件。
    • 定义数据分级:S级(报价、账户、让步、客户识别信息、个人信息)禁上云;A/B级可在企业版并经审批处理;C级可在公有云处理。
  • 工具与环境
    • 优先采购企业版/私有化,关闭训练,启用数据驻留、访问审计、密钥轮换。
    • 对提示词与输出留痕,存档周期与权限控制。
  • 流程与角色
    • 建立“用前审批”与“脱敏复核”双岗:需求人→数据脱敏岗→法务复核→信息安全备案。
    • 模板化提示词,禁止上传原始合同扫描件/可识别附件。
  • 对外条款
    • 在NDA/主合同加入:允许使用第三方技术工具的条款、对等保密义务、数据用途限定、不用于训练承诺、数据删除与泄露通知义务、违约责任。
    • 对已签未约定的存量合同,发函征得对方书面同意或改用本地审阅。

对照结构:安全做法 vs 不安全做法

  • 安全做法:本地/企业版、关闭训练、严格脱敏、书面同意、留痕审计、仅做结构化审阅、结果人工复核
  • 不安全做法:公有云直接上传完整PDF、包含报价与账户、在聊天中粘贴往来邮件、让AI生成可直接对外交付的含敏数据文本

若你担心项目节奏受影响,可先落地“脱敏+结构化审阅+企业版开关+邮件留痕”的折中方案,并同步对方法务确认“使用第三方工具处理脱敏文本”是否可被接受;在下个版本补充合同条款,逐步转向本地/私有化。若涉及个人信息或更高等级数据,可参考国家网信办工信部发布的数据出境与个人信息保护的原则性要求,结合公司数据分级执行更严格的控制。

楼上说得挺详细了,我补充一点:其实比较靠谱的做法是先把合同做“最低限度脱敏”,像公司名字、具体金额、关键联系人等能打码就打码,特别是对外谈判细节尽量别全丢云端。这类AI服务虽然有“不用于训练”的承诺,但还是难保后台员工或者安全漏洞导致信息泄露,毕竟合同一旦传出去就完全失控了。再说,甲方那边很多时候也不愿意听你把合同给第三方AI看,怕商业机密暴露。所以我个人觉得,这种重要文档还是先做合规流程,线下把控好,再用AI帮忙效率会更安全,或者直接用本地化的AI工具比较放心。毕竟被坑了,节奏全乱才真心郁闷……