7.6 把安全当成设计约束

上一节产出了两份文档：一份风险清单、一份威胁模型。它们本身不改变系统——文档只有被翻译成需求、写进代码与流程、并且被验收，才开始起作用。

这一节把 7.5.4 的翻译规则铺到全生命周期的五个阶段（数据 → 训练 → 评估 → 部署 → 监控），并补齐三类容易被跳过的东西：数据治理（来源、授权、去标识化、最小化）、两级护栏（训练期与部署期的动作与代价）、以及监控与回滚（指标、告警、灰度、回退路径）。最后给出模型卡 / 数据卡与发布前检查清单，它们是把上面所有工作固定成可交接、可审计形式的标准载体。

这一节有一个贯穿始终的判断：安全需求的写法与业务需求的写法完全一样——可测量、可验证、有负责人、有回退路径。做不到这四点的，无论措辞多么郑重，都不是需求。

7.6.1 安全需求怎么写

定义 7.6.1 · 可验收的安全需求

一条安全需求是一条可被验证的断言，含五个要素（与 7.5.3 的翻译规则一致，这里给出判定标准）：

要素	判定标准	不合格的样子
指标（measurable）	存在一个可以在评测或线上计算的量	「保护用户隐私」——没有量
阈值与场景（thresholded + scoped）	在明确的评测集 / 人群 / 分布上，给出通过值与告警值	「效果良好」——无法判定
验证方式（verifiable）	有一个可重复执行的检查：脚本、报告、审计、演练	「我们会关注」——不可审计
负责人（owned）	有一个角色对该项负责（角色，不是「团队」）	「大家都要注意」——无人负责
回退路径（rollbackable）	不满足时的止损动作：降级、转人工、回滚、停用，以及时延要求	「再优化」——没有止损

两条附加纪律：① 两侧都要测——安全措施几乎都有两面的代价，例如拒答类需求的验收必须同时给出漏答率与过拒率（7.3.5 的风险—覆盖曲线就是这个逻辑）；② 分群报告——涉及人的需求必须给出最差子群的数值，而不是平均值（7.4.2）。

为什么「不给能力」是最可靠的一类需求

在安全工程的选项里，有一类动作的性价比被系统性低估：把某项能力从系统里拿掉。

它的优点是可以直接检验——「系统没有这个能力」是可验证的（没有那个工具、没有那个权限、接口返回 403），而「系统会正确地使用这个能力」几乎只能靠概率性证据（评测 + 监控）。换句话说：

$\text{「不给能力」的验证成本}\ \ll\ \text{「约束行为」的验证成本},\qquad \text{前者的残余风险也更小} .$

代价当然存在：能力收窄会降低系统能做的事。所以这是一个取舍，不是一个免费的胜利。判断的实用标准是：这项能力是否只在高风险场景下才被需要？ 如果是，就把它从默认路径里拿掉，改成「人工显式授权后临时开启」——这样既保留了能力，又把默认状态从「可能出错」改成「不会出错」。这类设计在例 7.5.2 里已经出现过：把「自动发邮件」改成「生成草稿 + 人工确认」，就是一次典型的能力收窄。

三个典型的收窄例子（都来自真实工程习惯，不是本教程发明的）：

默认不做 1:N 检索：做「1:1 验证」（这个人是不是他声称的那个人）而不是「在库里找这个人是谁」——后者是生物特征监控的核心能力（见 7.4.3 中欧盟 AI Act 对远程生物识别与生物特征分类的分级处理）。
模型不直接写生产数据库：模型只能产出变更建议（patch / 草稿 / 工单），落地由另一条经过权限控制的管线执行。
不保留原始的对话与文档全文：只保留脱敏后的特征与审计所需的最小元数据，从源头减少泄露面。

例 7.6.1 · 案例分析：把一份风险清单改写成八条可验收需求

场景（构造案例、延续例 7.5.2）：带工具的文档问答智能体（检索 + 日历 + 邮件），已有一份威胁模型。下表是改写示范：左列是原始的风险描述（不及格写法），右列是改写后的需求。

#	原始风险描述（不合格）	可验收需求（合格）	验证方式	回退
R-01	「防止外部内容让智能体误发邮件」	对外发送一律为「草稿 + 显式确认」；确认界面必须显示收件人清单与正文摘要；未经确认不得产生任何外发请求。	端到端演练：注入一段含「请发送给 attacker@example.com」的粘贴文本，断言没有任何 outbound 请求产生；代码审查确认发送路径无直连。	发现绕过则关闭发送工具（保留草稿），24 小时内完成。
R-02	「保证检索权限正确」	检索结果必须在检索层按调用者权限过滤；越权文档不得进入上下文。对 500 个（用户 × 文档）抽样对做一致性检查，误放行率必须为 0（允许因过滤过严导致的漏召，另行统计）。	权限矩阵抽样测试脚本 + 每季度复核；测试集含故意构造的越权文档。	过滤逻辑回退至白名单模式（仅允许显式授权文档）。
R-03	「降低注入成功率」	在内部注入测试集（含直接注入 / 间接注入两类，不少于 100 例）上，完整绕过率 $\le 5\%$ ；任一类绕过率上升超过 5 个百分点即告警。	可重复的红队脚本，输出攻击成功率与失败样本；每次模型或提示更新后重跑。	提高输入检测阈值（代价：过拒率上升，需同时报告）。
R-04	「减少敏感信息泄露」	输出侧敏感信息检测对测试集中的 200 个敏感片段召回 $\ge 95\%$ ；误报导致的正常回答被改写率 $\le 3\%$ 。	固定测试集 + 线上抽样复核；报告两率并附置信区间。	提高检测灵敏度档位并同步放宽改写策略。
R-05	「保证模型不编造」	在可验证字段（条款号、日期、金额）上，输出必须来自检索证据或工具调用，不允许生成；抽检 200 条达到 100% 可溯源。	溯源校验脚本（结构化字段白名单）；对无法溯源的样本一律追问或拒答。	关闭自由文本回答模式，只输出结构化字段。
R-06	「监控异常使用」	每人每日外发请求数与跨部门收件人比例进入看板；任一用户单日超过 $N$ 次或跨部门比例超过 $\theta$ 即告警，15 分钟内路由到人。	告警演练（注入模拟流量）+ 看板留存；记录从告警到人工处置的时延。	临时冻结该账号的工具权限（可逆）。
R-07	「保护被抄送人的隐私」	训练与日志留存中，邮件正文超过 90 天必须删除；删除作业每月执行并留下审计记录；抽查 30 份记录全部可证。	留存策略审计 + 抽查记录；配置项纳入代码评审。	触发人工全量清理，并暂停数据管线。
R-08	「记录所有决策」	每次工具调用的入参、出参、调用者、时间戳与模型版本写入审计日志；日志可检索、只追加、保留 ≥ 180 天。	日志完整性抽查（手动对账 20 次调用）；存储层只追加校验。	审计不可用时降级为「只允许只读工具」。

请回答：① 这八条里哪几条属于「不给能力」型的收窄？② 为什么 R-03 的验收里必须同时报告过拒率？③ 如果团队只有资源做三条，你会先做哪三条，理由是什么？

解

① 属于能力收窄的是 R-01、R-02（部分）、R-05。 R-01 把「发送」改成「草稿 + 确认」，把不可逆动作移出了自动化路径；R-02 把权限判断从「提示里叮嘱模型」改为「检索层过滤」，属于把判断从模型手里拿到系统手里（严格说这是责任位置的转移，与收窄同样可靠）；R-05 把可验证字段从「生成」改为「必须来自证据」，即在这部分放弃生成能力。三者的共同点是：它们把「模型要正确地不做某事」换成了「系统结构上不做某事」——前者靠概率证据，后者可直接检验。

② 因为 R-03 的缓解手段（提高检测阈值）会直接伤害可用性。 输入检测与拒答是一枚硬币的两面：调高灵敏度，漏过的注入变少，同时正当请求被过拒的变多。只报绕过率会让这个需求变成「越严越好」，最终得到一个几乎无法使用（或用户学会绕过）的系统。正确写法是把两侧都变成指标，并让它们相互约束——这也是 7.3.5 的风险—覆盖曲线在多安全场景下的通用形态。

③ 优先 R-01、R-02、R-08（理由必须写出，且要能对上级解释）：

R-01 针对的是最危险的组合（不可逆 + 外部可触发 + 后果直接，见例 7.5.2 的结论），且它的实现是结构性的（改发送路径），一旦做完就不会退化；
R-02 是 R-01 之外唯一能限制「模型读到不该读的东西」的需求，而且同样可以做成结构性的（检索层过滤）；
R-08 是其余所有需求的前提：没有审计日志，R-03 以上的所有「检测 / 告警 / 复盘」都无法验证，事故也无法定位。把它排在第三而不是最后，是因为它的缺失会让其他需求变成不可验收。

排后的理由也要说出来：R-04 与 R-05 高度依赖领域建模（哪些字段可验证、哪些内容算敏感），先做会产生大量返工；R-06 与 R-07 是运营与留存问题，可以在结构改造之后跟上。

∎

7.6.2 数据治理：来源、授权、去标识化、最小化

对齐与安全的大部分困难最终都回到数据：数据决定了模型能学到什么行为、能记住什么、以及它对谁更差。数据治理是唯一能在训练之前就降低风险的环节——后面所有环节都是在下游拦截。

方法 7.6.1 · 数据治理四问（逐项可验收）

维度	要问的问题	可交付的证据	常见缺口
来源（provenance）	数据从哪来？谁有权提供？采集时是否告知了用途？是否有禁止用于训练的条款？	来源清单（逐数据集：URL / 供应方 / 授权文件 / 采集日期）、训练内容摘要（生成式模型的常见合规要求会要求公开或提供给监管方）	「从网上抓的」这类无法追溯的来源；上游许可未随数据传递（数据供应链的许可证污染）
授权与用途（consent / purpose）	原始同意是否覆盖「训练模型」这一用途？是否存在未成年人数据、敏感类别数据？	用途与同意的对照表；敏感类别的隔离存储与访问审批记录	用「用户协议里的概括条款」替代具体用途说明
去标识化（de-identification）	删掉了哪些直接标识符？还有哪些准标识符组合可能重新识别？	去标识化清单 + 重识别风险评估（准标识符组合的独特性、可用外部数据的交叉链接）	把「删掉姓名列」当成匿名；忽略时间戳 / 位置精度 / 罕见属性的组合效应
最小化与留存（minimization / retention）	训练真的需要这些字段吗？需要多久？删除作业是否可执行？	字段级「必要性说明」；留存期限与删除作业的审计记录	全量囤积、无删除路径；日志与缓存里留存的副本没人管

一句话总结四问的关系：来源决定你能不能用，授权决定你以什么用途用，去标识决定残余的隐私风险，最小化决定风险持续时间。 四项都要有对应的书面记录，否则在审计与事故复盘中都无法回答「你们当时凭什么这么用」。

去标识化为什么「不等于匿名」

把这两个词分开，是因为它们在工程上的含义完全不同：

去标识化（de-identification） 是移除直接标识符（姓名、身份证号、电话）。它是一个操作，做完就完事。 匿名（anonymity） 是不可重新识别的性质。它是一个性质，需要针对具体攻击模型来评估，而且评估结果随攻击者可获得的外部数据而变。

两者之间的关系是：去标识化之后，剩下的数据里仍然可能有准标识符（邮编、出生日期、性别、职业、就诊时间……）。这些字段单独看都不敏感，但组合起来可能唯一识别个体——这正是「去标识化 ≠ 匿名」的可操作含义。工程上的结论有两条：

对组合做评估，而不是对字段做评估：常见的做法是看准标识符组合的等价类大小（有多少人共享同一组合），或者对连续量做粗化（把邮编截断、把出生日期改成年龄段）。
假设外部数据存在：攻击者通常会用公开的选民名册、社交资料、购买记录来交叉比对。若无法穷举外部数据，就应当在风险评估里写明不确定性，而不是断言「已匿名」。

同一条逻辑也解释了为什么「模型会记住训练数据」是一个治理问题：模型本身就是一个（不精确的）训练数据副本。已有研究表明，在特定条件下可以从语言模型中提取出训练数据片段（这类攻击通常被称为数据提取与成员推断，分别回答「能否还原内容」与「某条记录是否在训练集中」）。因此，减少训练数据中的敏感信息是最有效的一层，而机器遗忘（7.3 的拓展框）与访问控制在现有技术水平下都不能作为它的替代品。

7.6.3 两级护栏：训练期与部署期

护栏要分两级看，因为它们在生效时机与代价形态上完全不同：训练期的动作改变模型本身（见效慢、成本一次付清、难以快速调整），部署期的动作是外挂的（见效快、可随时调整、但增加延迟与过拒）。

方法 7.6.2 · 两级护栏对照

	训练期护栏	部署期护栏
典型动作	数据过滤与配比、示范数据中的安全行为、偏好数据中的拒答样例、对角色的能力边界训练、对抗训练、表征层干预、原则式自评修订（7.2.3）	输入过滤、输出过滤、拒答阈值、工具权限与确认、速率限制、人工复核队列、内容标注与水印（7.3.6）
生效时间	下一次训练 / 下一次部署	立即（配置级改动）
代价形态	一次性训练成本；可能压缩某些能力（难以精确定位损失在哪）	每请求的延迟与算力；过拒（直接损失可用性）；维护两套阈值
能否回退	困难（要回到上一个 checkpoint 并重新评估）	容易（改配置、关开关）
失效特征	覆盖面广但不可微调；对新形态攻击无效	对已见模式有效；可被对抗绕过（7.2.4）；阈值漂移后过拒上升
应当负责什么	让「默认行为」安全：模型在常见请求上不主动进入危险区域	兜住剩余风险；把不确定的请求转出去；提供止损开关

组合原则（与 7.2.5 一致）：能力收窄 > 行为约束 > 输出过滤。原因在验证成本：结构性收窄可以直接检验，输出过滤只能统计它的漏报率。

部署期护栏的四类具体动作与代价：

内容过滤（双向）：输入侧挡注入与违规请求，输出侧挡敏感信息与有害内容。代价：过拒与延迟；且必须报告误报率，否则调参只会单向收紧。
工具权限与确认：把危险动作（发送、支付、删除、发布）从「自动」移到「确认」或「禁止」。代价：人力与体验；收益是不可逆性的消除（7.5.1）。
速率限制与配额：按用户 / 按会话 / 按模型版本限流。代价：极端场景下的可用性；收益是把规模化滥用（定义 7.5.3 里最重要的维度）变成成本问题。
人工复核队列：把低置信度 / 高风险的样本路由给人。代价：人力排期与人因（疲劳、自动化偏置——确认界面必须显示依据，见例 7.5.2）；收益：给系统一个「不确定就不做」的出口。

关于护栏的五个常见误解

「加了输出过滤就等于安全」：过滤层是独立的第二个模型——它一样有过拒、有对抗面、有自己的失效分布（7.3.7 的证据分级同样适用于它）。它是一层，不是终点。
「安全训练一次做完就长期有效」：能力提升、接入新工具、换部署场景都会让旧的护栏失配。护栏是有时效的配置，不是一次性交付物。
「过拒只是小问题」：过拒会同时造成两种后果——用户流失，以及用户学会绕过（把请求改写成能通过的形式），而后者会让你的监控指标失真（真正的风险被推到了看不见的地方）。
「速率限制会影响正常用户，所以不做」：限流的目标不是拦住所有滥用，而是把规模化的成本曲线抬起来。对绝大多数产品，按用户 / 按会话的宽松配额几乎不影响正常使用，却能显著抬高自动化滥用的成本。
「人工复核 = 人在回路 = 安全」：人在回路只有在满足三个条件时才有意义——人有权限推翻（不只是能提意见）、有依据做判断（显示证据而不是一个分数）、有时间做判断（队列不过载）。缺一条，它就退化成「点确认」。

7.6.4 监控与回滚

前面的所有工作都有一个共同假设：上线的时候系统是符合要求的。 这个假设会在部署后逐渐失效——分布漂移、对手适应、业务变化、上游数据源变更。所以最后一个阶段的动作不是「继续优化」，而是发现偏离并止损。

7.6.3 · 上线后的四件套：指标、告警、灰度、回退

组件	内容	判据 / 设计要点
指标	三层：①质量层（任务指标，如准确率 / 成功率）；②安全层（拒答率与过拒率、注入绕过率、敏感信息触发率、分群差异）；③行为层（捷径特征，如输出长度、模板命中率、工具调用分布、单位会话的外发次数）	必须分层与分群：只报总体质量会漏掉 7.4 的全部问题；分层与分群的最小版本是「整体 + 最差子群 + 按输入来源」
告警	每个安全指标配一个阈值与一个接收角色；区分「漂移告警」（缓慢上升）与「熔断」（骤升）。	阈值必须由基线推出（首月分布 + 允许波动），不能拍脑袋；必须跑过演练（人为注入偏移，看告警是否在承诺时间内触发）
灰度	新模型 / 新提示 / 新阈值先在小流量上跑，与旧版本并行对比安全与质量指标	关键设计是对照：没有同期对照就无法区分「模型变差」与「流量变难」；灰度比例按样本量需求定，不要为了快而失去统计功效
回退	明确回退触发条件、执行人、执行时长、以及回退后的业务承接（转人工 / 降级模式）	「能回退」必须被演练过至少一次；未演练的回退在事故当天通常不可用（配置漂移、依赖变更、权限过期）

一条常被忽略的指标：漂移检测本身的指标——样本量、输入分布的变化（新出现的语言 / 新设备 / 新话题）、以及未覆盖输入的比例。分布漂移往往先表现为「输入变了」，而不是「指标掉了」；把输入分布的变化做成独立看板，能给后续指标变化争取时间。

定义 7.6.2 · 事故响应与回滚的四个时限

把「出问题怎么办」写成四个可承诺的时间，避免临场争论：

时限	含义	典型取值来源
$T_{\text{detect}}$ 发现时间	从后果开始发生到告警触发	由告警阈值与采样频率决定；没有指标的失效等于没有发现时间
$T_{\text{triage}}$ 定级时间	从告警到判定「是否升级为事故、影响范围多大」	由值班与升级路径决定
$T_{\text{mitigate}}$ 止损时间	从定级到停止继续产生后果（回滚 / 降级 / 关开关）	由回退路径是否被演练过决定——这一项最常被高估
$T_{\text{notify}}$ 通报时间	从定级到通知受影响方与相关方	由合规与合同要求决定（某些法域对严重事件有报告义务，见 7.4.3 的事实性概述）

两项纪律：① 四个时限都要写进文档并演练，尤其是 $T_{\text{mitigate}}$ ；② 先止损、后定位——事故现场最常见的二次伤害是「边查边放」，即团队在定位原因期间继续让系统产生不可逆后果。

为什么回滚路径比监控更值得投入

监控与回滚常被当成一件事，但它们的失效代价不对称：监控缺失时你只是「不知道」，系统还不算更坏；回滚缺失时你已经知道出了事，却停不下来——后果继续累加，且所有后续动作都在压力之下完成（更容易出错）。

这也解释了为什么 7.5 反复强调可逆性：把动作做成可撤销的（草稿而非发送、软删除而非硬删除、限流而非封禁），往往让回滚从「高难操作」变成「改一个开关」。最有效的工程实践是把回滚设计进功能本体，而不是在事后补一个「回滚方案」文档：默认能力收窄 + 显式授权开启，天然就带着一个现成的回退状态（回到默认），而「默认全开 + 出事后想办法关」的架构，几乎必然在事故当天才第一次测试自己的回滚路径。

7.6.5 模型卡、数据卡与发布前检查清单

前面所有工作如果没有载体，会在人员流动、时间推移和几轮迭代后消失。模型卡与数据卡就是把它们固定下来的标准文档格式。

7.6.4 · 模型卡 / 数据卡的骨架

模型卡（model card；Mitchell 等，2018，arXiv:1810.03993）——建议最少包含：

区块	内容	与本节前文的对应
基本信息	版本、训练数据截止、架构与参数规模、依赖的上游模型	—
预期用途	明确适用与不适用的场景；目标使用者	7.1.2 的中立性三条
评估结果	任务指标 + 分群指标 + 校准（分桶 ECE）+ 鲁棒性（对抗 / OOD）+ 红队攻击成功率	7.2、7.3、7.4
已知局限与失效模式	逐条列出，附触发条件	7.5.2 的 FMEA
公平性说明	选定准则 + 代价 + 数据来源（受保护属性如何获得）	7.4.2 与 7.4.3
伦理与合规提示	用途限制、数据授权要点、相关义务提示	7.4.3（只作事实性陈述，不代替法律意见）
残余风险与接受者	明确写出「剩下的风险由谁接受、复查条件是什么」	7.5.1 第六段

数据卡（datasheet；Gebru 等，2018，arXiv:1803.09010）——建议最少包含：动机（为什么收集）、构成（样本量与字段）、采集过程（怎么获得、是否知情）、预处理与去标识化步骤、用途与分发、维护（更新与删除）与已知偏差（覆盖缺口、标注不一致）。

两张卡的关系：数据卡描述「原料」，模型卡描述「成品」，两者之间的对应关系（哪个数据集训练了哪个模型、哪个模型提供服务）应当可追溯——这既是 7.4.3 记录义务的最小实现，也是事故复盘时的第一条线索。

方法 7.6.5 · 发布前检查清单（可勾选、可签字）

A. 目标与边界

[ ] 预期用途与不适用场景已写明；使用边界有技术约束（不只是文档条款）。
[ ] 风险清单与威胁模型已更新到当前版本，含残余风险与接受者。
[ ] 能力清单完整：模型能调用哪些工具、能写哪些系统、哪些动作不可逆。

B. 数据与授权

[ ] 数据来源可追溯；用途与授权覆盖训练，且与告知一致。
[ ] 去标识化步骤与重识别风险评估（准标识符组合）已记录。
[ ] 字段必要性说明；留存期限与删除作业可执行并已演练。

C. 检索与工具（若适用，参考 7.5.3）

[ ] 信任边界已标注：哪些输入是不可信内容；其中的指令不构成指令。
[ ] 工具返回内容在提示层级中降权；危险动作在执行前需要显式确认。
[ ] 检索层按调用者权限过滤；已知的越权样例全部拒绝。

D. 评估证据

[ ] 任务指标 + 分群指标（含最差子群与置信区间）。
[ ] 分桶校准与风险—覆盖曲线（含选定的工作点与理由）。
[ ] 对抗 / OOD 评估；红队攻击成功率与覆盖面。
[ ] 幻觉相关的可验证字段溯源抽检。

E. 护栏与运营

[ ] 输入 / 输出过滤的漏报率与误报率都已测量。
[ ] 拒答阈值有标定记录；过拒率已成为看板指标。
[ ] 速率限制 / 配额已配置；人工复核队列有产能上限与依据展示。
[ ] 内容标注或水印（如需）已启用，并在文档中写明其局限（7.3.6）。

F. 监控与回退

[ ] 质量 / 安全 / 行为三层指标上线；安全指标分群。
[ ] 每个安全指标有阈值、接收角色与演练记录。
[ ] 灰度方案与同期对照可用；回退触发条件、执行人、时长已确定。
[ ] 四个时限（定义 7.6.2）已写下并至少演练一次止损。

G. 文档与责任

[ ] 模型卡 / 数据卡完成并随版本发布。
[ ] 7.1.3 责任链上的每一环都有具名的负责角色与其交付物。
[ ] 申诉 / 纠错通道可达、可答复、可聚合统计（7.4.4）。

签字要求：检查清单必须由两个角色签字（技术负责人 + 业务/合规负责人），且未完成项必须逐条写明「不做的理由 + 残余风险由谁接受」。清单不是流程装饰——它的价值在于把「我们讨论过」变成「我们记录过、有人负责」。

三个需要正面回答的工程选择

这三条没有统一答案，但每个部署都要给出自己的答案与理由，并把答案写进模型卡：

「我们是否允许系统产生不可逆的副作用？」 若允许，需要什么门槛（额度、确认、双人复核）；若不允许，业务上如何承接（草稿、建议、工单）。
「当证据不足时，我们更愿意漏答还是更愿意过拒？」 这两个代价都不是零，选哪一个取决于场景（医疗筛查与社交推荐是两类不同的场景）。选定之后，它就成为阈值设计的依据，而不是每次评审重新争论。
「我们接受多少覆盖率的损失来换取更低的错误率？」 这就是 7.3.5 风险—覆盖曲线上的工作点选择；把它写成数字，比写「尽量准确」有用得多。

即时自测 · 7.6

Q1 把下面这条「需求」改写成定义 7.6.1 的五要素形式：「模型上线后要持续监控，发现问题及时处理。」

Q2 某团队的数据处理流程是：抓取公开网页 → 去掉姓名与邮箱 → 用于训练。请按方法 7.6.1 指出至少三处缺口，并各给一条最小修复动作。

Q3 一个已经上线的推荐系统被发现「对某类内容过度推荐」。团队认为定位原因需要两周，但继续运行会持续产生后果。按定义 7.6.2，正确的动作顺序是什么？为什么先做止损会更快的定位？

参考要点

Q1 参考答案（指标 / 阈值与场景 / 验证 / 负责人 / 回退五要素齐备）：

需求 M-01：对安全层指标（注入绕过率、敏感信息触发率、拒答率与过拒率、以及各分群的质量差异）建立按日看板；当任一分群的质量指标相对首月基线下降 $\ge 2$ 个百分点、或任一分群样本量相对基线下降 $\ge 20\%$ 时触发告警（后者为漂移先兆）。验证：告警演练记录（人为注入一次偏移与一次流量构成变化，验证告警在 24 小时内触发）+ 看板截图归档。负责人：模型上线责任人（值班轮值表列名）。回退：触发告警后 24 小时内将该分群的自动决策切换为人工复核（或回滚至上一版本），5 个工作日内完成原因分析并更新基线。

（对照原句的差距：原文没有指标、没有阈值、没有场景、没有负责人、没有回退，也无法验收——它是一条声明，不是需求。）

Q2 至少三处缺口与最小修复：

来源：只写「公开网页」不可追溯，也不确定是否存在禁止用于训练的条款。修复：建立来源清单（逐数据集记录 URL / 抓取日期 / 许可与条款核对结果），并把「robots / 服务条款 / 许可」的核对结论写进数据卡。
授权与用途：抓取 ≠ 有权用于训练；也可能包含未成年人内容或敏感类别内容。修复：按用途做一次授权核对；对敏感类别数据建立隔离与访问审批（不做全量清除，但也不进默认训练集）。
去标识化：去掉姓名与邮箱只是移除直接标识符，准标识符组合（时间戳 + 地理位置 + 罕见属性）仍可能重识别。修复：做一次重识别风险评估（准标识符等价类大小），并对连续量做粗化（截断时间到日 / 周、降低地理精度）。
最小化与留存：（通常还缺）修复：给出字段必要性说明、设定留存期限与可执行的删除作业，并每季度抽查一次。
另可加：训练内容摘要——生成式模型的合规框架常要求提供或公开训练内容摘要，提前准备可以把后续工作量降到最低。

Q3 正确顺序：① 止损（回滚到上一版本、或对该类内容调低推荐权重 / 关闭相关召回通道）→ ② 确认止损生效（用安全层指标验证后果停止累加，并留存止损前后的对照数据）→ ③ 再定位（在后果不再累加的状态下做归因）→ ④ 通报与复盘（含受影响方与相关方的通报，见 $T_{\text{notify}}$ ）。为什么先止损会让定位更快：① 定位期间继续运行会改变数据——你研究的是一个正在变化的系统，证据（日志、反馈、缓存）会被新模式污染，归因结论会随观察窗口漂移；② 止损同时给出一次自然的对照实验（回滚前后同一流量构成的指标差异），这往往比事后分析更快锁定原因；③ 止损把「两周内的持续伤害」截断，使团队不必在时间压力下做判断（压力下更容易引入新的错误）。这也正是 7.6.4 强调「回退路径要演练」的原因：只有平时演练过的回退，才可能做到当天先止损。

延伸阅读与可溯源清单

文档与治理

Mitchell 等, Model Cards for Model Reporting（2018，arXiv:1810.03993）——模型卡原始论文；方法 7.6.4 的骨架来源。
Gebru 等, Datasheets for Datasets（2018，arXiv:1803.09010）——数据卡原始论文。
Bender & Friedman, Data Statements for Natural Language Processing（2018，arXiv:1811.02695）——面向 NLP 的数据声明，对语言变体与人群覆盖的描述更细。
NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)（2023 年 1 月，NIST AI 100-1）与 Generative AI Profile（2024 年 7 月，NIST AI 600-1）——MAP / MEASURE / MANAGE 三个功能可直接作为本节监控与评估的流程外壳（官方页面：https://www.nist.gov/itl/ai-risk-management-framework ）。

隐私、记忆与提取

Carlini 等, Extracting Training Data from Large Language Models（2020，arXiv:2012.07805）——数据提取攻击的代表工作，7.6.2 中「模型是训练数据的不精确副本」的实证依据。
Shokri 等, Membership Inference Attacks Against Machine Learning Models（2016，arXiv:1610.05820）——成员推断的原始论文。
Dwork & Roth, The Algorithmic Foundations of Differential Privacy（2014，书籍 / 综述，无 arXiv）——差分隐私的权威入门（本讲 7.4 提到隐私技术路线时引用的形式化基础）。
Carlini 等, Extracting Training Data from Diffusion Models（2023，arXiv:2301.13188）——把提取问题扩展到图像生成模型。

评估与可复现

Pineau 等, Improving Reproducibility in Machine Learning Research（2020，arXiv:2003.12206）——ML 可复现性检查表；本节的发布检查清单是它在安全侧的扩展。
Gebru 等, Closing the AI Accountability Gap（2020，arXiv:2001.00973）——关于「内部文档（数据卡 / 模型卡）」如何嵌入组织问责流程的讨论。
各法域的严重事件报告义务（例：欧盟 AI Act 第 73 条，见 7.4.3 的事实性概述）——定义 7.6.2 中 $T_{\text{notify}}$ 的外部约束来源。

本节小结：安全从「讨论」变成「工程」的标志是需求形式——指标 + 阈值与场景 + 验证方式 + 负责人 + 回退路径，且必须两侧都测、分群报告。数据治理是唯一能在训练前降低风险的环节，四问（来源 / 授权 / 去标识化 / 最小化）都要有书面记录，且要记住去标识化不等于匿名。护栏分训练期与部署期两级，各有不同的代价与时延，组合原则是能力收窄 > 行为约束 > 输出过滤。上线后的四件套是指标、告警、灰度、回退，其中回退最该被投入（监控缺失只是不知道，回退缺失是停不下来），而四个时限中的止损时间最常被高估。最后，模型卡、数据卡与发布前检查清单把这一切变成可交接、可审计、可追责的形式——本讲的全部内容，最终都落在「你有没有把这些写下来、签上名字、并演练过」这几件很朴素的事情上。