误区一：等于全本地
域可以按机房、区域或租户划分，专属区域同样可能落在范围内。把不出域直接等同于全本地，会让方案在算力与成本上被过度约束；正确做法是先由合规部门定义域的范围，再看哪些形态落在范围内，而不是先定形态再解释边界。
误区二：本地即合规
数据留在本地只解决了位置问题，权限、审计、删除与日志留存仍要单独建设。为什么容易混淆：位置最直观，其他项看不见。验证方式是抽查一条请求，看能否回答谁访问、何时删除、日志存多久，答不上来就说明流程还没建起来。
误区三：只盯数据库
推理请求、向量检索、监控上报、备份与远程运维通道都会带出数据，缓存里也常留着原文。怎么办：画一张包含缓存、日志、备份与第三方接口的流转图，逐条核对目的地址；只核数据库位置，边界说明与实际往往对不上，检查时很难自证。
误区四：脱敏一次就安全
脱敏规则要随数据组合变化，多个字段拼接后可能重新识别到个人。为什么：单字段看不出问题，关联分析才暴露。做法是按用途设定脱敏强度并定期复评，日志与备份同样要处理，否则脱敏只覆盖了主链路，旁路照样泄露。
误区五：承诺等于结论
供应商声明不用于训练，属于合同承诺而非合规判定。怎么办：把数据用途、留存期限、子处理者与审计权写进合同，并保留抽查权利；合规路径是否成立，要由客户方法务与安全部门出具结论，技术方案不能替代，也不该代签。
适用与不适用
适合谁
- 正在做数据合规评审的企业安全与法务团队
- 使用外部模型服务、需要界定边界的业务方
- 要准备监管检查材料并对外说明的合规负责人
不适合谁
- 数据公开、无敏感字段、不存在流转争议的业务场景
- 只需要一句合规口号、不愿做链路核查的团队
典型场景
某零售企业在评审客服助手时，业务方认为数据在本地就万事大吉。安全团队抽取一条会话追查，发现日志平台把完整对话发到了外部监控服务，缓存中也留有未脱敏原文。团队补充了字段级脱敏与出站白名单，并把审计权条款写进采购合同，评审才通过，会话样本也留作后续复核。
可执行步骤
- 先由合规部门书面定义域的范围与判定标准，并明确解释权归属与签认人
- 画一张数据流转图，逐条标出缓存、日志、备份与外部接口的位置与责任人
- 抽取一条真实业务请求做全链路追踪，逐个核对每个目的地址与端口
- 逐条核对合同中的数据用途、留存期限、子处理者与审计权与抽查条款
- 把五项误解转成可勾选的评审问题清单，纳入上线检查与季度自查范围
常见坑
- 把不出域当成全本地，方案被迫自建机房，算力与运维成本抬高，最终因能力不足又偷偷接回外部接口。
- 只做位置合规，权限与删除流程缺失，检查时无法自证，整改要重做管道，前期投入几乎白费。
- 忽略日志与监控上报，数据从旁路流出，边界说明与实际不符，出问题时责任很难界定清楚。
自检与验收清单
- 域的范围是否由合规部门书面定义并明确签认人
- 流转图是否覆盖缓存、日志、备份与外部接口
- 是否至少做过一次全链路追踪抽查并把记录留存归档
- 合同是否写明数据用途、留存期限、审计权与抽查权
- 五项误解是否已转成可勾选的问题清单并纳入评审
常见问题
本地部署还需要做等保吗？
需要。等保针对系统整体，与数据放在哪里无关，定级、备案与测评按系统承载的业务与数据判断。把本地部署当作免测理由，检查时会被直接指出，整改周期也很难压缩。
脱敏后就可以外发吗？
要看脱敏强度、接收方与用途。单字段脱敏在关联后仍可能重识别，外发前应做组合字段评估，尽量只发任务必需的最小集合，并保留接收方使用范围的约束条款与复核记录。
供应商说数据不用于训练，能信吗？
可以作为谈判起点，但不能直接当合规结论。要把承诺落到合同条款，明确留存期限、子处理者清单、删除时限与审计权，并保留抽查机制；否则承诺无法验证，出现争议时也缺少依据。