AI敏感信息检查的依据由四层构成：制度层明确AI使用与数据分级规则，清单层列出敏感信息类别和允许输入范围，流程层规定在哪些节点由谁检查，证据层保留检查记录与审批留痕。本文按这四层给出编制方法、节点检查表、角色分工和一个代码辅助场景示例，最后提供验收清单，帮助团队判断依据能否真正执行和追溯。
要点总览（TL;DR）
- AI敏感信息检查的依据由四层构成：制度层明确AI使用与数据分级规则，清单层列出敏感信息类别与允许输入范围，流程层规定检查节点与责任人，证据层保留检查记录与审批留痕。
- 编制顺序从数据分级和敏感信息清单开始，由数据安全或合规负责人牵头，业务与研发共同确认字段范围，并明确每类数据的允许使用场景。
- 检查动作嵌入三个节点：AI工具与账号申请、提示词与附件提交前、AI输出外发或入库前，每个节点设定检查项、通过标准和不通过处置方式。
- 例外审批要写明用途、数据范围、期限和到期复核，避免例外成为绕过检查的通道；审计角色定期抽样复核检查记录。
- 验收时用阻断项快速判断：无分级清单、无检查记录、例外无审批，任一存在即视为检查依据未完成。
检查依据由哪四层构成
只写一份《AI使用管理办法》不足以支撑检查。制度说明原则，检查需要可对照的清单、可执行的节点和可查证的记录。四层依据各自承担不同任务，并且要能相互对应：每一条规则都应落到一个具体检查动作，每个检查动作都应产生一份留存证据。
| 层级 | 文件或机制 | 对应检查动作 | 留存证据 |
|---|---|---|---|
| 制度层 | AI使用管理办法、数据分类分级规则、账号与授权要求 | 确认工具与账号已获批、使用范围符合授权 | 工具申请单、账号授权记录 |
| 清单层 | 敏感信息分类分级清单、敏感字段与关键词表、允许与禁止输入范围 | 提交前比对提示词与附件是否命中敏感类别 | 自检勾选记录、命中项说明 |
| 流程层 | 提交前自检、评审、例外审批与升级路径 | 按节点执行检查、评审或提交例外申请 | 评审意见、例外审批单 |
| 证据层 | 检查记录、审批留痕、处置记录与复盘结论 | 归档、抽样复核、问题整改跟踪 | 检查台账、复核报告、复盘纪要 |
四层的对应关系可以用一句话检验：随机抽一条制度条款，能否说出它由哪个检查项落实、由谁执行、留下什么记录。如果答不上来，这条规则在实际使用中很难被验证。制度层与清单层解决“依据什么判断”，流程层解决“什么时候由谁判断”，证据层解决“如何证明判断发生过”。
需要说明适用范围：本文讨论的是员工在日常工作中使用AI工具时的敏感信息检查，覆盖提示词、附件和输出结果三个接触面。全平台账号权限体系、模型训练数据治理属于相邻主题，需要另行制定规则，本文不展开。
第一步：确定数据分级与敏感信息清单
检查的起点是清单。没有分级和敏感字段表，使用者只能凭感觉判断“这段内容能不能发给AI”，评审人也缺少统一口径。编制清单是一项有明确输入、动作和输出的工作，通常一到两周可以完成首版。
输入
- 现有的数据安全制度、保密协议和客户合同中的数据使用条款；
- 业务系统的字段清单，重点看客户信息、订单、财务和日志类系统；
- 历史泄露、违规外发或安全告警事件，用来补充容易遗漏的敏感类别；
- 研发侧需要确认的代码仓库、设计文档和测试数据范围。
动作
先按公开、内部、敏感、严格受限四级划分数据，再在每一级下列出具体类别。常见类别包括：个人信息（姓名、手机号、身份证号、住址）、客户数据（合同金额、联系人、交易记录）、密钥凭证（访问密钥、数据库口令、证书私钥）、未公开代码与设计文档、财务与经营数据。每个类别要写清典型字段、示例格式和允许使用场景，例如“客户手机号属于敏感级，禁止直接输入外部AI工具，脱敏后可输入”。
在此基础上编制关键词与匹配表，供自检和工具辅助识别使用。关键词覆盖字段名和常见值格式，正则用于手机号、身份证号、密钥串等结构化特征。匹配表不必追求一次穷尽，应保留版本号和更新记录，按季度或按事件触发修订。
输出与完成标志
输出物是《敏感信息分类分级清单》和《关键词与匹配表》。完成标志有两条：清单经数据安全或合规负责人书面确认；每一类数据都标注了允许使用场景，使用者能据此判断某段内容能否提交。负责人由数据安全负责人牵头，业务负责人确认客户与财务字段范围，研发负责人确认代码与项目数据范围。
第二步：把检查动作嵌入AI使用流程
清单只有嵌入流程才会被使用。检查应放在三个节点，每个节点设定检查项、责任人、通过标准和不通过时的处置方式。下表可作为节点检查表的初稿，团队按自身工具情况增删。
| 节点 | 检查项 | 责任人 | 通过标准 | 不通过处置 |
|---|---|---|---|---|
| AI工具与账号申请 | 用途说明、拟处理的数据范围、工具是否在获批清单内 | 申请人提交，研发负责人或数据安全负责人审批 | 用途与数据范围匹配，工具已通过评估 | 退回补充说明或改用获批工具 |
| 提示词与附件提交前 | 是否命中敏感类别、是否已完成脱敏、是否属于禁止输入范围 | 使用者自检，高风险场景由同伴或评审人复核 | 无敏感信息，或脱敏后不构成可识别信息 | 脱敏后重新提交；无法脱敏则走例外审批 |
| AI输出外发或入库前 | 输出是否包含内部信息、是否被直接引用到对外文档或代码库 | 使用者复核，对外材料由评审人确认 | 输出内容符合外发范围要求 | 修改、删减或改为内部留存 |
例外审批是流程层的必要组成。确需输入敏感信息时，申请人应说明用途、数据范围、使用时长和留存期限，由数据安全负责人或指定审批人批准，并设定到期复核时间。例外审批的价值在于把不可避免的例外纳入记录，避免它变成绕过检查的通道。
流程落地时，检查项、审批单和记录需要有承载位置。ONES 的文档与工作项管理可以把检查项做成工作项模板，把例外审批单和自检记录作为附件或页面留存在对应项目中，使检查动作与项目数据在同一处流转；ONES 的 AI 能力基于其权限体系运行，输出过程可追踪、结果可审计，便于把AI使用记录纳入同一套追溯范围。具体配置方式以实际产品和合同为准。
角色分工与各角色交付物
依据能否执行，取决于每个角色是否清楚自己交付什么、在什么时点交接。下表按角色列出职责与交付物，团队可据此写入制度附件。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 数据安全或合规负责人 | 制定分级规则与敏感信息清单，审定例外申请 | 分级规则、清单、例外审批意见 | 清单每季度修订；例外随申请处理 |
| 研发负责人 | 确认代码、设计文档与项目数据的可输入范围 | 研发数据输入范围说明 | 新项目启动或工具变更时更新 |
| 使用者 | 提交前自检，如实申报数据范围 | 自检记录、脱敏后文本 | 每次提交AI工具前 |
| 评审或审批人 | 处理例外申请，判断风险并留痕 | 例外审批单 | 收到申请后按约定时限处理 |
| 审计或质量角色 | 抽样复核检查记录，跟踪整改 | 复核报告、整改跟踪记录 | 每月或每季度抽样一次 |
分工中容易出现两个空档：一是使用者自检缺少复核，高风险场景无人把关；二是例外审批后无人跟踪到期复核。前者可以通过对涉及客户数据和密钥凭证的场景增加同伴复核来补足，后者需要在审批单上写明复核日期，并纳入审计角色的抽样范围。
示例：一次代码辅助场景的检查过程
以下为演示情景，用于说明依据如何被引用和执行，不代表真实项目记录。
场景。研发人员使用AI助手分析一段生产日志，日志中包含客户标识、请求时间和错误堆栈，目的是定位一个接口超时问题。
引用依据。使用者查阅敏感信息分类分级清单，客户标识属于客户数据中的敏感级；AI使用管理办法规定客户标识禁止直接输入外部AI工具。日志中的错误堆栈和请求时间属于内部级，允许输入。
动作。使用者将客户标识替换为统一占位符，保留请求时间与错误堆栈，在自检记录中勾选“客户数据—已脱敏”检查项，然后提交AI助手分析。若问题必须依赖原始标识才能复现，使用者提交例外审批，说明用途为故障定位、数据范围为单条日志、留存期限为七天，由数据安全负责人审批。
输出与归档。归档材料包括自检记录、脱敏后文本，以及例外情形下的审批单。审计角色在抽样复核时，可对照清单确认脱敏是否覆盖全部敏感字段，对照审批单确认例外是否在期限内关闭。
这个示例体现的检查逻辑可以迁移到其他场景：先查清单定性，再查制度确认允许范围，然后执行脱敏或审批，最后留下可核对的记录。三个动作对应三类证据，缺一项都会让检查难以追溯。
完成检查：依据是否可执行、可追溯
依据是否完备，可以用一份验收清单逐项核对。清单中的前五项是完备性要求，最后一项是阻断项，用于快速判断整体状态。
- 每条禁止性规则都能对应到具体检查项和责任人，随机抽取三条制度条款可以完成对应；
- 敏感信息清单有版本号、修订记录和更新触发条件，最近一次修订有确认人；
- 检查记录可追溯到人、时间、检查对象和结论，抽样十份记录能还原当时判断；
- 例外审批形成闭环，审批单包含用途、范围、期限和到期复核结果；
- 抽样复核发现问题时，有整改责任人和复盘结论，整改项已关闭；
- 阻断项：无分级清单、无检查记录、例外无审批，任一存在即视为检查依据未完成，应先补齐再扩大AI工具使用范围。
验收通过后，依据仍需维护。建议把清单修订、例外到期复核和抽样复核结果纳入固定的季度回顾，发现新的敏感类别或新的AI使用场景时同步更新清单与节点检查表。这样，检查依据才能随AI工具的使用范围变化保持可执行。
常见问题
团队规模较小，是否也需要完整的四层依据？
四层依据的核心是让规则可判断、可执行、可追溯，规模小的团队可以压缩文件数量，但不宜省略层级。常见做法是把制度层与清单层合并为一份《AI使用与数据分级说明》，流程层用一页节点检查表代替，证据层直接复用现有的审批单和项目记录。判断标准仍然成立：随机抽一条规则，能说出由谁在什么节点检查、留下什么记录。若团队尚未建立数据分级，可先按公开、内部、敏感、严格受限四级做一版简表，再逐步细化字段。
敏感信息清单多久更新一次，什么情况需要临时修订？
建议设定固定周期与事件触发两种更新机制。固定周期可按季度回顾，核对业务系统字段变化和新增的AI使用场景。事件触发包括：发生违规外发或安全告警、上线新的业务系统或数据源、引入新的AI工具、客户合同中的数据使用条款发生变化。每次修订保留版本号、修订内容和确认人，便于审计时还原当时的判断口径。清单更新后，节点检查表中的检查项和关键词匹配表应同步调整，避免清单与执行脱节。
使用者自检容易流于形式，怎么提高执行质量？
自检流于形式通常有两个原因：检查项太笼统，使用者不知道具体看什么；自检没有复核，填了也无人核对。可以把检查项写成可判断的问题，例如“附件中是否包含客户手机号、身份证号或合同金额”，而不是“是否包含敏感信息”。对涉及客户数据、密钥凭证和未公开代码的场景，增加同伴复核或评审人确认。审计角色按月或按季度抽样，对照清单核对脱敏是否覆盖全部敏感字段，发现问题时记录整改责任人和关闭时间，抽样结果反馈到下一次清单修订。
例外审批通过后，如何保证到期复核真正执行？
例外审批单上应写明用途、数据范围、使用时长、留存期限和复核日期，并把复核日期作为审批单的必填项。到期前由审批人或其指定人员核对：例外是否仍在必要范围内、数据是否已按期限删除或归档、是否需要续期。复核结论记录在同一张审批单上，形成闭环。审计角色的抽样范围应覆盖例外审批单，检查是否存在到期未复核或超期使用的情况。若例外频繁出现，说明清单中的允许使用场景可能需要调整，应回到清单层评估，而不是持续依赖例外通道。
检查记录需要保存哪些内容，保存多久？
检查记录至少包含四项：检查人、检查时间、检查对象（提示词、附件或输出结果）和检查结论。涉及脱敏的，保留脱敏后文本或脱敏说明；涉及例外的，附上审批单。保存期限可与团队现有的数据安全与审计要求对齐，客户合同或行业规范有明确期限的从其约定。记录不必包含完整的原始敏感内容，保留足以还原判断过程的信息即可，这样既能支撑抽样复核，也避免记录本身成为新的敏感信息聚集点。
