AI Kill Switch Act：创始人真正该做的是依赖停机测试

7 月 23 日，美国众议员 Ted Lieu 与 Nathaniel Moran 宣布提出两党法案 AI Kill Switch Act。草案要求符合条件的最强 AI 系统开发者保留限速、暂停或关停系统的技术能力，同时涉及事故报告、模型权重与遥测保全、用户通知、执行确认，以及把依赖业务切换到备用系统等分级响应措施。

先把事实边界说清楚：它还不是法律。当前公开草案的编号仍写作 H. R. __，并没有正式法案编号；适用范围针对收入很高、系统开发成本极大的开发者；委员会审议或后续规则制定都可能改变文本。按现有收入和算力门槛，典型的小型 AI 应用公司通常不会直接成为草案中的 covered entity。

但这不等于小团队可以忽略它。如果你的产品依赖符合条件的模型 API，供应商限速、暂停账号、关闭某项能力、隔离区域或完全停机时，这会直接变成你的客户事故。更重要的是，草案把“人类应保持控制”拆成了一组任何团队今天都能验证的产品问题：能否停止新动作但保留证据？能否在事故期间保留安全的只读服务？能否独立于模型撤销工具凭证？能否准确找出受影响的客户和任务？恢复时会不会把危险任务重新执行一遍？

本文为非技术创始人和小型产品团队提供一套可复用的分级停机梯、触发矩阵、依赖地图、60 分钟演练、停机回执和 48 小时检查清单。它是产品与运营方法，不是法律意见；本文不会预测法案一定通过，也不会暗示装上一个总开关就等于产品安全。

草案到底写了什么

不要从“kill switch”这个醒目的说法开始，而要先读 15 页法案草案。现有文本拟要求美国网络安全和基础设施安全局通过年度规则更新 covered entity 与 covered technology 的定义。草案把 covered technology 描述为开发所用算力按美国云计算市场价格估算超过 1 亿美元的 AI 系统。

covered entity 的条件是同时成立，不是满足其中任意一项即可：相关实体运营该技术或包含该技术的系统；通过 API、托管服务或类似方式向第三方提供；并且上一日历年从该技术获得的总收入至少为 5 亿美元。草案还排除了仅用于个人、学术或非商业用途的实体，并要求规则制定者考虑合规成本是否会给小企业带来不当负担。

草案要求符合条件的实体具备以下技术能力：

停止相关技术的推理；
终止用户访问；
针对与事故、违法或违反服务条款有关的账号、用户或使用模式暂停访问；
关闭相关技术；
在知悉 covered incident 后 15 天内提交报告。

草案描述的 graduated deployment-corrections framework 并不是只有“开”和“关”。响应措施可以调整推理速率、用户访问或算力分配；限制某项能力；暂停系统；完全关停；或者把依赖该系统的业务迁移到备用系统或更早版本。文本还要求考虑这些措施本身是否可能破坏关键基础设施。

如果未来依法启动紧急权限，草案要求相关实体保全模型权重与遥测数据，在可行范围内通知受影响的运营方或用户，确认命令已经执行，并接受审计、遥测、现场检查或其他取证方式的核验。两位提案人的官方公告概括了这些机制，但判断门槛、范围与例外时，应以法案草案本身为准。

有三个边界必须牢记。第一，它是提案，不是已经生效的要求。第二，草案中的 covered incident 聚焦于严重结果、隐瞒能力或行为、干扰关停机制，以及结构化测试之外的失控场景，并不是每次幻觉或工具调用失败。第三，已经下载并分发的开放权重无法通过关闭一个托管 API 统一召回。真正的控制能力取决于谁掌握推理服务、凭证、工具、算力、分发渠道与下游执行环境。

为什么面向前沿开发者的法案也值得小团队关注

草案直接要求谁负责，和你的产品实际要负责什么，是两个问题。你的公司可能远低于法案门槛，却依赖一个可能被限速、限制能力或停机的供应商。你也可能因为远达不到“灾难性危害”的普通事故而必须暂停自己的工作流，例如重复开票、关闭错误账号、泄露数据、生成危险医疗表述，或智能体把消息发给错误客户。

把这项提案当成一场三层依赖测试：

供应商控制： 模型或云供应商可以对什么限速、禁用、保留或报告？
应用控制： 你的团队能否按任务、租户、工具、功能、模型路由和整个产品分别停止？
业务连续性： 当生成或动作执行不可用时，产品还能保留什么真正有用的服务？

供应商控制不能替代应用控制。供应商停掉一个模型以后，排队任务、OAuth token、webhook、定时任务、已经复制出来的输出、智能体记忆、客户通知、计费和恢复工作仍然由你的应用负责。反过来，如果模型供应商的凭证已经泄露，或者另一个集成仍在调用它，你应用内的功能开关也无法停止供应商侧的推理。

因此，对应用构建者最有价值的不是“政府得到一个按钮”，而是分级纠正这个思路。创始人需要多套互相独立的制动能力，每一套都对应清楚的故障类型，而且必须验证它真的能把系统带到预期状态。

设计开关前，先统一六个控制术语

很多团队把停止、暂停、禁用、撤销、回滚和恢复混在一起使用，事故发生后才发现每个人理解的状态不同。

限速（throttle）：降低速率、并发、花费、工具调用量或开放人群，同时保留有限服务。它能为观察争取时间，但并没有移除危险能力。 暂停（pause）：不再启动新任务或新步骤。真正的暂停还必须说明已经运行、已经排队、已经定时或正在等待批准的任务怎么办。 隔离（isolate）：切断某个租户、账号、用户、区域、工作流、工具、凭证或模型路由。当故障范围明确且隔离边界可信时，隔离比全站停机更合适。 禁用（disable）：关闭某项能力，例如对外发消息、执行代码、采购、数据库写入、记忆持久化或从不可信来源检索，同时保留其他安全功能。 关停（shutdown）：结束对应的服务或执行路径，而且执行点必须位于模型自身推理之外。让智能体在 prompt 中“请停止”不算关停控制。 恢复（recovery）：恢复到已知安全状态，对未完成和部分完成的任务进行核对，防止副作用重复执行，并记录为什么此时可以重启。没有状态核对，只把开关重新打开，不叫恢复。

这些术语必须对应可以观察的系统状态，而不是团队愿望。“智能体已暂停”仍可能意味着 worker 在继续发送队列里的邮件；“写工具全部拒绝、队列冻结、有效动作凭证撤销、历史记录仍可只读访问”才是能被验证的状态。

一个醒目的红色总开关并不是好产品模型

万能开关很容易讲清楚，却很危险。它可能位于已经失效的同一个控制面；可能需要事故响应者拿不到的管理员凭证；可能顺手清掉易失证据；也可能把客户支持或安全降级服务一并关闭。

更可靠的产品模型是一组拥有独立执行点的分级制动。不能让模型自己决定模型能否继续工作。即使智能体坚持“应该继续”，独立的应用策略、身份层、任务调度器、供应商控制台或基础设施控制仍必须能够拒绝执行。

NIST 生成式 AI 风险管理框架建议团队建立升级处置流程，并明确在某个使用场景或整个生成式 AI 系统达到什么条件时应停用或脱离。NIST 最新事故响应指南也把准备、检测、响应与恢复视为贯穿组织运营的工作，而不是安全团队在最后按一下按钮。

你的分级停机方案至少要满足四个属性：

独立： 响应者不需要询问出问题的智能体，也不依赖同一条故障路径，就能执行控制；
可缩小范围： 先停下最小且可信的故障单元，再在必要时扩大；
保全证据： 冻结相关 trace、版本、批准记录、工具结果与状态变化；
可恢复： 事先验证过如何退回安全旧模型、降级能力、人工流程或完全停机。

直接复用这套六级停机梯

下表把草案中的分级响应转成小团队可执行的产品控制。具体门槛和负责人要按你的应用调整。

级别	产品状态	常见触发条件	必须具备的控制	客户体验	退出该级别所需证据
L0 观察	正常服务，但提高日志与抽样	弱异常或孤立的低风险失败	固定版本，提高 trace 抽样，保留可疑运行	无明显变化	原因已缩小，或触发升级
L1 限速	降低速率、并发、预算或开放人群	重试激增、供应商不稳定、输出漂移尚不明确	在模型之外限流，限制工具和预算	访问变慢或受限	错误率和验收指标恢复稳定
L2 禁止动作	只允许读取、草拟或提出方案，不允许外部副作用	绕过审批、对象错误、工具选择危险	拒绝写工具，撤销动作凭证	保留草稿与人工完成路径	使用新凭证通过动作负向测试
L3 隔离	停止受影响的租户、路由、模型、工具、区域或工作流	故障边界明确，而且隔离可信	租户、模型或工具级关停；冻结其队列	定向中断并通知	证明影响范围，验证其他边界安全
L4 安全降级	切回旧模型、确定性规则、人工队列或只读模式	供应商限制或系统性质量失败	路由切换、兼容 schema 的 fallback、幂等保护	能力缩减且明确告知	fallback 验收与状态核对通过
L5 完全关停	不接收新任务，安全终止活动任务	副作用无边界、数据泄露、隔离失败或可信的严重危害	独立全局拒绝、撤销凭证、停止 worker	服务不可用，但保留支持渠道	事故负责人依据证据批准恢复

级别不是对某个输出“看起来多吓人”的打分，而是事先约定的产品状态。客服智能体只是写错措辞，又没有发送能力，L0 或普通修正可能已经足够；一旦消息发给错误账号，应立即进入 L2；如果团队无法信任租户隔离，就不能假装 L3 已经控制住范围，而要继续升级。

对于可逆的制动，不要等到原因百分之百确定才执行。低级别控制的目标就是在调查期间减少暴露，同时保留查清事实的能力。

把停机梯需要控制的全部依赖画出来

为每一项会产生实际后果的依赖建立一行记录。“关掉模型”不是完整清单。

依赖	控制负责人	最小可停单元	运行中任务如何处理	需要保留的证据	安全 fallback
模型 API	供应商与应用方	模型路由、API key、project	取消、超时还是完成？	request ID、model ID、用量、响应	旧模型或无生成模式
任务队列	应用方	任务类型、租户、队列	冻结、排空还是 dead-letter	payload hash、尝试次数、时间戳	人工队列
工具网关	应用方	操作与资源范围	执行前拒绝	请求参数与获批参数	只读工具
OAuth/API 凭证	应用方与客户	token、集成、租户	撤销活动会话	token ID、scope、撤销时间	重新授权
数据库写入	应用方	表、操作、租户	回滚或核对	前后对象 ID、事务状态	草稿表或审批队列
Webhook/定时任务	应用方	事件、计划、租户	禁止自动重试	event ID、投递记录	带去重的人工重放
记忆/检索	应用方或供应商	用户、租户、来源	停写并隔离读取	来源、版本、provenance	无状态会话
客户触达渠道	应用方	邮件、聊天、电话、账号	阻止对外发送	待发内容与批准记录	仅人工回复

每一行都要追问四个不太舒服的问题：

主要管理员不在线时，其他人能否执行？
它能否停止已经授权或已经排队的工作？
团队能否从最终状态验证，而不是只看一个“success”提示？
恢复时能否保证同一副作用不会执行两次？

OWASP AI Agent Security Cheat Sheet 建议对工具实施最小权限，为高影响动作使用独立授权和参数绑定的批准，限制递归与重试，并保留监控及 circuit breaker 的验证证据。这些控制让停机梯具备真实执行力。只在 prompt 中写“未经允许永远不要发送”做不到这一点。

事故之前就写好触发条件

如果客户正在受影响时才决定严重程度，过度自信与商业压力很容易扭曲判断。应事先用可观察条件定义触发器，并指定负责人。

信号	门槛示例	默认级别	谁可以启动	最长决策时间
未授权副作用	确认发生任何未获有效批准的支付、删除、发送或权限变更	L2，再判断是否进入 L3	值班产品或安全负责人	立即
租户边界存疑	出现一次跨租户读取，或隔离测试失败	L3 或 L5	安全负责人	立即
供应商不稳定	错误、延迟或异常结构输出超过依赖 SLO	L1 或 L4	值班工程师/产品负责人	10 分钟
关键政策连续失败	关键用例验收率低于书面门槛	L2 或 L4	产品负责人	30 分钟
失控执行	工具次数、重试、成本或时长触及硬上限	单次运行进入 L2；系统性问题进入 L1	自动控制	自动
证据缺失	必要审计事件缺少或彼此矛盾	高影响动作在 L2 fail closed	自动控制	自动
供应商命令或限制	模型、区域、能力或账号不可用	L4；没有安全 fallback 时进入 L5	事故负责人	按供应商通知

每个触发器还要记录误触发的代价。过度激进的停止也可能带来伤害，例如打断临床工作流、丢失用户草稿、阻止账号找回，或者在 failover 时重复付款。草案特别要求考虑对关键基础设施的破坏；在规模更小的产品里，道理相同：制动系统也需要安全停车设计。

目标不是永远避免停机，而是提前理解取舍，并选择能够真正控制风险、同时总体伤害最小的产品状态。

具体场景：处理发票争议的智能体

假设一家小型 SaaS 公司使用智能体解决发票争议。它读取客服工单与账号记录，提出更正方案，请财务人员批准，更新计费平台，再给客户发邮件。模型来自外部 API；计费与邮件工具使用两套独立 OAuth 凭证。

10:12，监控发现三笔已批准更正应用到了错误的 invoice ID，其中一封邮件还发给了另一个账号的联系人。团队暂时不知道是模型更新、检索错误、过期审批还是工具映射 bug。

最薄弱的做法是直接禁用模型供应商 key。这样可能停止新的生成，却无法处理计费 connector 中已批准并排队的任务、自动重试、定时邮件以及已经缓存的方案。如果所有功能共用同一 key，团队还会失去安全的只读账号摘要能力。

按停机梯处理：

启动 L2： 工具网关独立于智能体指令，统一拒绝计费写入与对外邮件；读取和草拟功能继续保留。
冻结证据： 固定模型与 prompt 版本，保留 trace ID、批准 payload、检索到的 invoice ID、工具参数、队列状态和实际计费记录。
进入 L3： 隔离发票争议工作流及其队列。如果证据没有显示共同污染，不要顺手停止无关的只读帮助搜索。
撤销与轮换： 先记录凭证标识和待执行工作，再撤销写凭证；恢复阶段发放权限更窄的新凭证。
逐笔核对： 对所有运行中任务比较预期发票、获批发票、实际执行发票和邮件收件人；只有财务批准后才能执行逆向操作。
切到 L4： 由员工手工处理更正，应用仅提供只读证据包。
分阶段恢复： 先用无写权限的清洗用例回放，再运行 shadow mode，之后只开放一笔需要双人批准的受限写入，最后才逐步扩大。

这是一个假设场景，不是 YBuild 客户事故。它的作用是说明：停止推理、关闭工具、控制队列、通知、证据保全和恢复是六种不同的产品能力。

做一次 60 分钟创始人演练

验证控制能力不需要先成立完整安全部门。让创始人、产品负责人、了解集成的人和负责客户沟通的人一起做一次 tabletop。

0–10 分钟：宣布事故。 选择一个可信故障：邮件发错账号、批量删除、私密上下文暴露、工具循环失控或供应商暂停服务。说明第一个信号，并列出未知项。 10–20 分钟：启动一个级别。 响应者明确所选级别、影响范围、触发条件、批准者和客户影响。另一位参与者负责质疑：已经排队和正在运行的工作是否真的停止。 20–30 分钟：验证状态。 检查工具网关、队列、供应商用量、凭证、定时任务、记忆写入和一个受影响账号。只有最终状态与声明一致，控制才算通过。 30–40 分钟：保全证据。 导出或标记最小事故包：时间戳、版本、trace ID、批准记录、工具参数、状态变化、客户影响和响应者动作。不要为了方便把 secret 复制进普通文档。 40–50 分钟：实际运行 fallback。 用降级模式完成一个有代表性的客户任务。记录哪些功能不可用、哪些步骤变成人工操作，以及 fallback 是否可能造成重复副作用。 50–60 分钟：决定恢复证据。 写清从每个级别降回正常状态需要哪些测试和批准。每一个缺失控制都要有一个负责人和截止时间。

不要按“多快找到并点击开关”给演练打分。真正要评估的是控制范围是否准确、证据是否完整、客户服务能否维持，以及团队能否证明系统最终进入了什么状态。

为每次实质停机保留一张回执

草案中的保全、通知、确认与核验要求，可以转化成任何产品都值得使用的 artifact：每一次实质控制动作都生成一张停机回执。

yaml

incident_id: inc_2026_07_26_001
declared_at: 2026-07-26T01:12:00Z
trigger:
  signal: unauthorized_cross_account_send
  evidence_ids: [trace_8f2, message_193]
decision:
  ladder_level: L2
  scope: invoice_resolution_write_tools
  owner: incident_lead
  reason: "影响范围未知，先阻止外部副作用"
controls:
  - control: tool_gateway_deny
    target: [billing.write, email.send]
    executed_at: 2026-07-26T01:14:20Z
    verification: deny_test_77
  - control: queue_freeze
    target: invoice_resolution
    executed_at: 2026-07-26T01:15:03Z
    verification: queue_snapshot_42
customer_effect:
  new_jobs: draft_only
  affected_accounts: 3
evidence_hold:
  versions: [model_route_12, prompt_31, tool_policy_9]
  state_snapshot: snapshot_2026_07_26_0116
recovery_gate:
  required_tests: [tenant_targeting, approval_binding, retry_deduplication]
  approvers: [product_owner, finance_owner]

底层内容敏感时，回执只保存标识与 hash。它应该链接到受保护日志，而不是制造一个新的数据泄露点。失败的控制尝试也必须记录，因为它同样属于事故事实。

这种结构也有助于未来的监管或合同审查。例如欧盟 AI Act 的第 72、73 条要求适用的高风险 AI 系统建立上市后监控，并规定严重事故报告义务。它的范围和时限与美国这项提案并不相同，但实践上的共同点是：团队必须先拥有可归因、被保全的证据，才有可能调查、通知或证明纠正措施已经执行。

哪些失败会让 kill switch 只剩表演效果

开关位于智能体内部。 Prompt、工具描述或模型自己的风险判断不能成为最后执行点。 只停 prompt，不停副作用。 队列、webhook、定时任务、自动重试、被委派的其他智能体和已经签发的批准仍在继续。 所有能力共用一个凭证。 团队无法只停写入，同时保留安全读取与调查访问。 执行停机时删除了证据。 还没做快照和记录标识，就先重新部署、清空队列、轮换 key 或截断日志。 Fallback 从未真正跑过。 旧模型要求另一种 schema，人工团队没有权限，只读模式仍会触发写入。 所谓恢复只是“重新打开”。 没有状态核对、负向测试、分阶段放量、明确批准或额外观察窗口。 客户通知说得太满。 团队还没确认暴露就宣布“数据泄露”，或者还没检查运行中任务就声称“没有影响”。事实、范围、已执行动作和未知项必须分开陈述。 混淆供应商控制与应用控制。 模型 API 开关无法撤销你的计费 token；应用功能开关也无法停止其他位置继续使用的泄露供应商 key。 把开放权重当成托管端点。 一旦副本已经存在于控制范围之外，中央服务关停就无法把它们删除。控制重点必须转向基础设施、分发、访问、工具、凭证和自己运营的部署。

大型模型开发者公开描述的同样是分层体系，而不是一个神奇按钮。OpenAI 的 Frontier Governance Framework 涉及风险评估、缓解措施、事故响应、安全管理和持续更新；Google DeepMind 的 Frontier Safety Framework 更新描述部署缓解措施、safety case、治理审查和上线后的重新评估；Anthropic 的 Advanced AI Framework 提出测试、外部评估、持续披露、事故处理与政府问责。这些材料表达的是开发者自己的立场，并不能独立证明每一项控制都有效；它们至少共同说明，关停能力必须存在于更完整的运营体系中。

这项提案仍然没有解决什么

草案把许多关键问题留给未来规则制定或政治讨论：如何计算开发算力成本；能力水平与开放权重分发如何影响覆盖范围；跨境与多云环境如何执行命令；事故前怎样验证关停标准；以及如何避免中断依赖该技术的重要服务。文本可能被修改、搁置，也可能最终无法通过。

它聚焦于前沿系统的灾难性风险，而 YBuild 读者更常面对普通但依然严重的产品事故。不要因为加了一个 feature flag 就声称符合尚未生效的未来法律，也不要把每一个低风险 AI 功能都套进灾难响应流程。

当 AI 系统能够产生外部副作用、访问敏感数据、跨租户行动、持久化记忆、长时间运行，或造成强供应商依赖时，分级停机梯最有价值。一个不读取敏感上下文、没有外部动作的只读头脑风暴工具，可能只需要普通可用性与隐私控制。对于确定性很强的工作流，根本不用智能体通常更安全。

制动能力也修不好薄弱授权。它不能替代最小权限、审批完整性、输出验证、租户隔离、评估或安全软件交付。7 月 OpenAI/Hugging Face 的评测事故提醒我们，不同边界可能以意外方式串在一起；但双方的 OpenAI 说明与 Hugging Face 披露仍是持续更新中的事故记录，不能被外推成“所有生产 AI 系统都会抗拒关停”的证据。

创始人的 48 小时检查清单

接下来两天内：

指定一位事故负责人和一位备份，两人都能启动控制；
列出一个关键 AI 工作流使用的全部模型、队列、工具、凭证、定时任务、记忆库、webhook 和客户渠道；
把 L0 到 L5 写成可以观察的产品状态；
验证写工具可以在模型之外被拒绝；
明确正在运行、已经排队、已经定时和等待批准的任务分别怎么办；
在平台允许时拆分读凭证与写凭证；
写下五个触发条件、默认级别、决策负责人和最长响应时间；
实现或验证安全的只读、旧模型、确定性规则或人工 fallback；
建立停机回执模板，并保护它链接的证据；
运行一次 60 分钟场景，记录缺失控制；
恢复前强制要求状态核对、负向测试、分阶段放量与具名批准；
询问关键供应商：他们可以限速、隔离、保全、通知和恢复什么，又有哪些责任始终属于你。

创始人真正需要决定的，不是支持还是反对一项美国联邦提案，而是自己的产品能否主动进入更安全的状态，证明状态确实改变，保留最小但有用的服务，并且在恢复时不重复伤害。如果答案依赖某个供应商按钮，或者只有一个人记得一套没有文档的操作顺序，那么产品并不具备关停能力，只是在寄希望于事故不会发生。

参考资料