Amazon Quick 推出 Smart Approvals:在关键环节保留人工审核
Smart Approvals in Amazon Quick: Human oversight where it matters
Amazon Quick 推出 Smart Approvals,用独立的分类器模型对符合条件的智能体操作自动审批,或交回用户审核,不新增权限也不移除必需的人工批准。
随着 AI 智能体承担更多工作,安全负责人应如何保持人类监督?权限决定了智能体可以执行哪些操作,但被允许的操作仍可能需要人的判断。要求每一步都进行审批似乎是最安全的方式,但多步骤任务可能产生重复的提示,即使是例行动作也不例外。关于安全警告的研究表明,注意力和遵循度会随着重复而下降。挑战不在于要求更多审批,而在于为需要人工审查的决策保留注意力。
Amazon Quick 中的智能审批通过在您现有控制范围内审查符合条件的操作来应对这一挑战。它会根据用户的请求评估每个拟执行的操作,然后自动批准该操作,或将其返回给用户审查。此过程不会授予额外权限,也不会移除必需的人工审批。安全负责人可以保留对哪些操作必须始终交由人工处理的控制权,而智能审批旨在减少例行工作中的不必要打扰。
图 1:策略决定是否符合条件。智能审批会批准符合条件的操作,或将其返回给用户审查。策略拒绝的操作仍会被阻止
策略设定边界
Quick 在自动化审查之前,会根据自定义权限、Quick Guardrails、连接器操作权限以及用户的设置来评估每个拟执行的操作。被拒绝的操作仍保持拒绝状态,强制性人工审批依然适用。启用智能审批后,只有当用户设置为“每次询问”且没有其他控制要求人工审批时,该操作才符合条件。连接器操作权限在创建连接器时配置,可以对特定操作要求人工审批。
管理员使用自定义权限来决定谁可以使用智能审批。该功能默认开启,但启用了 默认拒绝 的用户档案必须显式允许它。用户也可以自行关闭智能审批。该选择适用于所有对话和计划运行。关闭后,原本符合自动审查条件的操作都需要用户审批,并且没有任何账户级设置能为其重新开启。
符合条件的操作如何被审查
智能审批使用一个单独的模型(即分类器),根据用户的请求和对话的有界视图来评估符合条件的操作。它会考虑该操作做什么、数据去向何处,以及影响谁。它可以查询用户的知识图谱,其中包含从已连接来源提取的人员和工作关系。这有助于它理解收件人与用户的关系,例如收件人是否在用户的汇报链中。此查询始终在您的 Quick 账户内进行。Quick 不会使用分类器审查的内容(包括知识图谱数据)来训练模型或改进服务。
即使操作与请求相匹配,仍可能需要人工审查。示例包括向组织外部或向用户汇报链中的高级领导发送内容、更改访问权限、删除记录或发起付款。此列表并不完整,分类器还会权衡周围的上下文。对照用户的请求审查操作,可以增加一道防范间接提示注入的检查——检索到的内容中的指令试图转移智能体的方向时就是这种情况。Quick 指示智能体和分类器将这些内容视为信息,而非指令。模型审查仍可能出错,因此必须始终获得人工批准的操作,包括那些移动敏感数据的操作,应通过连接器操作权限来要求人工批准。
分类器提供判断。权限服务执行权限。每次自动批准都是一次性的,仅适用于经过审查的确切操作和参数,不会授予持续的权限。Quick 会在对话中标注自动批准。分类器不批准的操作会返回给用户,超时和其他审查失败也是如此,它们绝不会获得自动批准。这些执行边界限制了批准所授权的范围,但并不能证明分类器的判断是正确的。
当操作超出请求范围时
一位客户经理请 Quick 使用她团队的客户记录和上一季度的电子邮件,为 AnyCompany 准备一份季度业务回顾简报。随后她请 Quick 将其发送给她指定的两位同事。假设此次发送符合自动化审查的条件,Smart Approvals 会根据她的请求和可用的对话上下文来评估拟议的操作。
现在假设某条客户记录中提到简报还应发送给一个约有 2,000 人的全销售部门通讯组列表。这会将受众更改为超出她指定的收件人范围,因此 Smart Approvals 的设计是将拟议的发送返回给她审查,她可以在审查中拒绝。针对原始收件人的批准不能被重复用于更广泛的受众。
审计证据与调查
Quick 权限服务会在您账户的 AWS CloudTrail 中记录与 Smart Approvals 相关的权限更新。每个事件都会标识用户、连接器、操作和时间,并将该请求标记为与 Smart Approvals 相关联。该标记并不能证明权限服务接受了授权或操作已运行。Quick 还会记录权限检查的裁定结果,包括来自连接器操作权限的拒绝,以及用户 Smart Approvals 设置的更改。
调查人员可以在 CloudTrail 和通过 Amazon CloudWatch Logs 交付的日志中,按用户和时间将这些事件与其他 Quick 活动关联起来。聊天日志会捕获用户的请求、系统响应和对话上下文。智能体元数据日志记录智能体的更改。来自目标系统的记录,例如已发送的电子邮件或已更新的工单,可确认操作是否完成。这些来源共同帮助重现发生了什么,而不将批准视为执行的证明。CloudTrail 事件历史记录将事件保留 90 天,因此对于更长时间的调查,请配置跟踪。由于聊天日志可能包含敏感内容,请限制访问,并考虑使用 CloudWatch Logs 数据保护策略来掩蔽敏感数据。
从哪里开始
由于 Smart Approvals 默认开启,请先确认需要人工审批的操作已通过连接器操作权限进行配置。设置 CloudTrail 跟踪,并将聊天日志和智能体元数据日志传输到 CloudWatch Logs,以支持调查。聊天日志仅记录配置交付之后的活动,因此较早的审批将缺少相应的对话上下文。在审批要求和日志配置就绪后,先使用 Custom Permissions 将 Smart Approvals 限制在一个负责特定工作流的试点团队中,然后再扩展到其他团队。
在试点之前,先定义成功的标准:例行动作的提示减少,同时重要操作仍会返回给人工审核。在试点期间,抽查一部分自动审批,并测试高影响场景,例如向组织外部发送内容或添加由文档引入的收件人。确认这些场景会返回给用户。确认你的团队能够从审批到执行对每个操作进行追踪。只有当结果符合这些标准时,才扩展到更多团队和工作流,并在操作和策略发生变化时重新评估。
有效监督的衡量标准不是智能体请求审批的频率,而是人们是否对重要决策保持控制。对于安全负责人而言,扩展 Smart Approvals 的依据应来自试点的证据。减少提示之所以有价值,是因为它在保持专注的同时不会削弱问责性。
有关设置步骤,请参阅 Amazon Quick 用户指南治理部分中的 Smart Approvals。
关于作者
来源: AWS Machine Learning Blog · aws.amazon.com
