环节一：数据地图
项目启动时先确认要用哪些系统的哪些字段，谁维护、流向哪里。没有地图就无法判断是否超范围使用，也无法在设计阶段做最小化，后期改动成本会成倍上升，甚至连申请数据都说不清用途，评审时也答不上来。怎么画：从系统到字段，标注责任人与流向。
环节二：字段最小化
逐个字段问用途与替代方案，能不用就不用，能用粗粒度就不用细粒度。最小化不是砍功能，而是把想要与必要分开，让方案在满足业务的同时减少暴露面，也减少后续的告知与授权成本。为什么逐字段问：字段一旦进库就要长期负责。
环节三：脱敏与合成数据
展示、分析、训练用不同强度的脱敏；样本不足时可用合成数据替代真实数据做早期验证。要注意合成数据也可能残留真实分布特征，对外提供前仍需评估，不能默认合成即安全。边界在于合成不等于匿名，可识别性仍要单独验证。
环节四：出境与外部处理
使用境外模型或境外 SaaS 前先画数据流，判断是否构成出境以及是否属于豁免情形。需要时走标准合同或安全评估，并把结论写进项目文档，避免上线后才发现程序缺失，补做时既成事实。怎么判断：不确定时按需要申报处理，不要先传再说。
环节五：验收含合规证据
验收清单除功能项外，应包含字段清单、脱敏规则、权限配置、请求处理入口与影响评估结论。把这些作为交付物，合规才不会在上线后被当成额外工作，也便于后续审计直接取用。为什么写进验收：不写就没人签收。
适用与不适用
适合谁
- 正在做数据准备与模型训练的 AI 项目团队
- 使用外部模型或境外服务的企业，需判断出境路径
- 需要把合规写进验收清单的项目经理
不适合谁
- 不涉及任何个人数据的内部工具项目
- 已完成上线、只做运维的存量系统，也无数据可清理
典型场景
某银行要做客户意图识别模型，项目组先画数据地图确认只用对话文本与产品编号，去掉手机号与证件号，训练用假名化文本，评估不涉及出境，验收时把字段清单、脱敏规则与影响评估一并列入交付物，由合规与业务共同签认。
可执行步骤
- 确认数据来源系统与字段清单，标出必要与非必要，由业务确认用途，避免重复申请
- 逐字段评估用途与替代方案，能删的删除，删除理由要留档，并说明保留理由
- 按用途设脱敏强度，样本不足时用合成数据验证，验证结果写入设计文档
- 判断是否构成出境并留存书面结论与依据，结论与依据一并归档，豁免结论要写明
- 把合规证据写入验收清单，由业务与合规分别签认，签认记录随验收单保存
常见坑
- 先拉全量数据再想用途，最小化无从谈起，清理时又要重新判断哪些字段保留，人力反复消耗，申请数据也难通过
- 脱敏规则写在文档里，代码里没实现，上线后仍能看到明文，验证环节也常被省略，没人抽查导出，风险仍在
- 用了境外模型未判断出境，补做程序时已产生处理事实，解释空间很小，数据也已经流出，监管问询时很被动
- 验收只看功能，合规交付物无人签收，审计时找不到证据，风险被带到线上，只能临时翻找记录，合规无法在验收时把关
自检与验收清单
- 数据地图是否到字段级并标注用途，含系统与责任人
- 字段最小化是否有逐项结论，是否逐项签字，并逐项签名
- 脱敏规则是否在代码中生效并验证，是否有验证样本
- 出境判断是否有书面结论与依据，是否含豁免判断
- 合规证据是否列入验收交付物，是否有签收记录
常见问题
训练数据一定要脱敏吗？
建议做，尤其是含联系方式、位置与证件信息的字段。脱敏降低泄露与滥用风险，也便于说明已采取必要措施；能否完全去除取决于任务需要，需逐字段权衡，并记录取舍理由。
合成数据能替代真实数据吗？
在早期验证与边缘场景补充上可以，但不能完全替代真实分布。合成数据可能放大偏差或残留真实特征，关键决策场景仍需真实数据并做质量评估，对外提供前也要评估可识别性。
项目中途才发现涉及出境怎么办？
立即暂停相关数据流，补做判断与必要的合规程序，评估已完成处理的影响并记录。越早处理成本越低，隐瞒或绕过会在检查时成为加重情节，也会影响后续项目的审批，并把结论补进项目文档。