先说结论Power BI做了RLS不代表AI问数天然不会越权这两句话听起来很接近实际差别很大。假设一家企业按区域设置了行级安全RLS华南经理只能看华南华东经理只能看华东总经理可以看全国在Power BI报表里三个人登录后看到的数据都正确。现在接入AI问数。华南经理问「全国销售额是多少」AI会怎么回答可能返回「无权查看」也可能只计算华南数据。但在某些接入方式下它还真有可能把全国数据查出来。问题并不在AI会不会「破解」RLS而在于它绕过了哪一段权限链路。01 RLS保护的是语义模型不是所有数据副本Power BI的RLS本质上是语义模型中的行过滤规则。例如模型根据当前登录人的账号找到他负责的区域用户查询数据时Power BI引擎先识别用户身份再应用对应的RLS规则最后只返回他有权看到的行。因此只要AI满足下面两个条件RLS通常仍然有效1 AI通过原来的Power BI语义模型查询2 查询时传入了当前提问者的有效身份微软当前文档也明确说明Fabric Data Agent访问Power BI语义模型时会继续应用用户在数据源上的权限包括RLS和列级安全用户只需拥有语义模型的Read权限并不需要进入工作区。换句话说AI生成了什么DAX并不是安全的决定因素。只要DAX最终交给语义模型执行并且执行身份正确RLS会在模型层过滤结果。AI即使问「全国销售额」也只能拿到当前用户权限范围内的数据。真正需要警惕的是另外几种让RLS失效的接入方式02 第一种风险所有人都共用一个后台账号一些自建AI问数系统连接Power BI时并没有把提问人的身份传给语义模型。前端登录的是华南经理后台执行查询的却始终是语义模型管理员工作区成员账号拥有广泛权限的服务账号没有配置有效身份的服务主体此时模型识别到的不是华南经理而是后台账号。如果这个账号可以查看全国数据AI当然也能拿到全国数据。这不是RLS失效而是查询从来没有以华南经理的身份进入RLS因此检查AI问数权限时最重要的问题不是「Power BI有没有配置RLS」而是「这条查询进入Power BI时Power BI认为它是谁发起的」如果这个问题答不清楚前面做得再完整的角色配置也不能证明AI不会越权。03 第二种风险AI绕过语义模型查询了另一份数据还有一些AI方案虽然声称「连接Power BI」实际流程可能是1 从Power BI或数据库导出数据2 把数据写入Excel、Lakehouse、数据库或向量库3 AI再查询这份副本一旦数据离开原来的语义模型Power BI中的RLS不会自动跟着复制过去。原模型可能规定华南经理只能看华南但导出的明细表里包含全国数据。如果新的存储层没有重新建立权限AI查询数据副本时就可能返回超出用户范围的结果。同样需要检查的还有AI为提高速度建立的结果缓存定时生成的分析摘要已导出的CSV或Excel向量化后的业务文本自动生成并保存的Word、PPT和HTML报告被其他用户打开的历史对话或共享链接RLS只能约束经过受保护模型执行的查询不能自动保护已经被复制出去的结果04 第三种风险测试账号本身不受RLS限制Power BI有一个很容易被忽略的规则RLS主要约束Viewer用户不适用于工作区中的Admin、Member和Contributor。即使用户被加入了某个RLS角色只要同时拥有工作区编辑权限RLS也可能不对他生效。拥有语义模型Write权限的用户同样可以不受RLS角色限制。这会造成一种很有迷惑性的测试结果项目人员用自己的管理员账号测试AI发现可以查询所有区域于是认为AI绕过了RLS或者相反因为管理员账号运行正常就误以为普通用户的权限也一定正确。这两种判断都不可靠。验收AI问数权限必须用真实Viewer账号并给不同账号配置不同数据范围05 第四种风险只做了行权限却以为所有敏感信息都被保护了RLS解决的是哪些数据行可以看到。它并不自动解决哪些字段可以看到哪些指标允许查询能否看到客户手机号、身份证号或成本明细能否导出数据能否把回答分享给其他人对话和报告会保存多久例如一位销售经理可以查看自己区域的销售记录这并不代表他也应该看到这些记录中的客户手机号、采购底价和员工薪资。此时仅有RLS还不够还要结合列级安全、对象级安全、敏感字段处理、分享权限和审计机制。AI问数把查询入口从「点击报表」变成了「自由提问」用户更容易问到报表页面上从未展示过的字段。因此权限检查不能只看现有报表里显示了什么还要看语义模型实际开放了什么。06 AI会不会通过推理猜出无权查看的数据这里还要区分两件事查询到了越权数据AI根据已有信息生成了一个看似真实的数字如果RLS正确执行AI不能仅靠改变提问方式让Power BI返回被过滤掉的行。但大模型可能根据上下文、公开信息或错误推断编造一个「全国销售额」。这属于回答准确性问题不等于数据越权。判断方法很简单检查这条回答背后的查询、返回记录和数据来源。如果底层查询没有获得全国数据而回答中出现了一个全国数字这更可能是臆测如果查询结果本身包含其他区域的数据才是权限链路出现了问题。安全治理和回答准确率需要分别测试不能混为一个指标07 怎么验证AI问数真的继承了RLS不要只看系统架构图也不要只问供应商一句「是否支持RLS」。可以直接准备两个权限不同的普通用户让他们提出完全相同的问题。例如测试时还应记录四项证据1 前端登录用户是谁2 查询进入语义模型时的有效身份是谁3 实际执行的DAX或SQL是什么4 模型最终返回了哪些数据此外还要继续检查换一种问法能否绕过限制导出明细是否仍受约束AI生成的报告能否被无权限人员打开历史回答和缓存是否会被其他用户复用工作区管理员与普通Viewer的结果是否被错误混用微软的「Test as role」可以验证语义模型中的RLS但官方文档也特别提醒这项测试不能覆盖Copilot等所有交互。因此AI问数仍然需要单独做端到端测试不能用「报表里的RLS测试通过」代替。08 所以Power BI做了RLSAI问数安全吗答案不是简单的「安全」或「不安全」。可以把判断标准压缩成一句话如果AI始终以当前用户身份通过受RLS保护的语义模型查询并且查询结果、缓存和生成报告没有绕到权限体系之外RLS就能继续发挥作用。反过来只要出现以下任何一种情况就需要重新评估AI统一使用高权限后台账号查询没有传递提问者的有效身份数据被提前导出到另一套存储缓存没有按用户权限隔离普通用户被授予工作区编辑或Write权限生成的报告脱离原有权限范围传播只保护了数据行没有保护敏感字段因此企业接入AI问数前真正需要验收的不是一句「支持RLS」而是一条完整链路谁在提问——以谁的身份执行——经过哪个数据模型——返回哪些数据——结果又保存和分享给了谁。这五个环节全部说得清楚才能判断AI问数有没有越权。