如何在 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 资格的服务，第三方审计机构依据包括 HIPAA、FedRAMP、PCI DSS、SOC 和 ISO 在内的 AWS 合规计划对其进行评估。AWS 作为云服务并不存在官方的 HIPAA 认证，AWS 本身也不“符合 HIPAA 资格”。

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

什么是 Amazon Quick

Amazon Quick 通常通过其聊天代理为人所知，但 HIPAA 资格适用于整个工作区，而非单一功能，因此从平台层面审视对合规至关重要。Amazon Quick 的所有能力均由以下构建模块组成：

• 聊天是主要界面。用户可以用自然语言提出问题或给出指令，由 Amazon Quick 决定如何响应。
• 聊天代理处理每一个请求。这就是你在控制台 Chat agents 菜单下看到的内容。每个聊天代理都可以配置指令、以知识源为依据，并配备用于执行操作的工具。Amazon Quick 自带一个默认聊天代理（My Assistant），你也可以为特定领域创建自定义聊天代理。
• 空间用于组织聊天代理所需的资源，例如文档、仪表板、数据集、知识库和操作连接器。空间可以与团队共享。
• 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).

  在这些构建模块之上是各项功能。What it draws on（所依赖的构建模块）一列对合规性很重要，因为它显示了每项功能依赖哪些构建模块，从而依赖哪些数据路径。

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

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

Amazon Quick 为受监管环境提供的支持

Amazon Quick 符合 HIPAA 资格，我们概述了这在实践中意味着什么。

托管基础设施

Amazon Quick 是一项完全托管的服务。AWS 运营底层基础设施，并负责云的安全，这一点已由第三方审计机构依据 AWS 共享责任模型进行验证。

加密

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

• 静态数据加密默认启用，使用 AWS 自有或 AWS 托管密钥。注册客户托管密钥是可选的，并非 HIPAA 要求。如果你需要对加密密钥进行直接控制，可以为参与的资源类型（包括 SPICE 数据集、数据源凭证、OAuth 令牌和报告产物）注册客户托管的 AWS KMS 密钥（需要 Enterprise 订阅）。在不适用客户托管密钥的情况下，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 提供的日志会将 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. 签署 BAA 并通过 AWS Management Console 进行配置。管理员在 AWS Artifact 中针对该 AWS 账户接受 AWS BAA，然后通过 AWS Management Console 使用 IAM Identity Center 配置 Amazon Quick。AnyCompany 在其合规登记册中记录协议 ID、时间戳和账户。只有通过 AWS Management Console 配置的 Web 版 Amazon Quick 才能通过 AWS Artifact 纳入已签署的 BAA 范围，这是客户构建涉及 PHI 的 HIPAA 合规工作流的必要组成部分，前提是配置得当且客户履行自身的合规责任。
2. 在第零天设置不可逆的控制项。由于 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 的行级和列级安全以及运行身份角色。
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 工具、Web 查询、Quick Flows、Quick Automate 工作流、定时智能体运行。对于涉及 PHI 的智能体：

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

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

实施最小权限和数据隔离

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

践行数据最小化

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

• 在用例允许的情况下，优先使用去标识化数据。
• 从数据库或 API 摄取结构化数据时，在索引之前先在源头过滤列和行。
• 配置智能体护栏，使用内置的 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，哪些代理可以访问它们。
• 对抗性查询和提示注入场景已经过测试。
• 日志正在被采集，且掩码功能正常工作。
• 桌面推演式的泄露演练已经完成。
• 信息安全团队已签字确认。

已知限制

以下是 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）。
• 确认该账户位于专用工作负载组织单位（OU）中，并带有区域限制 SCP。

第 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 提供的日志。
• 应用数据保护脱敏。将保留期设置为至少六年。启用 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 Management Console 开通的账户上执行 BAA。
3. 先设置不可逆的控制项：KMS 密钥、身份模型、感知 ACL 的知识库。
4. 最小化代理的读取和操作范围，强制执行最小权限，并在日志中对 PHI 进行脱敏。
5. 与你的信息安全团队一起验证，然后从非 PHI 工作流扩展到与 PHI 相邻的工作流。

合规期望的变化速度与技术的发展速度一样快。AWS 于 2026 年 4 月发布了针对代理式 AI 的四项安全原则，并于 2026 年 6 月发布了Well-Architected 代理式 AI 透镜。如今基于确定性、基础设施级控制构建的组织，很可能在监管期望赶上代理式 AI 能力时处于有利位置。

下一步行动

如果你正在评估 Amazon Quick：向你的 AWS 客户团队申请一次以合规为重点的简报。询问 BAA 范围、代理式 AI 的共享责任，以及最新的符合 HIPAA 资格的服务新增项。

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

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

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

关于作者

Meena Menon

Meena 是 AWS 的高级客户成功经理，拥有超过 20 年交付企业客户成果和推动数字化转型的经验。在 AWS，她与安全、可观测性和医疗健康领域的战略 ISV 合作，帮助他们在 AWS 上启动和扩展 AI 工作负载。她拥有深厚的跨行业经验，与这些 ISV 并肩合作，加速云采用、实现平台现代化，并将新兴技术转化为可衡量的业务影响。

Shailesh Doshi

Shailesh 是 AWS 的高级客户解决方案经理，拥有超过 30 年跨多个行业垂直领域的经验，帮助组织将云和 AI 投资转化为可衡量的业务价值。目前，他专注于医疗保健与生命科学领域，与医疗服务提供方、支付方和生命科学创新者合作，实现其战略目标，并通过人工智能、机器学习和分析释放企业价值，推动 GenAI 采用率的多倍增长。Shailesh 与高管和技术团队并肩合作，加速 GenAI 投资、推动采用，并实现关键任务平台的现代化。