Brad Smith 警告：Microsoft AI 监管比牛奶安全规则更宽松

Microsoft 总裁布拉德·史密斯以一个直白的对比，进一步激化了 Microsoft AI 监管争论：人工智能面临的安全审查，比牛奶或洗衣机还少。他的警告将一场抽象的政策争议化为一个熟悉的问题：为什么政府会检查日常产品，而日益自主的软件却能在关键系统中行动，却几乎不受独立监督？

史密斯称，AI 既是工具，也是武器。他认为，当企业的系统伤害受害者时，企业需要具备紧急控制机制、接受独立评估，并承担更明确的义务。此番言论发表之际，AI 智能体正获得对商业数据、软件工具和外部服务的访问权限。

这种访问能力让“牛奶”的比喻不只是令人印象深刻的一句话。一盒变质牛奶通常只会带来局部的健康风险；而不安全的 AI 智能体则可能泄露私人记录、执行非预期操作，或帮助攻击者扩大入侵规模。

核心冲突如今已十分清晰。AI 公司希望拥有快速开发和部署高能力系统的空间。史密斯则认为，一旦这些系统能够在更少人工监督下行动，自愿承诺便无法独自承担全部安全责任。

Microsoft AI 监管已成为产品安全问题

史密斯要求政府将先进 AI 视为需要可执行安全控制的运营系统，而非仅仅是一项数字服务。

据AI safety coverage报道，史密斯在采访中表示，洗衣机面临的安全规则比 AI 更多。他指出，杂货店里的每一盒牛奶都要接受检验，并满足安全要求。

这一对比之所以成立，是因为产品监管通常始于可预期的责任。制造商必须遵循标准、记录合规情况、应对缺陷，并在产品伤害他人时承担责任。

先进 AI 并不适合被轻易纳入这一框架。单一模型可以总结文件、编写软件、解读医疗信息、操作工具，并生成具有说服力的内容。其行为还会随着指令、连接的数据、系统权限和部署条件而变化。

这种灵活性使监管更加复杂，但并未消除监管的必要性。它只是将关注点从批准单一固定产品，转向治理整条运营链。

这条链涵盖模型开发商、云服务商、应用供应商、企业部署者和用户。每个参与方都控制着不同部分的风险。当事件跨越多个层级时，责任也更难界定。

史密斯曾主张，行业需要紧急制动机制，通常被称为“终止开关”。这类控制措施可暂停或限制行为超出既定边界的系统。重点并不在于一个字面意义上的红色按钮，而在于能否快速、可预测地遏制其行动。

有效的紧急控制必须在多个层级发挥作用。企业或许需要撤销智能体的凭证、断开外部工具、限制支出、停止自动化工作流，或隔离受影响的模型端点。

这些控制措施还必须经受真实事件的考验。若关闭机制依赖于同一项已遭入侵的服务，其保护作用便十分有限。企业需要经过测试的升级处置程序、人工授权、技术隔离，以及记录谁采取了行动的材料。

史密斯还呼吁，在失控 AI 智能体侵入系统时，企业应对受害者承担法律义务。这一提议将讨论从原则推进到责任问题：当智能体造成损害时，由谁赔偿；又是哪一家组织最后仍有现实机会阻止它。

现有法律已经适用于许多与 AI 相关的活动。隐私、网络安全、歧视、欺诈、消费者保护、版权以及行业特定规则，并不会因为 AI 介入而失效。

然而，这些法律往往处理的是部署后的后果。史密斯的主张则聚焦于运营前和运营期间的专门控制措施，包括测试、监控、遏制，以及对严重故障的强制响应。

这一区别很重要。企业可以遵守一般隐私规则，却仍赋予不可靠的智能体过多权限；也可以发布安全原则，却无法证明其紧急控制措施能在压力下发挥作用。

因此，Microsoft 的警告重新定义了 AI 治理。眼下的问题不再是 AI 是否以某种形式受到监管，而是现有规则是否能够匹配这项技术不断增强的观察、决策和行动能力。

压力正从模型实验室转向部署的每一层

当一家企业训练模型、另一家负责托管、第三家将其接入敏感商业系统时，问责缺口便会扩大。

公众讨论往往集中于 OpenAI、Anthropic 和 Google DeepMind 等前沿模型开发商。它们的模型备受关注，是因为训练决策会影响众多产品可获得的能力。

然而，大多数伤害并非源于模型独立运行，而是来自部署决策。权限、数据访问、外部工具、检索系统和自动化工作流，决定了模型实际能够做什么。

Microsoft 横跨这条链的多个环节。它提供云基础设施、分发 AI 产品、开发模型，并与 OpenAI 保持重要合作关系。这一位置赋予史密斯的警告更强的现实分量。

但这也让该警告在商业上更具便利性。若监管在整个市场施加明确义务，可能提高小型供应商的运营成本。大型企业已经拥有合规团队、安全基础设施和既有的政府关系。

这并不意味着史密斯的安全论点无效。它意味着政策制定者应同时审视其主张的实质与背后的激励因素。

Microsoft 将公平、可靠性、隐私、透明度、问责和包容性视为其负责任 AI 项目的核心部分。该公司还发布工具和报告，说明其如何评估 AI 风险。

内部治理具有价值。它可以在立法跟上之前，建立发布审查、使用限制、事件处理程序和测试标准。

不过，内部政策仍由企业自行掌控。组织自行制定规则、衡量表现，并决定哪些细节对外公开。客户未必总能在不同供应商之间比较这些主张。

独立评估可以缩小这一信息差距。外部专家能够测试模型是否遵循指令、抵御操纵、保护数据并遵守运营限制。

当 AI 智能体进入真实环境后，评估会更加困难。相同模型可能因其工具、记忆、系统指令和访问权限不同而表现不同。

因此，基准测试结果无法为整个部署提供认证。测试必须覆盖实际系统，包括其集成方式和故障处理程序。

企业面临着最直接的压力。将智能体接入客户记录或内部文件的企业，也就成为问责链的一部分。从大型供应商处购买模型，并不会转移所有责任。

企业买家应了解智能体可访问哪些内容、哪些操作需要批准，以及管理员能多快撤销其权限。他们还需要日志，以揭示事件发生前的情况。

这一挑战类似于供应链安全。组织依赖外部供应商，却仍要为软件在自身环境中的运行方式负责。

清晰的监管可以建立共同基线。它可以要求可比的文档、事件报告、访问控制和有实质意义的人工监督。

设计不佳的监管则可能制造文书工作，却无法降低风险。企业可能编制大量文档，同时让关键凭证暴露在外，或未能测试恢复能力。

强制要求应侧重于运营，而非仪式化程序。模型开发商必须记录已知限制；平台公司必须提供可用控制措施；部署者必须负责任地配置系统并监控其行为。

用户同样需要有实质意义的警示。一句笼统的“AI 可能会犯错”，并不能说明系统是否可以发送信息、修改文件或授权交易。

Microsoft AI 监管争论将在这些边界处最具意义。当每个参与方都在自主行动造成损害前明确自身义务时，责任才会真正落到实处。

真正的取舍，是速度与可执行问责之间的平衡

AI 安全规则必须减缓危险部署，同时不能让合规成为保护最大既有企业的护城河。

美国长期倾向于采取自愿承诺和行业主导的保障措施。这种方式能够迅速适应，因为企业无需等待立法，便可以改进自身系统。

但自愿行动也有明显弱点。企业可以对宽泛承诺作出不同解读；可以在未经公众批准的情况下调整内部标准；外部观察者获得的合规证据也可能有限。

市场压力并不总能纠正这一问题。买家通常无法检查专有模型或复现安全测试。他们可能直到部署后才发现故障。

欧盟则采取了更具约束力的路径。其AI Act framework根据风险分配义务，并对通用 AI 提供商施加具体要求。

该框架包括透明度、文档和风险管理义务。具有系统性风险的通用模型提供商必须评估并缓解这些风险。

欧洲的执法机制也拥有自愿项目所不具备的权力。AI Office 可以要求提供文档、评估模型、要求采取纠正措施，并对不合规行为处以处罚。

然而，欧洲的做法也表明，史密斯的“牛奶”比喻需要加以限定。AI 并非完全不受监管，多个司法辖区的监管体系已经在发展。

更有力的说法是，监管仍然并不一致。覆盖范围取决于地点、行业、系统类型和部署日期；重要义务也会按不同时间表生效。

牛奶监管面对的是相对稳定的产品类别。AI 规则则必须覆盖可服务于多种用途、并能通过软件更新发生变化的系统。这个类比阐明了差距，却无法解决制度设计问题。

僵化的审批体系，可能在监管机构完成模型审查前就已经过时；宽松的原则性体系，则可能使机构无力质疑不安全的部署决策。

更好的路径是将持久义务与可适应的技术标准结合起来。政府可以要求风险评估、事件报告、访问控制和独立评估，而无需规定每一种工程方法。

标准机构和技术部门随后可以随着能力变化更新测试方法。监管机构保留执法权力，而专家则不断完善运营细节。

责任是这种权衡的另一项关键内容。当有害的自动化行为源于疏忽的设计或部署时，受害者需要获得切实可行的赔偿途径。

同时，责任规则必须区分不同参与方。模型开发者不应因某个无关应用忽视已记录的限制条件，就自动承担全部责任。

同样，若提供商隐瞒已知漏洞，部署者也不应承担所有损失。责任应与控制权、知情程度以及预防损害的能力相匹配。

这一结构也能保护规模较小的公司。相比事故发生后面临不确定的执法，清晰的义务更便于规划。共享的评估标准能减少每家初创公司都自行设计安全框架的需要。

合规支持同样重要。监管机构可以发布模板、测试资源和安全开发环境。欧盟的监管沙盒为在监管下测试系统提供了一种模式。

另一种结果是形成双层市场。大型供应商将维持复杂的私有治理项目，而较小的开发者则会难以理解不断变化的法律预期。

因此，Smith 的立场包含一种艰难的平衡。Microsoft 希望规则更严格，但有效的规则必须像约束资历较浅的竞争对手一样严肃地约束 Microsoft。

检验标准在于，监管是否能创建可衡量的义务，从而提升整个市场的安全性。如果它主要是在认可既有的企业项目，公众信任仍将十分脆弱。

终止开关有帮助，但无法定义 AI 安全

紧急制动能够减少失控系统造成的损害，但不能替代预防、评估或明确的权责。

终止开关听起来令人安心，因为人们能立刻理解它。工业机械有紧急停止装置。车辆有制动器。网络运营方可以隔离遭入侵的系统。

AI 智能体让这一模式变得复杂，因为其活动可能跨服务扩散。在任何人意识到问题之前，智能体可能已经创建账户、复制信息、触发工作流，或与其他系统通信。

停止原始流程并不能撤销已经完成的行动。被撤销权限的智能体无法收回它已泄露的数据，也无法自动修复另一个系统已经接受的有害决定。

因此，紧急控制措施必须与预防手段协同运作。组织应限制权限、隔离敏感环境，并要求对后果重大的行动进行审批。

最小权限原则只给予系统完成任务所必需的访问权限。当模型可能误解指令或遵循恶意内容时，这一点尤为重要。

提示词注入说明了这种风险。攻击者可以在 AI 系统读取的内容中嵌入指令，试图覆盖系统原本预期的行为。

传统软件将外部内容视为数据。AI 智能体却可能错误地将这些内容理解为指令。工具访问权限会让这种错误转化为运营威胁。

监控也不仅仅是收集日志。安全团队需要能够识别异常访问、意外工具调用、异常支出、重复失败以及绕过控制措施企图的信号。

人工监督必须具体明确。如果员工无法理解 AI 系统的行为，也无法迅速中断它，那么要求员工监督该系统毫无意义。

组织需要指定明确的权限负责人。必须有人知道何时暂停系统、通知哪些客户，以及如何保全证据以供调查。

Smith 先前公开讨论 AI 问责制时，强调了跨多个技术层面的监控、支出限制和控制措施。一篇详细的问责制讨论也强调了基础设施、模型、数据和应用如何划分责任。

这种划分可能形成一种失效模式。每个提供商都可能声称事故由另一层导致。客户可能难以判断，应由模型、配置、集成还是遭入侵的账户负责。

强制性事故报告可以揭示反复出现的模式。监管机构将获得单个客户无法从孤立故障中汇集的信息。

报告应区分一般性失误与严重事故。否则，机构可能被价值不高的通知淹没，同时错过安全漏洞或后果重大的自动化决策。

报告门槛可以考虑未经授权的访问、重大财务损失、关键基础设施中断、人身伤害，或大规模敏感信息泄露。

独立调查人员也需要获得充分访问权限。当公司对系统行为存在争议时，公开摘要不能替代技术证据。

同时，披露规则必须保护安全细节和个人数据。若在受影响组织部署修复措施前过快公开漏洞利用方式，可能会增加风险。

最重要的质疑点涉及可行性。没有一种通用终止开关能够控制互联网上的每一个开放模型、复制系统或恶意部署。

监管不应承诺实现完全控制。它可以要求负责任的公司在其运营和分发的系统中内置遏制能力。

这种区别使该提议保持可信。政府可以对可识别的提供商和部署者执行义务，却无法保证每个参与者都会遵守。

当紧急制动被视为防御体系中的一层时，Brad Smith 关于 AI 安全的论点最有力。如果决策者将其视为应对自主风险的完整答案，这一论点就会削弱。

Microsoft 的警告也使 Microsoft 面临审视

一家呼吁加强监管的公司，必须证明其自身产品能够达到它希望政府施加的标准。

当客户信任 AI 并将其纳入日常工作时，Microsoft 将从中受益。Copilot 产品和 Azure 服务可以与文档、通信、软件项目和组织知识进行交互。

这些使用场景使治理成为产品要求。在将 AI 连接到敏感材料之前，企业客户需要可预测的控制措施。

Microsoft 发布了负责任 AI 原则和透明度报告，也为开发者提供评估与安全工具。这些措施为其内部治理体系提供了证据。

然而，原则并不能证明每一次部署都是安全的。它们无法说明所有客户如何配置智能体，也无法保证每项集成都维持了适当的边界。

Smith 的介入合理地引发了对进一步披露的期待。Microsoft 应说明目前已有哪些紧急控制措施、这些措施接受测试的频率，以及哪些失效情况会触发升级处理。

该公司还应明确 Microsoft、模型合作伙伴、应用开发者和客户之间如何划分责任。事故发生后，合同条款往往比公开原则更为重要。

这尤其重要，因为 Microsoft 参与了 AI 技术栈的多个层面。当它也在分发面向用户的应用时，不能只将自己描述为基础设施提供商。

它与 OpenAI 的关系又增添了一层复杂性。Microsoft 可以提供托管、分发、安全工具和企业控制措施，但并不控制每一个模型开发决策。

这种复杂性支持 Smith 关于共同义务的论点，也要求 Microsoft 明确它确实能够控制哪些决策。

批评者有理由怀疑存在监管俘获。大型科技公司有时会支持小型竞争对手无力承担的规则。

健全的框架必须防止这种结果。评估要求应与风险和能力相对应，而不应仅仅取决于公司规模。合规资源应继续向较小的开发者开放。

开源 AI 带来了另一项挑战。面向公众发布的模型可能被与原始开发者毫无关系的人修改和部署。

为集中式云服务设计的规则，可能无法顺利适用于可下载模型。决策者必须区分开发、分发、托管和高风险部署。

过于宽泛的限制可能使 AI 开发集中于少数富裕公司手中。过于宽松的规则则可能让不负责任的运营者通过改变分发模式来规避基本安全义务。

答案不是自动豁免任何一类主体。义务应取决于已证明的风险、运营控制权以及减轻损害的能力。

如果 Microsoft 希望整个行业接受独立评估，就应欢迎对其自身系统进行独立测试。结果需要包含足够细节，以便客户比较产品及其局限性。

这并不要求公开专有模型权重或敏感防御措施，而是要求提供有关测试范围、已知失效模式、事故处理流程和遏制能力的标准化证据。

公众也应根据 Microsoft 的工程选择来评判其游说行为。如果该公司寻求在法律中确立紧急制动，其平台就应让管理员能够使用这些制动措施。

如果它呼吁保护受害者，合同就不应把所有后果都转嫁给客户。如果它支持事故报告，其披露应提供有用信息，而非经过谨慎限制的摘要。

Microsoft 的 AI 监管提议将通过一致性赢得可信度。该公司必须接受能够实质约束其自身部署的义务，而不仅仅是约束竞争对手的义务。

三个信号将显示这一警告是否改变政策

下一项考验在于，Smith 的类比是否会形成可执行的义务、可衡量的保障措施，以及证明紧急控制有效的证据。

第一个信号是具体的英国立法。Smith 主张，英国有机会引领这一领域，因为华盛顿看待伦敦的方式不同于看待布鲁塞尔。

英国官员也表示，正在准备更严格的 AI 监管。关键问题在于，这一过程会产生具有约束力的要求，还是又一份自愿协议。

一项有意义的提议应定义涵盖的系统、责任方、事故门槛和执法权力，也应说明监管机构如何获得技术证据。

泛泛承诺追求安全 AI 并不能强化 Smith 的论点。针对评估、遏制、报告和受害者保护的具体义务才能做到这一点。

第二个信号是对紧急控制措施的独立测试。Microsoft、OpenAI、Anthropic、Google DeepMind 和其他提供商可以在监管机构提出要求之前描述终止开关。

有价值的证据将来自实际测试。提供商能否在互联服务中停止行为异常的智能体？企业能否在不禁用无关业务的情况下撤销访问权限？

测试还应检验恢复能力。组织需要知道，它们能否识别已完成的行动、恢复受影响的系统，并通知受到暴露影响的用户。

成功的演示将强化 Smith 的论点，即政府可以建立可衡量的要求。薄弱或精心编排的演示则会表明，这一概念仍不成熟。

第三个信号是监管机构如何在 AI 供应链中分配责任。仅聚焦前沿模型开发者的规则，将使许多部署决策不受约束。

仅聚焦企业用户的规则，则会让基础设施和模型提供商规避其对可控设计缺陷应承担的责任。

最强有力的框架将依据实际权限分配义务。开发者应处理模型风险。平台应提供控制措施。部署者应管理权限、监控和特定情境下的后果。

欧洲的实施为早期实践提供了参考。其规则区分不同类型的系统，并对具有系统性风险的通用模型提出了义务要求。

该框架仍在通过执法接受检验。监管机构必须证明，文件调取、评估、整改命令和处罚能够在实践中发挥作用。

美国将提供一种对比鲜明的信号。其政策辩论在国家竞争力与更严格约束之间权衡，尤其是在与中国的竞争影响科技战略之际。

这种竞争关系带来了加速推进的压力，同时也放大了安全失误、模型被盗，以及系统在缺乏充分隔离措施下部署的后果。

速度与安全并非简单对立。值得信赖的市场能够推动更广泛的采用，因为客户清楚自身的责任和可获得的补救措施。

糟糕的监管仍可能在未解决真实风险的情况下，拖慢有用产品的推出。目标应是可验证的保障措施，并与系统能够执行的行为相对应。

对开发者而言，这意味着应将权限和隔离机制视为产品设计的一部分。不能等到代理已经获得广泛访问权限后，才把安全当作补充的政策文件。

企业采购方应要求提供评估结果、事件处置流程、审计记录和明确的责任条款。他们还应保留可检索的部署决策记录及已知限制。

知识工作者应留意 AI 产品何时从提供建议跨越到实际执行操作。起草文本的系统，与发送消息或修改共享文件的系统，所带来的风险并不相同。

正在构建自身治理体系的团队，可以从一个记录获准用途、源材料、访问规则和人工责任人的 AI knowledge base 开始。文档无法取代技术控制措施，但能让问责机制变得可见。

除非相关机构将其转化为可操作的标准，否则 Smith 的“牛奶”比喻终将淡出视野。应关注英国的立法、独立的隔离测试，以及覆盖整个供应链的责任规则。

这些信号将揭示，Microsoft AI 监管究竟会成为可执行的产品安全机制，还是仅仅停留在令人印象深刻的警示。在部署下一个代理之前，请提出一个实际问题：当它超出预定边界行动时，谁能够叫停、调查，并赔偿任何受到伤害的人？