在 HIPAA 合规环境中使用 Amazon Quick 部署 AI

医疗机构和其他企业一样，希望 AI 能带来更快的答案、更少的手工工作，以及能及时送达决策者手中、供其采取行动的洞察。然而，医疗行业的不同之处在于，其数据格外复杂、高度依赖上下文，并受到严格监管。因此，本文先给出几个定义，为后续内容奠定基础。

受保护健康信息（PHI）是指任何能够识别某人，并与其健康、护理或护理费用支付相关的信息，例如医疗记录、理赔单或会员 ID。当软件接触 PHI 时，它就受《健康保险可携性与责任法案》（HIPAA）的约束，这部联邦法律规定了 PHI 数据的访问、保护和审计方式。

智能体 AI 改变了软件“接触 PHI”的含义。传统分析工具读取数据并返回响应，而像 Amazon Quick 这样的智能体工作区可以做得更多。例如，其聊天智能体既能处理非结构化内容（如临床记录和申诉信），也能处理结构化数据（如理赔和会员记录）。智能体可以从非结构化和结构化来源检索数据，通过连接器调用其他系统，并代表用户完成多步骤任务。连接器是预先构建的集成，可让 Amazon Quick 安全地读取您的外部系统并在其中执行操作，例如 Slack、Microsoft Outlook、Salesforce、Atlassian Jira 和 Microsoft SharePoint。您还可以通过模型上下文协议（MCP）添加自己的自定义工具。只有您组织内获得授权的连接器才可见。当聊天智能体既能读取 PHI 又能对其执行操作时，您就需要足够的治理：确定性的护栏、记录智能体行为的审计跟踪，以及对在无人参与情况下所采取行动的明确问责。为支持这种治理，Amazon Quick 提供了感知 ACL 的检索、聊天与反馈日志记录，以及对每个聊天智能体可执行操作的控制。

Amazon Quick 是一项符合 HIPAA 要求的服务。此项合规适用范围涵盖 Amazon Quick 的 Web、桌面和移动客户端，前提是遵循共同责任模型并取决于您的配置。不过，本文重点介绍 Amazon Quick 的 Web 版本的功能，您可以通过浏览器访问该版本。

在本文中，我们先从基础知识入手：HIPAA 适用于谁，以及符合 HIPAA 要求与符合 HIPAA 合规之间的区别。然后，我们将 Amazon Quick 作为一个平台进行介绍，以及 PHI 的两种数据流（非结构化和结构化）。接着，我们将介绍 Amazon Quick 为受监管环境提供了什么、没有提供什么，并梳理一个虚构健康计划（AnyCompany）的部署过程，总结您应当预先做出的最佳实践和不可逆决策。最后，我们以分步实施指南、结论和深入阅读的资源收尾。

HIPAA 适用于谁？

HIPAA 的适用范围不止于医院和诊所。根据该法律，有两类组织承担相关义务，而大多数 AI 项目会同时涉及这两类。

受涵盖实体（CE）

• 健康计划 – 健康保险公司、HMO、雇主资助的计划、Medicare 和 Medicaid。
• 医疗信息交换所 – 将非标准健康信息处理为标准电子格式的组织。
• 医疗服务提供方 – 医生、诊所、医院、药房、养老院，以及任何以电子方式传输健康信息的提供方。

业务伙伴（BA）

• 业务伙伴是指受覆盖实体员工之外的任何个人或实体，其代表受覆盖实体创建、接收、维护或传输受保护健康信息（PHI）。
• 常见例子包括云服务提供商、IT 供应商、计费公司、数据分析公司、理赔处理机构、律师事务所和咨询公司。
• 代表另一个业务伙伴处理 PHI 的分包商本身就是业务伙伴。

受覆盖实体和业务伙伴在 PHI 交接之前都必须签署业务伙伴补充协议（BAA）。当您通过 AWS Artifact 接受 AWS BAA 后，AWS 将作为您该特定 AWS 账户的业务伙伴，且仅当您使用 Amazon Quick 等 HIPAA 合格服务在该账户内处理 PHI 时才生效。该补充协议不扩展到您的其他账户、不适用于存放在非 HIPAA 合格服务中的 PHI，也不涵盖您对服务的配置方式。这些仍由您自行负责。请始终与您自己的法务和合规团队一起审阅并确认当前的 AWS BAA 条款及您的义务。

HIPAA 合格不等于 HIPAA 合规

HIPAA 合格是 AWS 的一项认定，而 HIPAA 合规是您整个环境的一种属性。HIPAA 合格意味着 AWS 已评估该服务，并允许您在签署 AWS BAA 的前提下使用它来处理、存储和传输 PHI。Amazon Quick 是一项 HIPAA 合格服务，第三方审计师会根据 AWS 的 HIPAA、FedRAMP、PCI DSS、SOC 和 ISO 等合规计划对其进行评估。对于 AWS 作为云服务而言，并不存在官方的 HIPAA 认证，AWS 本身也不是“HIPAA 合格”的。

Amazon Quick 的合格性只是一个构建模块。仅凭这一点并不能使您的应用程序和环境符合 HIPAA。您仍然需要签署 BAA、对数据进行分类、正确配置控制措施，并承担 HIPAA 要求的管理性和物理性安全保障，包括 AWS 不会替您执行的员工培训、风险分析和违规事件处理程序。一项合格服务（如 Amazon Quick）、一份已签署的 BAA、正确的配置、治理机制以及您自己的安全保障措施，共同构成符合 HIPAA 的部署。Amazon Quick 的合格性意味着您可以在其上构建合规的工作流，但这并不意味着启用它就会让您自动合规。

什么是 Amazon Quick

Amazon Quick 通常通过其聊天智能体来介绍，但 HIPAA 合格性适用于整个工作区，而非单一功能，因此从平台层面审视对于合规非常重要。Amazon Quick 的所有功能均由以下构建模块组装而成：

• 聊天（Chat）是主要界面。用户可以用自然语言提出问题或下达指令，由 Amazon Quick 决定如何响应。
• 聊天智能体（Chat agents）处理每个请求。这就是您在控制台的 Chat agents 菜单下看到的内容。每个聊天智能体都可以配置指令、通过知识源进行接地（grounding），并获得采取行动的工具。Amazon Quick 提供默认聊天智能体（My Assistant），您也可以为特定领域创建自定义聊天智能体。
• 空间（Spaces）用于组织聊天智能体所需的资源，例如文档、仪表板、数据集、知识库和操作连接器。空间可以与团队共享。
• Integrations connect Amazon Quick to your environment: knowledge bases for unstructured content such as Amazon Simple Storage Service (Amazon S3), Microsoft SharePoint, and Atlassian Confluence; structured data connections that link Amazon Quick Sight to your structured databases, data warehouses, and data lakes; action connectors (built from OpenAPI specifications or Model Context Protocol servers); and extensions (Chrome, Slack, Microsoft Teams, and Microsoft 365).

  在这些构建模块之上是各项功能。依赖的模块一列对于合规至关重要，因为它显示了每项功能依赖哪些构建模块，从而依赖哪些数据路径。

注意：SPICE 是 Amazon Quick Sight 的内存查询引擎。SPICE 数据集在创建时使用账户默认的客户自主管理密钥，若要将现有数据集导入到新的默认密钥上，必须执行一次完整的刷新。如果您的数据包含 PHI，请将 SPICE 纳入您的加密策略（如果您使用了客户自主管理的 AWS Key Management Service (KMS) 密钥，请用它来保护 SPICE），并在决定导入哪些数据时考虑数据最小化原则，例如改为实时查询或加载去标识化的提取数据。

同样的资格要求、BAA、加密、访问控制和审计机制贯穿每一项功能。但正如开头所述，PHI 通过两条路径进入 Amazon Quick，且两者的保护方式不同。非结构化路径经过知识库，其中的文档由文档级 ACL 控制，并在查询时进行评估。结构化路径则通过 Amazon Quick Sight 读取您的数据库和数据湖，其中行和列的访问由行级和列级安全机制控制。这两条数据流以不同方式承载 PHI，而且正如下一节所示，每条路径上实施的控制在方式上也各不相同。

Amazon Quick 为受监管环境提供的能力

Amazon Quick 符合 HIPAA 要求，我们将阐述这在实践中意味着什么。

托管基础设施

Amazon Quick 是一项完全托管的服务。AWS 运营底层基础设施，并负责云本身的安全性，这一点由第三方审计师按照 AWS Shared Responsibility Model（AWS 共担责任模型）中的规定进行验证。

加密

Amazon Quick 默认对静态数据进行加密，并支持对传输中的数据进行加密。

• 静态数据加密默认开启，使用 AWS 拥有的密钥或 AWS 托管密钥。注册客户自主管理密钥是可选的，并非 HIPAA 的要求。如果您需要对加密密钥的直接控制，可以为参与的资源类型注册客户自主管理的 AWS KMS 密钥（需要企业版订阅），这些资源类型包括 SPICE 数据集、数据源凭证、OAuth 令牌和报告工件。在没有适用客户自主管理密钥的情况下，AWS 会使用 AWS 拥有的密钥或 AWS 托管密钥对数据进行加密。
• 需要注意的一个细节：对聊天回复的用户反馈（包括可选的自由文本评论）不会使用您的客户自主管理密钥或保护 Amazon Quick AI 索引数据的密钥进行加密。用户反馈应被视为潜在的 PHI 暴露面，并据此进行治理。
• 对于传输中的数据，Amazon Quick 使用传输层安全协议（TLS）保障加密传输。对于某些数据库连接，你可以选择是否加密传输，因此你应当在这些数据源连接上显式启用 TLS/SSL，而不是默认它始终开启。

你的数据不会用于训练模型

Amazon Quick 不会使用你的客户数据来训练或改进底层大语言模型（LLM）。

访问控制与身份联合

Amazon Quick 支持通过 AWS IAM Identity Center、Microsoft Active Directory 和 SAML 2.0 身份提供方实现基于角色的访问控制（RBAC）和单点登录（SSO）。对于商业智能（BI）工作负载，你还可以辅以行级和列级安全以及运行身份（run-as）角色，在查询时限制数据访问。借助这些能力，你可以实施唯一的用户标识和最小权限原则。

审计与监控信号

Amazon Quick 会产生几种不同的信号。它们不可互换，混淆它们是一个常见的审计疏漏。

• AWS CloudTrail 记录受支持的 API 操作以及一组有文档说明的非 API 事件，例如仪表板查看和用户管理操作。它记录的是谁在什么时间做了什么，但不包括聊天消息正文或响应内容。
• Amazon CloudWatch 提供的日志（vended logs）可将 AI 专属记录交付到你控制的目的地（CloudWatch Logs、Amazon S3 或 Firehose）。共有五种日志类型：聊天对话（CHAT_LOGS）、用户反馈（FEEDBACK_LOGS）、智能体与研究时长（AGENT_HOURS_LOGS）、索引存储用量（INDEX_USAGE_LOGS），以及知识库文件同步（KB_FILE_SYNC_LOGS）。“用户问了什么、Amazon Quick 回答了什么”就记录在这里，而不是在 CloudTrail 中。
• CloudWatch 指标和警报也提供准实时的运营监控。
• 分析仪表板为管理员展示使用和采用情况。请注意，在负面反馈审查的范围内，它可能会暴露详细的查询文本和完整的对话上下文，因此应仅向获得授权的管理员授予访问权限。

由于聊天日志和反馈可能包含受保护健康信息（PHI），请应用 CloudWatch Logs 数据保护脱敏，并在依赖某个信号用于合规之前，确认它确实覆盖了你要跟踪的事件。

将功能转化为 HIPAA 控制措施

Amazon Quick 是一项合格服务，这一点很有用，因为它将每项功能映射到特定的 HIPAA 安全保障措施，如下表所示：

Amazon Quick 不做的事情

虽然 Amazon Quick 提供了上述控制措施，但本节讨论的是 Amazon Quick 未涵盖的内容以及如何弥补这一差距。Amazon Quick 管控访问、检索和交互，它并不是数据工程或数据湖治理平台。在 HIPAA 场景下，有几项需求超出了 Amazon Quick 的范围，需要由位于其上游的其他 AWS 服务来满足。

• 去标识化与数据转换。Amazon Quick 不会对 PHI 进行去标识化处理，也不会重塑源数据。当您的用例需要受限数据集或去标识化提取数据时，应在数据进入 Amazon Quick 之前，使用合适的 AWS 服务进行准备，例如使用 AWS Glue DataBrew（AWS Glue 的一项功能）进行可视化数据准备和脱敏，或使用 AWS Glue 构建提取、转换和加载（ETL）管道。
• 数据湖治理与细粒度表权限。对于 Amazon Quick Sight 通过数据湖查询的结构化数据，数据湖本身的列级和行级治理是 AWS Lake Formation 的职责，而非 Amazon Quick。Amazon Quick Sight 在分析层实施自己的行级和列级安全控制，但权威的湖级授权保存在 Lake Formation 和 AWS Glue Data Catalog 中。
• 管理与物理层面的安全保障。员工培训、风险分析和泄露处理流程无论使用何种工具，仍然是您自己的责任。

一个通用的最佳实践是明确划分职责，让上游服务来决定哪些数据存在以及谁可以在源端查询这些数据；而让 Amazon Quick 决定谁可以向它提问，以及智能体可以对数据做什么。

AnyCompany Health Plan：一个示例用例

AnyCompany Health Plan 是一家虚构的健康保险公司，我们用它来说明一个用例和模式。AnyCompany Health Plan 是一家受保护实体，它有两个需求：让护理管理团队能够用自然语言查询保单和会员申诉文档，并让运营负责人通过自助仪表板查看理赔数据。两者都涉及 PHI，因此 AnyCompany 需要确认解决方案符合 HIPAA。AnyCompany 的环境有两条数据路径，每条路径在 Amazon Quick 访问数据之前，都由不同的解决方案进行架构设计和治理。

非结构化路径（保单和医疗记录文档）

→ Amazon S3 存储桶（支持 ACL 的知识库源）

→ Amazon Quick 知识库（文档级 ACL，查询时默认拒绝）

结构化路径（理赔）

所有理赔数据目前都存放在一个湖（Amazon S3）中。

→ Glue ETL（数据加工）→ Glue DataBrew（去标识化）

→ Lake Formation（行/列级授权和 AWS Glue Data Catalog）

→ Amazon Quick Sight 数据集（Amazon Athena）（行级和列级安全，以运行角色执行）

上述结构化和非结构化数据的两条数据流最终汇入一个 Amazon Quick 聊天智能体，该智能体配置了联合 SSO、最小权限空间、防护栏以及 CloudWatch 交付日志。

以下是 AnyCompany 的管理员实施该解决方案的步骤：

1. 通过 AWS Management Console 签署 BAA 并完成预配。管理员在 AWS Artifact 中代表该 AWS 账户接受 AWS BAA，然后通过 AWS Management Console 使用 IAM Identity Center 预配 Amazon Quick。AnyCompany 将协议 ID、时间戳和账户记录在其合规登记册中。只有通过 AWS Management Console 预配的 Amazon Quick 网页版才能通过 AWS Artifact 纳入已签署的 BAA，这是构建涉及 PHI 的 HIPAA 合规工作流的客户所必需的组成部分，前提是进行正确的配置并履行客户自身的合规责任。
2. 在第 0 天设置不可逆的控制措施。由于 AnyCompany 的安全政策要求控制自己的加密密钥，管理员选择在任何 Amazon Quick AI 数据创建之前，将客户自主管理密钥注册为账户默认密钥。数据密钥只能设置一次，之后无法更改。（默认的 AWS 托管加密同样符合 HIPAA 要求。使用客户自主管理密钥并不是该服务符合 HIPAA 的前提条件。）管理员还将身份模型确定为 IAM Identity Center，以便启用不活跃用户检测。Amazon Quick 数据密钥在首次创建数据时设置一次，此后永远无法更改。如果密钥被删除，唯一的恢复方法是退订并重新订阅，这将永久删除所有 Amazon Quick 数据。
3. 在 Amazon Quick 之外准备结构化路径。在 Amazon Quick Sight 处理理赔数据之前，AnyCompany 的数据团队使用 AWS Glue 构建经过整理的理赔表，并使用 Glue DataBrew 为运营仪表板生成去标识化的数据提取。AWS Lake Formation 通过 AWS Glue Data Catalog 对这些表授予行级和列级访问权限。因此，Amazon Quick 永远不会看到它不需要的原始 PHI。
4. 为文档创建支持 ACL 的知识库。管理员将政策与申诉 S3 存储桶连接为知识库，并在创建时启用文档级 ACL。由于 ACL 无法在之后开启，因此需要在创建 S3 存储桶时进行配置。Amazon Quick 会在查询时评估每个用户的身份，在无法确认访问权限时不返回任何文档。
5. 构建专属空间和自定义聊天智能体。AnyCompany 创建了一个成员受限的 PHI 空间，与通用生产力空间分开。护理管理聊天智能体的作用范围仅限于支持 ACL 的知识库，禁用了开放式网络搜索，并配置了防护机制。对于任何与 PHI 相关的内容，都实现了只读连接器。
6. 通过查询时安全机制连接仪表板。运营仪表板通过 Athena 读取去标识化的 Amazon Quick Sight 数据集，在 Lake Formation 授权之上叠加 Amazon Quick Sight 行级和列级安全性以及运行身份（run-as）角色。
7. 在引入用户之前开启审计信号。管理员创建 CloudTrail 跟踪，并配置 CloudWatch 托管日志投递（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS 等）到保留且脱敏的目标位置。反馈被视作 PHI 暴露面。
8. Validate, then scale from non-PHI to PHI. AnyCompany starts with non-PHI workflows, such as policy Q&A and document search, to confirm governance, tests with adversarial prompts to verify fail-closed ACL behavior, reviews the logs to confirm the events are captured, and only then expands the care-management team into PHI-adjacent work.

   Amazon Quick 负责实施身份验证、检索、防护栏和审计跟踪。但去标识化、ETL 以及湖级别的授权发生在上游的 Glue、Glue DataBrew 和 Lake Formation 中。这种分工是推荐的模式，也是在联邦环境中增强 Amazon Quick 的实用方案。

如何实现合规：最佳实践

资格认证为你提供一个能够处理 PHI 的平台。你仍然必须进行配置，使其真正做到这一点。

本节帮助你理解其中涉及的共担责任决策。由于其中一些决策是不可逆的，请在创建资源或接入用户之前做出这些决策。

从智能体 AI 的安全模型入手

Amazon Quick 智能体不会在每一步都等待指令。它们会自行调用工具、修改数据并与外部系统交互。这改变了你保护环境的方式。AWS 于 2026 年 4 月发布了面向智能体 AI 的四项安全原则，这些原则在这里同样直接适用。

原则 1 — 将智能体防护措施叠加到现有安全框架之上。不要为 Amazon Quick 建立一套平行的安全态势。在你已经实施的 IAM、网络和加密策略之上，添加针对智能体的措施（防护栏、主题屏蔽和 PII 脱敏）。

原则 2 — 相比基于提示词的控制，更信任确定性控制。 一条精心构造的对抗性输入可以绕过提示词指令。AWS Identity and Access Management (IAM) 策略、文档级 ACL、网络边界以及管理员配置的防护栏无法通过花言巧语绕过。请将这些作为你的主要执行手段。智能体指令是你的第二层防护，而不是唯一的防护。

原则 3 — 在感知、推理和行动三个环节实施纵深防御。 将智能体的每项能力映射到以下三层之一：

• 感知： 知识库、上传的文件、网络搜索、连接器输入、MCP 工具输出。
• 推理： 处理上下文的 LLM，由防护栏和主题控制进行约束。
• 行动： 连接器、Quick Flows、Quick Automate、计划任务、MCP 工具调用。

在每一层独立实施控制。某一层的缺口不应级联影响到其他层。

请注意，HIPAA BAA 义务延伸至 MCP 工具等支持性服务和解决方案。

原则 4 — 逐步扩展自主性。 让智能体先以只读模式处理非 PHI 数据。每次只添加一项能力。在进入下一步之前，在每一步测试数据泄露、提示词注入抵御能力和权限边界遵守情况。

部署前先做决策

由于这三项选择是永久性的，请在实施之前做出这些决策。

首先注册你的 KMS 密钥。 如果你的组织要求掌控自己的加密密钥，请在创建任何 Amazon Quick AI 资源之前，将客户托管密钥注册为账户默认密钥。数据密钥在该账户中首次创建 Quick AI 数据时设定，此后无法更改。客户托管密钥支持需要 Enterprise 订阅。请注意，使用客户托管密钥会禁用聊天记忆。配置了客户托管密钥的账户不支持该功能。

慎重选择你的身份模型。你有四个选项：IAM Identity Center、Active Directory、IAM 联合身份和 Quick 本地用户。它们在预置配置、离场处理和治理行为上各不相同。例如，非活跃用户检测只支持 IAM Identity Center 或 Active Directory。部署后再切换身份提供商意味着要重新预置每个用户的权限和空间成员资格。一次性选定。

在创建时就让 PHI 知识库启用 ACL 感知。对于受支持的数据源（Amazon S3、Google Drive、SharePoint、Confluence Cloud 和 OneDrive），你需要在创建时决定该知识库是否强制执行文档级 ACL。该设置是永久性的。你无法为创建时未启用 ACL 的知识库再启用 ACL。对于任何涉及 PHI 的场景，请从一开始就创建为 ACL 感知的知识库。

警告：用户存储映射配置错误可能会在不报错、不告警的情况下，悄悄地把受限文档暴露给错误的用户。在摄取 PHI 内容之前，务必验证你的身份与 ACL 的映射关系。

AWS 区域、网络和账户边界

请基于以下因素规划部署区域：

• 数据驻留：Amazon Quick 在你预置它的区域中处理和存储数据，你需要确认该区域满足组织的数据本地化要求。注意 Amazon Quick 是单区域服务：它在区域内具备多可用区韧性，但不会跨区域进行故障转移。如果你支持的业务关键型工作流需要跨区域韧性，请在第二个区域预置一套独立的 Amazon Quick 部署及其配套数据，例如跨区域复制基于 S3 的知识库数据源。
• 服务可用性。不同功能有时会在不同区域、不同时间推出。请验证智能体所需的一切（如知识库、连接器和 Amazon Quick Sight 功能）在你计划部署的位置均可用。
• 多账户策略。将 Amazon Quick 放在 AWS Organizations 中一个专用的工作负载账户里。使用服务控制策略（SCP）来强制执行区域限制，并阻止在范围外区域的意外预置。

关于网络边界：Amazon Quick 是一项通过 HTTPS 访问的托管服务。你不需要将其部署到虚拟私有云（VPC）中。但你的数据源（S3 存储桶、数据库、本地系统）可能位于 VPC 边界之内。在可用之处使用 VPC 终端节点和 AWS PrivateLink。确保 DNS 解析和防火墙规则允许 Amazon Quick 的连接器访问你授权的数据源，同时不将网络开放范围扩大到不必要的程度。

最小化智能体的攻击面

Amazon Quick 自身的文档将对抗性风险描述为一个双条件问题：当 (1) 智能体能够读取你的信任边界之外的内容，且 (2) 它能采取有实质影响的操作时，风险即存在。缩小任一条件即可降低暴露面。

限制智能体可读取的内容（感知层）。了解为智能体提供上下文的每一个来源：知识库、上传的文件、网络搜索、第三方研究提供商、连接器响应、MCP 工具输出以及保留的对话记忆。对于 PHI 工作流：

• 将智能体的范围限定在受信任的、ACL 感知的知识库内。
• 在不需要的地方关闭开放式网络搜索。
• 如果智能体不需要，请关闭文件上传功能。
• 将对话历史保留时间限制在最小可用窗口。

限制智能体能做什么（Act 层）。清点所有出站路径：连接器、MCP 工具、网络查询、Quick Flows、Quick Automate 工作流、定时运行的智能体。对于涉及 PHI 的智能体：

• 优先使用只读的连接器访问权限。
• 谨慎对待自动化和定时工作流，因为它们在无人监督的情况下运行。
• 除非有明确理由并获得安全团队的批准，否则阻止写入操作。
• 使用连接器级别的权限范围限制，以约束智能体可以调用哪些操作。

了解操作以什么身份运行。按需操作以发起调用的用户身份进行身份验证，并受该用户的连接器权限约束。自动化工作流则在没有交互会话的情况下运行。将自主级别与操作的敏感度相匹配，并记录哪些智能体以哪种身份模式运行。

实施最小权限原则和数据隔离

• 将包含 PHI 的知识库和空间与通用生产力类知识库和空间分开，并限制成员资格。
• 按需知情原则授予空间和智能体访问权限。同时审查共享权限（谁可以使用知识库）和源文档 ACL（经授权的用户实际能检索哪些已索引的文档）。
• 默认的知识库刷新周期为 24 小时。当您的访问变更要求要求更快的传播速度时，请缩短该周期。在重新分配或回收电子邮件地址之前，先刷新 ACL。
• PHI 智能体不应与通用生产力工具共享同一个空间。这意味着您需要在空间层面隔离用例。
• 定期审查连接器权限。按照与您的凭证管理策略相匹配的时间表轮换存储在 AWS Secrets Manager 中的凭证。

实践数据最小化

AWS 建议不要在资源名称或标签中输入机密数据，以避免在账单或诊断日志中被意外提及。

• 只要用例允许，优先使用去标识化的数据。
• 在从数据库或 API 摄取结构化数据时，先在源头过滤列和行，然后再进行索引。
• 配置智能体防护栏（guardrails），使用内置的 PII 检测过滤器对响应中的 PII 进行脱敏，隐藏社会安全号码（SSN）、病历号（MRN）和出生日期。

配置审计日志记录与保留

Amazon Quick 提供了几种不同的审计信号。它们默认都不会流转，您可能需要手动开启。

以下是设置它们的方法：

1. 为相关账户和区域创建 CloudTrail 跟踪。
2. 在开启 Amazon Quick 的 AI 功能后不久，配置 CloudWatch 托管日志交付（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS）。
3. 对聊天日志应用 CloudWatch Logs 数据保护掩码，确保 PHI 不会以明文形式存储。
4. 设置至少六年的保留期限。考虑对日志归档使用 S3 Object Lock。
5. 为异常活动添加 CloudWatch 告警。
6. 启用 AWS Security Hub 以进行持续合规检查。
7. 将关键告警路由到您的安全信息与事件管理（SIEM）平台或事件响应平台。

扩大规模之前先验证

在扩展范围之前，请检查以下各项：

• BAA 接受情况已记录在您的合规登记册中。
• 数据分类已记录在案：哪些知识库和空间包含 PHI，哪些智能体可以访问它们。
• 对抗性查询和提示词注入场景已经过测试。
• 日志正在被捕获，且脱敏功能正常工作。
• 已完成一次桌面推演式泄露演练。
• InfoSec 已签字批准。

已知限制

以下是 Amazon Quick 的一些已知限制。

• Free 或 Plus 路径不提供 BAA。您必须使用通过 AWS Management Console 开通的路径才能获得 BAA 保障。
• 不支持跨区域复制。灾难恢复（DR）仅限于单一区域。
• 防护栏是概率性的，而非确定性的。它们可以降低风险，但不能消除风险。请辅以先前所述的基础设施级控制措施。
• 第三方连接器会扩展您的 BAA 义务。当连接器将数据发送到外部系统时，您的合规责任会随数据而延伸。
• 对话记忆可能包含回显的 PHI。请设置保留策略并应用脱敏。

实施指南

AnyCompany Health Plan 示例展示了如何推出 Amazon Quick。本节将该模式转化为一份分步项目计划，您可以将其交给您的平台团队。

步骤 1：签署 BAA（第 1 天）

• 使用 AWS Artifact 权限登录并接受 BAA。
• 记录协议 ID、时间戳、主体 ARN 和账户 ID。
• 通知您的法律和合规团队。

步骤 2：设置基础性、不可逆的控制措施（第 1–2 天）

• 将一个客户托管密钥注册为账户默认密钥。
• 验证密钥策略授予了所需权限：Encrypt、Decrypt、GenerateDataKey、DescribeKey。
• 配置您的身份模型（推荐使用 IAM Identity Center）。
• 确认该账户位于具有区域限制 SCP 的专用工作负载组织单位（OU）中。

步骤 3：创建支持 ACL 的知识库（第 3–7 天）

• 对您的数据源进行分类：PHI、PHI 相关和非 PHI。
• 为 PHI 和 PHI 相关数据源创建开启了 ACL 感知的知识库。
• 将身份存储映射到数据源权限，并使用多个测试用户进行验证。
• 确认同步日志显示成功摄取。将 PHI 知识库与一般内容分开。

步骤 4：创建空间（第 5–8 天）

• 将 PHI 相关空间与一般生产力空间分开。
• 附加知识库、仪表板和操作连接器。限制成员资格。
• 确认未经授权的用户被阻止访问。

步骤 5：创建带防护栏的自定义智能体（第 7–12 天）

• 将每个智能体的用途定义得足够窄。仅附加其所需的知识来源。
• 配置 PII 脱敏、被阻止的主题、内容过滤器和接地控制。
• 使用常规查询、边界查询和对抗性提示词进行测试。
• 记录结果和整改步骤。

步骤 6：配置操作连接器（第 10–14 天）

• 对 PHI 相关数据先从只读模式开始。将每个连接器的范围限定在特定资源。
• 将凭证存储在 AWS Secrets Manager 中并开启轮换。
• 记录任何写权限的理由。在开启之前获得安全团队签字批准。
• 测试范围限制，确认连接器无法访问超出其预期范围的资源。

步骤 7：配置审计、保留和监控（第 12–16 天）

• 启用 CloudTrail 和 CloudWatch vended 日志。
• 应用数据保护脱敏。将保留期限设置为至少六年。启用 S3 Object Lock。
• 配置告警，启用 Security Hub，并与你的 SIEM 集成。

第 8 步：与信息安全团队进行验证（第 14–21 天）

• 整理证据包：BAA 确认文件、KMS 配置、身份设置、数据分类、测试结果和日志样本。
• 进行一次桌面推演式数据泄露演练。
• 向你的信息安全团队汇报。整改发现的问题。获得签字批准。

扩展阶段（第 4–8 周）

从非 PHI 工作流开始：政策问答、文档搜索、会议准备、工作流自动化。这些工作流可以让你的团队在 PHI 进入之前建立对该平台的信心。

然后扩展到与 PHI 相关的工作流：临床文档辅助、理赔处理、事先授权、法规问答，以及在人工审核参与下的患者沟通起草。

密切监控：每周审查聊天日志，跟踪防护栏触发率，并在每个新工作流上线后的 30 天内关注访问模式。

结论

Amazon Quick 为受监管的医疗健康机构以及为其服务的业务伙伴提供了一个托管式 AI 工作区，其全部功能范围均符合 HIPAA 要求：智能体 AI、知识检索、商业智能、自动化和研究。

实现合规部署的路径遵循一个清晰的顺序：

1. 理解“符合条件”与“合规”之间的区别，并承担共同责任中属于你的那一部分。
2. 在通过 AWS 管理控制台预置的账户上签署执行 BAA。
3. 首先设置不可逆的控制项：KMS 密钥、身份模型、具备 ACL 感知能力的知识库。
4. 最小化智能体的读取和操作范围，强制实施最小权限原则，并在日志中对 PHI 进行脱敏。
5. 与你的信息安全团队进行验证，然后从非 PHI 工作流扩展到与 PHI 相关的工作流。

合规要求正与技术一样快速演进。AWS 于 2026 年 4 月发布了面向智能体 AI 的四项安全原则，并于 2026 年 6 月发布了 Well-Architected Agentic AI Lens（卓越架构智能体 AI 视角）。今天就在确定性基础设施级控制之上进行构建的组织，当监管预期赶上智能体 AI 的能力时，很可能已经处于有利位置。

接下来该做什么

如果你正在评估 Amazon Quick：请向你的 AWS 客户团队申请一次以合规为重点的简报。询问 BAA 的覆盖范围、智能体 AI 的共同责任，以及最新符合 HIPAA 要求的新增服务。

如果你已准备好部署：请将实施指南用作你的项目计划。第 2 步中的不可逆决策值得在你开始创建资源之前进行专门的架构评审。

如果你已经在运行 Amazon Quick：请对照本文中的最佳实践审计你的部署，尤其是智能体安全原则和已知限制清单。

如需架构指导，请联系你的 AWS 解决方案架构师或 AWS 医疗健康与生命科学团队。

关于作者