Amazon Quick 如何部署在符合 HIPAA 资格的环境中

医疗机构希望从 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 网页版、桌面版和移动客户端，但须遵循共同责任模型并正确配置。不过，本文重点介绍通过浏览器访问的 Amazon Quick 网页版功能。

本文将从基础内容讲起：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 不会代你执行的员工培训、风险分析和违规事件处理流程。符合 HIPAA 资格的服务（如 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).

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

注意：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 共同责任模型对其进行验证。

加密

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

• 默认情况下，静态加密处于启用状态，使用 AWS 拥有或 AWS 管理的密钥。注册客户托管密钥是可选操作，并非 HIPAA 要求。如果您需要直接控制加密密钥，可以为支持的资源类型注册客户托管的 AWS KMS 密钥（需要 Enterprise 订阅），包括 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）工作负载，你可以通过行级和列级安全性以及运行身份角色进一步限制查询时的数据访问。借助这些功能，你可以实施唯一用户标识和最小权限原则。

审计与监控信号

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 是受 HIPAA 约束的实体，希望实现两项目标：让其护理管理团队能够用自然语言查询保单和会员申诉文档，并为运营主管提供自助式理赔数据控制面板。两者都涉及 PHI，因此 AnyCompany 需要确认该解决方案符合 HIPAA 要求。AnyCompany 的环境包含两条数据路径，在 Amazon Quick 访问数据之前，每条路径都通过不同的解决方案进行架构设计和治理。

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

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

→ Amazon Quick Knowledge Base（文档级 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 管理控制台进行预置。管理员在 AWS Artifact 中代表 AWS 账户接受 AWS BAA，然后通过 AWS 管理控制台使用 IAM Identity Center 预置 Amazon Quick。AnyCompany 在其合规登记簿中记录协议 ID、时间戳和账户。只有通过 AWS 管理控制台预置的 Amazon Quick Web 版本，才能通过 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。你仍必须对其进行配置，确保它确实能够处理 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 导入结构化数据时，应在编入索引前于数据源处筛选列和行。
• 配置代理护栏，在响应中隐藏社会保障号码（SSN）、医疗记录号码（MRN）和出生日期，并使用内置的 PII 检测筛选器来编辑 PII。

配置审计日志记录和保留

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）。
• 确认账户位于专用工作负载组织单位（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 步：与 InfoSec 团队验证（第 14–21 天）

• 整理证据材料包：BAA 确认、KMS 配置、身份设置、数据分类、测试结果和日志样本。
• 开展桌面推演式数据泄露演练。
• 向 InfoSec 团队进行汇报。修复发现的问题。获取签字批准。

扩展阶段（第 4–8 周）

从非 PHI 工作流入手：政策问答、文档搜索、会议准备、工作流自动化。这些工作流能让团队在涉及 PHI 之前，先建立对平台的信心。

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

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

结论

Amazon Quick 为受监管的医疗保健机构及其服务的业务伙伴提供托管式 AI 工作空间，其全部功能均符合 HIPAA 资格要求，包括智能体 AI、知识检索、商业智能、自动化和研究。

实现合规部署的路径遵循清晰的步骤：

1. 了解符合资格与合规之间的区别，并承担自身在共同责任模型中的责任。
2. 通过 AWS Management Console 配置的账户签署 BAA。
3. 首先设置不可逆的控制措施：KMS 密钥、身份模型、支持 ACL 的知识库。
4. 尽量缩小智能体的读取和操作范围，强制执行最小权限原则，并在日志中屏蔽 PHI。
5. 与 InfoSec 团队完成验证，然后从非 PHI 工作流扩展到与 PHI 相邻的工作流。

合规要求的变化速度与技术发展一样快。AWS 于 2026 年 4 月发布了面向智能体 AI 的四项安全原则，并于 2026 年 6 月发布了Well-Architected 智能体 AI 透镜。如今基于确定性基础设施级控制措施进行构建的组织，很可能会在监管要求跟上智能体 AI 的能力时做好充分准备。

接下来该怎么做

如果你正在评估 Amazon Quick：向 AWS 客户团队申请以合规为重点的情况介绍。询问 BAA 范围、智能体 AI 方面的共同责任，以及最新新增的符合 HIPAA 资格的服务。

如果你准备部署：将实施指南用作项目计划。开始创建资源前，应针对第 2 步中的不可逆决策开展专项架构评审。

如果你已经在运行 Amazon Quick：依据本文中的最佳实践审核部署，尤其要关注智能体安全原则和已知限制清单。

如需架构指导，请联系你的 AWS 解决方案架构师或 AWS Healthcare and Life Sciences 团队。

作者简介

Meena Menon

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

Shailesh Doshi

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