AI上下文权限要解决的是：AI在什么场景下、以什么身份、能读取和带出哪些研发上下文。本文给出一套可落地的管理框架——把上下文按敏感度分级，按角色与任务场景设定最小必要授权，把申请、审批、使用、回收串成可追溯的流程，并用脱敏、范围限定和审计记录兜住风险，最终形成分级表、授权矩阵和申请回收流程三份核心产物。
要点总览（TL;DR）
- AI上下文权限管的是AI在具体场景下以什么身份、能读取和带出哪些研发上下文，落地抓手是分级、授权、流程、审计四件事。
- 先按敏感度、可外发程度、业务归属给需求、代码、缺陷、文档、日志分级，形成一张有级别、有默认处理方式的上下文分级表。
- 再把级别对应到研发人员、项目负责人、安全或合规负责人、平台管理员四类角色和个人辅助、团队协作、跨团队共享三类场景，矩阵未覆盖的组合一律视为不允许。
- 申请、审批、使用、回收四段流程各有输入输出，回收与审计是收尾动作；离职、转岗、权限变更要写清触发人和核对记录。
- 上线前用检查清单逐项核对分级覆盖度、矩阵完整性、流程闭环、审计可追溯和越权处置，再进入试运行并按月复核。
先给答案：AI上下文权限管什么、管到哪一步
AI上下文权限，指的是对“AI可以访问哪些研发上下文、以什么身份访问、用于什么用途、结果能带出到哪里”作出明确约定并留下记录。它管的对象是喂给AI或由AI检索的研发资料，包括需求、代码、缺陷、文档、日志等；管的手段是分级、授权、流程和审计；管的落点是每一次AI使用都有据可查、有边界可依。
需要先划清边界。本文聚焦AI使用环节的上下文治理，回答“哪些资料能给AI看、谁能批准、看完怎么收回”。全平台账号与权限体系、模型训练数据治理不在本文展开，它们由各自的安全与平台团队负责。把范围收窄，机制才建得起来、跑得动。
整体框架可以概括为四件事，按顺序推进：
- 分级：把研发上下文按敏感度和可外发程度划成若干级别，形成统一判断口径。
- 授权：把级别对应到角色和场景，明确谁在什么情况下可以授权AI读取哪一级上下文。
- 流程：把申请、审批、使用、回收串成一条端到端链路，每一步有输入、动作、输出。
- 审计：记录授权对象、上下文范围、用途、审批依据和使用时间，支撑事后追溯与定期复核。
落地需要三份核心产物：一张上下文分级表，回答“这类资料属于哪一级”；一份角色授权矩阵，回答“谁能批、批到哪一级、有效期多久”；一套申请与回收流程，回答“怎么走、谁签字、何时失效”。三份产物互相咬合，缺一件机制就会漏风。
第一步：把研发上下文按敏感度分级
分级是整套机制的起点。没有统一的分级口径，授权就只能靠个人判断，审批人也无从核对。分级的做法是先盘点常见上下文类型，再用固定维度打分，最后落到一张可填写的表上。
常见上下文类型与分级维度
研发场景中经常进入AI的上下文大致有五类：需求描述（需求文档、用户故事、验收标准）、代码与提交记录（源码、分支、提交说明、合并请求）、缺陷与测试数据（缺陷单、复现步骤、测试用例与测试数据）、设计文档（架构说明、接口文档、方案评审记录）、日志与配置（运行日志、环境配置、密钥相关配置）。
判断级别时建议同时看三个维度：敏感度（泄露后对业务、客户、合规的影响）、可外发程度（能否离开内网、能否进入外部模型）、业务归属（属于哪个项目、哪个客户、是否涉及第三方约束）。三个维度交叉后给出级别，比单看“是不是机密”更可操作。
分级表字段与填写规则
| 上下文类型 | 示例 | 级别 | 允许的AI用途 | 默认处理方式 |
|---|---|---|---|---|
| 需求描述 | 需求文档、用户故事、验收标准 | 中 | 需求分析、拆解、评审辅助 | 限项目内使用，跨团队需审批 |
| 代码与提交记录 | 源码片段、提交说明、合并请求 | 中至高 | 代码解释、评审辅助、缺陷定位 | 按仓库归属定级，核心仓库升一级 |
| 缺陷与测试数据 | 缺陷单、复现步骤、测试数据 | 中 | 缺陷归因、用例生成 | 含真实用户数据的须脱敏 |
| 设计文档 | 架构说明、接口文档、评审记录 | 中至高 | 方案总结、影响分析 | 未发布方案按高一级处理 |
| 日志与配置 | 运行日志、环境配置、密钥配置 | 高 | 排障分析（限脱敏后） | 默认禁止直接输入，须脱敏并审批 |
填写规则建议固定三条：级别只升不降，遇到拿不准的资料按高一级处理；同一类型在不同项目下可以不同级，以业务归属为准；默认处理方式必须写清“是否需要脱敏、是否需要审批”，避免只标级别不给动作。
这一步的输入是各团队的资料清单和业务归属信息，动作是逐类判定级别并填写表格，输出是一份经安全或合规负责人确认的分级表。完成标志是：主要上下文类型全部有级别、有默认处理方式，且团队对边界案例的判定口径一致。
第二步：按角色与场景设定最小授权
分级回答“资料多敏感”，授权回答“谁能把它交给AI”。做法是把角色和场景做成二维矩阵，交叉点上写清可访问级别、审批要求和有效期，默认拒绝、按需申请。
角色与场景的划分
角色建议分四类：研发人员（日常使用AI辅助编码、分析需求、排查缺陷）、项目负责人（决定本项目上下文的使用范围）、安全或合规负责人（审批高敏感上下文、裁定边界案例）、平台管理员（配置权限、维护记录、执行回收）。场景分三类：个人辅助（仅本人使用、结果不外传）、团队协作（项目内共享AI产出）、跨团队共享（跨项目或跨部门调用上下文）。
授权矩阵示例
| 角色 | 场景 | 可访问级别 | 审批要求 | 有效期 |
|---|---|---|---|---|
| 研发人员 | 个人辅助 | 低、中 | 无需审批，登记用途 | 随项目周期 |
| 研发人员 | 团队协作 | 低、中 | 项目负责人审批 | 不超过项目阶段 |
| 项目负责人 | 团队协作 | 低、中、高（本项目） | 安全或合规负责人复核高敏感 | 按项目里程碑 |
| 安全或合规负责人 | 跨团队共享 | 高 | 本人审批并记录依据 | 单次或短期 |
| 平台管理员 | 全部场景 | 按配置执行 | 不自行授权，仅执行已批事项 | 与授权一致 |
最小必要原则要落到具体写法上：矩阵里没写的组合一律视为不允许；高敏感上下文默认只给单次、短期授权；跨团队共享必须单独审批，不能沿用项目内授权。默认拒绝的好处是，新增场景时需要显式补规则，而不是靠“应该没人会这么用”来兜底。
这一步的输入是分级表和角色清单，动作是逐格填写可访问级别、审批要求和有效期，输出是经评审的角色授权矩阵。完成标志是：每个角色在每个场景下都有明确结论，空白格被解释为“不允许”而非“待定”。
第三步：把申请、审批、使用、回收串成流程
矩阵定规则，流程保证规则被执行。端到端流程分四段，每段都要有输入、动作、输出和完成标志，缺一段就会出现“批了但没记录”或“到期了没人收”的漏洞。
申请
申请人提交上下文范围（具体到项目、文档、仓库或数据集）、用途（要AI完成什么任务）、期限（起止时间或项目阶段）。动作是填写申请单并附上分级依据；输出是一份可审批的申请记录。完成标志是范围、用途、期限三项齐全，且范围能对应到分级表中的具体条目。
审批
按申请涉及的级别匹配审批人：中低级别由项目负责人审批，高级别由安全或合规负责人审批，跨团队共享单独走一次审批。动作是核对分级依据、确认用途合理、给出批准范围与有效期；输出是带审批人、审批时间、审批依据的批准记录。完成标志是审批结论明确、批准范围不超出申请范围。
使用
AI侧按批准范围限定可读取的上下文，涉及真实用户数据或日志的先脱敏，使用过程留痕。动作包括范围限定、脱敏处理、记录使用时间与用途；输出是使用记录。完成标志是实际读取范围与批准范围一致，脱敏记录可查。
回收
到期或项目结束时撤销授权，并核对使用记录是否与批准范围相符。动作是撤销权限、核对记录、归档申请与审批材料；输出是回收记录。完成标志是权限已撤销、记录已核对、异常情况已转交处理。
这条流程需要有承载的地方。ONES 的 AI 研发管理方案围绕真实项目、真实知识和真实权限运行，基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 能理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，并可基于指定的 Wiki 页面组回答问题、附上引用来源。把申请单、审批结论和回收记录挂到对应的工作项或文档状态上，流程就有了可查的落点，而不必另建一套台账。
角色分工与交付物：谁负责哪一段
流程跑不起来，多数时候不是规则不清，而是责任没落到人。下表把四类角色在机制中的职责、交付物和交接点对齐，便于直接分工。
| 角色 | 主要职责 | 交付物 | 交接点 |
|---|---|---|---|
| 研发人员 | 提出申请、按批准范围使用、发现异常上报 | 申请单、使用记录 | 向项目负责人提交申请；向平台管理员反馈异常 |
| 项目负责人 | 审批项目内中低级别申请、确认用途与期限 | 审批记录、项目内授权清单 | 高敏感申请转交安全或合规负责人 |
| 安全或合规负责人 | 审批高敏感与跨团队申请、裁定边界案例、定期复核 | 审批依据、复核报告 | 复核结论反馈平台管理员执行 |
| 平台管理员 | 配置权限、执行回收、维护审计记录 | 权限配置记录、回收记录、审计台账 | 向安全或合规负责人报送审计结果 |
权限变更、离职和转岗是最容易漏的环节，责任要提前写死：离职由平台管理员在离职流程触发时撤销全部AI上下文授权，并核对最后一段使用记录；转岗由本人提出变更申请，原项目负责人确认收回、新项目负责人重新审批；权限变更一律走申请流程，不允许口头调整。交接点写清楚，责任才不会在角色之间掉地上。
示例：一个需求分析场景的上下文授权全过程
以下为演示情景，用于说明分级、授权、流程与审计如何串联，不代表真实客户案例。
场景设定：某项目组研发人员小张要用AI辅助分析一个新需求，需要读取本项目的需求文档，并参考历史缺陷记录判断实现风险。
分级判定：按分级表，需求文档属于“需求描述”，级别为中，默认限项目内使用；历史缺陷记录属于“缺陷与测试数据”，级别为中，含真实用户数据的部分须脱敏。两项都在中级别，未触及高敏感上下文。
授权确定：对照授权矩阵，研发人员在“个人辅助”场景可访问低、中级别，无需审批但需登记用途；由于小张要把AI产出用于团队评审，场景变为“团队协作”，需项目负责人审批，有效期不超过当前项目阶段。
流程执行：小张提交申请，写明范围（本项目需求文档、近一年缺陷记录）、用途（需求拆解与风险识别）、期限（本迭代结束）。项目负责人核对分级依据后批准，记录批准范围与有效期。使用环节，缺陷记录中的用户信息先脱敏，AI读取范围限定在批准的项目与文档内，使用时间与用途留痕。迭代结束后，平台管理员撤销授权，核对使用记录与批准范围一致，归档申请与审批材料。
可迁移的规律：先分级再定授权，场景变化会改变审批要求；范围写得越具体，审批和使用越好核对；回收不是可选项，而是流程的收尾动作。适用边界在于，这个示例覆盖的是中级别上下文；一旦涉及高敏感日志或跨团队共享，审批层级和有效期都要相应收紧。
完成检查：上线前逐项核对
机制建成后，用一张清单判断是否达到可用状态。每项给出通过标准和负责人，逐项打勾再上线。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 分级表覆盖度 | 需求、代码、缺陷、文档、日志等主要类型均有级别和默认处理方式 | 安全或合规负责人 |
| 授权矩阵完整性 | 角色与场景交叉格均有结论，默认拒绝已写明，审批要求可执行 | 项目负责人 |
| 流程闭环 | 申请、审批、使用、回收四段均有输入输出，回收环节有明确触发条件 | 平台管理员 |
| 审计可追溯 | 授权对象、上下文范围、用途、审批依据、使用时间均可查 | 安全或合规负责人 |
| 异常与越权处置 | 有上报入口、处置责任人和处理时限，越权使用能被发现并纠正 | 平台管理员 |
| 变更与离职衔接 | 离职、转岗、权限变更均有触发动作和核对记录 | 平台管理员 |
清单全部通过，说明分级、授权、流程、审计四件事已经咬合，机制可以进入试运行；试运行期间建议按月复核一次授权清单和审计记录，把边界案例补进分级表，让规则随使用逐步收敛。
常见问题
AI上下文权限和公司现有的账号权限体系是什么关系？
两者管的对象不同。账号权限体系解决“谁能登录哪些系统、能操作哪些功能”，AI上下文权限解决“AI在具体任务中能读取和带出哪些研发资料”。实施时通常以现有账号与项目权限为基础，再叠加一层面向AI使用的分级与授权规则，避免另起一套身份体系。本文只讨论后一层；全平台账号与权限治理由平台和安全团队负责，两边的规则需要对齐，例如项目成员变动后，对应的AI上下文授权也应同步复核。
团队规模小、上下文类型不多，能不能先简化分级表？
可以简化字段，但不宜省掉分级这个动作。小团队可以先只保留“上下文类型、级别、默认处理方式”三列，把需求、代码、缺陷、文档、日志五类各给一个级别，先跑起来。需要保留的底线是：拿不准的资料按高一级处理；含真实用户数据的资料先脱敏；跨项目使用单独确认。等使用场景增多、出现边界案例，再补充“允许的AI用途”和“业务归属”字段，把判定口径逐步写细。
审批通过后，怎么确认AI实际读取的范围没有超出批准范围？
关键是把批准范围写成可核对的具体对象，例如具体项目、文档、仓库或数据集，而不是“相关需求资料”这类模糊描述。使用环节记录读取时间、用途和实际范围，回收时由平台管理员把使用记录与批准范围逐项比对，发现不一致就转交安全或合规负责人处理。如果所用工具支持按项目或页面组限定问答范围并附引用来源，核对会更容易；ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，ONES 基于自身权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计，具体记录字段和保留期限需在实施时与平台团队确认。
员工离职或转岗时，AI上下文授权应该由谁负责收回？
建议把回收动作挂到既有的离职和转岗流程上，由平台管理员执行，原项目负责人确认。离职时撤销全部AI上下文授权，并核对最后一段使用记录；转岗时由本人提出变更申请，原项目负责人确认收回，新项目负责人重新审批。责任写进流程触发条件，比依赖人工提醒更可靠。审计台账中保留撤销时间和核对结果，便于后续复核。
机制上线后，多久复核一次比较合适？
试运行阶段建议按月复核一次授权清单和审计记录，重点看三类情况：到期未回收的授权、超出批准范围的使用、分级表中没有覆盖的新上下文类型。稳定运行后可以按项目里程碑或季度复核，但高敏感上下文和跨团队共享的授权仍建议保持较短有效期、单次或短期审批。复核结论要回写到分级表和授权矩阵，让规则随实际使用逐步收敛，而不是停留在初版文档上。
