研发团队引入代码补全、知识问答等 AI 应用后，真正难管的是“谁能用、能用什么数据、能做什么动作、用完留下什么记录”这四件事能否固定成机制。本文按划定范围、跑通授权流程、明确角色分工、完整示例、完成检查的顺序，给出一套可执行的治理方法，并说明如何借助研发管理工具承载申请、审批与复核记录。
要点总览（TL;DR）
- 治理范围先按研发环节列出 AI 使用场景，再按数据敏感度分级，形成场景—数据级别对照表，作为授权与审批依据。
- 授权流程分四步：登记 AI 应用清单、定义权限层级并绑定数据级别、跑通申请—审批—授予链路、设置复核与回收节奏，每步明确输入、动作、输出与完成标志。
- 角色分工覆盖 AI 应用负责人、数据或业务负责人、研发团队负责人、安全与合规角色、平台或工具管理员，各自对应可交付物，避免职责悬空。
- 机制是否有效以证据判断：应用清单、审批记录、日志与复核纪要齐全，无清单、无审批记录、权限长期未复核可直接判定为阻断项。
先定边界：哪些 AI 使用纳入治理范围
治理范围划得过大，机制会因牵扯全平台账号体系而推不动；划得过小，敏感代码已经流出却无人知晓。可行的做法是先按研发环节列场景，再按数据敏感度分级，两者交叉后确定哪些组合必须纳入治理。
研发环节中常见的 AI 使用场景包括：编码辅助（代码补全、片段生成）、代码评审（自动摘要、缺陷提示）、测试用例生成、文档与知识问答（基于内部 Wiki 或需求文档提问）、日志与故障分析。每个场景都要问清楚两件事：AI 应用读取什么数据，输出被用在哪里。
数据敏感度可按四档划分，档位越高，审批层级越高：
- 公开代码与公开文档：已开源或对外发布的内容，泄露风险低。
- 内部代码与内部文档：仅限公司内部可见的仓库、设计文档、需求说明。
- 含客户数据：包含客户名称、业务数据、合同信息的代码或文档。
- 含密钥与生产配置：访问凭证、数据库连接串、生产环境配置、部署脚本。
把场景与数据级别交叉，形成一张对照表，作为后续授权与审批的依据。表中每一行是一个“场景—数据级别”组合，标注是否纳入治理、需要哪一级审批。
| 使用场景 | 典型数据级别 | 是否纳入治理 | 审批要求（示例） |
|---|---|---|---|
| 编码辅助 | 公开代码 | 纳入，轻量登记 | 团队负责人确认 |
| 编码辅助 | 内部代码 | 纳入 | 团队负责人 + 安全角色 |
| 代码评审辅助 | 内部代码 | 纳入 | 团队负责人 + 安全角色 |
| 测试用例生成 | 内部代码、含客户数据 | 纳入 | 数据或业务负责人审批 |
| 文档与知识问答 | 内部文档 | 纳入 | 团队负责人确认 |
| 日志与故障分析 | 含密钥与生产配置 | 纳入，从严 | 安全角色 + 平台管理员 |
需要说明本文的边界：治理对象是 AI 应用的使用权限与数据输入输出，即谁被允许在什么场景下把什么数据交给 AI、AI 的输出如何被使用和留存。全平台账号与权限体系、模型训练与微调治理属于另外的主题，本文不展开，也不把它们混入同一张审批表，否则审批人会因职责不清而拖延。
核心答案与操作步骤：把授权流程跑通
核心答案可以概括为四步：登记应用清单、定义权限层级、跑通申请审批授予、设置复核与回收。四步串成一条闭环，每一步都有明确的输入、动作、输出和完成标志，缺任何一步，机制都会停在纸面。
第一步：登记 AI 应用清单
输入是团队正在使用或计划引入的 AI 应用信息。动作是逐项记录应用名称、提供方、部署方式（公有云服务、私有化部署或本地工具）、可访问的数据范围、对接的研发系统。输出是一份统一维护的应用清单。完成标志是：清单覆盖团队实际在用的全部 AI 应用，且每个应用都写明了数据范围，没有“用途待补充”的空项。
第二步：定义权限层级并绑定数据级别
输入是第一步的应用清单和 S1 的场景—数据级别对照表。动作是把使用权限划分为可区分的层级，例如：只读问答（只能提问，不能提交代码）、可提交代码片段（允许把代码发给 AI 处理）、可调用内部接口（允许 AI 应用访问内部系统或知识库）。每个层级与允许触及的最高数据级别绑定，形成“权限层级—数据级别”的对应关系。输出是权限层级定义表。完成标志是：任一权限申请都能对应到唯一层级，且该层级的数据上限清晰可查。
第三步：设计申请—审批—授予链路
输入是权限层级定义表和对照表中的审批要求。动作是让使用人提交申请，写明使用场景、拟访问的数据范围、使用期限；审批人依据数据级别确定——低级别由团队负责人确认，涉及客户数据由数据或业务负责人审批，涉及密钥与生产配置由安全角色审批；审批通过后由平台或工具管理员执行授权与配置。输出是审批记录和授权配置结果。完成标志是：每一次授权都能追溯到一条申请记录和对应的审批人，授权范围与申请范围一致。
第四步：设置复核与回收节奏
输入是授权记录清单。动作是按固定节奏（例如每季度）复核每项授权是否仍有必要，并在人员转岗、离职、项目结束、应用下线等事件发生时触发即时回收。输出是复核纪要和回收记录。完成标志是：复核覆盖全部有效授权，事件触发的回收在约定时限内完成，回收后权限状态与记录一致。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 登记应用清单 | 在用与拟引入的 AI 应用信息 | 记录名称、提供方、部署方式、数据范围 | AI 应用清单 | 清单完整，数据范围无空缺 |
| 定义权限层级 | 应用清单、场景—数据级别对照表 | 划分权限层级并绑定数据上限 | 权限层级定义表 | 每次申请可对应唯一层级 |
| 申请审批授予 | 权限层级定义表、审批要求 | 提交申请、分级审批、执行授权 | 审批记录、授权配置 | 授权可追溯到申请与审批人 |
| 复核与回收 | 授权记录清单 | 定期复核、事件触发回收 | 复核纪要、回收记录 | 复核全覆盖，回收及时且留痕 |
这条链路要真正跑起来，申请单、审批意见和复核任务需要有统一的承载位置，否则记录散落在聊天工具和邮件里，复核时无从查起。ONES 的 AI 研发管理方案强调围绕真实项目、真实知识和真实权限运行，基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；团队可以把 AI 使用申请作为工作项提交、把审批意见留在工作项流转记录中、把季度复核设为周期性任务，使授权记录与研发项目数据处在同一上下文里。具体到申请审批链的配置方式，需结合团队实际使用的 ONES 版本与部署方式确认。
角色及交付物：谁审批、谁维护、谁复核
治理机制失效最常见的原因不是规则缺失，而是职责悬空：清单没人维护、审批人不知道自己要审什么、复核没人发起。把角色与交付物一一对应，才能让每个环节有人负责、有物可查。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| AI 应用负责人 | 维护应用清单，说明每个应用的数据范围与用途 | AI 应用清单、数据范围说明 |
| 数据或业务负责人 | 按数据级别审批敏感数据的使用申请 | 审批意见与依据 |
| 研发团队负责人 | 确认成员的使用场景与必要性，控制授权范围 | 场景确认记录 |
| 安全与合规角色 | 制定分级规则，抽查调用日志，组织定期复核 | 分级规则、抽查记录、复核纪要 |
| 平台或工具管理员 | 执行授权、回收与配置变更 | 授权与回收操作记录 |
分工时有两个容易出错的点。其一，审批人与申请人不能是同一人，涉及客户数据或生产配置时尤其如此，否则分级审批形同虚设。其二，应用负责人与平台管理员职责要分开：前者对“这个应用该不该用、能用什么数据”负责，后者对“权限是否按审批结果准确开通和关闭”负责。团队规模较小时，一人可以兼任多个角色，但兼任关系要写进清单，复核时重点检查兼任角色的操作记录。
安全与合规角色的工作要落到具体动作上：每季度从日志中抽取一定数量的调用记录，核对实际访问的数据是否超出授权范围；发现超范围使用时，推动权限调整并记录处理结果。这类抽查不需要覆盖全部调用，但要保证抽查样本覆盖高敏感级别的应用。
示例：一次代码辅助工具接入的授权全过程
以下情景为演示用途，其中的团队规模、工具类型和审批时限均为假设条件，用于说明流程走法，不代表任何具体产品的实际能力。
情景设定：某研发团队计划引入一款代码补全类 AI 应用，供 20 名开发人员日常编码使用，应用需要读取内部代码仓库的代码片段。假设该团队已有应用清单制度，并按季度开展权限复核。
申请：团队负责人代表使用成员提交申请，写明使用场景为“日常编码辅助”，拟访问范围为两个内部业务仓库的代码，使用期限为一年，申请权限层级为“可提交代码片段”。申请作为工作项提交，附上场景说明和数据范围。
审批：由于涉及内部代码，按对照表需要团队负责人与安全角色分别确认。团队负责人确认使用必要性；安全角色核对拟访问仓库中是否包含客户数据或密钥配置，确认不含后批准，并在审批意见中注明“仅限指定两个仓库，不得扩展”。
授予与配置：平台管理员依据审批意见开通权限，在 AI 应用侧限定可访问的仓库范围，并在应用清单中登记本次授权的范围与期限。授权完成后，申请工作项状态更新为“已授权”，审批意见与配置结果一并留存。
留痕与复核：应用负责人按月查看调用日志，确认访问集中在授权仓库内；季度复核时，安全角色检查该授权是否仍被使用、使用范围是否变化。若项目结束或成员转岗，团队负责人发起回收，平台管理员关闭权限并记录回收时间。
这个示例可以迁移到测试用例生成、知识问答等其他场景，迁移时只需替换数据级别和对应审批人。示例中的审批时限、日志字段和工具配置方式需按团队实际情况确定。
完成检查：机制是否真的在运行
机制是否有效，不看制度文档写得多完整，而看能否拿出证据。以下检查项按证据来源组织，每项给出通过标准，并列出可直接判定为不通过的阻断项。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 应用清单完整性 | 团队在用的 AI 应用全部在清单中，数据范围无空缺 | AI 应用清单 |
| 权限与数据级别匹配 | 每项授权都能对应到权限层级，且未超出该层级的数据上限 | 权限层级定义表、授权记录 |
| 审批记录可追溯 | 每次授权都有申请记录、审批人和审批意见，审批人与申请人不同 | 申请工作项与审批记录 |
| 敏感数据输入有拦截或提示 | 涉及密钥、生产配置的输入有拦截或提示记录，且被处理 | 拦截或提示日志、处理记录 |
| 权限回收及时 | 离岗、转岗、项目结束、应用下线后，权限在约定时限内关闭 | 回收记录、人员变动记录 |
| 定期复核执行 | 复核覆盖全部有效授权，有纪要和处理结论 | 复核纪要 |
以下情况可直接判定机制未在运行，应先补齐再谈优化：没有任何形式的 AI 应用清单；授权找不到审批记录，或审批记录无法对应到具体申请人；存在长期未复核的授权，且无人能说明其必要性。这三类阻断项的共同点是“无法证明”，而治理机制的价值恰恰在于可证明。
检查频率可与复核节奏一致，按季度执行，并在引入新 AI 应用或发生重大人员变动后追加一次。检查结果应形成简短纪要，记录未通过项、责任人和整改期限，下次检查时优先核对上次未通过项是否已关闭。这样，治理机制才能从一次性的制度设计，变成持续运行的日常动作。
常见问题
团队规模较小，一人兼任多个治理角色时需要注意什么？
兼任本身可行，但要把兼任关系写进应用清单或角色说明，并在复核时重点检查兼任角色的操作记录。尤其要避免审批人与申请人为同一人，涉及客户数据或生产配置时更应分开。安全与合规角色的抽查动作也应有独立记录，不能因兼任而省略。
AI 应用清单应该记录哪些字段，后续复核才够用？
清单至少应包含应用名称、提供方、部署方式、可访问的数据范围、对接的研发系统、当前授权层级与授权期限。复核时主要核对数据范围是否变化、授权期限是否到期、使用人是否仍在原岗位。字段不必一次求全，但数据范围和授权期限不能空缺，否则复核时无法判断授权是否仍然必要。
季度复核发现某项授权长期未被使用，应该直接回收还是先确认？
建议先由应用负责人或团队负责人确认该授权是否仍有业务需要。确认不再需要的，按回收流程关闭权限并记录；确认仍需保留的，应在复核纪要中说明理由并设定下次复核时间。长期未使用且无人能说明必要性的授权，应作为阻断项处理，优先回收。
引入新的 AI 应用时，治理流程从哪一步开始衔接？
从应用清单登记开始。在正式授权前，先把应用名称、提供方、部署方式和拟访问的数据范围登记进清单，再按场景—数据级别对照表判断审批要求，然后走申请—审批—授予链路。这样新应用不会绕过既有机制，复核时也有记录可查。
