AI上下文权限设置的核心，是把“谁能把哪些数据带进哪次AI会话、以什么方式使用”拆成可配置的授权规则。落地顺序通常是：按数据敏感度与业务域划分上下文范围，按角色与项目成员关系设定可见与可引用边界，规定上下文进入、留存、外发与撤回的动作规则，再用审计记录和定期复核验证规则是否被执行。默认采用最小必要授权，敏感上下文单独审批，跨项目引用显式授权。
要点总览（TL;DR）
- AI上下文权限设置按“分层—授权—配置—验证—治理”五段推进：先按敏感度与业务域划分上下文范围，再确定角色与动作矩阵。
- 分层建议采用公开、内部、受限、机密四级，每级明确默认授权方式；未归类的来源一律按受限级处理，避免灰色地带。
- 授权矩阵以“角色×上下文层级×动作（读取、引用、外发、留存）”展开，默认最小授权，敏感与跨项目引用走显式审批并留痕。
- 配置落地分五步：盘点工具与来源、定义分层与矩阵、配置可见范围与引用规则、设置留存外发与撤回策略、小范围试点。
- 上线前用六项清单验收，上线后以月度审计加事件触发复核维持规则有效，审计发现与使用反馈作为迭代输入。
先定上下文边界：把AI可见数据分成哪几层
上下文权限的第一步是盘点“AI可能接触到的数据”，再按敏感度和业务归属分层。分层的目的在于让授权规则有统一的判断依据：同一层级的上下文采用同一套默认授权方式，例外情况才进入审批。建议同时使用两个维度：敏感度决定“能不能给AI用”，业务域与项目决定“给哪个范围的人用”。
按敏感度分四级
公开、内部、受限、机密四级适合多数研发团队起步使用。公开级指已对外发布或可公开引用的资料；内部级指团队日常协作内容，泄露会造成一定影响但可控；受限级指涉及未发布产品、客户信息、核心代码等，需要限定人员范围；机密级指合同、密钥、个人敏感信息等，原则上不进入AI会话，确有需要时走单独审批。
按业务域与项目划范围
敏感度回答“数据多重要”，业务域回答“谁的业务”。同一个内部级文档，属于A项目的成员可以引用，B项目成员默认不可见。把项目、产品线、职能部门作为上下文范围的基本单位，可以让授权规则与现有的成员关系对齐，减少逐人配置的工作量。
分层清单模板
下表可直接作为团队绘制上下文权限地图的起点，示例数据按团队实际情况替换。
| 层级 | 示例数据 | 默认授权方式 | 进入AI会话的条件 |
|---|---|---|---|
| 公开 | 已发布的产品文档、公开技术博客、开源代码 | 默认可用 | 可直接引用，记录来源 |
| 内部 | 迭代计划、需求文档、测试用例、一般缺陷记录 | 项目成员默认可用 | 限本项目成员，跨项目需显式授权 |
| 受限 | 未发布版本代码、客户定制需求、性能数据 | 需显式授权 | 按角色白名单开放，引用留痕 |
| 机密 | 合同、密钥、个人敏感信息、安全漏洞细节 | 禁止进入AI会话 | 单独审批，限定会话与用途 |
清单完成后要覆盖全部上下文来源：文档库、代码仓库、缺陷与工单系统、会议记录、聊天记录、附件与音视频。任何未归类的来源都视为受限级，直到明确归类为止，这样可以避免出现“没人管所以随便用”的灰色地带。
角色与授权规则怎么配：从默认最小授权到例外审批
分层确定后，需要回答“谁来设、按什么设”。角色划分与授权矩阵的作用，是把分散的判断变成可重复执行的规则。默认最小授权意味着：用户只能使用与其项目成员关系和数据层级同时匹配的上下文；超出这个范围的引用，一律走显式授权或审批。
四类角色及其职责
- 平台管理员：维护上下文分层清单、角色矩阵和工具侧配置，负责新AI工具接入时的权限评估。
- 项目负责人：审批本项目内的受限上下文引用和跨项目引用申请，确认申请人确有业务需要。
- 普通使用者：在授权范围内使用上下文，发起例外申请，对自己发起的会话内容负责。
- 审计角色：独立于业务线，定期检查授权记录、审批记录和会话引用记录，输出审计发现。
角色×层级×动作授权矩阵
动作维度建议拆成读取、引用、外发、留存四类。读取指在AI会话中看到内容；引用指内容被AI用于生成回答并标注来源；外发指把AI输出或上下文带到团队外部；留存指会话记录与上下文的保存期限。四类动作的风险依次上升，授权应逐级收紧。
| 角色 | 公开 | 内部 | 受限 | 机密 |
|---|---|---|---|---|
| 平台管理员 | 读取/引用/留存 | 读取/引用/留存 | 读取/引用，外发需审批 | 仅配置规则，不直接读取 |
| 项目负责人 | 读取/引用/外发/留存 | 读取/引用/外发/留存 | 读取/引用，外发需审批 | 不可用，需单独审批 |
| 普通使用者 | 读取/引用/留存 | 读取/引用，外发需审批 | 需显式授权后读取/引用 | 不可用 |
| 审计角色 | 读取记录 | 读取记录 | 读取记录与审批单 | 读取审批单，不读取内容 |
例外审批路径
敏感上下文的例外申请应包含：申请人、所属项目、目标上下文、使用目的、预计使用时长、外发范围。审批人为项目负责人；涉及机密级或跨多个项目时，增加数据归属方负责人会签。审批通过后授予的是限定范围的临时权限，到期自动回收，审批单与授权记录一并留存，供审计角色抽查。
设置步骤：从策略定义到上线生效的操作顺序
规则设计完成后，按以下五步落到工具与流程中。每一步都给出输入、动作、输出和完成标志，便于逐项验收，避免配置做到一半无法判断是否完成。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、盘点AI工具与上下文来源 | 团队在用的AI工具清单、各系统的数据目录 | 逐个工具记录可接入的上下文来源、接入方式、当前权限设置 | 工具与来源对照表 | 每个来源都有归属系统和责任人 |
| 二、定义分层与角色矩阵 | 来源对照表、组织成员关系 | 完成分层清单和授权矩阵，明确例外审批人 | 分层清单、授权矩阵、审批流程说明 | 矩阵中不存在“默认全开”的单元格 |
| 三、配置可见范围与引用规则 | 分层清单、授权矩阵 | 在AI工具及关联系统中按项目、空间、成员组设置可见范围，配置引用来源展示 | 配置记录与截图存档 | 用测试账号验证：越权访问被拒绝，授权访问正常 |
| 四、设置留存、外发与撤回策略 | 合规要求、数据层级定义 | 按层级设定会话留存期限、外发限制条件、撤回操作方式 | 留存与外发策略文档 | 策略与合规条款逐条对应，撤回操作有人会执行 |
| 五、小范围试点并收集反馈 | 已生效配置、试点项目名单 | 选一个项目或一个业务域试运行两到四周，记录误拦截、审批耗时、使用障碍 | 试点反馈清单与调整项 | 试点期内无越权事件，反馈项完成分类处理 |
第三步是配置工作量最集中的环节。可见范围应尽量复用系统中已有的项目成员关系和组织架构，减少单独维护白名单；引用规则要确保AI回答能标注来源，便于使用者判断内容是否在授权范围内。ONES 的 AI 研发管理方案基于 ONES 权限体系进行知识问答和任务执行，输出过程可追踪、结果可审计；ONES Assistant 可基于指定的 Wiki 页面组回答问题并附上引用来源，这类能力可以作为“限定上下文范围+来源可核查”的配置落点。具体配置项与操作路径以实际产品界面为准。
第四步容易被忽略。留存期限要与数据层级挂钩：内部级可保留较长周期用于知识沉淀，受限级应缩短留存并限制导出，机密级原则上不落库。撤回策略要明确触发条件，例如人员离职、项目结项、发现误授权，并指定执行人和执行时限。
示例：一个研发团队的上下文权限配置
以下为演示情景，用于说明分层、角色与规则如何组合，不指向任何真实客户。某研发团队约三十人，分为两个项目组，使用AI辅助编码和需求分析，上下文主要来自需求文档、代码仓库和缺陷记录三类。
三类上下文的授权差异
- 需求文档：迭代内的需求文档定为内部级，项目成员可读取和引用；涉及未发布定价或客户定制的需求定为受限级，仅产品负责人和项目负责人可引用，外发需审批。
- 代码仓库：主干分支代码定为受限级，参与该仓库开发的成员经显式授权后可让AI读取和解释；涉及安全模块的目录定为机密级，不进入AI会话。公开开源组件按公开级处理。
- 缺陷记录：一般缺陷定为内部级，项目成员可用；含客户信息或安全漏洞细节的缺陷定为受限级，仅测试负责人与项目负责人可引用，且会话留存期限缩短。
角色权限差异
项目负责人可审批本项目内的受限上下文引用和跨项目申请，可查看本项目的会话引用记录；普通成员在授权范围内直接使用，超出范围时提交申请，申请单需填写用途和预计时长。审计角色由质量人员兼任，每月抽查一次审批单与引用记录的一致性。
一次跨项目引用的审批与记录
演示情景：A项目成员在分析一个共用组件的问题时，需要引用B项目的缺陷记录。操作路径为：该成员提交跨项目引用申请，注明目标缺陷编号、使用目的和预计一周的使用期；B项目负责人收到申请后确认该缺陷不涉及客户敏感信息，批准一周权限；系统记录申请单、审批人、授权范围和到期时间；一周后权限自动回收，审计角色在月度抽查中核对这条记录与实际引用是否一致。整个过程的关键在于：授权有明确范围、有到期时间、有可查记录。
完成检查：上线前要验证哪些项
配置完成后，用下面这份清单逐项确认。任何一项不通过，都应先修复再扩大使用范围。
- 分层覆盖完整：工具与来源对照表中的每个上下文来源都已归入某一层级，没有“待定”项。
- 无越权默认项：授权矩阵中不存在普通使用者默认读取受限或机密上下文的配置；用测试账号实际验证越权访问被拒绝。
- 审批可追溯：敏感上下文和跨项目引用的每次授权都能关联到申请单、审批人和授权范围。
- 留存与外发合规：各层级的留存期限、外发限制与团队适用的合规要求逐条对应，并有书面说明。
- 审计日志可查询：审计角色能按人员、项目、时间查询授权记录和引用记录，查询结果可导出留档。
- 异常与撤回已演练：至少完成一次撤回演练，包括人员离职场景下的权限回收和误授权场景下的范围收缩，记录执行耗时。
检查通过后，把分层清单、授权矩阵、审批流程和检查结果整理成团队使用规范，随新成员入职和工具接入同步更新。
持续治理：审计、复核与规则迭代
权限规则上线后，人员、项目和工具都会变化，一次性配置很快会与实际情况脱节。持续治理要解决三个问题：规则是否被执行、规则是否仍然合适、由谁负责维护。
定期审计的内容与频率
建议每月执行一次常规审计，检查审批单与授权记录是否一致、是否存在到期未回收的临时权限、受限上下文的引用是否都在授权范围内。每季度做一次全面复核，覆盖分层清单的完整性和授权矩阵的适用性。审计输出应包含发现项、责任人和整改期限。
触发式复核的条件
以下事件发生时，应立即触发针对性复核，而不必等到下一个审计周期：人员入职、转岗或离职；项目立项、合并或结项；新AI工具或新上下文来源接入；合规要求或数据分类标准更新；发生越权事件或疑似泄露。
规则迭代的输入与责任人
规则迭代的输入主要来自三处：审计发现的问题、使用者的反馈（如误拦截过多、审批耗时过长）、外部合规要求的变化。平台管理员负责汇总输入并起草调整方案，项目负责人参与评审，审计角色确认调整后仍可核查。每次调整都要记录版本、生效日期和变更原因，与历史审批记录一并留存，确保任何时点的权限状态都可以回溯。
常见问题
团队规模较小，是否也需要做四级分层和完整授权矩阵？
分层和矩阵的作用是给授权提供统一判断依据，规模小的团队可以简化执行，但不宜省略判断维度。起步阶段可先合并层级，例如把公开与内部合并为“默认可用”，受限与机密合并为“需审批”，同时保留敏感度与业务域两个维度。角色也可以合并，由项目负责人兼任审批与审计，但审批记录和授权记录仍需留存，否则后续人员变动时无法回溯。等团队扩大或接入新的AI工具，再拆回更细的层级。
业务部门坚持要用机密级数据做AI分析，审批应该怎么设计才不至于形同虚设？
机密级数据进入AI会话应作为例外而非默认路径。可行的做法是把审批拆成两道：第一道由数据归属方负责人确认使用目的正当且范围最小，第二道由平台管理员确认技术侧限制到位，例如限定单次会话、限定使用时长、禁止导出。审批通过后授予临时权限并设置自动回收时间，审批单与授权记录一并留存供审计抽查。若同一类需求反复出现，应回到分层清单评估是否调整该数据的归类，而不是持续走例外审批。
配置完成后如何验证越权访问确实被拦住？
仅检查配置界面不足以确认效果，需要用测试账号做实际验证。建议准备三类账号：仅属于A项目的普通成员、属于B项目的普通成员、无项目归属的新成员，分别尝试读取和引用各层级上下文，确认受限与机密级访问被拒绝、内部级仅在本项目内可用。跨项目引用场景也要单独验证一次，确认申请未审批时无法引用、审批通过后权限在到期时间自动回收。验证结果记录存档，作为上线检查清单的一项证据。
AI工具更新或更换后，原有权限配置需要重新做一遍吗？
不需要从零重做，但必须做针对性复核。分层清单和授权矩阵属于团队规则，可以沿用；需要重新评估的是新工具的上下文接入方式、可见范围配置能力、留存与外发控制手段是否与现有规则匹配。复核时应把新工具加入工具与来源对照表，确认每个来源都有归属系统和责任人，再用测试账号验证关键授权场景。若新工具缺少某项控制手段，应在规则中补充替代措施，例如缩短留存或限制可接入的上下文层级。
审计发现审批记录与实际引用不一致时，应该怎么处理？
先冻结相关权限，再核查差异原因。常见原因包括临时权限到期未回收、审批范围与实际引用范围不符、人员转岗后权限未同步调整。处理顺序是：收回超出范围的权限，补齐或更正记录，评估是否发生了数据外泄风险，必要时通知数据归属方。整改完成后要把该案例写入审计发现清单，明确责任人和整改期限，并在下一次规则迭代中评估是否需要调整审批流程或自动回收机制。
