可能遇到的情况

一家在上海做企业服务的软件团队，准备在既有产品里接入通用大模型：员工先把客户提交的合同、工单、产品文档和聊天记录导入知识库，再由模型生成摘要、检索答案或协助客服回复。产品负责人已经和模型供应商谈到测试账号和接口调用，销售也希望尽快让几家客户试用，但付款主体、接口账户、数据存储位置、模型是否保留输入输出、供应商是否会调用分包商等情况还没有被逐项说清。此时卡住的往往不是“能不能接上接口”，而是业务数据从客户到企业、再到云服务商或其技术链条的每一步，谁能决定用途、谁能导出、谁能删除，以及出现投诉、误答或安全事件时谁先处理。先别急着把一份通用合规清单套进来，真正需要还原的是每一种数据进入产品前后的实际路径：是员工手工上传、客户自行输入，还是系统批量同步；是只做即时推理，还是沉淀为知识库、评测集或后续优化材料；对外回复是否还要经过人工确认。

为什么需要重视

这类项目在试点阶段容易被当成采购一个工具，实际却同时发生了产品功能、数据处理和客户交付安排的变化。合同里写了“数据归客户”并不当然回答接口日志、向量库、备份、模型供应链中的中间处理记录能否被留存或再次使用；前端放了提示语，也不当然替代对具体数据来源、使用范围和对外承诺的核对。判断重点应落在可核实的事实：导入资料中是否含有可识别个人的信息、受保密义务约束的客户材料或第三方作品；企业对这些材料是否享有把它们提供给技术服务商处理的权限；模型供应商、云资源和检索组件各自承担什么角色、合同是否允许转委托；生成结果是内部辅助还是直接面向客户；发生删除请求、客户审计、输出错误或异常访问时，现有产品和合同能否给出可执行的处理链路。不同用户对象、部署方式、数据类型、是否跨境以及是否面向公众，可能改变需要进一步评估的规则和程序，不能仅根据“AI 产品”这一名称作结论。

现在可以做什么

  • 把本次试点涉及的系统、接口账户、云存储桶、知识库和管理员权限逐一列出，并以一条真实的客户资料为样本画出从上传、解析、检索、生成到日志和备份的流转图；同时标注每一环由谁控制、保存多久、能否下载或删除，交由律师据此判断数据处理边界。
  • 从计划导入的合同、工单、聊天记录和产品文档中抽取具体样本，按客户资料、员工资料、个人信息、商业秘密、第三方作品和公开材料分别登记来源；对每一类材料补齐取得方式、客户授权、保密约定和现有使用目的，而不是只用“内部数据”统一描述。
  • 向拟合作的模型、云服务和检索组件供应商索取当前适用的服务条款、数据处理说明、子处理方清单、日志与备份规则、数据删除机制及事故通知安排；把企业拟使用的接口账户、区域和产品版本写入采购或测试记录，供律师核对合同承诺是否覆盖实际配置。
  • 在客户合同、隐私说明、产品页面和销售话术中找出涉及资料上传、AI 辅助回复、结果准确性、保密和服务终止的现有表述；将准备新增的功能、可处理的数据类型和人工复核节点逐项对照，明确哪些内容需要取得客户确认或调整对外承诺。
  • 固定一轮可复现的上线前测试：分别使用不含敏感内容的样本、需要删除的样本和可能导致错误回复的样本，记录上传人、测试账户、输出可见范围、日志位置和删除结果；保留审批记录，并由律师结合实际服务对象和部署方式判断是否还需补充专项程序或制度。

以上仅基于有限线索整理，具体数据类型、合同权限、部署地点、服务对象及适用法域尚未核实，须由具备相应执业资格的律师结合完整材料复核。