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