安全审计视角看生成式 AI

生成式 AI 给安全审计带来了一批新对象：模型、提示、输出与调用链。这些对象在传统的账号与系统审计里并不存在，而它们恰恰是风险最容易发生的位置 —— 数据泄露往往发生在一次不经意的提示里，而不是一次入侵

审计通常会问什么

• 输入侧：提示里是否包含敏感信息，这些信息是否被记录、是否被发送到外部。
• 输出侧：模型是否生成了违反政策的内容，例如泄漏内部数据或给出错误的合规建议。
• 权限链：一次调用用过哪些数据、依据什么授权、中途是否跨过了本不该跨的边界。
• 供应链：基座模型来源、版本更新机制、第三方组件与数据管道是否有清单与变更记录。

四类记录及其字段

• 调用记录：身份、时间、模型与版本、检索到的知识条目、输出内容。
• 数据访问记录：谁在什么时候读取了哪些数据，以及被拦下的越权尝试。
• 模型与配置记录：版本、参数、提示模板与后处理规则的变更历史。
• 事件与处置记录：异常、投诉、处理人与结论，包括转人工的原因。

四类记录的用途不同，缺哪一类都会让某个问题无法回答。只留调用记录，能说清「它答了什么」，但说不清「它凭什么能看这些数据」。

保留期限按数据类型分别确定

这里有一个常见误区：把留存期限统一成一个数字。实际上两类数据的口径并不相同 —— 留资类个人信息适用实现处理目的所必要的最短时间，而服务器访问日志另有不少于六个月的留存要求。混用会导致一边留存过长、一边留存不足。

常见缺口

• 只记录问题与答案，不含依据的资料，出错时无法定位。
• 权限调整没有留痕，无法解释某个时间段内谁为什么能看到这些数据。
• 模型版本切换没有记录，出现质量波动时找不到对比基线。
• 日志存在但分散在多个系统，时间口径不一致，无法对齐成一条链路。
• 有人能查日志，但没有明确谁负责定期看，异常只能靠偶然发现。

审计前的三项准备

让审计高效的前提不是临时补材料，而是平时就把三件事准备好

• 一张清单：写清 AI 系统涉及哪些数据源、哪些角色可以访问、哪些环节会对外输出。
• 一个入口：日志与记录能通过统一的入口检索，而不是分别去几个系统里翻。
• 一个责任人：谁负责在审计期间对接、解释字段含义、协调补充材料。

边界

审计的目标不是把所有信息都留下来，而是出事时能还原事实。留存越久，隐私与合规成本越高，所以期限应当按数据类型分别确定，并能说明为什么是这个期限。无差别长期留存，本身就是一种需要解释的做法。