生成式人工智能安全范围矩阵

从法律角度来看，了解服务提供商的最终用户许可协议（EULA）、服务条款（TOS）以及在范围 1 到 4 内使用他们的服务时必须遵守的任何其他合同协议非常重要。对于范围 5，您的法律团队应当为模型的任何外部使用行为提供他们自己的服务合同条款。此外，对于范围 3 和范围 4，请务必验证服务提供商为他们的服务设定的法律使用条款，以及模型提供商为他们在此服务内提供的模型设定的法律使用条款。

此外，如果欧盟的《通用数据保护条例》（GDPR）的“删除权”或“被遗忘权”要求适用于您的企业，请考虑隐私问题。仔细考虑利用可能需要应要求删除的数据对模型进行训练或微调时产生的影响。从模型中移除数据的唯一一种完全有效的方法是从训练集内删除数据并训练新版本的模型。当要删除的数据量只占全部训练数据的一小部分时，这种做法不切实际，而且根据模型的大小，代价可能非常高昂。

虽然由人工智能提供支持的应用程序与传统的应用程序相似，但它们会与大型语言模型（LLM）进行交互，因此应当对它们格外警惕并设置特定的护栏。识别与生成式人工智能工作负载相关的风险并开始缓解这些风险至关重要。

通常可以利用风险评估和威胁建模来完成风险识别。对于范围 1 和 2，评估来自第三方提供商的风险，并了解他们的风险缓解策略。作为服务使用者，您还必须认识到自己的风险管理责任。

对于范围 3、4 和 5，实施威胁建模，以解决人工智能安全风险和数据安全风险，并重点关注即时注入等独特的 LLM 威胁。这包括生成可以操纵 LLM 响应的输入，这样可能导致数据泄露或未经授权的访问。NIST、MITRE 和 OWASP 提供的最新指导将即时注入确定为一种主要威胁，与 SQL 等传统注入攻击不相上下。通过在风险到达 LLM 之前应用精细授权和数据筛选来缓解这种风险，并使用 Bedrock Guardrails 提供额外的保护。

生成式人工智能中的新兴威胁要求调整传统的网络安全措施，并与开发团队密切合作，以便有效地对威胁进行建模并确立量身定制的最佳实践。

实施强有力的控制措施对于执行合规性、政策和安全要求至关重要，因此能够降低与生成式人工智能工作负载相关的风险。关键考虑因素之一是管理对模型的身份和访问权限。 与提供精细安全控制的传统数据库不同，基础模型没有对存储在模型内的数据或推理时提供的数据实施访问控制这一概念。因此，在将数据作为上下文添加到推理请求之前，必须对数据实施最低权限访问控制。

为了实现这一目标，您可以利用通过 Amazon Bedrock 等端点与模型进行交互的应用程序层。这些层应当整合 Amazon Cognito 或 AWS IAM Identity Center 等身份解决方案，以便对用户进行身份验证和授权。通过根据角色、属性和用户社区定制访问权限，您可以限制特定的操作并帮助确保敏感数据受到保护。

此外，随着人工智能工作负载的演变，必须不断评估并更新控制措施，以适应新的威胁和数据敏感度的变化。采用检索增强生成（RAG）等高级技术，可以在不影响模型完整性的情况下提供实时数据。这些策略与持续的威胁建模相结合，可以帮助为您的生成式人工智能应用程序维持安全、合规的环境。 

正如 C.I.A. triad 中指出的那样，可用性是安全性的一个关键组成部分。构建弹性应用程序对于满足贵组织的可用性和业务连续性要求至关重要。对于范围 1 和 2，您应了解提供商的可用性如何与贵组织的需求和期望保持一致。仔细考虑当由于底层模型、API 或表示层不可用而导致中断时，会对您的企业产生哪些影响。此外，还要考虑复杂的提示和补全操作可能如何影响使用配额，或者应用程序可能对账单产生哪些影响。

对于范围 3、4 和 5，请确保设置适当的超时时间，以应对复杂的提示和补全。您还可能希望查看模型定义的分配字符限制的提示输入大小。还要考虑弹性设计的现有最佳实践，例如回退和重试以及断路器模式，以实现所需的用户体验。使用向量数据库时，建议使用高可用性配置和灾难恢复计划，以便能够弹性应对不同的故障模式。

除了可能为极其关键的工作负载预留或预置计算以外，推理和训练模型管道的实例灵活性也是重要的架构考虑因素。如果使用 Amazon Bedrock 或 SageMaker 等托管式服务，当实施多区域部署策略时，必须验证 AWS 区域的可用性和功能一致性。同样，为了获得对范围 4 和 5 工作负载的多区域支持，您必须考虑跨区域微调或训练数据的可用性。如果您使用 SageMaker 在范围 5 中训练模型，请在训练模型时使用检查点来保存进度。必要时，这样可以从上次保存的检查点恢复训练。

请务必审查并实施在 AWS 韧性监测中心中以及架构完善的框架的可靠性支柱和卓越运营支柱内确立的现有应用程序弹性最佳实践。