联邦专家呼吁在部署前严格测试 AI

Google News 再次聚焦一项联邦警告，其中存在鲜明冲突：各机构正在部署更多 AI，但可靠测试依然成本高昂、进展缓慢且并不完整。

相关报道指出，联邦技术专家敦促各机构在将 AI 用于具有重大影响的环境前，反复进行测试。他们担忧的不仅是人们熟悉的训练数据偏见问题，也希望各机构审查模型在面对真实用户、敏感信息、运营压力，以及开发人员未预料到的情形时会如何表现。

这一立场与联邦政府同时推动加快采用的举措形成挑战。各机构被要求消除不必要的障碍、现代化服务，并更高效地使用商业 AI。然而，当自动化推荐、身份核验、摘要或软件操作对公众造成伤害时，承担责任的仍是这些机构。

Google News 标题指向更广泛的测试缺口

关键进展并非新的联邦禁令，而是在 AI 进入具有重大影响的工作流程之前，对证据的需求不断增长。

这场联邦测试讨论汇集了来自国土安全部、爱达荷国家实验室和 HP Federal 的官员与专家。他们的评论聚焦于偏见、人工监督，以及持续测试的价值。

国土安全部科学与技术局高级顾问 Arun Vemury 将测试描述为一项必不可少、却常被忽视的支出。组织往往会回避它，因为有意义的评估需要时间、合适的数据、技术专家，以及接近实际运营情况的环境。

这种回避会造成危险的捷径。一个模型可能在受控演示中表现良好，却在面向不同人群、设备、地点或工作条件部署时失效。

人脸识别系统就是一个清晰例子。其平均准确率几乎无法告诉决策者，它在光线不佳、证件受损或不同人口群体中的表现如何。看似出色的总体分数，可能掩盖集中出现、影响特定人群的错误。

语言模型带来了不同的衡量难题。它们的回答会随着提示词、检索到的文件、模型版本和系统指令而变化。一个团队不能仅通过提交几个有利问题、记录最佳回答，就确立系统的可靠性。

因此，这些联邦专家将偏见视为必须在系统整个生命周期中持续管理的问题。这一框架很重要，因为它否定了开发者能够在训练期间消除所有不良倾向的想法。

模型的行为源于数据选择、系统设计、用户交互和部署环境。即使技术能力过硬的模型，在其被分配的任务定义不当时，也可能产生有害结果。

Google News 的呈现将这一论点简化为对严格测试的直接呼吁。完整的问题更为棘手：各机构需要能够反映每项任务、受影响人群和可接受失败程度的测试计划。

这一要求改变了参与 AI 项目的人员构成。采购官员必须索取证据，项目经理必须界定预期任务，领域专家必须识别不可接受的结果。安全团队必须测试访问边界，而用户则必须评估输出在实践中是否有用。

仅靠开发者无法回答这些问题。他们了解系统，但并不代表每一位受其决策影响的人。

演示与部署之间的区别尤为重要。演示关注 AI 工具能否产生预期结果。部署测试则关注它失败的频率、哪些用户会遇到这些失败，以及现有控制措施能否发现这些问题。

联邦机构还面临消费软件公司未必需要承担的限制。它们的系统可能处理健康记录、福利信息、执法数据、人事档案和国家安全材料。

起草助手中的无害错误，并不等同于身份、医疗或资格认定工作流程中的错误。测试必须围绕后果展开，而不是围绕模型引发的热度展开。

这正是为何即使没有新规，这一标题也值得关注。它体现了从讨论 AI 原则转向要求其在真实条件下展现可观察性能的实际转变。

联邦加快采用，提高了风险

联邦机构面临双重压力：行动过慢会失去有用能力，行动过快则可能让公众暴露于缺乏充分了解的系统之下。

采用规模解释了为何测试变得紧迫。政府问责局开展的一项联邦 AI 审查研究了 11 个机构的清单。

这些清单中，2023 年报告的 AI 用例为 571 个，2024 年增至 1,110 个。同期，报告的生成式 AI 用例从 32 个升至 282 个，约增长了九倍。

这些数字并不能证明每个列出的系统都已投入生产。清单可能包括规划中、探索性和运营中的用途。不过，它们仍显示联邦团队正在针对远比过去更多的任务评估 AI。

这些用例不止包括面向公众的聊天机器人。GAO 识别出的潜在应用包括书面沟通、信息获取、项目跟踪、医学影像，以及从文件中提取公共卫生信息。

每一类应用都对可接受性能有不同定义。如果有人审查，写作助手可以容忍一句表达别扭的句子。支持医疗或公共安全工作的系统则需要更有力的证据。

因此，机构领导者必须在选择评估方案前对风险进行分类。关键问题不是模型是否使用生成式 AI，而是模型出错时会发生什么。

以一款总结内部政策的工具为例。其最明显的风险是摘要不准确。然而，它也可能遗漏例外条款、暴露受限文本、引用已被取代的规则，或为相似用户生成不同答案。

试点项目可能遗漏这些失效情形，因为参与者已了解源材料。新员工可能会信任同样的输出，却无法意识到哪些内容消失了。

采购又增加了一层复杂性。各机构通常从供应商处购买模型、云服务和应用程序，而非将所有内容都在内部构建。买方随后便依赖于可能与政府环境并不匹配的文档和评估证据。

供应商的基准测试可以证明模型在标准测试中的表现良好，却无法证明完整的机构系统能够在本地数据、检索工具、权限设置和用户环境下安全运行。

随着智能体 AI 的发展，这一区别更为严重。AI 智能体是一种可通过连接的软件选择并执行操作的系统，而不只是返回文本。

普通聊天机器人可能生成错误建议。接入系统的智能体则可能据此采取行动，例如更改记录、发送消息、调用外部服务，或启动另一项工作流程。

测试因此必须覆盖模型及其权限。评估人员需要确定哪些操作被允许、审批如何运作，以及当指令发生冲突时系统是否会停止。

美国卫生与公众服务部助理监察长 Tamara Lilly 曾警告，自动化系统的运行速度可能快于传统控制措施。她的运营治理指导强调了清晰边界、访问规则，以及持续证明控制措施有效的证据。

这正是 Google News 报道背后的压力目标。首席信息官和首席 AI 官必须在取得有用成果的同时，防止实验演变为失控部署。

预算压力不可避免。评估环境、具有代表性的数据集、红队测试、无障碍审查、安全测试和部署后监测都会消耗资源。

这些支出可能看似会延迟任务收益。但测试不足并不会消除成本，只会将成本转移给用户、事件响应人员、审计人员和未来的补救工作。

政府还面临私人组织有时可以规避的信任问题。在自动化系统失效后，人们并不总能选择另一套福利系统、边境流程或公共机构。

这种缺乏选择的情况提高了标准。各机构需要证明工具能实现其既定目的，而不是笼统宣称底层模型很先进。

因此，有效的采用计划会将低风险辅助与具有重大影响的决策支持区分开来。它可以在可逆的起草任务上快速推进，同时对影响权利、访问、安全或基本服务的系统实施更严格的关卡。

这一方法并不要求将每项 AI 功能都视作同等危险。它要求让证据和控制强度与失效后果相匹配。

速度与保障才是联邦 AI 的真正冲突

核心冲突并非创新与监管，而是快速部署与任务特定保障之间的矛盾。

白宫于 2025 年 4 月通过修订后的机构 AI 使用和采购政策，强化了联邦加快采用的方向。这项联邦 AI 政策强调，在维护隐私、民权和公民自由保护措施的同时，减少不必要的障碍。

这一组合在纸面上看似兼容。但在实践中，速度与保障会争夺同一批人员、资金和领导层关注。

一个团队可以快速采购商业助手，却无法立即确定该助手会如何处理每一份受限文件、误导性指令、缺乏依据的主张或不寻常的用户请求。

由此产生的权衡常被错误地呈现。领导者被问及是支持 AI 采用，还是偏好谨慎。这样的框架将必要的工程工作变成了政治偏好。

测试是部署的一部分，而非反对部署的理由。航空、医疗技术、网络安全及其他高后果领域都依赖评估，因为有用的系统仍可能失效。

AI 使这一原则变得更复杂，因为其行为具有概率性。概率性系统可能从相似输入产生不同输出，尤其是在供应商更新模型后。

传统软件测试仍然必要，但并不充分。开发者可以验证 API 是否返回响应，却无法据此确定响应是否准确、公平、安全或有用。

联邦团队需要多层保障。能力测试关注系统是否完成指定任务。对抗测试关注它如何应对操纵企图。

现场测试考察系统在真实用户和现实运营条件下的表现。监测则检查部署、新数据或模型更新后结果是否发生变化。

人工监督将这些层面连接起来。如果一个人没有足够的时间、权限和领域知识来质疑 AI 输出，就无法对 AI 系统进行有意义的监督。

名义上的批准按钮并不等于监督。如果员工在截止期限压力下处理数百项建议，他们可能会不假思索地接受输出结果。

机构必须将人工工作流程与模型一并测试。它们应衡量审查人员是否能发现错误、理解不确定性，并知道何时应升级处理某项结果。

这带来了一种令人不安的反转。AI 通常被购买来减少人力投入，但安全实施在初期反而可能需要更多专业工作。

项目团队需要领域专家构建测试案例。安全专家必须审查数据流，律师必须评估法律义务，无障碍专家则必须评估对用户的影响。

这项投入仍可能带来回报。经过测试的系统能够减少重复性工作，同时让人们专注于例外情况和判断。然而，领导者不应假装监督会自动出现。

同样的冲突也影响着供应商。政府采购方希望迅速获得更新的模型，但频繁升级可能会使先前的评估结果失效。

供应商可能在改进通用推理能力的同时，改变拒答行为、格式或在专业任务上的表现。机构在接受此类更新前，需要具备版本控制和重新验证触发机制。

模型提供商也无法自行测试每一种联邦使用场景。通用系统在接入移民记录、科学数据、采购文件或临床工作流程时，会面临不同风险。

因此，责任是共同承担的，但不能相互替代。供应商应披露相关限制和变更。机构仍必须在预定环境中测试组装完成的系统。

Google News 为发现这一议题提供了一条简便路径，但政策冲突远比一条新闻标题更深刻。联邦领导者正被要求在不降低公共权力所附带标准的前提下加快采用。

可行的应对方式是分阶段部署。团队先从范围狭窄的任务、有限的数据、受限的权限和可衡量的成功标准开始。

只有在证据支持扩展时，他们才会扩大范围。这种方法既保持推进势头，也建立起可供审计人员、管理者和受影响用户审查的记录。

分阶段实施也让失败更具参考价值。受控试点能够揭示某个模型并不适用，而不会造成全国性的服务问题。

另一种选择是凭热情部署。这种路径将初步的流畅表现视为证据，把供应商基准测试与任务表现混为一谈，并通过公开事件才发现其局限。

严格的 AI 测试必须伴随系统进入生产环境

部署前测试只是起点，因为模型、数据、用户和连接工具发生变化后，AI 的行为也可能改变。

美国国家标准与技术研究院通过更广泛的测试、评估、验证和确认流程来描述测试。这一流程通常简称为 TEVV。

NIST 的风险框架指出，AI 系统应在部署前接受测试，并在运行期间定期测试。该框架还要求采用有文档记录的方法、可衡量的标准、真实条件，并让开发团队之外的独立或内部专家参与。

这一指导说明了“严格”为何重要。仅让模型针对一份固定提示词列表运行一次，并不能证明其性能可靠。

有意义的评估始于明确的任务定义。机构应说明预期用户、可用数据、运行条件、禁止行为以及失败后果。

随后，评估人员可以围绕真实案例构建测试。测试应包括常规示例、罕见案例、对抗性输入、不完整信息，以及系统应拒绝采取行动的情形。

指标也必须反映任务目标。准确率可能很重要，但它未必能反映错误是否集中于特定群体。

评估摘要的团队可能会衡量无依据的主张、遗漏的要求、不正确的引用以及受限信息的披露。评估身份识别技术的团队则需要不同的衡量标准。

领导者看到有利结果之前，就应设定阈值。否则，项目团队可能在观察到系统弱点后重新定义成功。

独立评估有助于应对这种风险。开发者天然了解如何让自己的系统产生良好结果。用户和外部评估者则更可能发现令人困惑的指令和意外行为。

红队测试提供了另一种视角。红队测试是一种结构化的对抗性测试，用于寻找弱点、有害输出或绕过控制措施的方法。

它不应沦为表演。少数几个戏剧化的提示词可能制造宣传效果，却无法衡量对特定机构真正重要的风险。

优秀的红队以威胁模型为基础，该模型识别潜在攻击者、受保护资产、可能的方法和运营后果。其发现应促成修复、重新测试和有文档记录的决策。

实地测试同样重要，因为实验室无法复现所有人类行为。员工可能复制比预期更多的文件、提出含糊的问题，或将输出与非官方信息结合使用。

系统也可能改变周围的工作环境。员工可能不再核查一手来源，改变记录决策的方式，或依赖掩盖责任归属的生成式措辞。

这些影响很少出现在基准测试中。它们会通过观察、用户访谈、事件报告和重复测量显现出来。

随后，生产环境监控必须能够发现漂移。漂移是指输入、模型行为与预期结果之间的关系会随时间发生变化。

原因可能是新模型版本、不同的用户群体、检索集合发生变化，或现实条件改变。任何一种情况都可能削弱先前评估的效力。

监控不应只记录系统可用性。团队需要针对异常输出、控制失效、用户覆盖、投诉和任务特定质量的信号。

他们还需要事件处理流程。员工必须知道应向何处报告可疑结果，项目负责人必须有权限制或暂停系统。

这种能力对连接型代理尤为重要。最小权限访问意味着只授予系统完成其分配任务所需的权限。

起草助手不需要发布权限。日程安排代理不需要不受限制地访问人事记录。

团队应测试模型请求执行超出其权限的操作时会发生什么。预期结果必须是受控失败，而非临时拼凑的变通办法。

数据评估同样值得重视。机构需要了解哪些信息进入模型、在哪里处理、保留什么信息，以及谁能够检索这些信息。

检索增强生成是一种向模型提供选定文件的方法，可以提升相关性。它也可能复现过时、未经授权或相互矛盾的材料。

因此，文件治理成为 AI 测试的一部分。可靠的可搜索知识库需要明确所有权、访问控制、最新的源材料和可追溯的更新。

需要保持怀疑的一点是，没有任何评估计划能够证明通用模型在所有条件下都安全。可能的输入和交互范围过于广泛。

机构应避免使用“无偏见”“安全”或“无幻觉”等绝对表述。这些描述超出了有限测试所能证明的范围。

可辩护的结论应更为有限。证据可以表明，某一特定系统在特定任务、版本、人群和环境下达到了既定阈值。

这种限定并非软弱。它是诚实保证的基础。

联邦团队还需要在不暴露敏感系统的前提下，发布足够的信息以支持监督。他们可以说明预期用途、评估类别、限制和监控流程，同时保护运营细节。

透明度能增强问责，因为它让公众能够区分受控助手和自动化决策者。它也为监察人员和立法者提出精确问题提供了依据。

最大的实施风险是将测试变成一张清单。填写完成的表格无法替代真实证据。

合规文件很重要，但它们应指向测试结果、事件记录、模型版本和责任明确的负责人。否则，机构可能围绕一个不确定的系统生成大量文书工作。

联邦 AI 采购方接下来应关注什么

下一阶段的衡量标准，将是联邦机构能否将测试原则转化为可执行的部署门槛和持续证据。

第一个信号是，机构如何对具有重大影响的 AI 实施基于风险的批准机制。仅有清单无法说明领导者是否暂停、缩小或重新设计了未通过评估的系统。

关注那些将低风险辅助与影响权利、安全、获取机会或基本服务的 AI 区分开来的公开文件。明确的分类将强化这样一种观点：更快采用可以与更严格的保证并存。

缺少这些类别则会削弱这一观点。机构可能声称合规，却对风险本质上不同的系统采用类似审查。

第二个信号是，采购合同是否在购买后保留评估权。政府采购方需要获得模型变更通知、相关文件、测试支持以及对更新的控制权。

合同条款还应明确事件责任和数据处理方式。缺少这些条款，机构可能会依赖无法反映其部署环境的供应商保证。

可重复适用的合同要求将表明，测试已向上游进入采购环节。持续依赖通用性能主张则意味着部署缺口依然存在。

第三个信号是，系统投入生产后机构报告了什么。有用的证据包括监控实践、重要事件、纠正措施，以及受限或停止使用的案例。

没有报告事件并不一定证明安全。这可能表明员工缺少报告渠道，或者机构对事件的定义过于狭窄。

读者应特别关注那些获得行动权限的系统。从生成文本转向自主行动，既提高了潜在收益，也增加了出错成本。

这正是 Google News 和类似发现平台发挥作用的地方。它们可以呈现原本分散的机构听证会、专家访谈、监督机构报告和政策变化。

不过，聚合并不等于验证。读者应从标题追溯至原始报道，再将其主张与政策、审计和技术指导进行比较。

现有证据支持一个克制的结论。联邦 AI 部署正在扩大，而专家仍在构建评估系统在真实条件下表现所需的方法。

这并不意味着应冻结每一个项目。它支持范围狭窄的使用场景、可衡量的阈值、人类决策权、受限权限以及上线后的监控。

决定性问题不再是联邦机构是否会使用 AI。它们已经在使用，而且其报告的使用案例已大幅增长。

问题在于，每个机构能否证明某一特定系统为何配得上被赋予的权限。这一证明应包括任务、已测试条件、失败阈值、责任负责人，以及行为发生变化时的应对措施。

下次 Google News 的头条报道联邦政府推出 AI 项目时，别只盯着模型名称。请关注它测试了什么、由谁评估、还存在哪些故障，以及该机构能否安全地停止该系统。