基础设施是一张治理地图,而不是一份打击目标清单
前沿 AI 依赖于先进芯片、半导体制造设备、大型数据中心、云服务、电力、网络,以及训练有素的人员。这种集中化,反而为各国政府、运营方、客户与开发者提供了施加安全要求的合法途径。但它并不能成为非法闯入、蓄意破坏、暴力行为,或对电力与通信系统进行干扰的正当理由。物理攻击会危及劳动者与社区的安全、扰乱与之无关的其他服务、销毁相关证据,并很可能削弱整个社会应对一次事故的能力。
真正有价值的问题,是一个制度层面的问题:哪个经授权的行为体,能够依据什么规则、凭借什么证据,来限制一项存在风险的活动,又该如何安全地撤销这一决定?这个问题的答案,会随着 AI 生命周期的不同阶段而发生变化。
四个不应被混为一谈的管控面
训练管控,针对的是一个模型的创建过程,或对其进行的重大改进。一次前沿级别的训练运行,可能会连续数周甚至数月使用一个规模庞大、且在地理位置上可辨识的集群。相关的管控措施包括:客户尽职调查、安全标准、算力核算、部署前评估,以及针对超大规模训练运行所附加的合同或监管条件。训练管控发挥作用的时点,是在一个模型以最终形态问世之前;叫停一次训练运行,并不能追回此前已经产生的模型权重。
模型权重管控,保护的是那些学习得来的参数文件。权重可以被复制、被窃取、被微调,也可以在别处运行。相应的安全措施可能包括:基于硬件的访问控制、职责分离、加密、监测、内部人员风险管理流程,以及事故应对机制。一旦具备强大能力的权重被广泛发布,中心化的撤回可能已无从谈起。开放发布能够支持研究与竞争,因此,相关限制应当基于已被证实的风险,并在可行的情况下,配以独立的访问渠道。
部署管控,针对的是一个已托管的模型或应用本身。运营方可以撤销身份凭证、禁用某项工具、回滚模型版本、限制速率或地域范围、把某位用户划入更高保障级别的层级,并监测滥用行为。相较而言,这类管控更为精准,也更容易逆转。然而,如果下游的副本、被缓存下来的输出结果,或独立托管的模型权重依然可以获取,这些管控措施便会失效。
推理管控,针对的是一个系统生成输出或采取行动时所使用的计算过程。推理活动可能发生在一个中心化的云端、一个企业环境、一部手机,或一个分布式集群之中。一家供应商可以约束自己托管的推理服务,但无法自动阻止本地副本的运行。对于一项已部署的风险而言,推理阶段的算力使用、工具权限、数据访问权限,以及行动量,可能比最初的训练成本更为关键。
把这四者统统称为一个所谓的「算力关键节点」,会掩盖它们之间的种种差异。一项合法的干预措施,理应明确指出所涉及的具体管控面与预期效果。
组织内部的运营层面管控
各类组织所需要的,不仅仅是一个戏剧化的「紧急关闭开关」。它们需要的,是一套经过实际演练的安全状态处置程序。突然终止一个系统的运行,可能会破坏数据、中断临床或工业流程、让用户陷入困境,或触发不安全的默认设置。正确的应对方式,或许是撤销权限、降低流量、隔离处理、回滚,或转为人工控制——而不是把一切都彻底关闭。
一份可用于生产环境的应对预案,应当包括:
- 清单建设: 识别出每一个模型、版本、工具、身份凭证、数据集、供应商,以及下游依赖关系。
- 权责界定: 明确列出有权限制服务的人员,并界定他们在何种情况下无需等待常规审批即可采取行动。
- 最小权限原则: 只赋予系统完成其任务所需的数据与操作权限;在可行的情况下,使用有时限的身份凭证。
- 监测记录: 在尊重隐私的前提下,记录模型版本、提示词或安全的事件摘要、工具调用情况、审批记录、输出结果,以及配置变更。
- 遏制能力: 支持从网络、工具、资金流转、代码部署或物理管控中快速隔离出来的能力。
- 回滚能力: 保留一个已知可用的版本、兼容的数据格式,以及经过测试的恢复流程。
- 人工后备方案: 保留经过训练的人员、操作指引、访问权限,以及提供一种降级基本服务的能力。
- 演练: 开展桌面推演与技术层面的演习,记录其中的失误,并加以改进。
NIST 的《AI 风险管理框架》要求开展全生命周期的治理、问责、持续监测、针对第三方失灵的应急流程,以及安全的退役处理(NIST AI RMF 核心内容)。这是一份自愿性的指导意见,而不是对某一具体组织已经落实这些做法的认证。
撤销权限,往往是最快见效的刹车手段
当一个 AI 系统被连接到电子邮件、生产环境代码、金融账户、实验室工具、身份认证系统,或运营技术设施时,它所带来的实际后果会变得更加重大。撤销这些权限,能够在为调查保留该模型的同时,降低相应的危害。访问权限应当被加以分段管理,从而使得单一一项决定,就能在不导致无关服务全面瘫痪的情况下,禁用某项存在风险的能力。
身份凭证不应被永久性地嵌入提示词或模型文件之中。运营方应当使用范围受限的服务身份、较短的有效期、针对高影响力操作的审批关卡,以及模型本身无法修改的独立管控机制。「紧急破例」访问权限,需要有其自身的日志记录与审查机制。一个系统不应当能够自行为自己授予更广泛的权限。
对于外部供应商而言,合同应当保证及时的服务暂停、证据保存、数据导出,以及对迁移工作的支持。否则,客户可能会在事故发生时才发现,自己根本无法查阅日志记录,也无法撤销一次自动更新。
人工后备方案本身,也是一种基础设施
基本服务需要一种可行的降级运行模式。这并不意味着每一项流程都能瞬间恢复到纸质作业状态。它意味着,运营方需要提前决定:哪些功能必须持续运转、以怎样的最低运转能力,以及配备怎样的人员与沟通方式。电力、供水、医疗、金融、交通与公共福利领域,各自面临着不同的安全约束条件。
一套从未有员工实际演练过的人工操作流程,算不上真正的后备方案。各类组织应当对员工进行培训、保留必要的非 AI 交互界面、测试从离线备份中恢复系统的能力,并衡量这种降级模式能够维持运转多长时间。供应商与公共机构应当协调彼此之间的依赖关系:如果一家医院的身份认证提供商、云服务与药房网络,都假定对方会持续保持在线状态,那么该医院自己的应对预案便可能因此而失效。
美国网络安全与基础设施安全局(CISA)针对关键基础设施,建议开展事故应对规划、资产状况摸底、网络分段,以及恢复演练(CISA 网络安全绩效目标)。针对 AI 的具体应对措施,理应被纳入既有的安全与网络安全项目体系之中,而不应被当作一件独立于其外的事情来处理。
政府与客户层面的杠杆
各国政府可以在采购、许可审批、拨款、公共资源使用权限,以及受监管的关键服务中附加相应条件。云服务与数据中心提供商,可以依法开展尽职调查。公用事业公司与地方当局,则可以适用常规的可靠性、环境、土地使用与应急规划规则,而无需把基础设施政策变成对所有 AI 的变相禁令。
客户则可以通过合同获得相应的杠杆。在采购之前,应当要求提供系统文档、与具体使用场景相关的评估结果、安全通报机制、版本管控、审计权限、事故应对配合义务、数据可携性,以及退出方案。客户理应知道,供应商是否可以在未经通知的情况下悄然替换一个新模型,以及在回滚过程中该服务是否依然保持可用。
这些措施需要正当程序作为保障。任何一项限制措施,都应当具备明确的法律依据、证据标准、需承担相应责任的决策者、持续期限,以及审查途径。紧急权力有时确实是必要的,但无限期的秘密管控,则容易招致滥用。
集中化既创造了杠杆,也带来了脆弱性
高度集中的芯片与云服务供应链,能够让监督工作变得切实可行,但也会造成单点故障、市场支配力与地缘政治层面的脆弱性。去中心化能够提升韧性与竞争活力,却也会让「召回」机制与统一一致的安全保障措施变得更加困难。集中化与开放性,都不是天然安全的。
政策应当把「反映真实工程约束的稀缺性」,与「因排他性合同或供应商锁定而人为造成的稀缺性」区分开来。互操作性、多云规划、统一的事故报告格式,以及可移植的日志记录,都能够在不假装「每一份工作负载都能瞬间迁移」的前提下,降低相应的依赖程度。
切实可行的结论
整个社会依然能够通过法律、采购、企业权力、技术层面的访问管控,以及具有韧性的服务设计,对 AI 保持有意义的影响力。正确的行动方式,很少是一种戏剧化的全面关停。而是在训练、模型权重、部署或推理这些具体环节中,采取一项经过授权的精准干预——并配合遏制措施、证据保存、回滚机制与业务连续性安排。
只有当人们清楚知道谁有权采取行动、并且已经演练过接下来会发生什么时,基础设施才能真正发挥其保护作用。合法的管控,当其精准到足以降低风险、而不至于制造出第二场紧急事态时,才最为有力。