在 HIPAA 适用环境中部署 Amazon Quick

#在 HIPAA 适用环境中部署 Amazon Quick

医疗机构希望从人工智能（AI）得到的东西，和其他企业一样：更快的答案、更少的手工工作，以及能及时送达决策者并据以行动的洞察。医疗行业的不同之处在于，数据格外复杂、高度依赖上下文，并且受到严格监管。因此，本文先给出若干定义，作为后文的基础。

受保护健康信息（Protected Health Information，PHI）是任何能够识别个人、并与其健康、诊疗或诊疗支付相关的信息，例如病历记录、理赔单或会员编号。当软件接触 PHI 时，就落入《健康保险流通与责任法案》（Health Insurance Portability and Accountability Act，HIPAA）的范围。该联邦法律规范 PHI 如何被访问、保护和审计。

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

Amazon Quick 是一项符合 HIPAA 适用资格（HIPAA-eligible）的服务。该资格覆盖 Amazon Quick 的 Web、桌面和移动客户端，但受责任共担模型和你的配置约束。本文聚焦通过浏览器访问的 Amazon Quick Web 版本能力。

本文从基础开始：HIPAA 适用于谁，以及 HIPAA 适用资格与 HIPAA 合规的差别。随后把 Amazon Quick 作为平台介绍，并说明 PHI 的两条数据流（非结构化与结构化）。接着说明 Amazon Quick 为受监管环境提供什么、不提供什么，走一遍虚构健康计划（AnyCompany）的部署，并归纳应预先做出的最佳实践和不可逆决策。最后是分步实施指南、结论，以及供进一步阅读的资源。

HIPAA 适用于谁？

HIPAA 的范围超出医院和诊所。根据该法，两类组织承担义务，而大多数 AI 项目会同时触及这两类。

受保实体（Covered entities，CEs）

• 健康计划 – 健康保险公司、健康维护组织（HMO）、雇主赞助计划、Medicare 和 Medicaid。
• 医疗信息清算所 – 把非标准健康信息处理成标准电子格式的组织。
• 医疗服务提供者 – 医生、诊所、医院、药房、护理院，以及任何以电子方式传输健康信息的提供者。

业务伙伴（Business associates，BAs）

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

受保实体和业务伙伴在 PHI 转手之前都必须签署业务伙伴附录（business associate addendum，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 的全部能力由下列构件组装而成：

• 对话（Chat）是主界面。用户可以用自然语言提出问题或给出指令，由 Amazon Quick 决定如何响应。
• 对话智能体（Chat agents）处理每一个请求。这就是你在控制台上、对话智能体菜单下看到的内容。每个对话智能体可以配置指令、由知识来源接地，并获得用于采取行动的工具。Amazon Quick 附带一个默认对话智能体（My Assistant），你也可以为特定领域创建自定义对话智能体。
• 空间（Spaces）组织对话智能体所需的资源，例如文档、仪表板、数据集、知识库和操作连接器。空间可以与团队共享。
• 集成（Integrations）把 Amazon Quick 连到你的环境：知识库用于非结构化内容，例如 Amazon Simple Storage Service（Amazon S3）、Microsoft SharePoint 和 Atlassian Confluence；结构化数据连接把 Amazon Quick Sight 连到你的结构化数据库、数据仓库和数据湖；操作连接器（由 OpenAPI 规范或模型上下文协议服务器构建）；以及扩展（Chrome、Slack、Microsoft Teams 和 Microsoft 365）。

这些构件之上是各项功能。它依赖什么这一列对合规很重要，因为它表明每个功能依赖哪些构件，因而依赖哪些数据路径。

说明： SPICE 是 Amazon Quick Sight 的内存查询引擎。SPICE 数据集在创建时使用账户默认的客户托管密钥；要把已有数据集导入到新的默认密钥上，必须执行一次完整刷新。如果数据包含 PHI，应把 SPICE 纳入加密策略（若使用客户托管的 AWS Key Management Service（KMS）密钥，则用该密钥保护它），并纳入数据最小化决策：导入什么，例如实时查询，或改为加载去标识提取。

同样的适用资格、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 用传输层安全（Transport Layer Security，TLS）保护加密传输。对某些数据库连接，你可以选择传输是否加密，因此应在这些数据源连接上显式启用 TLS/SSL，而不是假定它始终开启。

你的数据不用于训练模型

Amazon Quick 不使用你的客户数据来训练或改进底层大语言模型（large language models，LLMs）。

访问控制与身份联合

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

审计与监控信号

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 治理的是访问、检索和交互。它不是数据工程或数据湖治理平台。在 HIPAA 语境中，若干需求落在 Amazon Quick 之外，由它上游的其他 AWS 服务满足。

• 去标识与变换。 Amazon Quick 不对 PHI 去标识，也不重塑源数据。当用例需要有限数据集或去标识提取时，应在数据到达 Amazon Quick 之前用适当的 AWS 服务准备，例如用 AWS Glue DataBrew（AWS Glue 的一项能力）做可视化数据准备和脱敏，或用 AWS Glue 做提取、变换和加载（extract, transform, and load，ETL）流水线。
• 数据湖治理与细粒度表权限。 对于 Amazon Quick Sight 通过数据湖查询的结构化数据，湖本身的列级和行级治理是 AWS Lake Formation 的职责，不是 Amazon Quick 的职责。Amazon Quick Sight 在分析层强制执行自己的行级和列级安全，但权威的湖级授权位于 Lake Formation 和 AWS Glue Data Catalog。
• 管理和物理保障措施。 无论使用何种工具，员工培训、风险分析和泄露处置程序仍由你负责。

一般最佳实践是划清责任：让上游服务决定存在什么数据、谁可以在源头查询它。让 Amazon Quick 决定谁可以向它提问，以及智能体可以用这些数据做什么。

AnyCompany 健康计划：一个示例用例

虚构的健康计划 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 管理控制台开通。 管理员在 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 的知识库，关闭开放 Web 搜索，并配置护栏。任何与 PHI 相邻的内容都实施只读连接器。
6. 用查询时安全连接仪表板。 运营仪表板通过 Athena 读取去标识的 Amazon Quick Sight 数据集，并在 Lake Formation 授权之上叠加 Amazon Quick Sight 的行级和列级安全以及运行身份角色。
7. 在接纳用户之前打开审计信号。 管理员创建 CloudTrail 跟踪，并把 CloudWatch 供应日志交付（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS 以及其余类型）配置到一个保留且已掩码的目的地。反馈被视为 PHI 表面。
8. 验证，然后从非 PHI 扩展到 PHI。 AnyCompany 先从非 PHI 工作流开始，例如政策问答和文档搜索，以确认治理；用对抗性提示测试，以验证失败即关闭的 ACL 行为；复核日志以确认事件被捕获；只有在此之后，才把照护管理团队扩展到与 PHI 相邻的工作。

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 — 在感知、推理和行动上做纵深防御。 把每项智能体能力映射到三层之一：

• 感知（Perceive）： 知识库、上传文件、Web 搜索、连接器输入、MCP 工具输出。
• 推理（Reason）： 处理上下文的 LLM，由护栏和主题控制约束。
• 行动（Act）： 连接器、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 中的专用工作负载账户里。用服务控制策略（Service Control Policies，SCPs）强制区域限制，并阻止在范围外区域意外开通。

关于网络边界：Amazon Quick 是通过 HTTPS 访问的托管服务。你不把它部署进虚拟私有云（virtual private cloud，VPC）。但你的数据源（S3 存储桶、数据库、本地系统）可能位于 VPC 边界之后。在可用处使用 VPC 端点和 AWS PrivateLink。确保 DNS 解析和防火墙规则让 Amazon Quick 的连接器能够到达已授权的数据源，而不把网络开放得超出必要。

缩小智能体的攻击面

Amazon Quick 自己的文档把对抗性风险表述为两个条件的问题：当（1）智能体可以读取信任边界之外的内容，并且（2）它可以采取有后果的行动时，风险存在。收窄任一条件，就能降低暴露。

约束智能体能读取什么（感知层）。 知道喂给智能体上下文的每一个来源：知识库、上传文件、Web 搜索、第三方研究提供商、连接器响应、MCP 工具输出，以及保留的对话记忆。对于 PHI 工作流：

• 把智能体限定到可信的、感知 ACL 的知识库。
• 在不需要的地方关闭开放 Web 搜索。
• 如果智能体不需要，关闭文件上传。
• 把对话历史保留限制在最小有用窗口。

约束智能体能做什么（行动层）。 盘点每一条出站路径：连接器、MCP 工具、Web 查询、Quick Flows、Quick Automate 工作流、计划中的智能体运行。对于与 PHI 相邻的智能体：

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

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

强制最小权限和数据隔离

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

实行数据最小化

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

• 只要用例允许，优先使用去标识数据。
• 从数据库或 API 摄入结构化数据时，在索引之前于源头过滤列和行。
• 配置智能体护栏，在响应中脱敏个人身份信息（PII），使用内置 PII 检测过滤器隐藏社会安全号码（Social Security numbers，SSNs）、病历号（medical record numbers，MRNs）和出生日期。

配置审计日志与保留

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. 把关键告警路由到你的安全信息和事件管理（security information and event management，SIEM）或事件响应平台。

扩展之前先验证

在扩大范围之前，检查下列事项：

• BAA 接受情况已记入合规登记册。
• 数据分类已文档化：哪些知识库和空间包含 PHI，哪些智能体可以到达它们。
• 已测试对抗性查询和提示注入场景。
• 日志正在被捕获，且掩码工作正确。
• 已完成桌面泄露演练。
• 信息安全（InfoSec）已签字。

已知限制

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

• 免费或 Plus 路径上没有 BAA。 你必须使用通过 AWS 管理控制台开通的路径，才能获得 BAA 覆盖。
• 没有跨区域复制。 灾难恢复（disaster recovery，DR）受限于单一区域。
• 护栏是概率性的，不是确定性的。 它们降低风险。它们不消除风险。用前文所述的基础设施级控制加以补充。
• 第三方连接器延伸你的 BAA 义务。 当连接器把数据送到外部系统时，你的合规责任随数据走。
• 对话记忆可能包含被回显的 PHI。 设置保留策略并应用掩码。

实施指南

AnyCompany 健康计划的例子展示了如何推出 Amazon Quick。本节把该模式变成一份可以交给平台团队的分步项目计划。

步骤 1：执行 BAA（第 1 天）

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

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

• 把客户托管密钥登记为账户默认值。
• 验证密钥策略授予所需权限：Encrypt、Decrypt、GenerateDataKey、DescribeKey。
• 配置身份模型（推荐 IAM Identity Center）。
• 确认账户位于专用工作负载组织单元（organizational unit，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 管理控制台开通的账户上执行 BAA。
3. 先设置不可逆控制：KMS 密钥、身份模型、感知 ACL 的知识库。
4. 缩小智能体的读取面和行动面，强制最小权限，并在日志中掩码 PHI。
5. 与信息安全团队一起验证，然后从非 PHI 扩展到与 PHI 相邻的工作流。

合规预期与技术一样变化得很快。AWS 于 2026 年 4 月发布了智能体式 AI 的四项安全原则，并于 2026 年 6 月发布了 Well-Architected Agentic AI Lens。今天就建立在确定性、基础设施级控制之上的组织，在监管预期追上智能体式 AI 所能做的事情时，很可能会处于有利位置。

下一步做什么

如果你正在评估 Amazon Quick： 向 AWS 客户团队申请一次以合规为重点的简报。询问 BAA 范围、智能体式 AI 的责任共担，以及最新加入的符合 HIPAA 适用资格的服务。

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

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

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

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/deploy-ai-in-a-hipaa-eligible-environment-with-amazon-quick