
导语聊数据安全之前先做一次口径校准。在传统BI时代我们讨论的数据安全边界相对清晰账号权限、行列级管控、传输加密、审计日志、备份恢复——本质上是人访问数据这条链路的防护。评估维度成熟等保、GDPR、ISO 27001 都能一一对应。但当大模型嵌入分析链路后数据安全这个词的所指发生了变化。用户提问一句自然语言背后可能触发元数据抽取、SQL 生成、结果回传、上下文拼接、模型推理——这条链路上多了一个此前不存在的角色大模型本身。它可能是外部 API也可能是私有化推理服务它会不会保留对话、会不会把 A 客户的数据带到 B 客户的上下文、会不会因为一次 prompt 注入而越权取数这些问题在传统评估表里几乎找不到对应条目。换句话说AIBI 语境下的数据安全至少要在传统那套之上再叠加三个新维度传给模型的是什么原始明细还是聚合结果、模型会不会留下什么对话保留策略、模型能不能被诱导做什么权限穿透与注入防护。任何一个维度失守前面十年攒下的权限体系都可能被一句提问绕过。这也是我们想提出数据安全评分卡的原因。与其在选型 RFP 里堆几十条泛泛的合规术语不如把评估维度收敛成一张可打分、可自查的清单五个必做项——数据最小化、传输加密、零保留策略、字段级权限贯通、审计可追溯三个高风险项——原始明细外传、权限与 AI 链路脱钩、对话上下文跨租户污染。下文按这八个维度展开既可用于选型时对候选产品打分也可用于已上线 AIBI 系统的内部自查。评分卡不是终点它更像一张地图帮助数据负责人、IT 与合规团队在同一张表上对话。为什么这个问题值得现在重视一个容易被忽略的事实是AIBI 的数据安全风险并不是多了一个大模型这么简单而是数据流转路径本身被重构了。传统 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 的融合不是把模型接进来就结束了它重新定义了数据出口的形态——出口从固定的报表格式变成了自然语言驱动的动态响应。评分卡的意义正是把这种动态出口重新框回到可管控、可追溯、可回滚的工程边界内。五个必做项守住底线三个高风险项标出雷区剩下的是把安全能力做成产品默认动作而不是靠人工提醒去补丁。