模型可以外接，数据控制权不能外置
某大数据中心上线了第三方 AI 智能问数平台。上线第三周，安全团队发现：房管部门的用户，通过问答间接获取了交通部门的业务统计数据。
追查链路很简单：AI 使用共享服务账号直连数据库，房管用户提问"本月各窗口办事量排名"，AI 生成的 SQL 没有租户过滤条件，直接把所有部门数据汇总返回了。用户从排名中反推出了交通部门的业务量级。
更隐蔽的是：排名泄漏（"我局排第3"确认了前两名的存在）、对比泄漏（"比交通局低40%"直接暴露了量级）、汇总反推（用户用全市总量减去本局数据推算其他部门合计）——这些都不需要返回具体明细就能推断。
但最危险的场景是"张三问题"：张三在分租户"交通局"是普通分析员，在主租户"大数据中心"是数据运维工程师。当他在交通局租户提问时，如果 AI 取了他的全局最高权限去执行——主租户的数据边界就被击穿了。他不是黑客，没有越权操作，是系统身份绑定粒度出了问题。
根源在于：AI 查询链路没有继承数据中台原有的租户身份、行列权限、数据目录和审计规则。数据治理上下文在 AI 这条路径上被压缩，甚至丢失。
数据类 AI 的安全与可信，不取决于模型部署在中台内还是中台外，而取决于身份、权限、语义、执行和审计五类控制是否始终由数据中台掌握。
模型可以外接，统一入口可以外接，业务应用可以外接，但数据控制权不能外置。
一、外接AI的三类系统性失效
外部 AI 通过 SSO 和 API 网关理论上可以获取用户上下文。但要让外部 AI 完整继承中台的数据治理能力，绝不是"接一个接口"那么简单。
（一）权限上下文丢失
中台的权限控制包括数据源级、表级、列级、行级、租户隔离和用途控制。外接 AI 常见问题是：使用共享服务账号、SQL 执行时不校验最终用户权限、不携带租户和委托身份。结果中台看到的是一个高权限服务账号，而非"某租户下的某位业务人员"。更隐蔽的是前述"张三问题"——一个人在主租户和分租户各有一个账号，SSO 返回全局最高权限，分租户的数据边界被无声击穿。
身份必须以最终用户和所属租户为准；授权必须在每次查询和每次工具调用时强制执行。
（二）治理上下文缺失
中台数据分层存储：ODS（贴源层）、DWD（明细层）、DWS（汇总层）、ADS（应用层）、资产服务层。把全部层级开放给 AI，相当于把原料仓库、半成品车间和成品库房的钥匙都交给一个新人。AI 不知道哪个是权威来源、哪个口径适用、哪个已完成校验。
根本问题在于：AI 的"可见数据面"应该是什么？ 答案是只开放"成品库房"——已发布的数据产品和指标服务，中间层通过三层过滤对 AI 不可见：
第一层：元数据注册过滤 → 只有编目审核通过的数据资产进入 AI 检索范围
第二层：分层标记 → AI 只检索 published 层级
第三层：运行时策略拦截 → 拦截未授权查询
典型例子：客户问"整合工业企业的生产、用电、纳税、社保数据分析产值排名"。五套系统的企业标识各不相同（社会信用代码、户号、纳税人识别号、社保登记号），外接 AI 用企业名称模糊匹配，把"钢铁有限公司"和"钢铁有限责任公司"当两家企业。内置 AI 调用主数据映射表精确关联，同时自动提示口径差异（产值是规上、用电是全行业）。
（三）工具能力断链
数据中台沉淀了大量能力：数据归集、质量校验、任务调度、资产检索、审批共享、政务 API 等。外接 AI 每对接一个工具都要处理身份、租户、脱敏、审计、限流等适配工作，接口成百上千时维护成本爆炸。结果是 AI 只接入少数查询接口，退化为"会聊天的入口"。
来看真实对比——数据管理员发现业务表空值率从 2% 飙升到 35%：
外接 AI：
AI：建议您：①登录质量平台查看异常 ②在血缘系统追溯来源 ③联系上游管理员 ④创建修复工单 ⑤通知下游负责人 ⑥修复后重新校验
用户：……（手动登录四个系统，耗时两小时）
内置 AI：
AI：已检测到严重告警。✅ 血缘追溯完成 → 市不动产登记中心交换库（最近同步 02:15）✅ 质量工单已创建，指派数据归集组✅ 已通知下游负责人，已标记异常数据产品暂停服务待确认：是否通知登记中心？[确认] [转人工]
用户：确认
AI：✅ 已发送通知，工单已更新。
差距不在模型的聪明程度——而在 AI 能不能真正调动中台已有的工具和能力。
二、AI参与数据治理而非仅消费数据
数据中台真正的差异化在于将 AI 嵌入数据编目、质检、开发、分类分级等治理生产环节。
（一）AI数据编目
基于元数据和血缘关系自动识别库表字段、推断业务含义、生成标签建议，采用"AI 建议 + 人工审核"机制。
（二）AI数据质检
业务人员用自然语言描述"检查近三个月同一证件号在同一天是否存在重复办理记录"，AI 转化为可执行的质量规则和 SQL，但不能绕过人工审核直接投产。
（三）AI数据开发
用户用自然语言描述需求，AI 在授权数据资产范围内生成开发模型、SQL/Spark 作业和测试方案，经开发人员审核后进入发布链路。
（四）AI分类分级
结合字段名、数据类型、样本数据和业务语义识别敏感字段（如"LXDH"→推测为"联系电话"→建议标记为敏感个人信息）。AI 辅助打标，最终结论由安全责任部门确认，完成后自动联动到脱敏策略、访问控制和 MCP Tool 输出控制。
省 Token：外接 AI 每次回答"近三月不动产登记量"需要：遍历 2,347 张表 → 筛选 12 张 → 查 186 个字段 → 生成 SQL → 修正语法错误，共约 28,000 tokens。内置 AI 在数据产品目录中命中 1 个产品，读取元数据 + 生成参数化查询，约 1,300 tokens。省约 95%。 即使保守估算 50%-70%，日均数千次问数场景下累积差异可观。
三、原生智能中心：AI纳入治理体系
AI 不直接拥有数据，AI 只在中台授予的边界内调用受治理的数据能力。
（一）统一身份
智能体以用户委托身份执行操作，每次 SQL 查询、API 调用、MCP Tool 调用都携带完整的身份与租户上下文，由中台权限引擎裁决。用户看不到的，AI 也不能看。
（二）统一语义
AI 优先调用数据产品而非裸表。"全市不动产登记月度统计"是一个已定义口径、已完成校验、已设定访问范围的数据产品。用户提问时直接调用该指标服务，确保口径一致、结果可解释、责任可追溯。
（三）统一执行
智能体可在授权范围内创建工单、发起审批、生成开发模型，但不能由模型自由执行，必须通过中台的权限校验、审批机制和审计网关。
用户请求 → 智能体理解意图 → 查询目录和权限策略 → 选择已注册可授权的 Tool → 执行时身份校验、行列过滤 → 返回脱敏结果 → 统一记录全链路
四、多租户：隔离数据与AI上下文
传统外接 AI 以全局单例部署，多个租户共享运行环境和知识库。提示词不能当隔离边界——提示词注入、上下文污染、缓存串用都可能造成跨租户风险。
张三问题在架构层面的三条风险路径：
主租户：市大数据中心（可看全市数据）
├── 分租户 A：房管局
├── 分租户 B：交通局
└── 分租户 C：民政局
身份合并风险：SSO 返回全局身份集合，AI 取最高权限，分租户边界被击穿。
知识库跨租户污染：RAG 检索到了主租户权限下的数据字典和指标文档。
会话缓存串用：上一轮主租户的查询结果残留在模型上下文。
攻击面来自合法的用户、合法的界面、合法的问题——出错的是身份绑定的粒度。
因此必须从"一个账号一套权限"升级为"一个用户在当前租户下的一套权限"，覆盖四个层面：控制面（独立智能工作区）、数据面（隔离数据源、向量库、缓存、对话历史）、推理面（提示词和日志不跨租户复用）、运维面（按需授权、审批留痕、操作审计）。
五、奥腾AI数据中台：智能中心原生内置
奥腾 AI 数据中台在数据归集、开发、治理、资产、目录、API 服务、统一身份和运营管理之上内置智能中心。与通用智能体平台的区别在于：
通用平台解决"如何构建 AI 应用"；奥腾解决"AI 可以在什么数据范围内构建、调用、执行和输出"。
奥腾 AI 数据中台架构：
├── 数据治理与服务能力
│ ├── 数据编目、归集、开发、质量、分类分级
│ ├── 数据资产与目录、API 与数据服务
│ └── 身份权限与租户、审批授权与审计、运营管理
└── 内置智能中心
├── 模型接入 │ 知识库制作 │ 智能体制作 │ 工作流编排
├── 工具注册 │ MCP 制作 │ 智能问数与检索
└── 智能编目、质检、开发、分类分级 │ 运营审计
知识库纳入统一治理：管理密级、访问范围、是否允许进入外部模型上下文、检索结果脱敏策略。智能体具有明确的职责边界和权限范围。工具与 MCP 每一项都绑定调用主体、租户范围、脱敏规则、审批条件和审计追溯。
六、架构分层：能力层与控制层分离
模型是能力层，中台是控制层，二者分层独立，模型可替换迭代，数据控制体系保持稳定。
架构层级从上至下依次为：大模型服务/模型能力层、中台内置智能中心、中台治理控制面、数据与服务资源层。模型可替换、可路由、可评测，智能中心依托中台统一策略管控全域数据操作，治理控制面提供全维度规则与权限支撑，资源层提供标准化治理后数据。
（一）各层级核心职责与禁忌
1、模型能力层：核心职责为理解、生成、推理、工具选择；不应承担掌握高权限账号、决定授权的职责。
2、智能中心：核心职责为智能体构建、知识检索、工具编排；不应承担代替责任部门定义业务口径的职责。
3、中台治理控制面：核心职责为身份认证、授权执行、质量控制、审计；不应依赖提示词实现安全隔离。
4、数据资源层：核心职责为提供受治理的数据产品和指标服务；不应向模型开放裸数据和无限制访问。
即使更换模型厂商或编排引擎，数据控制体系不受影响。
七、可信机制与建设路径
（一）核心可信机制
1、回答有依据：系统不仅返回数字，还附带数据产品名称、口径、更新时间、责任部门。
2、高风险可审批：导出敏感数据、创建对外服务、批量数据操作等必须确认或审批。AI 可以建议和生成草稿，但不能替人完成高风险决策。
3、全过程可审计：记录用户意图、模型版本、检索目录、调用工具、策略命中、数据版本、脱敏状态、审批记录。出现争议时能追溯完整责任链。
（二）阶段化建设路径
遵循先治理后智能、先只读后可写、先辅助后协同的原则。第一阶段受控智能问数，第二阶段治理类 AI 助手（编目、质检、开发、分类分级），第三阶段受控工具调用与工作流，第四阶段跨域智能协同。
八、结语
回到开头——房管用户看到了交通部门的数据。这暴露的是架构分歧：当 AI 作为"外来者"接入数据平台，它究竟继承什么、放弃什么？
如果 AI 用自己的服务账号和权限模型操作平台数据，那它不是"辅助用户使用数据"，而是"替代平台管理数据"。那些经过多年打磨的租户隔离、行列权限、指标口径和审批链路，在 AI 这条路径上变成了装饰。
把 AI 智能中心做成原生模块——统一身份、数据产品目录、权限引擎和审计网关——它就不再是安全缺口，而是数据治理体系的延伸。
模型负责智能，中台负责治理；模型负责生成，中台负责执行；模型可以外接，数据控制权必须始终留在平台之内。
上海奥腾计算机科技有限公司，让数据同频，与城市共进。