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