美国国会众议员乔什·戈特海默(民主党)与迈克·劳勒(共和党)近日提出《停止失控人工智能法案》(Stop Rogue AI Act),将“如何防止人工智能系统脱离人类监督自主运行”推入两党政策议程。根据公开报道,法案的重要方向之一,是要求美国国家标准与技术研究院(NIST)制定面向人工智能智能体的安全部署标准、指南与最佳实践。对企业而言,这还不是一套已经生效的合规规则,但它释放出一个清晰信号:高权限智能体的权限边界、工具调用和人工干预能力,正在从技术团队内部的安全讨论进入公共政策框架。

这项提案关注的核心,不只是“能否关闭AI”
公开报道将该法案描述为一项旨在防止人工智能系统在缺乏人类监督的情况下自行运行的两党提案。半岛电视台的报道提到,法案意在确保联邦机构具备相应工具和能力,以应对人工智能系统失去控制的风险。
从企业部署角度看,“失控”并不只意味着出现科幻式的自主行为。对企业AI产品团队而言,更现实的风险包括:
- 智能体获得了超出业务所需范围的系统权限;
- 智能体可以直接调用支付、数据库、邮件、代码仓库或生产环境工具;
- 多轮任务执行过程中,权限不断累积,却缺乏重新审批;
- 模型输出被自动转化为外部行动,缺少人工确认;
- 发生异常时,企业无法快速暂停任务、撤销凭证或还原操作;
- 企业能够观察到单次调用,却无法追踪完整的任务链路和责任归属。
因此,法案若要求NIST形成智能体安全部署标准,其政策含义可能并非简单增加一个“AI开关”,而是推动企业建立一套覆盖设计、测试、上线和运行阶段的控制框架。
NIST标准为何会成为政策抓手
与直接规定某一种模型架构不同,标准、指南和最佳实践通常更容易覆盖快速变化的技术环境。人工智能智能体可能使用不同的大模型、插件、企业软件和自动化框架,如果法律直接锁定某类产品,规则很快可能落后于技术发展;而由NIST形成风险评估和安全部署方法,则有机会成为政府采购、行业审查和企业内部治理的共同参考。
这也解释了为什么智能体安全正在从“模型是否可靠”的讨论,扩展到“系统能否被控制”的讨论。一个模型即使在基准测试中表现良好,接入企业工具后仍可能面临新的风险:
- 权限风险:智能体是否拥有完成任务所必需的最小权限,是否能够访问无关数据或执行高影响操作。
- 工具风险:工具调用是否经过参数校验、环境隔离和权限审批,是否允许智能体连续调用多个工具。
- 流程风险:敏感操作是否必须由人确认,异常行为能否触发暂停或升级处理。
- 追责风险:企业是否保留提示词、工具调用、审批记录和结果日志,以便复盘事故。
- 变化风险:模型、工具、数据源或业务流程发生变化后,是否重新进行安全评估。
对于企业管理者来说,NIST可能带来的最大变化,不是立即出现一张统一的“合规清单”,而是让智能体部署逐渐拥有更明确的安全语言和评估维度。
从提案到生效,企业不能混淆两个阶段
目前讨论的是国会提出的法案,而不是已经生效的联邦法律。提案需要经过后续立法程序,最终文本、适用范围、执行机构和具体要求都可能发生变化。公开报道也显示,美国国会围绕人工智能安全立法仍存在分歧,相关法案的推进前景并不确定。Politico报道指出,两党议员对人工智能安全立法能否形成共识仍缺乏把握。
因此,现阶段不能据此得出以下结论:
- 企业已经承担了该法案中的具体合规义务;
- NIST已经发布了针对所有智能体的强制性安全标准;
- 美国企业必须按照某一套统一流程完成智能体上线;
- 法案最终一定会在某个时间点通过;
- 该提案会自动对中国企业产生直接法律效力。
更稳妥的理解是:美国政策制定者正在尝试为高自主性人工智能系统建立联邦层面的安全部署参考。企业可以提前借鉴其中的治理方向,但不应把政策提案当成现行法律,也不应把未来可能形成的标准直接等同于当前的法律责任。
高权限智能体上线前,企业可以先做四项检查
一、先画清楚权限边界
企业应当为每个智能体建立权限清单,而不是笼统地记录“可以访问企业系统”。清单至少应说明:
- 可以读取哪些数据;
- 可以写入或修改哪些数据;
- 可以调用哪些外部工具;
- 哪些操作需要人工审批;
- 哪些操作无论如何都禁止;
- 凭证是否具备时效、范围和环境限制。
尤其需要避免让智能体直接复用员工个人账号或长期有效的高权限密钥。更合理的做法是使用可撤销、可审计、按任务授权的访问凭证,并将开发、测试和生产环境隔离。
二、把工具调用当作高风险动作审查
智能体的风险往往不只来自模型输出,而来自输出能否被转化为现实操作。企业应针对工具调用建立分级机制:
- 查询类操作可以自动执行,但仍需记录;
- 修改业务数据的操作需要参数校验;
- 涉及付款、合同、客户权益和生产环境的操作需要人工确认;
- 删除数据、发布代码或变更安全配置等操作应设置强制阻断或双重审批。
对于连续任务,还要审查“组合风险”。单独看,每次调用可能都不敏感;但当智能体连续读取数据、生成文件、发送邮件并修改系统状态时,整体影响可能已经超过任何一次单独操作的风险等级。
三、建立上线前的风险评估记录
企业可以在智能体上线前形成一份简洁的评估表,记录以下内容:
| 评估项目 | 需要回答的问题 |
|---|---|
| 业务目标 | 智能体具体解决什么问题,失败会造成什么影响? |
| 自主程度 | 它是提供建议,还是能够直接执行任务? |
| 数据范围 | 接触哪些个人、财务、客户或内部敏感数据? |
| 工具权限 | 可以调用哪些系统,能否跨系统连续操作? |
| 人工介入 | 哪些节点必须审批,谁负责最终确认? |
| 异常处置 | 如何暂停任务、撤销凭证和恢复系统状态? |
| 监控审计 | 是否记录完整的决策过程、工具调用和结果? |
| 变更管理 | 模型、提示词、工具或数据变化后是否重新测试? |
这份记录的价值不在于形式上“完成合规”,而在于把技术风险转化为管理层能够审阅和决策的问题。
四、把“停止”设计成可验证的能力
企业经常会在方案中写入“支持人工接管”或“具备熔断机制”,但真正需要验证的是:在智能体已经开始执行任务时,企业能否可靠地让它停止。
上线前至少应测试:
- 是否可以从统一控制台暂停任务;
- 暂停后,已经发出的异步任务是否仍会继续执行;
- 相关访问凭证能否立即撤销;
- 外部系统中的部分操作能否回滚;
- 发生异常时,值班人员是否知道由谁处置;
- 处置过程是否留下完整日志。
“可停止”不应只是产品说明中的一个功能名词,而应成为定期演练的运行能力。
对企业AI部署的现实影响
如果这一政策方向继续发展,企业在采购和建设人工智能智能体时,评估重点可能会从“模型效果”扩展到“可控性证明”。供应商需要更清楚地说明权限管理、日志留存、人工审批、工具隔离、异常暂停和事故响应机制;企业内部的技术、法务、安全和业务部门也可能需要共同参与上线审查。
这并不意味着所有智能体都必须采用同样严格的流程。一个只生成内部会议摘要的低权限应用,与能够修改生产数据库或代表企业对外沟通的智能体,风险等级显然不同。更可行的路径是按影响程度分级管理:自主程度越高、数据越敏感、外部影响越大,越需要严格的测试、审批和持续监控。
对中国企业而言,这项美国提案目前不构成直接法律义务,但其中提出的问题具有普遍的工程和治理价值。企业无需等待某项法律正式生效,便可以先检查高权限智能体是否具备最小权限、人工接管、工具隔离、风险评估和可追责记录。真正需要提前准备的,不是猜测法案最终会写成什么,而是证明企业能够回答一个更基础的问题:当人工智能智能体做错事时,企业是否知道它做了什么、为什么做,以及如何及时让它停下来。
关于文章版权的声明:
https://news.softunis.com/75099.html 文章来自软盟资讯
若非本站原创的文章,特别作如下声明:
本文刊载所有内容仅供提供信息交流和业务探讨而非提供法律建议目的使用,不代表任何监管机构的立场和观点。不承担任何由于内容的合法性及真实性所引起的争议和法律责任。
凡注明为其他媒体来源的信息,均为转载,版权归版权所有人所有。
如有未注明作者及出处的文章和资料等素材,请版权所有者联系我们,我们将及时补上或者删除,共同建设自媒体信息平台,感谢你的支持!

