AI操作审计要解决的是“谁在什么工具里对哪些数据做了什么AI动作、结果如何、有没有人复核”。落地时先划定审计对象与风险分级，再确定最小记录字段和采集方式，配套分级复核、证据留存，最后用一次试点校验完整性。本文给出六步实施顺序、字段表、角色分工、端到端示例和验收清单，适合负责AI使用治理的研发管理者与安全合规人员参照执行。
要点总览（TL;DR）
- AI操作审计按六步推进：定范围与责任人、定记录字段、定采集方式、定复核规则、定证据留存、做试点校验，每步都有明确输入、输出和完成标志。
- 审计对象聚焦四类AI使用行为：AI对话与生成、代码助手调用、文档与知识库AI处理、AI相关配置变更；全平台权限治理和模型训练治理不在本篇范围。
- 最小字段表以操作人、时间、工具与模型、操作类型、输入摘要、输出摘要、涉及数据范围、结果状态八个必填字段为基线，输入输出只记摘要和类别标签，敏感原文不入日志。
- 复核要按风险分级：高敏数据操作逐条复核并限时关闭，一般操作按周抽样；复核结论需回写记录状态，证据能从结论反向追溯到原始操作。
- 验收看四项：抽样记录完整性、命中规则的复核闭环、证据可追溯、日志访问控制与留存期限，试点结束后逐项核对，未通过项列入整改。
先划清AI操作审计的范围与对象
AI操作审计的第一步是把“AI使用”拆成可记录的具体操作，而不是从全平台账号权限或模型训练治理入手。范围划得越具体，后面的字段设计和采集方式越容易落地。建议先列一份审计对象清单，再按数据敏感度和影响面做风险分级，用分级结果决定记录深度。
审计对象清单
以下四类操作构成AI操作审计的主要对象，覆盖了研发团队日常使用AI的高频场景：
- AI对话与生成：员工在AI助手中发起的问答、内容生成、总结、翻译等请求，重点记录输入内容涉及的数据范围和输出用途。
- 代码助手调用：在IDE或代码平台中调用AI补全、生成、解释代码的行为，重点关注是否携带了私有代码片段或密钥信息。
- 文档与知识库AI处理：对文档、Wiki页面、附件做AI总结、改写、检索问答的操作，重点关注文档的密级和所属项目。
- AI相关配置变更：模型接入、知识库挂载、权限范围调整、提示词模板修改等管理动作，这类操作影响面大，应作为高优先级审计对象。
边界说明
为避免审计范围无限扩张，需要明确两条边界。全平台账号、角色与权限体系的治理归权限治理流程，AI操作审计只记录“AI动作发生时使用了什么权限、触及了什么数据”，不重复建设权限台账。模型训练、微调、评测等模型侧治理归模型治理流程，AI操作审计关注的是使用侧行为，不采集训练数据与模型参数。
按风险分级确定记录深度
全量记录所有AI操作会带来存储和复核成本，记录过少又无法支撑追溯。建议按数据敏感度分两档处理：
| 风险等级 | 典型操作 | 记录深度 | 复核方式 |
|---|---|---|---|
| 高 | 处理含客户信息、个人信息、核心代码、未公开财务数据的AI操作；AI配置变更 | 全量记录，字段完整，保留输入输出摘要 | 逐条复核或按规则自动命中后人工复核 |
| 一般 | 公开资料总结、通用问答、非敏感代码补全 | 记录基础字段，输入输出仅留摘要 | 按比例抽样复核 |
完成标志：形成一份带风险等级的审计对象清单，每个对象标注记录深度和复核方式，并经安全或合规负责人确认。
核心答案与操作步骤：六步建立AI操作审计
AI操作审计可以按“定范围→定字段→定采集→定复核→定留存→做试点”六步推进。每一步都有明确输入、动作、输出和完成标志，避免停留在制度文本层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、确定审计范围与责任人 | AI工具清单、数据分类分级结果 | 列出审计对象，划分风险等级，指定审计负责人和各工具对接人 | 审计对象与边界清单、责任人名单 | 清单经审批发布，每个对象都有明确责任人 |
| 二、定义记录字段 | 审计对象清单、合规要求 | 确定必填与选填字段，明确脱敏规则 | 最小字段表 | 字段表通过评审，采集方确认可提供 |
| 三、确定采集方式 | 字段表、各工具的技术能力 | 按工具选择日志接入、网关代理、平台审计接口或人工登记，明确采集频率 | 采集方案与数据流向说明 | 至少一个工具完成采集联调，字段能对上 |
| 四、设定复核规则与分级 | 风险分级、字段表 | 定义命中规则（如涉及高敏数据、异常时段、大批量导出），设定复核人和时限 | 复核规则清单与升级路径 | 规则可配置，复核任务能自动生成并分派 |
| 五、确定证据留存位置与期限 | 复核规则、合规留存要求 | 指定日志与复核结论的存储位置、访问权限和保留期限 | 留存方案与访问控制矩阵 | 留存位置可查、权限受控、期限有书面依据 |
| 六、试点并校验完整性 | 前五步全部产出 | 选一个团队或一类工具试运行两到四周，抽样比对实际操作与记录 | 试点报告与问题清单 | 抽样记录完整率达到约定目标，问题完成整改 |
六步之间存在依赖关系：字段表决定采集方案，采集质量决定复核是否可行，试点结果反过来修正范围和字段。建议把试点安排在采集联调完成之后，用真实操作验证记录是否“找得到、看得懂、追得回”。
审计记录字段怎么定：最小字段表
字段设计的目标是“够用且不惹新风险”。记录太少无法追溯，记录太多会把敏感原文搬进日志，反而扩大泄露面。建议以八个必填字段为基线，再按工具能力补充选填字段。
| 字段 | 类型 | 说明 | 脱敏与留存要求 |
|---|---|---|---|
| 操作人 | 必填 | 账号标识与所属团队 | 保留账号ID，展示时按需映射姓名 |
| 操作时间 | 必填 | 精确到秒，统一时区 | 原样留存 |
| 工具与模型 | 必填 | 使用的AI工具、模型名称或版本标识 | 原样留存 |
| 操作类型 | 必填 | 问答、生成、总结、检索、配置变更等 | 使用统一枚举值 |
| 输入摘要 | 必填 | 输入内容的主题、长度、涉及的数据类别 | 不记录原文，敏感字段以类别标签替代 |
| 输出摘要 | 必填 | 输出类型、用途、是否被采纳 | 不记录全文，必要时仅留哈希或截断摘要 |
| 涉及数据范围 | 必填 | 数据所属项目、文档密级、是否含个人信息 | 用密级和标签表达，不写具体内容 |
| 结果状态 | 必填 | 成功、失败、被拦截、待复核、已复核 | 状态流转需留时间戳 |
| 会话标识 | 选填 | 用于串联同一会话内的多次操作 | 随机ID，不含用户信息 |
| 审批单号 | 选填 | 涉及敏感数据时的审批关联 | 原样留存 |
| 关联工作项 | 选填 | 该AI操作对应的需求、任务或缺陷编号 | 原样留存 |
| 留存位置 | 选填 | 原始日志或证据的存储路径 | 仅授权人员可见 |
脱敏有三条实操原则：输入输出只记摘要和类别标签，原文留在原系统并受原权限控制；涉及个人信息的字段做掩码处理；日志访问本身纳入权限管理，按角色授予查询和导出权限。完成标志是字段表通过评审，且采集方逐项确认可提供。
角色分工与交付物
审计机制失效的常见原因是“日志有人采、没人看”。需要把记录、复核、处置、归档四类动作落到具体角色，并明确交付物和时限。
| 角色 | 主要职责 | 交付物 | 频率与升级路径 |
|---|---|---|---|
| AI使用团队 | 按规范使用AI工具，敏感操作前提交审批，配合复核说明用途 | 审批单、操作说明 | 按需；拒绝配合时升级至团队负责人 |
| 平台/工具管理员 | 配置采集、维护字段映射、保障日志完整接入 | 采集配置说明、接入清单、异常告警记录 | 持续；采集中断时24小时内上报审计负责人 |
| 安全或合规复核人 | 按规则复核命中记录，判定是否合规，提出处置意见 | 复核结论、处置建议 | 高敏操作逐条复核，一般操作按周抽样 |
| 审计负责人 | 维护审计范围与规则，汇总复核结果，组织证据归档与定期报告 | 审计月报、问题整改跟踪表、归档记录 | 按月出报告；重大异常直接上报管理层 |
复核频率建议与风险等级挂钩：高敏数据操作在操作发生后一个工作日内完成复核，一般操作按周抽样。升级路径要写清楚触发条件，例如复核人判定存在数据外泄风险时，同步通知安全负责人和业务负责人，并在处置完成后将结论与证据一并归档。
在复核任务分派和证据归档环节，可以用工作项和文档承载状态流转。ONES 的AI研发管理方案基于其权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能将自然语言指令转化为 ONES 中可追踪的工作，并把结果保存为工作项、Wiki 页面等内容。对于已经在 ONES 内管理研发工作的团队，可以把复核任务建成工作项、把处置结论沉淀到 Wiki 页面，让审计记录与研发过程数据在同一处关联。具体审计字段、留存期限和导出能力需在选型时向厂商核验。
示例：一次高敏数据AI操作如何被审计
以下为演示情景，用于说明字段取值与状态流转，不代表真实案例。
情景：某研发团队成员需要整理一份含客户联系方式的反馈文档，使用接入企业知识库的AI助手做要点总结。
- 操作发生：员工在AI助手中上传文档并请求总结。系统生成一条审计记录：操作人为该员工账号，操作时间为当日14:32，工具与模型为内部AI助手及对应模型标识，操作类型为“文档总结”，输入摘要为“客户反馈文档，约12页，含个人信息”，输出摘要为“要点列表，未采纳”，涉及数据范围为“客户支持项目，内部密级，含个人信息”，结果状态为“成功”。
- 规则命中：复核规则中“涉及个人信息”为高敏条件，该记录自动标记为“待复核”，并生成一条复核工作项，分派给安全复核人，时限为一个工作日。
- 复核人核查：复核人查看记录摘要，确认文档是否经过审批、输出是否被外发。核查发现员工未提交审批，但输出仅保存在内部会话中、未对外发送。
- 处置结论：复核人判定为“流程违规、无外泄”，要求员工补交审批并对该文档做脱敏处理，结论写入复核工作项，状态更新为“已复核”。
- 证据归档：复核工作项、审批补单、脱敏后的文档版本一并关联归档，审计记录中的结果状态同步更新，留存位置字段指向归档目录。
这个例子体现了三个关键点：规则命中要能自动生成复核任务，复核结论要能回写到记录状态，证据要能从结论反向追溯到原始操作。三者缺一，审计就会停在“有日志、没闭环”的状态。
完成检查：审计机制是否可用的验收项
审计机制是否可用，不看制度写得多完整，而看能否通过以下四类检查。建议在试点结束后逐项核对，未通过项列入整改。
| 验收维度 | 检查项 | 通过标准 |
|---|---|---|
| 记录完整性 | 随机抽取若干条真实AI操作，能否在日志中找到对应记录 | 抽样记录完整率达到约定目标，必填字段无空缺 |
| 复核闭环 | 命中规则的操作是否都有复核结论，是否存在长期挂起的待复核项 | 待复核项在时限内关闭，超时项有升级记录 |
| 证据可追溯 | 从任一复核结论能否回溯到原始记录、审批单和处置动作 | 抽查若干条结论，链路完整可查 |
| 留存与权限 | 日志访问是否按角色受控，留存期限是否有书面依据并实际执行 | 越权访问为零，留存策略有配置记录 |
除上述四项，还可补充两项观察指标：复核结论中“流程违规”类问题的数量变化，用于判断培训和审批前置是否见效；采集异常告警的响应时长，用于判断采集链路是否稳定。验收通过后，建议每季度复检一次，并在AI工具新增、模型切换或数据范围扩大时重新评估审计对象清单。
常见问题
团队规模不大、AI工具用得也不多，能不能先只做人工登记，不上日志采集？
可以，但要满足两个前提。一是登记字段与最终字段表保持一致，至少覆盖操作人、时间、工具与模型、操作类型、输入摘要、输出摘要、涉及数据范围、结果状态，避免后续接入日志时口径对不上。二是人工登记只适合低频、低风险场景，涉及客户信息、个人信息、核心代码的操作仍建议通过平台审计接口或网关代理采集，减少漏记和事后补记。
试点阶段可以先在一个团队用人工登记跑两到四周，用抽样比对验证字段是否够用，再决定哪些工具优先接入自动采集。
审计记录里不保存输入输出原文，出了数据外泄事件还能查得清吗？
能查清的前提是记录之间能串起来。输入输出只留摘要和类别标签，原文仍保存在原系统并受原权限控制，审计记录通过会话标识、关联工作项、审批单号等字段指向原文所在位置。发生事件时，先从审计记录定位操作人和时间，再凭关联标识到原系统调取受控原文，整个过程留有查询记录。
如果某些高敏场景确实需要留存原文片段，应单独设定加密存储和更严格的访问权限，并写进留存方案，不要默认把所有原文搬进审计日志。
复核人判定“流程违规但无外泄”之后，还需要做什么？
处置结论要落到三件事上：一是回写审计记录的结果状态，从“待复核”更新为“已复核”并附结论；二是对违规环节提出整改要求，例如补交审批、对文档做脱敏处理，并把整改项建成可跟踪的任务；三是把复核结论、补交的审批单和整改后的文档版本一并归档，保证从结论能回溯到原始操作。
同类问题反复出现时，说明前置审批或培训没有见效，应把这类问题的数量变化纳入定期报告，作为调整规则和培训内容的依据。
AI工具新增或模型切换后，原来的审计范围和字段表要重新做吗？
需要重新评估，不必全部重做。新增工具或切换模型会改变数据流向和记录能力，先核对三件事：新工具是否在原有审计对象清单内、能否提供字段表要求的必填字段、采集方式是否仍然可行。字段表通常可以沿用，个别字段按新工具的能力做映射调整。
建议把“AI工具新增、模型切换、数据范围扩大”写成触发条件，触发后由审计负责人组织一次范围复核，更新对象清单和采集配置，并在季度复检时确认整改到位。
用ONES承载复核任务和证据归档，具体能落到哪些对象上？
按现有资料，ONES Assistant 能把自然语言指令转化为 ONES 中可追踪的工作，并把结果保存为工作项、Wiki 页面等内容；ONES 的AI研发管理方案基于其权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计。对应到审计流程，可以把命中规则的记录建成复核工作项分派给复核人，把处置结论和归档说明沉淀到 Wiki 页面，让审计记录与研发过程数据在同一处关联。
具体的审计字段、留存期限和导出能力，资料中未作说明，选型时需向厂商核验后再确定能否满足你们的留存与取证要求。
