研发团队接入AI工具后，权限风险往往藏在“谁能用、能输入什么、生成内容怎么处理”这些日常动作里。这份验收清单围绕数据边界、身份与授权、过程留痕、输出物管控、第三方依赖五类风险展开，每项给出通过标准、证据要求和负责人，并标出必须清零的阻断项，供研发负责人、安全对接人和平台管理员在引入前与上线后逐项核对。
要点总览（TL;DR）
- 研发AI权限风险检查应覆盖五类可核验项：数据边界、身份与授权、过程留痕、输出物管控、第三方依赖，每项需有通过标准、证据和负责人。
- 检查分三个时点执行：选型引入前由安全对接人主责，账号开通前由平台管理员主责，上线后由研发负责人主责定期复核。
- 共享账号、敏感数据无限制输入、无任何调用留痕属于阻断项，必须清零并经研发负责人与安全对接人双人签字才能放行。
- 通过标准要写成可观察结果，证据按配置类、流程类、运行类分别采用截图、审批单和日志样本，抽样量建议每次不少于20条会话、10个代码提交和5份生成文档。
- 检查项宜建成工作项承载，证据附件与复核状态随工作项流转，ONES 的 AI 研发管理方案基于其权限体系运行，输出过程可追踪、结果可审计。
谁在什么时点执行这份检查
这份清单的检查对象是两类主体：一是实际使用AI工具的研发团队，包括开发、测试和文档撰写人员；二是负责工具引入与账号管理的工具管理方，通常是IT或研发平台团队。检查要覆盖三个时点，每个时点解决的问题不同，责任角色也不同。
| 检查时点 | 检查重点 | 主责角色 | 配合角色 |
|---|---|---|---|
| 选型引入前 | 数据能否进入工具、第三方条款是否可接受、插件来源是否可信 | 安全对接人 | 研发负责人、采购或法务 |
| 账号开通前 | 账号归属、角色划分、资源范围与回收机制 | IT/平台管理员 | 研发负责人、安全对接人 |
| 上线后定期复核 | 留痕是否完整、输出评审是否执行、权限是否随人员变化更新 | 研发负责人 | 安全对接人、平台管理员 |
三个时点的检查结论要能互相衔接：引入前的准入结论决定账号能否开通，账号配置结果决定上线后复核的基线。建议把复核周期定为每季度一次，人员变动频繁的团队可缩短到每月，具体周期由研发负责人与安全对接人共同确定并写入检查记录。
引入前的准入检查项
工具进入团队之前，先判断数据边界是否可接受。这一阶段的结论是后续所有配置的前提，任何一项不通过都不应进入账号开通环节。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 可输入AI的数据范围清单 | 已形成书面清单，明确代码、需求文档、测试数据、生产日志各自可否输入，并区分公开、内部、机密三级 | 数据分级清单及审批记录 | 安全对接人 |
| 敏感信息与客户数据排除规则 | 明确禁止输入的内容类型（如密钥、个人身份信息、客户合同原文），并有可执行的识别与提醒方式 | 排除规则文档、培训或提示记录 | 安全对接人 |
| 外部模型的数据留存与训练使用条款 | 已确认服务方是否留存输入内容、是否用于模型训练、留存期限与删除方式，结论与团队数据分级匹配 | 服务条款摘录、厂商书面答复 | 安全对接人、法务 |
| 插件、扩展与第三方集成来源核验 | 每个插件有明确来源、维护方和所需权限说明，未经验证的插件不进入允许列表 | 插件清单及来源核验记录 | 平台管理员 |
外部模型条款这一项容易被跳过。实际操作中，应要求服务方以书面形式说明输入数据的留存位置、留存时长以及是否进入训练语料；如果条款表述模糊，按“默认留存并可能用于训练”处理，再决定是否允许机密级数据进入。插件核验同理，来源不明的扩展即使功能好用，也应先列入观察名单而非直接放行。
账号开通与权限配置检查项
准入通过后，权限要落到具体账号、角色和资源范围上，形成可以逐条核对的配置结果。这一阶段检查的是配置事实，而非制度文本。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 账号实名与归属 | 每个账号对应一名真实员工，账号信息可追溯到工号或企业邮箱，不存在多人共用的通用账号 | 账号清单与人员对照表 | 平台管理员 |
| 按角色划分可用模型、数据源与功能 | 已定义角色（如开发、测试、文档），每个角色对应的模型、可访问数据源和可用功能有书面配置说明 | 角色权限矩阵、配置截图 | 平台管理员、研发负责人 |
| 最小权限与按项目隔离 | 成员默认只能访问所属项目的知识库与工作项，跨项目访问需单独申请并有审批记录 | 项目成员配置截图、审批单 | 平台管理员 |
| 离岗、转岗、外包结束的回收动作 | 人员变动触发权限回收，回收在约定时限内完成并有记录；外包人员权限单独标注到期时间 | 回收记录、外包权限到期清单 | 平台管理员、研发负责人 |
共享账号是这一阶段最常见的失守点。共用账号会让调用记录无法对应到人，一旦出现数据外泄也无法定位来源，因此应作为阻断项处理。按项目隔离的配置方式需要与团队实际协作结构匹配：跨项目协作频繁的团队可以设置只读的跨项目知识访问，但写入和导出权限仍应限定在项目内。
使用过程中的留痕与输出管控检查项
工具上线后，检查重点转向日常使用是否可追溯、生成内容是否经过评审再进入交付物。这一阶段的检查依赖抽样，不能只看制度文件。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 会话与调用记录留存 | 会话内容、调用时间、调用人和涉及的数据源可查询，保存期限满足团队审计要求 | 日志样本、留存策略说明 | 平台管理员 |
| 生成代码进入仓库前的评审 | AI生成的代码与人工代码走同一评审流程，提交记录中可识别生成来源，署名规则明确 | 代码评审单、提交记录样本 | 研发负责人 |
| 生成文档与测试用例的复核 | 每份AI生成的文档或测试用例有指定复核人，复核意见留痕，未复核内容不进入正式交付 | 复核记录、文档版本历史 | 研发负责人 |
| 敏感内容外发与导出的拦截或审批 | 导出、复制到外部工具或分享链接的行为有拦截规则或审批流程，异常导出可被识别 | 拦截规则配置、审批记录 | 安全对接人、平台管理员 |
留痕检查建议每月抽取一定数量的会话记录，核对是否存在向AI输入禁止内容的情况。生成代码的评审规则要与现有代码评审流程合并，避免形成两套标准；署名规则的作用是让后续维护者知道这段代码的来源，便于追溯和复查。
每项检查的通过标准与证据要求
清单能否起作用，取决于每项是否可判断通过与否。通过标准要写成可观察的结果，例如“账号清单中每个账号对应唯一人员”而不是“账号管理规范”；“抽样20条会话中无禁止内容输入”而不是“员工安全意识较强”。
证据类型按检查项性质选择：配置类检查用配置截图或导出清单，流程类检查用审批记录和评审单，运行类检查用日志样本。抽样核验时，样本量应与团队规模匹配，建议每次复核抽取不少于20条会话记录、10个代码提交和5份生成文档，样本覆盖不同角色和项目。检查项确实不适用的，要记录不适用原因和确认人，不能留空或直接勾选通过。
| 判定口径 | 写法示例 | 不接受的写法 |
|---|---|---|
| 可观察结果 | 账号清单中无重复人员，抽查5个账号均能对应到工号 | 账号管理规范、责任到人 |
| 可核验证据 | 附配置截图与导出清单，截图含配置时间 | 已按要求配置 |
| 抽样结论 | 抽取20条会话，0条包含禁止输入内容 | 整体情况良好 |
阻断项与放行条件
检查结果分两类处理：阻断项必须清零才能放行，观察项可限期整改。阻断项针对的是会造成不可逆后果的配置缺陷，典型包括共享账号、敏感数据无限制输入、以及完全没有调用留痕。这三类问题一旦存在，事后无法通过流程补救，因此不设整改期。
观察项包括插件来源说明不完整、部分角色权限矩阵未更新、复核记录缺失个别签字等，可设定整改期限，一般不超过一个复核周期。放行由研发负责人与安全对接人共同签字，平台管理员确认配置已生效；签字记录与检查表一并归档。复核周期内发现同类问题复发，应升级处理：第一次复发限期整改并通报，第二次复发暂停相关账号的AI功能使用，直至重新通过检查。
| 类别 | 典型情形 | 处置方式 | 放行条件 |
|---|---|---|---|
| 阻断项 | 共享账号、敏感数据无限制输入、无任何调用留痕 | 立即停止相关使用，完成配置后重新检查 | 清零并经双人签字 |
| 观察项 | 插件说明不全、权限矩阵未更新、记录缺签字 | 限期整改，期限内可带条件使用 | 整改完成并附证据 |
用工作项承载检查记录与复核
清单要真正被执行，需要把每个检查项变成可追踪的记录，而不是停留在表格文件里。做法是把检查项建成工作项，指定负责人和检查时点，证据附件与评审记录直接挂在工作项上，复核结论通过状态流转体现。
具体流程可以这样组织：引入前检查项在选型阶段创建，负责人上传条款摘录和插件清单；账号配置项在开通前创建，平台管理员附配置截图；上线后的抽样复核按周期自动生成新一轮工作项，复核人填写抽样结论并附日志样本。复核不通过时，工作项退回负责人，补充证据后再次提交，状态从“待复核”回到“整改中”再到“已通过”。这样每次复核都有独立记录，历史结论可追溯。
ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，检查项、证据与复核状态可以在同一套工作项体系中承载，减少清单与记录分离带来的遗漏。对于使用 ONES Assistant 的团队，其连接 ONES Project、ONES Wiki 与 ONES TestCase 的工作上下文，也便于把检查记录与对应的项目、文档关联起来。需要说明的是，会话记录的具体留存字段与期限、AI 侧按角色的配置粒度，应以实际部署时向平台方或厂商确认的结果为准，并写入检查表的证据栏。
常见问题
团队规模较小、没有专职安全人员时，这份检查由谁执行？
可以由研发负责人兼任安全对接人的角色，但引入前准入检查与上线后复核不宜由同一人独自完成。建议至少安排一名非直接使用AI工具的人员参与复核，例如技术负责人或质量负责人，对数据范围清单和抽样结论做二次确认。账号配置类检查仍应由平台管理员提供截图证据，避免配置与检查由同一人闭环。
外部模型服务方不提供书面留存说明，还能继续引入吗？
可以引入，但需要按更严格的边界处理：将可输入数据限定为公开或内部非敏感级别，机密级数据不进入该工具，并在准入检查表中记录条款缺失情况和确认人。如果业务确实需要输入敏感数据，应暂停引入，待服务方提供书面说明或改用可确认留存策略的部署方式后再评估。
上线后复核发现个别账号权限过大，是否必须立即停用？
视权限性质判断。若该账号可访问机密级数据源或具备导出能力且无审批记录，应按阻断项处理，先收回相关权限再重新检查；若只是角色矩阵未及时更新、实际访问范围仍在项目内，可列为观察项限期整改，整改期限一般不超过一个复核周期。判断依据是权限是否已造成不可逆的数据暴露风险。
检查记录用表格文件管理，和用工作项承载有什么区别？
表格文件适合一次性盘点，但复核周期一到，历史版本容易散落，证据附件与整改状态难以对应到具体责任人。把检查项建成工作项后，负责人、检查时点、证据附件和复核状态在同一记录上流转，复核不通过可退回整改并保留历史。ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，检查记录可在同一套工作项体系中承载。
生成代码的评审规则和现有代码评审流程冲突怎么办？
不建议为AI生成代码单独建一套评审流程。更稳妥的做法是在现有评审流程中增加两个动作：提交时标注生成来源，评审时确认生成部分是否经过人工理解和修改。署名规则也并入现有提交规范，说明生成工具与人工修改范围。这样既保留原有评审标准，也让后续维护者能追溯代码来源。
