> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/data-not-leaving-domain-usable-invisible-ai-compliance-retry.md).

# 数据不出域 数据可用不可见：2027年企业AI合规怎么做

本文整理自 Duaer 文档站，围绕企业AI落地中“数据不出域、数据可用不可见”的合规难题，介绍如何画清数据流、选择计算路径、落实最小可见原则，并给出可追踪的衡量指标。

## 为什么这件事比想象中难

很多企业在推进大模型应用时，都会撞上同一堵墙：业务部门希望模型读懂合同、工单和客户记录，安全部门则明确要求原始数据不能离开本单位的网络边界。两边各有道理，于是项目要么停在试点阶段，要么演变成“先复制一份脱敏数据再说”，风险反而悄悄扩散。“数据不出域、数据可用不可见”正是为解决这一矛盾而提出的思路：数据留在自己的边界之内，外部只能拿到计算结果，拿不到原始数据本身。

边界与价值天然拉扯。数据之所以有价值，恰恰在于它会被反复调用、被不同角色理解，而边界的作用就是限制调用。当你想让一个外部模型或第三方工具“看一眼”数据时，边界就被打穿了。更麻烦的是，数据很少只待在一个地方：它会进入向量库、缓存、日志、提示词模板和调试截图，每一个副本都是一个新的出域口。多数企业在试点阶段并不清楚自己有多少副本，等到审计时才发现。

常见误区主要有三个。第一，是把“不出域”等同于“不上云”。私有部署并不自动意味着安全。如果检索服务把整段原文拼进提示词，再发送给一个外部推理接口，数据照样出了边界。第二，是把脱敏当成可用的充分条件。简单替换姓名、手机号，往往既削弱了语义，又留下了可被关联还原的字段组合。第三，是以为买一套隐私计算工具就能即插即用。隐私计算解决的是“怎么算”，而“算什么、谁能看结果、结果保留多久”仍然需要业务规则来定义。

## 怎么做才对：先画数据流，再选计算位置

实践中比较稳妥的做法，是先回答三个问题：数据在哪里产生，计算在哪里发生，结果交给谁。由此可以比较三类常见路径。第一类是把模型搬到数据旁边，即模型私有部署在数据所在域内，适合原始数据敏感、调用频繁的场景，主要代价是算力与运维成本。第二类是受控查询接口，外部只能通过有限接口获取聚合结果或字段级答案，适合问答、统计、报表等场景，代价是灵活性受限，需要专门设计接口。第三类是跨域协同计算，如联邦学习、多方安全计算等，适合多家机构共同建模，技术门槛高，性能开销大。

大多数企业的第一步并不需要最复杂的方案。把知识问答限定在域内检索，只把经过筛选的片段交给模型，并记录每次取用了哪些片段，就已经能覆盖相当一部分需求。这也是为什么在落地的基础条件中（可参考[2027年企业AI落地需要什么条件](https://doc.duaer.com/zh/guides/enterprise-ai-adoption-requirements/)），数据分级与权限体系应当先于模型选型。

## 怎么做才对：最小可见原则

无论选哪条路径，都应遵循“最小可见”：用户和模型只看到完成任务所必需的最少信息。落到具体动作上，包括：按字段而不是按整张表授权；输出尽量是结论、数值或引用编号，而不是整段原文；为提示词和检索上下文设置保留期限；对每一次跨域调用记录请求方、字段范围和用途。这些规则听起来琐碎，却恰好把“可用”和“不可见”拆成了可以验证的工程条款。

如果你希望把这些规则直接配置成一个小范围试点来验证，可以在 Duaer（https://www.duaer.com）里搭建流程，逐条检查字段权限和输出控制是否真的生效，是否适合你的系统现状，还需要结合自己的环境评估。

## 常见的失败模式：试点成功，规模化失败

不少团队在一个部门内跑通了方案，推广到全集团时却卡住：不同系统的数据标准不一致，权限模型无法统一，审计日志分散在各处。这类问题与试点到规模化的卡点高度相似，可以对照[企业AI落地的常见陷阱](https://doc.duaer.com/zh/guides/enterprise-ai-adoption-pitfalls/)排查。建议在试点阶段就把审计和权限的统一接口列为验收项，而不是等到规模化时再补。

## 如何衡量

“数据可用不可见”不能只靠感觉判断，需要一组可追踪的指标：数据出域事件数，理想状态是每一次都可解释、可追溯，而不是追求零记录；未授权访问的拦截次数与原因分布；任务完成率，即在限制条件下，业务问题真正被解决的比例；审计覆盖率，即有多少跨域调用留下了完整记录；以及响应时延的变化。其中任务完成率最容易被忽略。如果边界收得太紧，系统会变得很安全却没有用，这同样是一种失败。

## 这一周可以做的事

不必等待完整方案，本周就可以做一件具体的事：选一个正在推进的 AI 场景，用一张纸画出它的数据流。数据从哪个系统来，经过哪些副本和服务，最终输出给谁，每个环节由谁负责、保留多久。画完之后，你通常会发现至少两个超出预期的出域点，它们就是下一步整改的清单。

行动建议：先按上面的数据流图梳理一个场景，标出所有副本与出域点，再决定用哪一条计算路径。

如果你准备好把这套流程真正跑起来，欢迎到 https://www.duaer.com 注册试用 Duaer，先用一个边界清晰的内部场景做小范围验证，把数据接入、权限边界和审计记录放在同一个试点里检验，用实际结果判断“可用”与“不可见”能否同时成立。

合规不是把数据锁死，而是让每一次使用都有边界、有记录、有结果。

## 常见问题

### 数据不出域是否就等于私有部署？

不等于。私有部署只说明模型和数据位于本单位网络内，但如果检索结果整段拼接进提示词，再发送给外部推理接口，数据依然会离开边界。真正的要求是控制每一次调用中实际传出的内容。

### 企业如何在实践中落实“数据可用不可见”？

可以先画出数据流，标出所有副本与出域点，再选择合适的计算路径。大多数企业可以从域内检索加受控输出开始，只把筛选后的片段交给模型，并按字段授权、设置保留期限、记录每次跨域调用。

### 如何判断数据不出域方案是否有效？

可以跟踪几类指标：出域事件是否可解释、可追溯，未授权访问的拦截情况，业务任务的完成率，审计日志的覆盖率，以及响应时延的变化。其中任务完成率尤其重要，边界过紧会让系统安全却无法使用。