很多企业已经开始尝试 AI 问数：业务人员直接用自然语言提问，AI 自动查询订单、客户、库存和经营指标。但新的担忧也随之出现：如果把数据库直接交给大模型，会不会泄露客户手机号、供应商价格、员工薪酬或未公开的经营数据？
真正可落地的方案，不是简单地“把数据库接给 AI”，而是让 AI 只能访问经过授权、脱敏和解释的数据。以 AskTable 为例，企业可以在业务效率和数据安全之间建立一层可控的数据访问机制。
一、先把“能不能看”交给权限系统
AI 问数的第一道安全边界是权限，而不是提示词。企业需要按组织、角色和数据范围定义访问权限：
- 销售人员只能查看自己负责的客户和订单；
- 区域经理可以查看本区域汇总数据，但不能查看其他区域明细；
- 财务人员可以查看毛利和回款，业务人员不应看到成本底表；
- 管理层可以查看全局经营指标，但敏感字段仍然需要脱敏。
在 AskTable 中，可以把数据源、数据表和字段权限与角色绑定。业务人员提问时，AI 只能在当前用户有权限的数据范围内生成查询，不能通过换一种问法绕过权限。
二、敏感字段不要直接暴露
手机号、身份证号、银行卡号、客户地址、供应商报价等字段，通常不应该出现在业务问数结果中。建议采用“最小可用”原则：
- 默认隐藏不必要的敏感字段；
- 对必须使用的字段进行掩码，例如只显示手机号后四位；
- 用客户编号替代姓名、电话等直接身份信息；
- 在汇总分析中只返回统计结果，不返回明细记录。
例如，业务人员问“华东客户本月复购率是多少”，AI 只需要读取客户分群和订单聚合结果，不需要接触客户姓名和手机号。
三、用语义层限制 AI 的查询范围
直接让 AI 自由生成 SQL，容易出现指标口径不一致、误查明细甚至查询超范围的问题。更稳妥的方式是先建立业务语义层，把“销售额”“净收入”“毛利率”“活跃客户”等指标定义清楚，并为指标指定可用字段和计算规则。
这样，业务人员说“上个月销售额”，AI 会按照企业统一口径计算，而不是临时拼接一段可能出错的 SQL。AskTable 的自然语言问数可以建立在这类结构化定义之上，让回答既容易理解，也更容易审计。
四、让每一次问数都可追溯
安全不仅是“拦住不该看的数据”，还要知道数据是怎样被使用的。企业应保留：
- 谁在什么时间提出了什么问题；
- AI 使用了哪些数据源和指标；
- 返回了哪些结果；
- 是否触发了敏感字段或越权拦截。
当出现异常访问时，管理员可以根据日志快速定位。对于高风险问题，还可以设置人工审批或限制导出，避免数据被批量复制。
五、推荐的安全落地路径
企业可以按以下顺序上线 AI 问数：
第一阶段：只开放汇总指标。 先让业务部门查询销售额、订单数、库存周转等非敏感指标。
第二阶段：开放经过脱敏的明细。 例如使用客户编号、商品编码和区域信息，验证实际业务价值。
第三阶段：建立异常检测和审批机制。 对大范围导出、敏感字段查询和跨部门数据访问增加告警或审批。
每个阶段都应配套权限、口径、日志和复核机制，而不是一次性开放全部数据。
结语：安全的 AI 问数，核心是“可控访问”
企业不必在“数据安全”和“业务使用 AI”之间二选一。通过权限控制、字段脱敏、统一语义层和完整审计，可以让业务人员用自然语言获得答案，同时把敏感数据留在受控范围内。
AskTable 的价值，正是帮助企业把数据连接、权限管理和 AI 分析放在同一套工作流里。让 AI 能回答正确的问题，也让它明确哪些数据不能回答，才是企业级 AI 问数真正可持续的形态。
