AI 问数审计怎么做？从一句提问追到实际 SQL

AI 问数审计要回答的不是“系统有没有日志”，而是某次结果被质疑时，能否从提问者和入口追到当时的权限配置、实际工具调用、SQL 和返回结果。单看聊天文字或数据库 SQL 都不完整。下面用一条虚构的跨店问题说明怎样建立证据链；产品日志和企业的跨系统审计仍要分开设计。

先定义调查问题

假设 A 店经理投诉：“我问本周销售额，为什么结果像把 B 店也算进来了？”调查者至少要确认五件事：谁用哪个入口发问、提问原文与时间、当时绑定的身份和角色、系统实际查了哪些表与行、最终返回的数。若只能看到回答“本周 12 万元”，既无法证明正确，也无法判断是否越权。

这类问题应在上线前演练，而不是等真实投诉再临时找日志。演练样本不需要真实客户资料；A/B 店各放几笔可人工加总的测试订单即可。

一条证据链怎么串

AskTable 当前公开文档说明，智能体的审计列表包含提问、用户、来源、时间和执行状态；执行详情可查看消息与工具调用，包括 SQL。列表面向项目负责人和管理员。文档没有把“用户角色、可见范围”列为该日志的现成字段。因此，调查者需另外查看角色与策略配置，再与实际 SQL 对照；若配置会变更，企业应保存可追溯的配置版本或变更记录。

用一个虚构的跨店问题演练

测试库中 A 店订单共 300 元，B 店共 700 元。A 店经理从正式入口问：“本周两店销售额合计是多少？”若策略只允许 A 店数据，验收时要看实际 SQL 是否带有对应的行条件、结果是否包含 B 店订单，以及回答有没有明确说明可访问范围。别只检查回答有没有出现“700”这个数字；一段模糊回答仍可能掩盖错误查询。

再用无权账号从同一入口发问，观察请求在哪里被拒绝。若拒绝发生在身份层，未进入智能体执行流程，智能体审计列表可能没有这条记录。此时应查看入口或网关日志。能否定位所有前置拒绝，是企业要实测的验收问题，不是现成产品承诺。

审计范围要画清楚

智能体执行日志适合排查某次问数使用了什么数据、为什么答错或失败。企业级审计还可能要求跨飞书、嵌入应用、API 网关、数据库和模型服务关联，长期归档、统一告警、按法规留存。这需要企业自己的采集、存储和访问控制方案，不能把某个智能体的日志页面等同于完整的 SIEM 平台。

日志本身也含敏感内容。提问中可能写了客户姓名、合同编号或业务秘密；谁能看日志、保留多久、是否脱敏，同样需要授权。上线测试应同时覆盖“能查到证据”和“无权的人查不到证据”。

最后做一次限时演练：给调查者提问时间和用户，但不告诉他答案，让他独立找到执行链、核对权限和复算结果。记录缺失环节、修复责任人和复测日期。能完成这条闭环，审计才真正能服务排障与安全复盘。

参考资料

• •AskTable 日志与用户反馈
• •设置数据访问范围
• •原 Article：AI 问数审计记录