AI操作审计记录要能回答一串具体问题：谁在使用AI、依据哪次授权、处理了什么数据、用了哪个模型或工具、产生了什么结果、是否经过人工复核。本文给出一份可直接套用的字段表，并说明采集点、留存期限、访问控制、角色分工与验收检查，帮助团队把记录从“有日志”做到“能还原一次完整操作”。
要点总览（TL;DR）
- AI操作审计记录按身份与授权、动作与对象、数据、结果与复核、异常五组字段组织，必填字段用于还原操作链路，选填字段用于补充调查线索。
- 字段表确定后要把每个字段落到账号权限系统、审批工单、AI工具日志、评审流程等采集点，避免表上有字段、系统取不到。
- 留存期限按数据敏感级别分级设定，敏感级别越高留存越长、可访问范围越窄，查询与导出行为本身也要留痕。
- 使用方提交申请、团队负责人审批与复核、安全合规角色定规则并抽查、平台管理员维护采集与权限，各环节都要有明确交付物和交接时点。
- 验收以能否凭请求标识还原一次完整操作为核心标准，同时检查必填字段缺失率、留存与权限生效情况、抽查处置闭环和记录自身变更留痕。
一份可用的AI操作审计记录包含哪些字段
字段设计的目标是让记录具备可追溯性，而不是把能采集到的信息全部堆进去。建议按身份与授权、动作与对象、数据、结果与复核、异常五组组织字段，每组都标明采集来源和必填性。必填字段用于还原操作链路，选填字段用于补充调查线索。
| 分组 | 字段名 | 含义 | 采集来源 | 必填性 | 示例值 |
|---|---|---|---|---|---|
| 身份与授权 | 操作人 | 实际发起AI操作的人员 | 账号系统或工具登录态 | 必填 | 张明 |
| 身份与授权 | 所属团队 | 操作人所在研发团队 | 组织架构或账号系统 | 必填 | 支付服务组 |
| 身份与授权 | 账号标识 | 操作使用的账号或服务账号 | 账号系统 | 必填 | zhangming@example |
| 身份与授权 | 角色 | 操作时生效的角色或权限集 | 权限系统 | 必填 | 研发工程师 |
| 身份与授权 | 审批单号 | 本次AI使用所依据的申请或审批记录 | 审批或工单系统 | 必填（受控场景） | AI-2024-0317 |
| 动作与对象 | AI工具或模型标识 | 使用的AI产品、模型或插件名称 | 工具侧日志 | 必填 | 代码助手A |
| 动作与对象 | 版本 | 模型或工具版本号 | 工具侧日志 | 必填 | v2.3 |
| 动作与对象 | 调用时间 | 操作发生的准确时间 | 工具侧日志 | 必填 | 2024-03-17 14:22:08 |
| 动作与对象 | 请求标识 | 单次调用的唯一编号，用于串联上下游日志 | 工具侧日志 | 必填 | req-8f3a21 |
| 动作与对象 | 操作类型 | 生成、总结、检索、转换等动作类别 | 工具侧日志 | 必填 | 代码生成 |
| 数据 | 输入摘要或脱敏样本 | 输入内容的摘要，或经脱敏的样本片段 | 工具侧日志或人工填写 | 必填 | 接口参数校验逻辑片段 |
| 数据 | 数据范围 | 引用的代码库、文档库或数据集范围 | 工具侧日志或申请单 | 必填 | 支付服务仓库 |
| 数据 | 敏感级别 | 输入数据的分级标签 | 数据分类分级结果 | 必填 | 内部 |
| 结果与复核 | 输出摘要 | AI生成结果的简要描述 | 工具侧日志 | 必填 | 生成接口校验函数草案 |
| 结果与复核 | 输出去向 | 结果被保存、提交或发送的位置 | 工具侧日志或工单系统 | 必填 | 代码评审单MR-1182 |
| 结果与复核 | 人工复核结论 | 复核人对输出的判断 | 评审或复核记录 | 必填 | 修改后采纳 |
| 结果与复核 | 采纳或驳回 | 最终处置结果 | 评审或复核记录 | 必填 | 采纳 |
| 异常 | 拦截记录 | 是否触发策略拦截及拦截原因 | 安全策略或工具侧日志 | 选填（发生时必填） | 输入含密钥字段被拦截 |
| 异常 | 越权尝试 | 是否尝试访问授权范围外资源 | 权限系统或工具侧日志 | 选填（发生时必填） | 尝试读取未授权仓库 |
| 异常 | 失败原因 | 调用失败或结果异常的原因 | 工具侧日志 | 选填（发生时必填） | 超时未返回 |
填写要求有两点值得提前约定。输入摘要优先记录结构化摘要，避免把完整敏感内容写入审计库；请求标识必须与工具侧原始日志一致，否则后续调查无法把审计记录与底层日志对上。审批单号在受控场景中设为必填，普通公开信息处理场景可按团队规定放宽。
从字段表到可执行流程：采集、留存与访问控制
字段表确定后，下一步是把每个字段落到具体系统的采集点上，并明确留存与查看规则。字段与采集点脱节，是审计记录最常见的失效原因：表上有的字段，系统里根本取不到，最后只能靠人工补录。
采集点分工
| 字段类别 | 责任系统 | 采集方式 | 注意事项 |
|---|---|---|---|
| 身份、角色、团队 | 账号与权限系统 | 调用时自动写入 | 记录操作时点的角色快照，避免事后角色变更导致追溯失真 |
| 审批单号、用途 | 审批或工单系统 | 申请通过后关联 | 审批单与请求标识建立关联 |
| 模型标识、版本、时间、请求标识 | AI工具侧日志 | 工具自动记录 | 确认工具是否暴露版本与请求标识字段 |
| 输入摘要、数据范围、敏感级别 | 工具侧日志加数据分类结果 | 自动采集加规则映射 | 摘要规则需提前定义，避免写入原文 |
| 输出摘要、去向 | 工具侧日志、代码或文档系统 | 自动采集 | 去向需能定位到具体评审单或文档 |
| 复核结论、采纳或驳回 | 评审或复核流程 | 复核人填写 | 与请求标识关联，形成闭环 |
留存期限与访问控制
留存期限按数据敏感级别分级设定：敏感级别越高，留存时间越长、可访问范围越窄。例如公开级数据可保留6个月，内部级保留1年，机密级保留2年或按合规要求执行，具体期限由安全或合规角色结合行业要求确定。到期后按归档节奏处理：先归档到只读存储，再按计划清理，避免记录无限堆积，也避免在调查需要时已被提前删除。
访问控制需要回答三个问题：谁可以查询、谁可以导出、查询行为本身是否留痕。建议普通研发人员只能查看与自己相关的记录，团队负责人可查看本团队记录，安全与合规角色可跨团队查询，导出权限收紧到少数岗位。查询和导出行为本身也应写入审计日志，否则审计库可以被无痕读取，其作为治理证据的价值会大打折扣。
在研发流程系统内承载这套机制时，可以把AI使用申请做成工作项，审批、复核结论与输出去向作为工作项字段和关联记录保存，使申请、执行、复核、归档形成一条可追踪的链路。ONES 的 AI 研发管理方案说明其基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能将结果保存为工作项、Wiki 页面等内容。团队可据此把申请单、复核记录与产出物放在同一权限边界内管理。涉及具体审计字段、留存配置与导出能力时，需在选型核验阶段向官方确认。
角色分工与各环节交付物
审计记录能否持续运行，取决于每个环节是否有人负责、有明确产出。以下矩阵按角色列出职责与交付物，交接时点用于判断流程是否闭环。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| AI使用方 | 提交使用申请，填写用途、数据范围与预期输出 | AI使用申请单，含数据范围与敏感级别初判 | 使用前 |
| 团队负责人 | 审批申请，复核AI输出并给出采纳结论 | 审批意见、复核结论 | 使用前审批，输出后复核 |
| 安全或合规角色 | 定义敏感级别与留存规则，定期抽查，处置异常 | 分级规则、抽查报告、异常处置记录 | 规则制定阶段，按抽查周期 |
| 平台管理员 | 维护采集配置、留存策略与访问权限 | 采集配置说明、权限清单、归档记录 | 机制上线时，配置变更时 |
交接时点需要写进流程说明，而不是靠口头约定。使用方提交申请后，负责人应在约定时限内完成审批；输出产生后，复核结论应在结果被采纳前写入记录。安全角色的抽查频率可按数据敏感级别区分，机密级操作提高抽查比例。
示例：一次代码辅助生成操作的完整审计记录
以下为演示情景，用于说明字段如何串联，不代表真实项目数据。
场景设定：研发人员张明使用代码助手为支付服务生成接口参数校验代码，生成结果提交代码评审，评审人李华复核后修改采纳。
| 字段 | 记录值 |
|---|---|
| 操作人 / 团队 / 账号 | 张明 / 支付服务组 / zhangming@example |
| 角色 / 审批单号 | 研发工程师 / AI-2024-0317 |
| 工具标识 / 版本 | 代码助手A / v2.3 |
| 调用时间 / 请求标识 | 2024-03-17 14:22:08 / req-8f3a21 |
| 操作类型 | 代码生成 |
| 输入摘要 / 数据范围 / 敏感级别 | 接口参数校验逻辑片段 / 支付服务仓库 / 内部 |
| 输出摘要 / 去向 | 生成校验函数草案 / 代码评审单MR-1182 |
| 复核结论 / 处置 | 补充边界条件后可用 / 采纳 |
| 异常记录 | 无 |
复核环节依据记录判断是否采纳时，重点看三处：输入摘要是否与申请单声明的数据范围一致，输出去向是否指向可评审的载体，复核结论是否写明了修改意见。三者齐全，记录才能支撑“这次AI输出经过了人工判断”的结论。
异常情形示例：若张明在输入中粘贴了含数据库密码的配置片段，安全策略触发拦截，记录中应体现拦截记录字段，写明“输入含密钥字段被拦截”、拦截时间与请求标识，操作类型标记为被拦截，输出摘要为空。这条记录既证明拦截生效，也为后续排查同类输入提供线索。
完成检查：记录是否真的可用
机制上线后，用以下清单逐项核对，判断审计记录是否达到可用标准。检查以“能否凭记录还原一次完整操作链路”为核心标准。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 操作链路可还原 | 随机抽取记录，能按请求标识串起申请人、审批、调用、输出、复核各环节 | 安全或合规角色 |
| 必填字段完整性 | 抽样周期内必填字段缺失率低于约定阈值，缺失记录有补录机制与补录痕迹 | 平台管理员 |
| 留存与权限生效 | 抽查确认留存期限按敏感级别执行，越权查询被拒绝，查询与导出行为已留痕 | 平台管理员 |
| 抽查与处置闭环 | 按周期完成抽查，异常记录有处置结论与责任人 | 安全或合规角色 |
| 记录自身变更留痕 | 字段修改、补录、归档操作均有变更记录，可追溯修改人与时间 | 平台管理员 |
五项检查全部通过，说明记录机制具备基本可用性；任一项不通过，应回到对应环节修正采集配置或流程约定，再重新抽样验证。
常见问题
团队刚开始建立AI操作审计记录，字段可以一次全上吗？
建议分批推进。第一版先保证能还原操作链路的核心字段：操作人、团队、账号、角色、审批单号、AI工具或模型标识、版本、调用时间、请求标识、操作类型、输入摘要、数据范围、敏感级别、输出摘要、去向、复核结论与处置结果。异常类字段可以按“发生时必填”的方式先挂上，等采集点稳定后再细化拦截原因、越权尝试等子项。字段一次铺满容易导致采集点跟不上，最后大量字段靠人工补录，反而降低记录可信度。
输入内容必须完整保存原文才能审计吗？
通常不需要。审计记录的目标是能还原操作并支撑复核，输入侧保留结构化摘要或脱敏样本即可，完整原文可以留在原业务系统中按原有权限管理。把完整敏感内容复制进审计库，会扩大敏感数据的暴露面，也让留存期限和访问控制更难设计。摘要规则要提前约定，例如记录输入类型、涉及的业务对象和关键片段，确保复核人凭摘要能判断输入是否与申请单声明的数据范围一致。
留存期限定多长比较合适？
没有统一答案，建议按数据敏感级别分级设定，并结合行业合规要求和团队实际调查需要确定。常见做法是公开级数据保留较短周期，内部级适当延长，机密级保留更长时间或按合规要求执行。期限确定后要同步设计归档与清理节奏：先归档到只读存储，再按计划清理，避免记录无限堆积，也避免调查需要时已被提前删除。具体期限由安全或合规角色牵头确定，平台管理员负责配置落地。
审计记录建好后，怎么判断它真的能用？
用抽样回放来验证。随机抽取若干条记录，看能否按请求标识串起申请人、审批、调用、输出、复核各环节，形成完整链路。同时检查必填字段缺失率是否低于约定阈值、缺失记录是否有补录痕迹、留存期限与访问权限是否按规则生效、抽查发现的问题是否有处置结论和责任人。任一项不通过，就回到对应环节修正采集配置或流程约定，再重新抽样。记录自身的修改、补录和归档也要留痕，否则审计库本身的可信度无法保证。
在ONES中承载AI使用申请与复核记录，需要注意什么？
可以把AI使用申请做成工作项，审批意见、复核结论和输出去向作为工作项字段与关联记录保存，让申请、执行、复核、归档形成一条可追踪的链路。ONES 的 AI 研发管理方案说明其基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能将结果保存为工作项、Wiki 页面等内容。涉及具体审计字段清单、留存期限配置和导出能力时，建议在选型核验阶段向官方确认，再据此设计字段映射。
