企业把客户资料接入 AI 客服,先查哪些知识产权和数据合规边界?
这是一篇知乎稿件。为便于检索、归档与阅读,收录于“公开发声”。
很多企业卡住的不是技术接入,而是边界混在一起:客服话术、客户合同、工单记录、聊天记录、产品资料、日志、账号权限、模型输入输出,都被放进同一个“知识库”项目里。只要里面有个人信息、客户商业资料、作品性材料或供应商可访问的生产数据,就不能只按 IT 项目验收。
不能直接把“客户资料已经在公司手里”理解成“可以随便喂给 AI 客服”。我的判断是:先做一张数据访问边界表,再决定能不能接入、能不能保存、能不能用于再训练,以及供应商能承担什么责任。
很多企业卡住的不是技术接入,而是边界混在一起:客服话术、客户合同、工单记录、聊天记录、产品资料、日志、账号权限、模型输入输出,都被放进同一个“知识库”项目里。只要里面有个人信息、客户商业资料、作品性材料或供应商可访问的生产数据,就不能只按 IT 项目验收。
第一层:资料来源和权利边界
先把资料分成四类:企业自己形成的业务资料,客户或用户提交的材料,第三方授权取得的内容,以及从公开渠道整理来的内容。涉及文字、图片、音视频、代码、数据库内容时,要看著作权或邻接权益素材的授权范围;涉及客户合同、工单、聊天记录时,还要看合同中是否允许用于自动化服务、知识库检索、模型优化或对外服务。
这里的常见误区是:只要不公开原文,就认为没有版权风险。实际审查时,我会把“内部检索”“向客户生成回答”“保存为训练样本”“交给供应商处理”分开看。每一步使用目的不同,授权和责任也可能不同。
第二层:个人信息和数据安全边界
客户资料里只要含姓名、联系方式、订单、投诉、沟通记录、账号标识等个人信息,就要回到处理目的、处理方式、个人信息种类、保存期限、保护措施、委托处理或共同处理关系。脱敏也不是一句话,要看是否仍能通过上下文、订单号、日志或账号关系重新识别。
数据安全层面,还要识别数据来源、处理目的、数据类型、安全保护措施,以及是否存在特殊风险。对 AI 客服而言,最容易被忽略的是日志和模型输出:输入材料、检索命中、回答记录、人工改写记录,都可能成为后续责任判断的证据。
第三层:供应商访问和合同责任
如果 AI 供应商、云服务商或数据处理方能访问客户数据、源代码、模型输入输出、日志、凭证或生产系统,合同不能只写“保密”。至少要看六件事:访问范围,训练或再训练目的限制,数据或内容来源保证,第三方权利责任,审计权,删除、停用、替换和赔偿安排。
一个反例是:企业只要求供应商承诺“不会泄露”,但没有约定是否能把输入内容用于模型优化,也没有约定服务终止后的删除和模型更新义务。出了客户投诉或版权投诉时,企业很难倒推谁接触过什么、谁应停止什么、谁负责赔偿。
可以先做一张访问边界表
我建议这张表至少有八列:资料名称、资料来源、是否含个人信息、是否含第三方作品或数据库内容、接入目的、供应商是否可访问、是否会保存或再训练、合同责任条款。每一行都要对应到一个处理动作,比如检索、生成回答、人工复核、日志保存、模型优化、删除或导出。
表做完以后,再决定三件事:哪些资料只能本地检索不能进入供应商环境;哪些资料可以接入但必须做字段级脱敏和权限控制;哪些资料需要先补授权、补客户告知、补供应商合同,暂时不能进入 AI 客服。
两个追问
只把资料放进 RAG 知识库,不训练模型,是不是就安全? 不一定。RAG 仍然有输入来源、检索权限、回答输出、日志保存和供应商访问问题,只是风险形态不同。
供应商说数据不会用于训练,还要审合同吗? 要审。还要看它能否访问原始数据、是否保存日志、是否有子处理方、终止后如何删除、发生投诉时能否暂停和配合审计。
这篇回答只能提供一般性判断,不替代具体项目的法律意见。具体到某个 AI 客服或智能助手项目,建议在知乎问题里先列出资料类型、供应商访问方式和是否再训练;需要个案分析时,可以私信吕箐翎律师,把数据访问边界表一起发来。
参考资料
- [1] 《中华人民共和国著作权法》
- [2] 《生成式人工智能服务管理暂行办法》
- [3] 《中华人民共和国数据安全法》
- [4] 《中华人民共和国个人信息保护法》
- [5] 《中华人民共和国民法典》第八百四十三条至第八百四十五条