FDE 进现场前必须谈妥的数据与合规问题（8 件事与合同条款）

结论先给：这些事必须在开工前谈妥并写进合同，靠承诺无效。 “我们不会用你的数据”在争议出现时没有任何约束力。下面八件事都要有对应条款；谈不拢的，宁可不做。

一、数据访问范围与身份

• 为什么：权限一放开就是失控 —— 一个人能导出什么，取决于他有没有想到要导出。
• 怎么约定：列清可访问的系统与字段；生产数据走只读账号、逐人授权、不用共享账号；写权限单独走变更，写明授权期限。
• 后果边界：超出约定范围访问即违约；造成泄露按合同约定承担责任，并接受审计。

二、数据是否离开你的环境

• 为什么：AI 项目最容易失控的一步，是有人顺手把数据导出去调效果；数据离开内网，控制权只剩对方的承诺。
• 怎么约定：写清“不出内网”的含义 —— 哪些环节允许外发、是否脱敏、能用哪些外部模型。敏感场景写明驻场方式：用你的账号、在你的网络内开发调试，只拿脱敏样本分析。
• 后果边界：未经书面同意把数据传出环境属重大违约，你有权立即终止。

三、数据会不会被用于训练或复用

• 为什么：这是最担心、也最难事后发现的一件事。要区分模型训练和方法沉淀（把做法带到下一个项目）。
• 怎么约定：禁止把客户数据用于任何形式的模型训练、微调或第三方服务的能力改进；调用外部模型时要求走不保留、不用于训练的企业接口，并写成技术约束。
• 后果边界：这条必须可验证：保留调用配置与日志，接受审计。

四、项目结束后数据与产出物的归属

• 为什么：AI 项目的产出物比传统软件复杂：代码、配置、微调模型、评测集、文档。归属不清，二期换供应商时你什么都带不走。
• 怎么约定：逐项列明代码、模型（含微调产物）、配置、评测集与脚本、文档，默认归甲方；乙方保留通用组件与通用方法的使用权，不含你的数据、规则与系统细节。
• 后果边界：未按约定时间交付源码与产出物，视为交付未完成，款项不予支付。

五、交接设计：让系统可运行、可评测、可修改

• 为什么：部署约占总成本的 20%，另外 80% 是之后持续运行；若监控、评测和集成配置都在乙方手里，他们离开后你就只剩黑箱。
• 怎么约定：四样东西进交接清单 —— 运行监控与日志（建在你自有平台，或约定迁移时间）、效果评测套件（评测集、脚本、阈值、升级后怎么重跑）、集成逻辑与配置、运行手册（故障判断与回滚）。
• 后果边界：交接未完成不算项目结束；撤离前你方至少一名工程师要能独立完成一次发布和一次回滚。

六、审计与留痕

• 为什么：没有记录，事后无法判断发生过什么。这个要求通常来自安全或合规部门，不是“以后再补”的事。
• 怎么约定：逐次记录谁在什么时间、以什么身份、访问了哪些数据、做了什么操作；日志保留不少于合同约定的月数，甲方可随时调取。
• 后果边界：拿不出审计日志，等于无法证明合规。

七、数据销毁与退出机制

• 为什么：项目结束不等于数据回到原点，副本会散落在工程师电脑、测试环境和备份里。
• 怎么约定：约定销毁范围（原始数据、派生数据、缓存、本地副本、测试环境）、方式、时限与书面确认；并约定终止条件与交接、销毁的期限。
• 后果边界：未按期销毁并出具书面确认，可暂缓支付尾款或要求审计。

八、分包与人员管理

• 为什么：你谈的是一支团队，到场的可能是另一批人；交付质量依赖个人，换人等于风险重置。
• 怎么约定：是否允许转包（应禁止或需书面同意）；人员名单与更换规则；进场人员签保密协议，保密期长于合同期。
• 后果边界：未经同意转包或更换关键人员，甲方有权要求更换或终止。

可以直接抄进合同的六条表述

1. 乙方人员访问甲方生产数据须经甲方书面授权，逐人开通只读账号，不得共用账号；访问日志保留不少于 12 个月，甲方可随时调取。
2. 未经甲方书面同意，乙方不得将甲方数据及其副本、脱敏数据、测试样本传出甲方环境，不得用于任何形式的模型训练、微调或第三方服务的能力改进。
3. 项目结束后 10 个工作日内，乙方应将源代码、提示词与配置、微调模型产物、评测集与脚本、集成配置及运行手册完整移交甲方，并保证甲方可在自有环境独立部署运行。
4. 运行监控与日志须部署在甲方自有平台；如使用乙方平台，须在撤离前完成迁移，经甲方确认后方视为交接完成。
5. 撤离前须完成知识转移：甲方至少一名工程师独立完成一次版本发布、一次效果评测、一次故障回滚，并留存记录。
6. 项目结束或合同终止后 30 日内，乙方应销毁全部甲方数据及其副本（含本地副本、缓存与测试环境），并出具书面销毁确认。

IT 和业务谈不拢，怎么把两边拉到一起

• 争的是什么：业务已经用公开工具试出效果，想接公司数据；IT 的第一反应是叫停。业务投诉 IT“不让用 AI”，IT 的担忧却是真的：权限边界消失、没有审计记录、结果质量无法验证。
• 本质是责任归属：业务承担“做不成”的责任，IT 承担“出了事我签字”的责任；用“要支持创新”压 IT，只会让审批更慢。
• 写法比态度有用：把每条顾虑翻译成条款 —— 只读账号、逐人授权、日志留存、脱敏、内网部署，逐条回应。
• 让 IT 参与验收与审计条款的制定：参与得越早，叫停概率越低。
• 先要一个最小边界：一个系统、一类数据、一个只读账号、一段期限；小到 IT 敢签字，项目才能开始。

一条边界：什么可以复用，什么不可以

• 可以复用：去掉客户信息之后的通用方法与组件 —— 连接器、字段映射模板、评测脚本框架、提示词模式。
• 不可以复用：客户数据、客户的业务规则与判定逻辑、系统细节（表结构、接口清单、内部编码），以及了解到的组织信息。
• 判据：第一个同类客户需要 10 个人月、第十个仍然需要 10 个人月，说明没有可复用的东西；复用资产里带着你的业务规则，就是越界。

常见问题

数据不能出内网，项目还能做吗？ 能做，但要改工作方式：工程师进内网、用你的账号开发和调试，只把脱敏样本拿出来分析；前提是你提供开发机、测试库和账号。都不给，就没有可执行方案。

保密协议够吗？ 不够。它解决“不得泄露”，解决不了“不得使用”“不得训练”“必须交接”“必须销毁”；这四件事要单独约定，并且可验证。

条款写细会不会把关系搞僵？ 反过来。写细是在谈“出问题怎么办”；会因为条款细而退出的，通常是不打算交出产出物和日志的那一方。

---

数据与合规谈不拢的项目，拖到中途只会更贵。条款不是防着谁，而是让系统在两年后仍然有人能看懂、能改、能停。我们怎么交付讲的是同一件事的现场版本，服务形态见 FDE 外包服务，概念从《FDE 是什么》《FDE 和外包到底有什么区别》看起。有具体场景，联系我们做一次诊断。