即便签了保密协议，核心数据依然不能交给外包，因为一份协议只能约束违约后的赔偿，挡不住数据被复制、转存或二次分发的瞬间损失。真正要守住的是数据出域前的分级、脱敏和权限控制。下面从几个实际场景说清楚哪些数据不应外包、必须外包时怎么把风险降下来。
保密协议到底挡不住什么？
保密协议的最大作用是出事之后有追责依据，但它管不住数据离开公司内网之后的行为。外包人员把数据下载到个人电脑、上传到网盘或转发给第三方，这些动作往往在协议之外，事后也很难取证。更麻烦的是，有些外包项目会二次分包，实际接触数据的人根本没有和你签过任何东西。所以要么从一开始就不把核心数据给出去，要么给出去之前做好技术上的不可还原处理。
- 数据一旦离开内网，对方复制、转存、二次分发很难实时发现；
- 外包公司内部人员流动后，原签字的人可能已经离职，追责对象都找不到；
- 二次分包时，实际处理数据的人和协议主体不一致，法律上更难主张。
核心数据不是“不能碰”，是要先分级别
很多公司一说不能外包，就把所有数据都锁死，结果正常的开发测试都做不了。更实际的做法是先做数据分类分级，把客户名单、交易明细、算法模型参数、未公开的源代码这些划成核心级；把脱敏后的测试数据、公开历史报表划成可外包级。分类标准可以参考《数据安全法》里的数据分类分级要求，再结合自己业务影响来定。核心级数据默认不出域，出域必须走特殊审批。
分类这件事不能只靠一个部门拍板，更适合由业务、法务、安全一起先做一次影响评估。评估时问三个问题：数据泄露会不会导致客户大量流失？会不会让竞争对手拿到关键参数？会不会违反监管要求？只要有一个答案为是，就往上提一级。分级结果要落到数据资产清单里，每半年更新一次。
哪些数据更适合别离开公司内网？
有几类数据我个人建议直接排除在外包清单之外。第一是能直接定位到个人的完整身份信息，比如手机号加身份证号在一起；第二是尚未公开的产品规划、定价策略和投标底价；第三是能反推核心算法的训练数据或特征工程结果。这些数据就算脱敏，也可能被交叉关联恢复，所以更稳妥的办法是让外包商只接触经过合成的模拟数据，或者干脆用接口调用代替数据导出。
- 含姓名、手机号、身份证号、地址的组合数据；
- 未发布的产品路线图和价格表；
- 核心算法权重、特征工程脚本；
- 内部漏洞扫描报告和未修复清单。
这些数据的共同点是泄露后损失大、恢复难、关联性强。
外包商真要用到数据，怎么把风险降下来？
有些项目比如模型训练、系统压测，完全不给真实数据没法做。这时候可以考虑把数据放到你自己控制的环境里，外包商只通过堡垒机操作，不能下载、复制或截屏。技术手段至少包括：动态脱敏、水印溯源、操作全程录屏、导出审批。合同里还要写清楚，外包结束之后必须删除本地缓存，并由你方做一次清点。这些动作不能只靠外包商自觉，得在项目验收时逐项查。
还有一点容易被忽略：外包商自己的设备也要管。有些公司只控制云端环境，结果对方用个人电脑连VPN拷贝数据。所以要么强制使用你方提供的虚拟桌面，要么在合同里写明禁止本地留存，并在项目结束时让安全人员远程清点。清点动作可以很简单，就是把对方下载记录和你方导出清单对一遍。
别只让法务管协议，技术团队得先划红线
保密协议是兜底，前面得有技术和管理兜底。很多数据泄露不是外包商故意，而是对方员工安全意识差，比如把密码贴在显示器上、用个人邮箱传文件。所以外包开始前，技术负责人要明确哪些环境、哪些字段、哪些接口是对方可以碰的，哪些是完全隔离的。更适合把这些要求写进外包合同附件，而不是口头交代。安全团队还要定期抽查操作日志，看有没有越权访问的苗头。
外包启动前，技术负责人要逐项确认这些事：
- 外包环境是否和核心库网络隔离；
- 对方账号是否只开通了必要的数据读取权限；
- 脱敏规则是否经过验证，不会留下可识别的关联字段；
- 操作日志是否保留至少六个月；
- 合同附件里是否写明数据删除时间点和审计配合义务。
出了事再追责，不如一开始就做数据分离
追责的前提是你能证明数据是对方泄露的，而且损失算得清。这在实操里非常难，很多案子最后就卡在证据不足。所以更划算的做法是把数据流拆开：核心库只存在内网，外包环境只放脱敏数据，两边通过API交互。就算外包环境被拖库，拿到的也是没有价值的假数据。这种架构调整可能要花点时间，但比事后补救的成本低得多。
数据分离不是说把数据库搬到另一个机房就行，而是要按业务流重新设计。比如客服系统只需要调用脱敏后的用户信息，那就让外包客服系统只拿到脱敏数据；核心用户库永远不暴露。如果架构暂时改不了，至少可以先做字段级加密，让外包方看到密文，需要时通过接口解密，解密过程全程记录。这种渐进式改造比一次性大动干戈更容易落地。