域边界定义
明确是按物理机房、专有云区域还是租户隔离来划域，并把系统、数据库、对象存储逐一对应。边界含糊时，后续所有判断都缺少依据；划域方式还会影响合同条款与责任划分，必须先定下来再谈方案。
流转可审计
能回答谁在什么时间把哪类数据发到了哪里，包括同步、备份、日志上报与运维访问。审计记录要保留足够时间并防篡改；仅仅留下日志还不够，检索与导出能力才决定检查时能否快速自证。否则检查时很难自证。
处理位置可证
推理请求本身携带数据，要确认推理、向量检索、缓存与日志分别落在哪一侧。仅看数据库位置不够，缓存与第三方服务常被遗漏；模型服务若部署在外部，还要确认请求内容是否被留存或用于训练。
合规路径
判断是否构成数据出境，或需做安全评估、订立标准合同、开展个人信息保护影响评估。结论由法务与安全部门出具，技术方案不替代；不同路径的准备周期差别很大，也需要在项目排期里预留时间。
删除与举证
合同终止或用户请求删除时，能否在约定时间内清除各副本并出具记录。缺少删除能力，再严格的边界也会在事后被质疑；备份、缓存与日志副本都要覆盖，删除流程还应定期演练并留痕，删除记录要能对外出示。
适用与不适用
适合谁
- 金融、医疗等对数据位置有明确要求的企业
- 使用外部模型服务、需要评估合规路径的团队
- 要准备监管检查材料的合规负责人
不适合谁
- 数据完全公开、无敏感信息的业务，也没有可核查边界。
- 尚未梳理数据资产与系统清单的组织
典型场景
某医疗机构在引入辅助问诊功能前做评估，发现推理虽在本地，但向量检索调用了外部接口，病历片段会随之传出。团队改为本地检索、仅回传脱敏摘要，并补充了访问日志与删除流程，才通过内部评审，评审记录也纳入了年度自查。
可执行步骤
- 明确域的划分方式与覆盖系统，形成可对外说明的边界文件，并经评审，明确责任人
- 逐条梳理数据流转路径与载体，标注缓存、日志与第三方接口，形成清单，并标注责任人
- 确认推理、检索、缓存与日志的实际位置，必要时到机房现场核验，形成位置清单
- 由法务与安全判定合规路径，明确所需材料与准备周期，写入项目计划，并留存结论
- 制定删除流程并验证可举证，覆盖备份与各类副本，形成操作记录并定期演练
常见坑
- 只核数据库位置，忽略缓存、日志与第三方接口，数据仍在流出，边界说明与实际不符，检查时难以自证。
- 把本地部署等同于合规，遗漏权限、审计与删除要求，检查不通过，整改往往要重做架构，成本很高，返工周期很长。
- 删除只清主库，备份与副本长期留存，事后被追问时无法举证，解释成本很高，也可能被认定为未删除。
- 流转记录不完整，检查时无法还原调用链，解释成本很高，也容易引发监管关注，整改周期不可控，检查结论也不好看。
- 脱敏规则由技术单方设定，未获业务与安全认可，风险仍然存在，责任却难以界定，评审时也难通过。
自检与验收清单
- 域边界划分方式是否书面明确，是否有文件与责任人
- 数据流转路径是否逐条梳理并核对，责任人是否明确
- 推理与检索位置是否现场确认，是否有书面结论
- 合规路径是否由法务安全判定，是否有书面结论
- 删除流程是否可执行并可举证，是否演练过并留档
常见问题
数据不出域等于数据不出企业吗？
不等于。域可以是机房、区域或租户，企业内部不同部门之间也可能有边界要求。具体范围要由合规部门按监管要求确定，技术团队不能自行缩小或扩大解释，也不能只做口头说明。
用外部接口一定违规吗？
不一定。是否合规取决于数据类型、脱敏程度、合同条款与适用监管要求。需要做合规判断，不能一概而论，也不能仅凭供应商承诺或资质说明下结论，也不能照搬同行做法，判断要有书面结论。
日志里能存请求内容吗？
要看日志用途与保存期限，并对敏感字段做脱敏或加密。排障需要与最小化原则平衡，建议分级保存、限期清理，并限制可访问日志的人员范围，范围也要写进制度，访问要留日志。