1. 数据分级
知识点讲解区分公开、内部、敏感、受监管数据。
老师板书
数据分级
治理
数据分级先决定哪些资料能被 AI 看见。
先用人话讲明白
数据分级是按敏感程度和影响范围给数据分类，决定 AI 能否使用、如何脱敏、谁能访问。它是 AI 安全治理的起点。
类比可以把它理解成给 AI 上岗前办权限、签责任书、留操作记录。
为什么要学先判断数据敏感度，再决定 AI 能不能看。
把关键词拆开看
- 公开数据：可对外或低风险资料。
- 内部数据：团队内部使用，禁止外泄。
- 敏感数据：个人信息、账号、日志标识、商业机密等。
入门版理解：区分公开、内部、敏感、受监管数据。
适用范围和边界
1. 优先原则：先满足前提，再谈使用
在实际工程里，任何概念都不能脱离场景硬套。学习「数据分级」时，第一步不是问“它高级不高级”，而是问它是否真的能帮助你完成一个更清晰、更可验证的业务判断。
- 先看它服务的专业判断是不是「治理」：先判断数据敏感度，再决定 AI 能不能看。
- 数据、工具、输出、人群和使用场景都已分级。
- 知道哪些信息能给模型看，哪些只能脱敏，哪些禁止进入模型。
2. 引入边界：同时满足这些条件，才值得推进
只有当它能把问题从“凭感觉讨论”推进到“可设计、可评测、可复盘”时，才说明这个知识点真正进入了业务方案。
- 当「数据分级」能改变用户日志、设备标识、账号权益、内部故障资料、外部用户问答里的设计、评测或风险控制动作时，才值得进入方案。
- 适合任何接触用户数据、内部资料、工具调用、用户可见回答的 AI 项目。
- 适合在设计阶段就确定权限、脱敏、拒答、审计和责任边界。
3. 反向边界：这些情况先停下来
专业判断的价值，不只是知道什么时候用，更是知道什么时候不用。下面这些情况出现时，要先补数据、补流程、补权限或补评测，而不是继续堆 AI 能力。
- 不分级就无法制定权限和脱敏规则。
- 日志中常混有敏感字段，不要因为它是技术数据就忽视。
- 不要把安全治理放到上线前最后补，它会反过来影响架构和流程。
- 不要只靠 Prompt 防注入、越权和泄露，必须有系统级权限和校验。
- 日志、诊断包、截图 OCR 里常混有敏感信息，技术数据也可能是隐私数据。
4. 上线前判断：能回答这些问题再落地
- 能给数据、工具、输出分别做公开/内部/敏感/禁止分级。
- 能说明每个高风险动作的审批人、审计字段、回滚方式和责任人。
- 现场追问：如果这条 AI 输出被用户截图、被审计、被事故复盘，你能不能解释它为什么被允许？
架构师总结：数据分级先决定哪些资料能被 AI 看见。 对架构师来说，数据分级 不是一个要背的名词，而是一把判断尺：先看前提是否成立，再看收益是否大于复杂度，最后看失败时有没有证据、兜底和责任人。
通用例子：先脱离技术看懂它
公开 FAQ 和用户手机号显然不能用同一套访问规则。
这个例子要看见的重点：先判断数据敏感度，再决定 AI 能不能看。 所以例子不是为了记故事，而是为了训练你在新场景里做同类判断。
投影 / Android 实战推演
- 业务推演：投影 Android 业务里，产品手册可公开，内部故障复盘是内部数据，设备唯一标识、账号信息、用户日志原文可能是敏感数据，进入 AI 前要脱敏和授权。
- 你要补的证据：围绕「治理」列出数据、文档、日志、用户反馈或人工标注，避免只凭感觉判断。
- 可交付物：沉淀 数据分级、脱敏规则、权限控制、审计记录和责任边界。，让同事能照着复用，而不是只听你口头解释。
- 验收指标：至少选一个质量指标、一个效率指标、一个风险指标；比如正确率/一次解决率、定位耗时/追问轮次、误导用户率/转人工率。
- 迁移能力：同一套思路也能迁移到客服、测试、研发效率、运营分析和产品决策，不局限于投影业务。
老师会这样检查你是否真会了
- 你能不能用一句人话解释「数据分级」，并说出它解决的是「治理」里的什么问题？
- 你能不能举一个适用场景和一个不适用场景，并说明边界来自数据、流程、风险还是权限？
- 你能不能把它落到一个真实小任务：输入是什么、输出是什么、验收指标是什么、失败时谁兜底？
- 老师追问：如果这条 AI 输出被用户截图、被审计、被事故复盘，你能不能解释它为什么被允许？
- 练习产物：给你们常见数据列一张分级表：公开、内部、敏感、禁止进入模型。
精通标准：数据分级先决定哪些资料能被 AI 看见。 能精通的人，不是能背定义，而是能把它迁移到一个新业务里，写出判断表、数据要求、风险边界和落地动作。
业务判断方法
不同级别对应不同使用规则。