AI使用责任清单的核心，是让每一项AI使用行为都能对应到明确的责任人、使用目的、数据范围、风险等级和复核记录。一份可直接使用的清单至少包含六类信息：使用主体与责任人、AI工具与用途、输入数据与敏感级别、输出使用范围与人工复核、风险分级与审批记录、变更与退出安排。本文提供一张空白表格、逐字段填写口径、必填与选填规则、一条完整示例，以及清单的维护方法。清单落地时，可借助ONES将责任人与复核记录关联到工作项和Wiki页面，使记录随研发流程留存。
要点总览（TL;DR）
- AI使用责任清单至少覆盖六类信息：使用主体与责任人、AI工具与用途、输入数据与敏感级别、输出使用范围与人工复核、风险分级与审批记录、变更与退出安排。
- 必填字段围绕可追溯性设置：记录编号、使用主体、直接责任人、工具名称、使用场景、使用目的、输入数据类型、敏感级别、输出使用范围、复核方式与复核人、风险等级、审批人与审批日期，缺失时应退回补充。
- 字段可按风险等级增减：低风险场景可简化留痕，中风险补齐留痕位置与复核记录，高风险增加脱敏说明、抽检比例和更短复审周期。
- 填写时一行对应一条AI使用行为，同一工具用于不同场景应分行登记，复核记录要能对应到可查的工作项或文档。
- 清单需版本化管理，按风险等级设定复审周期，场景结束或工具停用的记录标记失效并保留历史记录。
可复制空白模板：AI使用责任清单表
下表为空白模板，可直接粘贴到文档或表格软件中填写。表格按“基本信息—工具与用途—数据与输出—风险与审批—变更与退出”五组排列，每组对应一类需要回答的问题。填写时一行对应一条AI使用行为，同一工具用于不同场景时应分行登记。
| 组别 | 字段 | 填写内容 |
|---|---|---|
| 基本信息 | 记录编号 | |
| 使用主体（团队/角色） | ||
| 直接责任人 | ||
| 业务负责人 | ||
| 登记日期 / 最近更新日期 | ||
| 工具与用途 | AI工具名称 | |
| 版本或接入方式 | ||
| 使用场景 | ||
| 使用目的与预期产出 | ||
| 数据与输出 | 输入数据类型 | |
| 数据敏感级别 | ||
| 输出使用范围 | ||
| 人工复核方式与复核人 | ||
| 风险与审批 | 风险等级 | |
| 审批人 / 审批日期 | ||
| 留痕位置 | ||
| 复核记录（日期/结论） | ||
| 变更与退出 | 变更事项与变更日期 | |
| 复审周期 | ||
| 退出条件与停用日期 | ||
| 备注 |
空白行示例：若团队同时用同一助手做“需求文档初稿”和“测试用例补充”，应登记为两条记录，分别填写使用场景、输入数据和复核人，因为两类产出的风险与复核要求通常不同。表格粘贴到文档软件后，可将“组别”列合并单元格保留为分区标题；粘贴到表格软件后，建议冻结首行并给必填字段加底色，便于检查完整性。
字段说明：每个字段记录什么、怎么填
字段说明的作用是让不同角色按同一口径填写，避免同一份清单里出现“用途写得很细、数据范围却空着”的情况。以下按组解释每个字段的含义与填写口径。
使用主体与责任人
“使用主体”填写实际使用AI的团队或岗位，精确到能追到人的层级；“直接责任人”是日常操作并對输出负责的人；“业务负责人”是该场景产出被谁使用、由谁承担业务后果。三个字段分开，是为了在人员变动时仍能找到接手方。登记日期与最近更新日期用于判断记录是否过期。
AI工具、版本与用途
工具名称填写可识别的产品名或内部系统名；版本或接入方式记录是网页版、插件还是通过接口接入，版本变化可能影响数据处理方式。“使用场景”用一句话描述业务动作，例如“编写接口文档初稿”；“使用目的与预期产出”说明希望得到什么结果、产出交给谁使用。用途写得具体，后续复审时才能判断场景是否仍成立。
输入数据类型与敏感级别
输入数据类型按实际内容填写，如代码片段、需求文档、测试数据、客户信息、日志。敏感级别由团队既有数据分级口径决定，常见分为公开、内部、机密等档位。填写时注明是否包含个人信息或客户数据，以及是否做过脱敏处理。这一字段决定后续风险等级和审批层级，不能留空。
输出使用范围与人工复核
输出使用范围说明产出用于内部参考、进入正式文档、对外交付还是进入代码库，范围越靠外，复核要求越高。人工复核方式填写具体动作，如“由模块负责人逐条核对”“抽样检查并记录差异”；复核人填写姓名或岗位。仅写“已复核”无法证明复核发生过，应能对应到可查的记录。
风险分级、审批与留痕
风险等级依据数据敏感级别、输出使用范围和影响面综合判定，可沿用团队已有的低、中、高分级。审批人填写对该等级有审批权的角色，审批日期与结论一并记录。留痕位置写明审批与复核记录存放在哪里，例如项目工作项、文档页面或审批单编号，保证事后可查。
变更、复审与退出
变更事项记录工具更换、用途扩大、数据范围调整等变化及日期；复审周期写明多久复核一次；退出条件与停用日期说明什么情况下停止使用，例如项目结束、工具下线或风险升级。退出安排提前写清，可以避免工具停用后记录无人处理。
必填与选填：哪些信息缺失就不能放行
必填项的作用是保证每条记录可追溯：能回答“谁在用、用来做什么、处理了什么数据、产出由谁复核、谁批准”。以下字段缺失时不应放行使用；选填项用于补充说明，缺失不影响基本追溯。
| 字段 | 属性 | 理由或适用场景 |
|---|---|---|
| 记录编号、使用主体、直接责任人 | 必填 | 缺少则无法定位责任归属 |
| AI工具名称、使用场景、使用目的 | 必填 | 缺少则无法判断使用是否在批准范围内 |
| 输入数据类型、数据敏感级别 | 必填 | 决定风险等级与审批层级 |
| 输出使用范围、人工复核方式与复核人 | 必填 | 保证产出在被使用前经过检查 |
| 风险等级、审批人、审批日期 | 必填 | 证明该使用行为经过授权 |
| 业务负责人 | 建议必填 | 产出进入业务交付时应填写 |
| 版本或接入方式 | 选填 | 工具存在多入口或版本差异时填写 |
| 留痕位置、复核记录 | 选填（中高风险必填） | 低风险场景可简化为审批单编号 |
| 变更事项、复审周期、退出条件 | 选填（长期使用必填） | 一次性或短期试验可先不填，转长期使用时补齐 |
| 备注 | 选填 | 记录特殊约定或例外说明 |
必填缺失时的处理方式是退回补充，不进入审批环节；若确因场景简单无法提供某项信息，应由审批人书面说明替代判断依据，并记入备注。不同风险等级下字段可增减：低风险场景可合并复核记录与留痕位置，保留审批人即可；中风险场景需补齐留痕位置和复核记录；高风险场景还应增加数据脱敏说明、输出抽检比例和更短的复审周期。字段增减应写入清单版本说明，避免不同团队各自解释。
填写示例：一条完整的AI使用记录
以下示例为演示情景，用于说明字段之间的对应关系，不代表真实团队数据。
| 字段 | 填写内容 |
|---|---|
| 记录编号 | AI-2025-014 |
| 使用主体 / 直接责任人 / 业务负责人 | 支付服务组 / 后端工程师张某 / 支付服务组负责人李某 |
| 登记日期 / 最近更新日期 | 2025-03-10 / 2025-03-10 |
| AI工具名称 / 版本或接入方式 | 团队已批准的代码助手 / 编辑器插件 |
| 使用场景 | 为退款接口生成单元测试初稿 |
| 使用目的与预期产出 | 减少重复编写测试的时间，产出测试代码初稿，供开发自测使用 |
| 输入数据类型 / 敏感级别 | 接口定义、脱敏后的示例报文 / 内部 |
| 输出使用范围 | 仅进入开发分支，经评审后合入 |
| 人工复核方式与复核人 | 逐条核对断言逻辑并运行测试，复核人为模块负责人王某 |
| 风险等级 / 审批人 / 审批日期 | 中 / 技术负责人赵某 / 2025-03-11 |
| 留痕位置 / 复核记录 | 项目工作项 AI-2025-014 / 2025-03-12 复核通过，补充2条边界用例 |
| 变更事项 / 复审周期 / 退出条件 | 无 / 每季度 / 插件停用或接口下线时停用 |
这条记录与字段说明保持一致：使用主体精确到组，责任人到人；用途写明具体业务动作；输入数据标注了脱敏处理；输出范围限定在开发分支，复核动作可验证；审批与复核分别有日期和结论，留痕位置指向可查的工作项。若该场景后续扩大到处理真实客户报文，应更新数据敏感级别、重新评估风险等级并补充审批，而不是沿用原记录。
在ONES中，这类记录可以以工作项承载审批状态，以Wiki页面保存清单与复核说明，使责任人和复核结论随项目数据留存，便于复审时直接查阅上下文。
调整与维护方法：让清单随使用场景演进
清单的价值在于长期可用，字段过多会让人应付填写，字段过少则无法追溯。调整时应围绕“是否影响责任追溯”判断增删，而不是追求字段齐全。
按团队与场景增删字段的原则
新增字段的条件是它能回答一个新的追溯问题，例如团队开始使用外部接口调用模型，就需要增加“调用凭证管理方”字段；删除字段的条件是它长期为空且不影响放行判断。同一组织内建议保留一套基础字段，团队只增加场景字段，避免各团队清单无法横向汇总。
清单版本与变更记录
每次调整字段应更新版本号，并在清单末尾记录变更日期、变更内容和批准人。已填写的旧记录保留原字段值，新记录按新版本填写；跨版本汇总时以字段映射说明对应关系。
定期复审与失效处理
按风险等级设定复审周期，低风险可半年、中高风险按季度或更短。复审时核对工具是否仍在使用、用途是否扩大、数据范围是否变化、复核是否持续执行。场景结束或工具停用的记录标记为失效并注明日期，保留历史记录供审计，不直接删除。
与现有研发流程文档的衔接
清单不宜独立于研发流程存在。可将登记动作放在需求评审或技术方案评审环节，把审批记录关联到对应工作项，把填写规范放入团队文档库，并在代码评审或发布检查中核对高风险场景是否已完成登记。这样清单成为流程中的检查点，而不是事后补填的表格。
ONES Assistant可基于项目、工作项和Wiki页面等上下文回答问题并执行操作，结果可保存为工作项或Wiki页面，清单中的责任人与复核记录因此能跟随研发流程留存；其知识问答与任务执行基于ONES权限体系运行，输出过程可追踪。团队可将清单模板放入Wiki，把每条AI使用记录建成工作项，在评审时同步更新状态，使复审有据可查。
常见问题
团队刚开始使用AI工具，清单字段可以精简吗？
可以按使用范围精简，但精简的前提是保留可追溯的主线。记录编号、使用主体、直接责任人、工具名称、使用场景、输入数据类型、敏感级别、输出使用范围、复核人与审批人这些字段建议保留，它们回答的是“谁在用、用来做什么、处理了什么数据、产出由谁检查、谁批准”。版本或接入方式、留痕位置、复审周期等字段在低风险、短期试验场景下可以先简化，转为长期使用或风险升级时再补齐。精简后的字段调整应写入清单版本说明，避免不同团队各自解释。
同一款AI工具用于多个场景，需要分别登记吗？
建议分别登记。同一工具用于需求文档初稿和测试用例补充，输入数据、输出使用范围和复核要求通常不同，合并成一条记录会让风险等级和审批依据变得模糊。分行登记后，每条记录对应一个明确的使用场景和复核人，复审时也更容易判断某个场景是否仍在使用。若多个场景的数据敏感级别和复核方式完全一致，可以在备注中说明关联关系，但记录编号仍应独立。
复核记录只写“已复核”可以吗？
不建议。复核记录需要能证明复核动作实际发生过，仅写“已复核”无法对应到具体检查内容和结论。较稳妥的写法是记录复核日期、复核人、检查了什么、发现了什么差异、如何处理。例如“2025-03-12 由模块负责人逐条核对断言逻辑，补充2条边界用例后通过”。如果复核通过工作项评论或文档批注完成，留痕位置填写对应的工作项编号或页面链接，复审时可直接查阅上下文。
清单做好后，怎么和现有的需求评审、代码评审流程衔接？
把登记动作嵌入已有流程节点，比单独维护一张表更容易坚持。可以在需求评审或技术方案评审时确认是否涉及AI使用并完成登记，在代码评审或发布检查中核对高风险场景是否已审批、复核记录是否齐全。审批状态和复核结论关联到对应工作项，填写规范放入团队文档库。这样清单成为流程中的检查点，记录随项目推进自然更新，减少事后补填。ONES Assistant可基于项目、工作项和Wiki页面等上下文回答问题并执行操作，结果可保存为工作项或Wiki页面，其知识问答与任务执行基于ONES权限体系运行，输出过程可追踪，便于将责任人与复核记录随研发流程留存。
AI使用记录停用后应该删除还是保留？
建议保留并标记失效，不直接删除。场景结束、工具下线或风险升级导致停用时，在记录中填写退出条件和停用日期，将状态标记为失效。保留历史记录的作用是复审和审计时能还原当时的使用范围、审批依据和复核情况。若涉及数据范围变更或风险事件，历史记录还能说明变更前后的差异。删除记录会让追溯链断开，后续排查问题时缺少依据。
