数据可见但不可得：大模型时代的企业数据访问控制新范式

定义：什么是“积极数据控制”？

“积极数据控制”（Positive Data Control，简称 PDC）是一种面向大模型（LLM）参与数据访问场景的安全架构范式。它的核心定义可以概括为：在大模型与底层数据存储之间，强制插入一个确定性的控制层，由该控制层负责所有请求的解释、校验、执行与结果脱敏，从而确保大模型“理解数据需求，但永不直接接触数据”。

从技术视角看，PDC 并非一种单一的算法或工具，而是一套架构设计原则。它明确了四个“不允许”：用户不允许直接向数据库发起查询；大模型不允许直接接收到数据库的原始返回结果；所有自然语言请求必须经过结构化控制层翻译与校验；所有下发的查询必须经过策略引擎的许可与审计记录。

从业务视角看，PDC 解决了企业内部“数据可用性与安全性”的矛盾。业务人员希望用自然语言获取数据洞察，安全团队则担忧数据泄露和越权访问。PDC 提供了一个双方都能接受的中间态：员工可以享受大模型带来的交互便利，而敏感数据的物理访问路径被严格锁定在受控管道内。

背景与价值：为什么传统数据治理不够用了？

传统企业数据访问治理依赖三层体系：身份权限（如 RBAC/ABAC）、数据库级权限、审计日志。这套体系在“人直接操作数据库”的时代是有效的。但当访问入口从“SQL 客户端”变成“自然语言对话界面”时，矛盾随之而来。

核心矛盾在于语义鸿沟。 用户不会说“SELECT * FROM orders WHERE customer_id = 123”，而是说“帮我查一下这个客户的最近订单情况”。大模型擅长将自然语言翻译成 SQL，这本是效率的提升。然而，一旦允许大模型直接连接数据库，风险就会指数级上升：

1. 提示注入攻击： 恶意用户可能通过精心构造的对话内容，诱导大模型生成越权查询语句，例如绕过条件限制导出全表数据。
2. 敏感字段隐性泄露： 即使查询本身合法，模型可能因为上下文学习能力，将结果中的隐私信息（如薪资、手机号）记入自己的“会话记忆”，在后续无关对话中回显。
3. 动态权限判断失效： 传统数据库权限是静态的，而自然语言请求中的“权限边界”是动态的。例如“分析一下销售部门薪酬”该请求是否合法，取决于当前用户的职级，这远超 SQL 语法层面的判断能力。
4. 结果无差别返回： 即使 SQL 正确，原始结果集可能包含超出用户需要或权限范围的字段（如附带其他客户数据），模型不做二次裁剪。

PDC 的价值正是为了堵住这些漏洞。它改变了安全假设：从“相信用户和模型不会犯错”转变为“默认一切请求都不可信，只有经过确定性规则验证后才放行”。

核心组成：PDC 的四大关键模块

PDC 架构并非单一组件，而是由四个职责清晰的模块串联而成。理解这些模块，有助于在实际系统中进行落地设计。

1. 意图解析层（LLM 沙箱）

该层是唯一涉及大模型的模块。它的职责是接收用户的自然语言输入，仅执行“语义理解”和“草拟查询”两项任务。例如，将“分析华东区上季度销售额”转换为中间表示（如 JSON 结构：{“维度”: “区域”, “过滤”: “华东”, “指标”: “销售额”, “时间”: “上季度”}）。

关键约束： 该层运行在完全隔离的网络环境中，无法访问任何真实数据库地址、连接凭据或数据字典。它只能看到表结构的元数据描述（如字段名称、类型注释），而非实际数据内容。这从物理层面切断了模型与敏感数据的通道。

2. 策略校验引擎（确定性系统）

这是 PDC 的“裁判员”，完全由规则代码构成，不包含任何大模型组件。它的输入是意图解析层输出的结构化请求，输出是“通过”或“拒绝”的判定。

校验动作分为三个层级：

• 语法级校验： 校验生成的查询语句是否符合既定模板，是否包含明显恶意特征（如全表删除、跨库联查）。
• 语义级校验： 将结构化请求与权限策略库比对。策略库通常基于 RBAC 扩展，增加了“数据密级”（如公开、内部、机密）和“环境上下文”（如工作时间、IP 段）维度。
• 资源级校验： 检查请求涉及的数据表、字段是否在用户授权范围内。例如，普通销售代表无权访问“薪资”字段，即使他请求了，该字段也会被策略引擎从目标字段列表中剥离。

3. 查询执行与拦截层

通过校验的请求会进入该层，由系统以受控账户身份连接真实数据库执行查询。值得注意的是，执行过程采用“最小权限账户”，即该账户仅拥有执行查询所需的最小表权限，且每次连接的会话超时时间极短。

同时，该层强制执行结果行数上限和字段裁剪。例如，系统限制单次查询最多返回 1000 行，防止数据批量导出。返回结果在离开该层前，会被封装为“已过滤数据集”。

4. 结果后处理与审计层

大模型此时才再次参与。它收到的是已经脱敏且裁剪后的数据集（例如，手机号中间四位打码、具体薪资转化为区间段）。模型仅负责将这份数据组织成自然语言回答或图表。整个过程，大模型从未接触原始数据。

此外，每一次完整的请求-响应过程都会生成结构化日志，包括：用户身份、意图结构、策略判定结果、执行 SQL、返回行数、脱敏规则。这些日志不可篡改，用于事后追溯与安全分析。

工作原理：以一次典型查询为例

为了更直观地理解 PDC 的工作流程，以“某部门经理查询本部门员工薪资分布”为例进行推演：

1. 输入阶段： 用户向对话窗口输入：“帮我看下我们部门员工的薪资范围分布。”
2. 意图解析： 沙箱内模型将其解析为：{“表”:”employee”,”字段”:[“salary”,”dept”],”过滤”:{“dept_id”:”当前用户所属部门”},”聚合”:”histogram”}。解析结果中不包含真实的数据内容。
3. 策略校验： 策略引擎发现请求字段包含 salary，随即查询策略库。策略库判定：该用户拥有查看“本部门人员薪资分布”的权限，但无权查看具体个人薪资。因此，引擎在结构化请求中追加标记 “salary_mode”: “bucket”，并要求聚合粒度不低于“每 5 万一个区间”。
4. 执行查询： 执行层以受限账户运行优化后的 SQL（如 SELECT width_bucket(salary, 0,100000,10) as bucket, count(*) FROM employee WHERE dept_id = ? GROUP BY bucket）。数据库返回的是分配区间计数，而非明细。
5. 结果后处理： 控制层将区间计数的结果集交给大模型。大模型据此生成描述：“贵部门薪资分布集中在 2-3 万区间，占比约 60%。” 全程，模型没有看到任何一个人的具体工资数额。

典型场景与适用边界

PDC 架构非常适合以下几类场景：

• 企业内部 BI 智能问答： 允许业务人员用自然语言查询销售、运营数据，但避免直接暴露客户级明细。
• Text-to-SQL 的安全增强： 作为常用 Text-to-SQL 工具的前置安全网关，过滤非法查询与越权字段。
• 数据治理 Agent： 用于构建“数据管家”类应用，允许 Agent 理解数据目录，但执行变更操作时需走 PDC 审批流。
• 多租户数据服务： 在 SaaS 平台中，确保租户 A 的模型永远无法通过上下文记忆或注入攻击获取租户 B 的数据。

适用边界方面： PDC 不适合对“性能损耗”极敏感的低延迟交互场景（因为多了一层校验与脱敏）；也不适合完全非结构化的数据探索场景（如图像数据理解），它当前更适用于结构化表格数据访问。

相关概念区别与联系

区别于“数据脱敏”工具： 数据脱敏只是 PDC 结果后处理层的一个动作。PDC 更强调从请求入口到结果出口的全链路管控，脱敏只是其中一环。

区别于“代理”（Proxy）模式： 传统代理只做流量转发，不感知业务语义。PDC 的核心在“策略判定”，它理解了请求的语义意图（查什么、为什么查），而不是单纯转发 SQL。

区别于“数据沙箱”： 沙箱侧重隔离计算环境，PDC 侧重放行控制。沙箱允许用户在独立环境内自由计算，PDC 则强调即便在授权环境内，每一次具体操作仍然要经过逐次审批。

注意事项与落地建议

1. 策略库的维护是最大难点。 PDC 的安全效果不取决于大模型，而取决于策略引擎的规则覆盖度。企业需要投入精力将组织架构、数据分类分级、岗位职责映射为机器可读的策略。如果策略不全，再好的架构也会出现漏洞。

2. 注意意图解析的容错。 大模型在解析意图时可能出错（如错误理解“客户”是指哪张表）。建议为意图层设置置信度阈值，低于阈值的请求直接转人工审批，而不是静默放行。

3. 性能开销需权衡。 相比直连数据库，PDC 链路会增加几百毫秒到秒级的延迟。对于内部报表场景通常可接受，但对于实时风控等场景，建议只对高敏感查询启用 PDC，非敏感查询走老链路。

4. 审计日志必须定期演练。 架构提供了日志能力，但安全团队需要定期利用日志进行攻击复盘演练，验证恶意请求是否真的被拦截。

总结

积极数据控制（PDC）重新定义了企业 AI 数据访问的安全边界。它的核心思想清晰而坚定：让大模型负责智能，让确定性系统负责安全。 在 PDC 架构中，大模型被当作一个“翻译器”和“解释器”，而绝非“数据库管理员”。这套范式不会限制大模型理解数据的能力，反而通过将“理解”与“访问”解耦，让大模型在合规前提下充分发挥其对业务问答的辅助价值。对于任何计划构建企业级数据问答、AI Agent 或智能 BI 的团队而言，将 PDC 作为默认的安全架构基线，是规避大模型数据泄露风险的最有效手段之一。