敏感字段识别：让 AI 问数先知道哪些数据不能乱用

很多企业做 AI 问数时，会先问一个问题：

谁能登录系统？

这当然重要。

但只控制登录还远远不够。

企业数据里有大量敏感字段。

客户手机号、身份证号、地址、银行卡信息、员工薪酬、渠道成本、合同金额、门店毛利、供应商价格、客户标签，都可能有不同的访问边界。

如果 AI 不知道哪些字段敏感，就可能在回答过程中把不该看的数据拿出来、拼起来、解释出来。

AI 问数会让字段风险变得更隐蔽

传统系统里，用户通常通过固定页面看数据。

页面展示什么字段、隐藏什么字段，是提前设计好的。

AI 问数不是这样。

用户可以用自然语言提出各种组合问题。

例如：

• •帮我列出高价值客户及联系方式；
• •哪些员工绩效最低；
• •哪些门店毛利最差；
• •某个供应商的结算价格和竞品相比如何；
• •把会员画像和消费记录合并分析一下。

这些问题可能跨表、跨字段、跨系统。

如果系统只做粗粒度权限，AI 可能在生成查询和解释时触碰敏感字段。

敏感字段识别需要进入语义层

敏感字段不能只放在安全文档里。

它应该成为 AI 数据分析语义层的一部分。

系统需要知道：

哪些字段属于个人信息；

哪些字段属于商业敏感信息；

哪些字段只能汇总展示，不能明细展示；

哪些字段只能特定角色访问；

哪些字段可以参与计算，但不能直接出现在答案里。

Snowflake 的敏感数据分类文档中，把识别出的敏感列分配到 semantic category 和 privacy category。AWS 的生成式 AI 安全治理指南也强调，企业级生成式 AI 平台需要默认的安全、治理和访问控制。

对 AI 问数来说，字段级安全不是附加项，而是前置条件。

不是所有敏感数据都要完全禁用

敏感字段治理不是简单地“一刀切”。

有些字段可以用于统计，但不能展示明细。

例如客户手机号不应该直接返回给普通运营，但可以用于去重后计算客户数。

有些字段可以给管理层看，但不能给门店角色看。

例如门店毛利、人员成本、供应商结算价。

有些字段可以在脱敏后使用。

例如只展示手机号后四位，或者只展示客户所在城市。

关键是让 AI 在生成查询和组织回答时理解这些边界。

AskTable 如何承接字段级治理

AskTable 的权限控制不能停留在“用户能不能进系统”。

它需要结合角色、项目、数据源、表、字段和字段值范围，让 AI 在正确边界内回答。

BuildTable 可以帮助企业把分散的数据整理成更适合 AI 使用的数据基础。

AskTable 则需要在语义配置中标注字段含义、敏感级别、可见范围和使用方式。

这样，AI 才能知道哪些数据可以查、哪些数据需要汇总、哪些数据应该拒绝。

结论

企业 AI 问数的安全，不是最后加一个权限开关。

它应该从字段级语义开始。

先识别敏感字段，再定义访问边界，再让 AI 在边界内分析。

只有这样，业务才能放心使用 AI 数据分析，而不是在每一次追问里担心数据被误用。

参考来源

• •Snowflake：Introduction to Sensitive Data Classification
• •AWS Prescriptive Guidance：Security and Governance for Generative AI Platforms