
sidebar.wechat

sidebar.feishu
sidebar.chooseYourWayToJoin

企业做 AI 问数,很多人第一反应是:SQL 生成准不准。
这当然重要。
但真正上线到企业环境后,还有一个更重要的问题:
这个人有没有权限看到这些数据?
如果权限边界不清楚,AI 越好用,风险越大。
一个店长只能看自己门店。
区域经理可以看自己区域。
总部能看全国。
财务可以看成本和利润。
一线员工不应该看到敏感毛利、供应商价格、会员手机号。
这些规则在报表时代就存在。
到了 AI 问数时代,它们不能消失,反而要更严格。
因为 AI 不只是展示固定报表,它会动态理解问题、选择字段、生成查询、调用工具。
每一步都要在权限内发生。
很多 AI 问数系统会用历史问法和 SQL 样例来提升准确率。
这很有用。
但这里也有一个隐蔽风险:训练样例本身可能引用了某些表。
如果用户没有权限看这些表,那么这些样例就不应该被召回给 AI 使用。
否则,AI 可能虽然没有直接查越权数据,却从样例里学到了不该出现的表、字段或分析路径。
AskTable 最近在做的一件事,就是把训练 Q-SQL 样例也放进权限边界里。
系统在召回样例前,会先按角色可见表过滤,再取最相关的候选。
也就是说,不是最相似的样例一定能用,而是必须先可见,才有资格被使用。
训练样例不是随便存进去就完了。
一个 SQL 样例如果写错了,后面 AI 可能反复学错。
所以 AskTable 对训练样例保存也做了校验:只读、可解析、不能直接 SELECT *,引用表要存在,表名要清楚。
这听起来是工程细节,但对企业很重要。
因为可信 AI 问数不是靠一句“模型很强”实现的,而是靠很多边界条件一起兜住。
企业不会因为 AI 会生成 SQL 就放心上线。
他们真正关心的是:
谁能看什么?
答案从哪里来?
口径能不能解释?
权限变化后,旧会话会不会越权?
训练样例会不会泄露不该看的数据?
这些问题解决不好,AI 问数就只能停留在演示。
AskTable 的方向很明确:AI 可以更聪明,但必须在企业规则里运行。
会回答,只是第一步。
在正确权限下回答,才是企业 AI 数据分析真正能落地的前提。
sidebar.noProgrammingNeeded
sidebar.startFreeTrial