AI+BI时代的数据安全评分卡：五个必做项与三个高风险项

导语

聊"数据安全"之前，先做一次口径校准。在传统BI时代，我们讨论的数据安全，边界相对清晰：账号权限、行列级管控、传输加密、审计日志、备份恢复——本质上是"人访问数据"这条链路的防护。评估维度成熟，等保、GDPR、ISO 27001 都能一一对应。

但当大模型嵌入分析链路后，"数据安全"这个词的所指发生了变化。用户提问一句自然语言，背后可能触发元数据抽取、SQL 生成、结果回传、上下文拼接、模型推理——这条链路上多了一个此前不存在的角色：大模型本身。它可能是外部 API，也可能是私有化推理服务；它会不会保留对话、会不会把 A 客户的数据带到 B 客户的上下文、会不会因为一次 prompt 注入而越权取数，这些问题在传统评估表里几乎找不到对应条目。

换句话说，AI+BI 语境下的数据安全，至少要在传统那套之上，再叠加三个新维度：传给模型的是什么（原始明细还是聚合结果）、模型会不会留下什么（对话保留策略）、模型能不能被诱导做什么（权限穿透与注入防护）。任何一个维度失守，前面十年攒下的权限体系都可能被一句提问绕过。

这也是我们想提出"数据安全评分卡"的原因。与其在选型 RFP 里堆几十条泛泛的合规术语，不如把评估维度收敛成一张可打分、可自查的清单：五个必做项——数据最小化、传输加密、零保留策略、字段级权限贯通、审计可追溯；三个高风险项——原始明细外传、权限与 AI 链路脱钩、对话上下文跨租户污染。

下文按这八个维度展开，既可用于选型时对候选产品打分，也可用于已上线 AI+BI 系统的内部自查。评分卡不是终点，它更像一张地图，帮助数据负责人、IT 与合规团队在同一张表上对话。

为什么这个问题值得现在重视

一个容易被忽略的事实是：AI+BI 的数据安全风险，并不是"多了一个大模型"这么简单，而是数据流转路径本身被重构了。

传统 BI 里，一份报表从数据源到用户屏幕，路径是可枚举的：数据集 → 权限过滤 → 查询引擎 → 可视化组件。安全团队评估的是节点，管控的是通道。而在引入自然语言问数、仪表板智能洞察、洞察 Agent 之后，链路里冒出了一批新对象——元数据（表结构、字段语义、指标定义）、聚合结果（经过 BI 层汇总后的数值）、对话上下文（用户的提问历史与模型的中间推理），它们都可能以不同形式触达大模型。任何一层如果按"反正是加工后的数据"来放行，都可能在事后审计时发现：离开企业边界的信息，比预想的多。

这就带来了评估视角的错位。等保 2.0、GDPR、个人信息保护法这套框架，原本围绕"数据存储、访问、传输"三个动词展开，覆盖不到"数据被用于模型推理"这个新动作。GDPR 讲的"最小保留期限"，在 AI 侧需要被翻译成"对话不落盘、上下文不跨会话保留、prompt 不进入训练语料"；等保 2.0 讲的"边界防护"，在 AI 侧需要被翻译成"传给模型的载荷做过聚合与脱敏"。不是新造一套标准，而是把老标准的适用范围向 AI 侧延伸一层。

从产品视角，想强调一个可能不太受欢迎但必须说清楚的判断：安全能力不能作为一个"增值模块"售卖，它必须是产品架构层面的默认行为。如果数据最小化要靠客户自己配脚本、零保留策略要靠合同条款兜底、字段级权限要在 AI 链路里重新声明一遍，那这套体系在真实业务压力下几乎一定会漏。默认安全（secure by default），意味着聚合而非明细、零保留而非可配置保留、权限贯通而非权限重建——这些应当写进产品的出厂设置，而不是留给实施顾问去开关。

评分卡的价值，正是在这里。合规要求写在文件里往往是抽象的："采取必要的技术措施保障数据安全"——什么叫必要？什么叫足够？IT、法务、业务、供应商各有各的理解。把这些抽象要求拆解成可配置的产品动作（比如"确认智能洞察是否只传输聚合结果"）、可验收的技术证据（比如"审计日志能否检索到每一次模型调用的输入摘要"）、可打分的评估条目（比如"字段级权限是否在自然语言问数场景下同样生效"），讨论才有共同语言。下文的八项，就是按这个思路拆的。

评估维度一：五个必做项——从传输到留存的基础线

五个必做项，本质上是把"传给模型的载荷"和"模型接触后的痕迹"这两条新链路，纳入原有的安全治理框架。它们没有炫技成分，但缺一项，评分卡就不算及格。

必做项 1：数据最小化——只传元数据与聚合结果。在"仪表板智能洞察"这类场景里，产品应当默认只向大模型发送两类内容：一是仪表板的结构定义（表名、字段语义、指标口径等元数据），二是经过 BI 层聚合汇总后的结果数据。原始明细一行都不出库。这条原则的意义在于，即便模型侧发生任何异常，泄露的也只是已被汇总的、脱去个体识别度的数值，而不是订单表、会员表里的原始记录。它需要在架构层强制，不能作为可选开关。

必做项 2：金融级传输加密——多重防护叠加。传输通道使用 HTTPS 作为基础框架，TLS 1.3 保障握手阶段抵御中间人攻击，AES-128/AES-256 对载荷进行端到端加密，同时对每个数据包附加动态盐值和消息认证码（MAC）用于完整性校验。"加密"和"完整性"是两件事：加密防截获，MAC 防篡改，二者叠加才能保证接收端拿到的数据与发送端逐字节一致。评分时要看这几层是否都到位，而不是只勾一个"支持 HTTPS"。

必做项 3：零数据保留策略——对话不落盘。用户与大模型之间的对话数据，产品侧应当承诺不做任何形式的截取和留存，会话结束即释放。这条对应 GDPR 的"数据最小保留期限"原则，也覆盖等保 2.0 中关于存储环节的要求。评估时不能只看产品宣传语，需要在合同、技术白皮书和实际部署配置里三处对齐：对话是否进入日志？是否进入模型训练语料？是否在私有化部署下也保持一致？

必做项 4：字段级权限贯通——AI 链路继承原有权限体系。这是最容易被忽略的一项。传统 BI 里，用户看到的数据严格受制于其账号权限——某个字段不可见，某个门店不可查。但一旦切到自然语言问数，如果 AI 链路走的是另一套上下文，就可能出现"用户手动查询看不到、问一句 ChatBI 反而能看到"的越权情形。合格的做法是：AI 链路里的每一次取数请求，都必须复用同一套字段级、行级权限规则，聚合结果本身也在权限过滤之后才被生成。权限声明只有一份，AI 只是新的消费入口，不是新的授权边界。

这四项加上后文会展开的审计可追溯，构成评分卡的"基础线"。达不到基础线，后续讨论治理与合规都只是纸面工作。

评估维度二：进阶必做项与产品化配置要点

如果说前四项守住的是"数据流出去"这条线，那么第五项以及随之而来的三项工程化能力，守住的是"事后能追溯、故障不掉线、变更不污染"这条线。

必做项 5：审计日志与异常行为识别。合格的审计能力不是"记下来就行"，而是要做到集中化管理、可检索、可关联。产品侧需要提供统一的审计日志界面，支持按用户、时间、操作类型、资源对象等多维度筛选查询，让安全状态一目了然；更重要的是双向监测——既能识别外部攻击、未授权访问尝试等外向威胁，也能捕捉内部越权取数、异常导出、非工作时段大批量查询等内部违规行为。对 AI 链路而言，每一次自然语言问数请求、每一次智能洞察调用，其输入摘要、命中的权限规则、返回的数据规模，都应当在日志里留痕，作为事后取证与合规审计的证据链。

高可用与备份恢复：安全能力的持续在线。安全能力如果本身不稳定，评分卡就失去意义。观远 BI 基于容器化部署，核心组件去单点、支持多副本，配合 K8s 的自动调度，单节点 Pod 故障可秒级切换到其他可用节点；数据侧采用冗余机制加上云平台定时快照，即便发生数据丢失也可通过快照回滚。审计日志、权限规则、加密通道这些安全组件，本身也在高可用体系的保护范围内，不会因为某台机器宕机而出现"安全裸奔"的窗口期。

开发与消费侧隔离：避免未验证变更污染线上。分析页面（仪表板、自助取数、数据大屏、智能归因编辑）与 ETL 任务均支持开发与消费侧隔离——编辑态实时保存不丢失，但未点击发布前不会影响线上用户所见；ETL 支持草稿功能与历史版本记录，正式发布的版本可一键回滚。这条能力的安全含义是：任何涉及权限、口径、字段暴露范围的调整，都必须经过显式发布动作才能生效，从流程上杜绝"改错一个字段权限，全公司立刻看到不该看的数据"这类事故。

订阅预警的全生命周期管控。订阅与预警是权限"僵尸化"的重灾区——离职员工的订阅还在跑、临时项目的推送半年后还在发。合格的做法是：管理员可设置订阅预警任务的最大有效期上限、开启到期提醒并通过多渠道通知负责人、支持批量修改有效期与启停状态。这套机制把"清理无效任务"从人工巡检变成系统级默认动作，避免历史任务堆积成为数据外泄的暗渠。

评估维度三：三个高风险项——容易被忽视的评分扣分点

必做项守的是基础分，接下来这三项则是评分卡里的"负分陷阱"——一旦命中，前面所有努力都会被打折扣。

高风险项 1：把原始明细直接喂给大模型。这是最常见、也最致命的一种误用。为了追求"AI 分析能力更强"，一些集成方案会把明细宽表、日志表、甚至含个人身份字段的原始数据直接推送到模型上下文，寄希望于让模型"自己做聚合、自己判断敏感度"。这条路径的问题在于：模型没有权限概念，也没有 BI 层的口径抽象——它接触到的是原始颗粒，输出边界完全依赖 Prompt 约束，而 Prompt 是可被引导、可被绕过的。合格的架构必须把聚合层与元数据抽象前置，让模型只在"脱敏后的语义空间"里工作。评分卡里，凡是绕过 BI 聚合层直连数据库明细表的方案，直接判为高风险。

高风险项 2：字段级权限与 AI 侧权限不一致。这一项与"必做项 4"互为镜像。当组织内部同时存在两条取数链路——传统 BI 走一套权限、ChatBI 或洞察 Agent 走另一套上下文时，就极易出现"越权洞察"：用户在仪表板里被过滤掉的字段，通过自然语言提问反而被模型汇总回吐。这种越权往往不会触发任何告警，因为从系统日志看每一次调用都是"合法"的。判分要看的是权限声明是否只有一份、AI 链路是否在每次取数前都完成同一套字段级和行级校验，而不是只在 UI 层做拦截。

高风险项 3：审计与订阅预警缺失，AI 结果无法追溯。AI 生成的分析结论一旦被写进周报、被引用到会议决策，就成为组织记忆的一部分——如果没有留痕，事后既无法复核数字口径，也无法定位是哪一次问答产生了偏差。同样地，缺少订阅预警的到期管控与批量治理，历史任务会持续把 AI 洞察结果推送给早已不该接收的收件人。没有审计的 AI 是黑盒，没有生命周期管控的推送是暗渠，二者叠加，就是评分卡上最难挽回的失分项。

FAQ / 结语

Q1：观远"仪表板智能洞察"会把明细数据发给大模型吗？ 不会。该功能严格遵循数据最小化原则，仅向大模型发送仪表板结构定义（元数据）以及经过聚合汇总后的结果数据，不会传输任何原始明细。换句话说，模型看到的是"图表上已经呈现的那部分内容"，而不是背后的宽表。叠加字段级与行级权限管控，用户能问到的、模型能触达的，都只在其自身权限范围之内。

Q2：零数据保留策略具体保留了什么、没保留什么？ 在「仪表板智能洞察」应用中，与大模型的对话数据不做任何形式的截取保留，这一策略对齐 GDPR "数据最小保留期限"原则，同时满足等保 2.0 对数据存储的安全要求。需要区分的是：对话内容不留存，但审计日志会留存——即"谁在什么时间、对哪个仪表板发起了智能洞察请求"这类操作元数据仍会入审计库，用于合规追溯，二者并不冲突。

Q3：传输链路的加密强度够用吗？ 基础层采用全程 HTTPS，握手环节走 TLS 1.3 抵御中间人攻击；数据层集成 AES-128/AES-256 端到端加密，并对每个数据包附加动态盐值和消息认证码（MAC），实现防截获与防篡改的双重校验。金融、零售等对合规敏感的行业客户可据此对接内部安全评审。

Q4：如果内部安全团队要做一次评分卡自检，从哪里入手最快？ 建议按三步走：先盘"AI 链路是否复用了同一份字段级权限声明"，这是最容易出问题的地方；再看"审计日志是否覆盖了每一次自然语言问数与洞察调用"；最后核对"订阅预警是否有到期机制与批量治理入口"。这三项通过，评分卡的核心失分点基本可以规避。

结语 AI 与 BI 的融合不是把模型接进来就结束了，它重新定义了"数据出口"的形态——出口从固定的报表格式，变成了自然语言驱动的动态响应。评分卡的意义，正是把这种动态出口重新框回到可管控、可追溯、可回滚的工程边界内。五个必做项守住底线，三个高风险项标出雷区，剩下的，是把安全能力做成产品默认动作，而不是靠人工提醒去补丁。