大模型服务审计、访问控制与敏感数据保护，不能只检查模型回答是否合规；还要追踪谁发起请求、哪些数据进入上下文、结果送往何处，以及审计日志保留了什么。以用户上传合同并要求提取条款为例，原文可能依次出现在应用请求、模型调用记录、错误日志和人工复核界面中。以下七项优化可按数据流逐项落实。
先厘清审计范围与访问边界
1. 画出数据流，标明敏感字段
从输入端开始，列出上传文件、提示词、检索片段、模型输出、工具调用参数和反馈记录，注明每一项的产生位置、接收方与存储位置。用姓名、联系方式、账号标识等字段做数据分类；是否属于敏感信息，应按组织政策及适用法规判断。这样能发现“正文已脱敏、异常日志仍记录原文”一类遗漏。
2. 按任务缩小授权范围
为用户、应用服务、审核人员和运维人员分别设置权限，采用最小权限原则：调用模型的服务只获得完成任务所需的接口权限，不能顺带读取无关文件；查看审计记录的人员也不应默认拥有查看完整提示词的权限。权限变更要记录申请人、审批人、范围和到期时间，并定期清理不再需要的授权。
让记录可追溯，但不复制原始数据
3. 记录必要事件，不默认保存全文
审计事件通常应包含请求标识、主体身份、时间、模型或服务版本、数据来源类别、策略判定、工具调用结果及异常状态。能用字段名称、数据分类、内容长度或处理结果说明问题时，不要把完整提示词、上传文件和模型回复直接写入普通日志。需要保留原文用于复核时，应单独说明目的、授权范围和访问方式。
4. 明确日志脱敏边界
字段级脱敏适用于可识别的结构化信息，例如在日志视图中遮蔽邮箱用户名或账号中段；但它不一定能处理自由文本里的姓名、地址或合同条款。应在写日志前设置过滤与替换规则，并用包含常见格式及边界情况的测试样本验证。还要检查异常堆栈、调试输出、队列消息和导出文件：主日志已遮蔽，不代表这些旁路副本也安全。
5. 将审计数据与业务内容分开存放
把事件元数据与提示词、文件正文等内容分开管理；确需保存的内容应限制可读主体，并采用适当的静态加密和传输保护。密钥与日志文件不应放在同一访问边界内。若使用 PostgreSQL 等数据库存放审计记录，应单独核对数据库账号权限、备份副本和查询导出权限，不能只检查在线表。
把复核与处置做成闭环
6. 设置留存、删除与异常告警规则
按审计目的和风险确定留存期限，区分高频运行事件、需要调查的安全事件和短期调试记录；不宜设置一个期限覆盖所有数据。到期后验证主存储、备份及导出副本是否按规则处理。对短时间内异常增长的拒绝事件、权限变更或敏感字段命中情况设置告警，并安排责任人复核，避免告警长期无人处理。
7. 定期用真实流程做权限与日志演练
- 选取上传文档、调用外部工具、用户申请人工复核等真实业务流程。
- 使用不含真实个人信息的测试样本，检查各环节能否访问超出授权的数据。
- 核对审计记录是否足以还原操作，又是否意外暴露输入或输出原文。
- 记录发现项、责任人和整改期限；修复后重跑同一流程并留存验证结果。
同时测试提示注入等输入风险：审计应记录策略是否拦截及工具是否被调用，但不要为了留证而无边界保存攻击文本和用户数据。
常见问题
审计日志要不要保存完整对话？
不应默认保存。先明确调查或合规目的；若确有必要，应缩小授权、单独存放并设定期限。
脱敏后还需要控制日志访问吗？
需要。脱敏可能遗漏自由文本和旁路副本，日志本身也可能暴露业务细节，因此仍应分级授权并记录查询行为。
如何判断日志是否足以支持排查？
用请求标识串联事件，检查能否还原身份、时间、策略结果、工具调用和错误阶段；无需依赖完整原文时，就不应把原文当作默认证据。
日志留存多久合适？
没有适用于所有场景的统一期限，应依据调查需要、风险、组织制度及适用要求确定，并验证到期删除是否覆盖备份。
有效的优化不是多记数据，而是让授权有边界、事件能追溯、原文少暴露、到期可处置。把这七项纳入日常复核，才能让大模型服务审计、访问控制与敏感数据保护形成可验证的闭环。
