AI 查过哪些数据，审计记录应该能回答什么？

审计 AI 问数，至少要能回答“谁、何时、从哪里、问了什么、系统实际执行了什么”。只留下聊天文本，无法判断是否越权；只留数据库 SQL，又难以还原自然语言问题和用户身份。企业需要把入口、权限决策与执行链路接起来。

审计问题比日志字段更重要

先列调查场景：有人投诉看到外部门店数字，运营发现一个异常汇总，数据库出现一波密集查询。每个场景都要求能定位提问者、智能体、数据源、时间、执行状态和所用角色。

日志应有适当留存与访问控制。问题文本可能包含客户名或业务秘密；让所有管理员无条件查看完整日志，同样会制造新的数据暴露面。

AskTable 能提供到哪一步

AskTable 文档中的“审计日志”是某个智能体的提问和执行记录，列表包含提问、用户、来源、时间与执行状态，并可进入执行详情排查。它适合追溯该智能体内的一次问数，也便于核对查询为何失败。

这不等于组织级 SIEM、安全告警平台或“日志永不丢失”的承诺。需要跨系统关联、长期归档和不可篡改保全时，企业还要设计自己的日志采集与存储链路。

上线前演练一次追溯

安排授权用户提出一次正常问题、越权用户提出一次受限问题，并记录时间窗口。让另一名管理员只凭日志找到两次请求，说明实际访问范围、执行结果和拒绝原因。若无法定位，补齐身份映射或日志字段后再上线。

数据库日志和 AskTable 日志建议用统一时间源；若两个系统时钟不一致，事后会难以串联。测试完成后按企业政策清理演练中的敏感样本。

审计不是防护的替代品

审计能提供可追查证据，但不能代替最小权限、只读账号和异常访问阻断。把审计视为持续复核的一层：发现越权配置，就修策略；发现大量重复失败请求，就检查入口和密钥。

参考资料

• •AskTable 日志与用户反馈
• •AskTable 如何工作
• •AskTable 权限配置

延伸阅读：查看含完整示例的博客版