医疗保健组织对AI的期望与其他所有企业相同：更快的答案、更少的手工工作，以及能及时传递给决策者以便采取行动的洞察。然而，医疗保健行业的不同之处在于，其数据异常复杂、高度依赖上下文，并受到严格监管。因此，本文首先给出几个定义，为后续的所有内容奠定基础。
受保护健康信息（PHI）是指任何能够识别一个人并与其健康、护理或护理费用支付相关的信息，例如医疗记录、索赔或会员 ID。当软件接触 PHI 时，它就受到《健康保险流通与责任法案》（HIPAA）的约束，这是规范 PHI 数据如何被访问、保护和审计的联邦法律。
Agentic AI 改变了软件“接触 PHI”的含义。传统分析工具读取数据并返回结果。而像 Amazon Quick 可能走得更远。例如，其聊天代理既能处理非结构化内容（如临床记录和申诉信），也能处理结构化数据（如理赔和会员记录）。代理可以从非结构化和结构化来源检索数据，通过连接器调用其他系统，并代表用户完成多步骤任务。 连接器 是预先构建的集成，可让 Amazon Quick 安全地读取您的外部系统并在其中执行操作，例如 Slack，微软 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 账户的业务伙伴，且仅当您使用 HIPAA 合规的服务（如 Amazon Quick）在其中处理 PHI 时才适用。该附录不适用于您的其他账户、不适用于放置在非 HIPAA 合规服务中的 PHI，也不适用于您对服务的配置方式。这些仍是您的责任。请务必与您自己的法务和合规团队一起审查并确认当前的 AWS BAA 条款及您的义务。
HIPAA eligible 不等同于 HIPAA compliant
虽然 HIPAA eligible 是 AWS 的一项指定，但 HIPAA compliant 是整个环境的属性。HIPAA eligible 意味着 AWS 已对该服务进行评估，并允许您在签署 AWS BAA 的情况下使用它来处理、存储和传输 PHI。Amazon Quick 是一项 HIPAA-eligible 服务，第三方审计机构会根据 AWS 的合规计划（包括 HIPAA、FedRAMP、PCI DSS、SOC 和 ISO）对其进行评估。AWS 作为云服务并不存在官方的 HIPAA 认证，AWS 本身也不是“HIPAA eligible”的。
Amazon Quick 的资格仅是一个构建基础。仅凭这一点并不能使您的应用程序和环境符合 HIPAA。您仍需签署 BAA、对数据进行分类、正确配置控制措施，并承担 HIPAA 所要求的行政和物理安全保障，包括员工培训、风险分析以及 AWS 不会为您执行的违规事件处理程序。符合资格的服务（如 Amazon Quick）、已签署的 BAA、正确的配置、治理以及您自身的安全保障措施，这些共同构成了符合 HIPAA 的部署。Amazon Quick 符合资格意味着您可以在其上构建合规的工作流程，并不意味着启用它就自动使您合规。
什么是 Amazon Quick
Amazon Quick 通常是通过其聊天代理来介绍的,但 HIPAA 合规资格适用于整个工作区,而不是单一功能,因此从平台层面进行审视对合规至关重要。Amazon Quick 中的所有功能都由以下构建模块组成:
- 聊天 是主要的交互界面。用户可以用自然语言提出问题或给出指令，由 Amazon Quick 决定如何响应。
- 聊天代理 处理每个请求。这就是您在控制台的 Chat agents 菜单下看到的内容。每个 chat agent 都可以配置指令、通过知识源进行接地，并被赋予工具以执行操作。Amazon Quick 附带一个默认的 chat agent（My Assistant），您也可以为特定领域创建自定义 chat agent。
- Spaces 组织聊天代理所需的资源，例如文档、仪表板、数据集、知识库和操作连接器。空间可以与团队共享。
- 集成 将 Amazon Quick 连接到您的环境： 知识库 针对诸如以下的非结构化内容 Amazon Simple Storage Service (Amazon S3), Microsoft SharePoint，以及 Atlassian Confluence；将 Amazon Quick Sight 连接到您的结构化数据库、数据仓库和数据湖的结构化数据连接；操作连接器（基于 OpenAPI 规范或 Model Context Protocol 服务器构建）；以及扩展（Chrome、Slack、Microsoft Teams 和 Microsoft 365）。
在这些构建块之上是各项功能。这些 它的灵感来源 此列对合规性很重要，因为它显示了每个功能使用了哪些构建模块，从而也显示了哪些数据路径。
| 功能特性 | 它的功能 | 它所借鉴的内容 |
| Amazon Quick Sight | 交互式仪表板和分析(BI) | 结构化数据连接、SPICE、数据集 |
| Amazon Quick Flows | 任务自动化 | 操作连接器、空间、代理逻辑 |
| Amazon Quick Automate | 带有人工参与的端到端流程自动化 | 操作连接器、代理、人工审核 |
| Amazon Quick Research | 带引用来源的深度研究报告 | 空间、知识库、网络 |
| Apps in Quick | 交互式网络应用程序 | 结构化数据、连接器、Amazon Quick Sight 可视化 |
注意： SPICE 是 Amazon Quick Sight 的内存中查询引擎。SPICE 数据集在创建时使用账户默认的客户自主管理密钥，而要将现有数据集导入到新的默认密钥上，您必须执行一次完整 刷新。如果您的数据包含PHI，请将SPICE纳入您的加密策略（使用您的客户托管 AWS 密钥管理服务 （如果您使用的话，还包括 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 使用传输层安全协议（TLS）保障加密传输。对于某些数据库连接，您可以选择是否加密传输，因此您应显式在这些数据源连接上启用 TLS/SSL，而不是假定它始终处于开启状态。
您的数据不会被用于训练模型
Amazon Quick 不会使用您的客户数据来训练或改进底层大型语言模型（LLMs）。
访问控制与身份联合
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 能力 | 使用方式 | 支持的 HIPAA 控制措施 |
| 联合 SSO + RBAC | IAM Identity Center / AD,最小权限角色 | 164.312(a)(1) 访问控制。唯一用户 ID |
| 知识库上的文档级 ACL | 具备 ACL 感知能力的知识库。在查询时采用默认拒绝（fail-closed）策略 | 164.312(a)(1) 访问控制。最小必要原则 |
| 静态和传输中的加密 | 默认使用 AWS 托管密钥开启。可选客户托管密钥以实现密钥所有权 | 164.312(a)(2)(iv) / (e)(2)(ii) 加密 |
| CloudTrail + CloudWatch 交付的日志 | 捕获 API 事件以及聊天/反馈记录 | 164.312(b) 审计控制 |
| 日志保留 + 脱敏 | 保留策略、S3 Object Lock、PII 脱敏 | 164.316(b) 文档保留 |
| AI 防护栏 + 内置筛查 | 屏蔽词语/短语、内容安全检查 | 支持最小必要和完整性目标 |
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 Knowledge Base（文档级 ACL，查询时默认拒绝/fail-closed）
结构化路径（理赔）
目前所有理赔数据都存放在数据湖（Amazon S3）中。
→ Glue ETL（数据整理）→ Glue DataBrew（去标识化）
→ Lake Formation（行/列级授权及 AWS Glue Data Catalog)
→ Amazon Quick Sight 数据集（Amazon Athena）（行级和列级安全，run-as 角色）
前面所述的结构化和非结构化数据流最终汇聚到一个 Amazon Quick 聊天代理，该代理具备联合 SSO、最小权限空间、防护栏以及 CloudWatch 交付的日志。
以下是 AnyCompany 的管理员实施该解决方案的方法：
- 签署BAA并通过以下途径进行配置： AWS 管理控制台. 管理员在 AWS Artifact 中针对该 AWS 账户接受 AWS BAA,然后通过 AWS 管理控制台并使用 IAM Identity Center 来开通 Amazon Quick。AnyCompany 将协议 ID、时间戳和账户记录在其合规登记册中。只有通过 AWS 管理控制台开通的 Amazon Quick 网页版才能通过 AWS Artifact 纳入已签署的 BAA,对于构建涉及 PHI 的 HIPAA 合规工作流的客户而言,这是一个必要的组成部分,前提是进行正确的配置并履行客户自身的合规责任。
- 在第零天设置不可逆控制。 由于 AnyCompany 的安全政策要求掌控自己的加密密钥，管理员选择在任何 Amazon Quick AI 数据创建之前注册一个客户托管密钥作为账户默认值。数据密钥只能设置一次，之后无法更改。（默认的 AWS 托管加密同样符合 HIPAA 要求。使用客户托管密钥并非该服务符合 HIPAA 要求的前提条件。）管理员还将身份模型确定为 IAM Identity Center，以便非活动用户检测能够生效。Amazon Quick 数据密钥是 设置一次 在首次创建数据时生成且永远无法更改。如果密钥被删除，唯一的恢复方法是取消订阅并重新订阅，这将永久删除所有 Amazon Quick 数据。
- 在 Amazon Quick 之外准备好结构化路径。 在 Amazon Quick Sight 处理理赔数据之前，AnyCompany 的数据团队使用 AWS Glue 构建经过整理的理赔表，并使用 Glue DataBrew 为运营仪表板生成去标识化的数据提取。AWS Lake Formation 通过 AWS Glue Data Catalog 对这些表授予行级和列级访问权限。因此，Amazon Quick 永远不会看到它并不需要的原始 PHI。
- 为文档创建一个支持 ACL 的知识库。 管理员在创建时将政策与申诉 S3 存储桶连接为知识库，并启用文档级 ACL。由于 ACL 无法事后开启，这需要在创建 S3 存储桶时进行配置。Amazon Quick 在查询时评估每个用户的身份，当无法确认访问权限时不返回任何文档。
- 构建专属空间和自定义聊天代理。 AnyCompany 创建一个成员受限的 PHI 空间，与通用生产力空间分开。护理管理聊天代理的范围仅限于该支持 ACL 的知识库，禁用了开放式网络搜索，并配置了防护栏。为所有接近 PHI 的内容实现了只读连接器。
- 通过查询时安全机制连接仪表板。 运营仪表板通过 Athena 读取去标识化的 Amazon Quick Sight 数据集，并在 Lake Formation 授权之上叠加 Amazon Quick Sight 行级和列级安全以及运行身份（run-as）角色。
- 在用户接入之前开启审计信号。 管理员创建 CloudTrail 跟踪，并将 CloudWatch 日志投递（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS 及其他）配置到具有保留期且已脱敏的目标。反馈被视为 PHI 面。
- 先验证，再从非 PHI 扩展到 PHI。 AnyCompany 从非 PHI 工作流开始，例如政策问答和文档搜索，以确认治理有效性；使用对抗性提示进行测试，以验证 ACL 的默认拒绝（fail-closed）行为；审查日志以确认事件已被捕获；然后才将护理管理团队扩展到接近 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 —— 在感知、推理和行动三个环节实施纵深防御。 将智能体的每项能力映射到以下三个层之一：
- 感知： 知识库、上传的文件、网络搜索、连接器输入、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 是一项单区域服务：它受益于多可用区（multi-AZ）弹性 之内 一个区域，但它不会跨区域进行故障转移。如果您支持需要跨区域弹性的关键业务工作流，请在第二个区域中预置一个单独的 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 感知的知识库。
- 在不需要的地方关闭开放网络搜索。
- 如果代理不需要文件上传，则将其关闭。
- 将对话历史保留期限制在最小有用窗口。
限制代理可以执行的操作（行动层）。 清点每一条出站路径：连接器、MCP 工具、网络查询、Quick Flows、Quick Automate 工作流以及计划代理运行。对于与 PHI 相关的代理：
- 优先使用只读连接器访问。
- 对自动化和计划工作流保持谨慎，因为它们在无人监督的情况下运行。
- 阻止写入操作，除非经过明确论证并获得你的安全团队的批准。
- 使用连接器级别的权限范围限定来限制代理可以调用哪些操作。
了解操作以何种身份运行。 按需操作以发起调用的用户身份进行认证，并受该用户的连接器权限约束。自动化工作流在没有交互式会话的情况下运行。使自主级别与操作的敏感度相匹配，并记录哪些代理以哪种身份模式运行。
实施最小权限和数据隔离
- 将包含 PHI 的知识库和空间与通用生产力用途的知识库和空间分开。限制成员资格。
- 按需知密原则授予空间访问权限和代理访问权限。同时审查共享权限（谁可以使用知识库）和源文档 ACL（经授权的用户实际能检索哪些已索引文档）。
- 知识库的默认刷新周期为 24 小时。当你的访问变更要求需要更快的传播速度时，应缩短该周期。在重新分配或回收电子邮件地址之前，请先刷新 ACL。
- PHI 代理不应与通用生产力工具共享空间。这意味着你需要在空间层面隔离用例。
- 定期审查连接器权限。按照与你的凭证管理策略相匹配的时间表轮换存储在 AWS Secrets Manager 中的凭证。
实施数据最小化
AWS 建议不要在资源名称或标签中输入机密数据，以避免其意外出现在账单或诊断日志中。
- 只要用例允许，应优先使用去标识化的数据。
- 在从数据库或 API 摄取结构化数据时，应在索引之前在源头过滤列和行。
- 配置代理护栏以对响应中的 PII 进行脱敏，使用内置的 PII 检测过滤器隐藏社会安全号码（SSN）、病历号（MRN）和出生日期。
配置审计日志和保留策略
Amazon Quick 提供多种不同的审计信号。默认情况下这些信号都不会流转，你可能需要手动开启它们。
| 信号 | 来源 | 捕获内容 |
| API 操作 | CloudTrail | 管理操作、配置更改 |
| 聊天交互 | CloudWatch | CHAT_LOGS — 完整对话记录 |
| 用户反馈 | CloudWatch | FEEDBACK_LOGS — 附带上下文的点赞/点踩 |
| KB 同步事件 | CloudWatch | KB_FILE_SYNC_LOGS — 摄取状态 |
| 运营指标 | CloudWatch | 延迟、错误率、调用次数 |
| 使用情况分析 | Quick 控制台 | 采用情况、热门查询、用户活动 |
以下是设置它们的方法：
- 为相关账户和区域创建 CloudTrail 跟踪。
- 在开启 Amazon Quick 的 AI 功能后不久，配置 CloudWatch 托管日志投递（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS）。
- 对聊天日志应用 CloudWatch Logs 数据保护脱敏，使 PHI 不以明文存储。
- 设置至少六年的保留期。考虑在日志归档上使用 S3 Object Lock。
- 添加 CloudWatch 警报以监控异常活动。
- 启用 AWS Security Hub 以进行持续合规检查。
- 将关键警报路由到您的安全信息和事件管理（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 提供的日志。
- 应用数据保护掩码。将保留期设置为至少六年。启用 S3 Object Lock。
- 配置警报、启用 Security Hub，并与您的 SIEM 集成。
步骤 8：与 InfoSec 进行验证（第 14–21 天）
- 编译证据包：BAA 确认、KMS 配置、身份设置、数据分类、测试结果和日志样本。
- 进行一次桌面推演式数据泄露演练。
- 向您的 InfoSec 团队汇报。整改发现的问题。获得批准。
扩展阶段（第 4–8 周）
从非 PHI 工作流开始：政策问答、文档搜索、会议准备、工作流自动化。这些工作流可让您的团队在 PHI 进入视野之前建立对平台的信心。
然后扩展到 PHI 相关工作流：临床文档辅助、理赔处理、事先授权、监管问答，以及有人在环审核的患者沟通起草。
密切监控：每周审查聊天日志，跟踪护栏触发率，并在每个新工作流上线后的30天内监控访问模式。
结论
Amazon Quick 为受监管的医疗组织及其业务关联方提供了一个托管 AI 工作区，其全部功能范围均符合 HIPAA 资格：代理式 AI、知识检索、商业智能、自动化和研究。
实现合规部署的路径遵循清晰的顺序：
- 理解“符合资格”与“合规”之间的区别，并承担共同责任中属于你的那部分。
- 在通过 AWS Management Console 预置的账户上执行 BAA。
- 首先设置不可逆的控制措施：KMS 密钥、身份模型、支持 ACL 的知识库。
- 最小化代理的读取和操作面，强制执行最小权限原则，并在日志中遮蔽 PHI。
- 与你的信息安全团队进行验证，然后从非 PHI 工作流逐步扩展到 PHI 相邻工作流。
合规期望正与技术同步快速演进。AWS 于 2026 年 4 月发布了 代理式 AI 的四项安全原则 ，并于 2026 年 6 月发布了 Well-Architected Agentic AI Lens 2026年6月。今天就在确定性、基础设施级控制之上构建的组织，随着监管期望赶上代理式 AI 的能力，很可能会处于有利地位。
下一步做什么
如果你正在评估 Amazon Quick： 向你的 AWS 客户团队申请一次以合规为重点的简报。询问 BAA 范围、代理式 AI 的共同责任以及最新符合 HIPAA 资格的服务新增内容。
如果你已准备好部署： 将实施指南作为你的项目计划。第 2 步中的不可逆决策值得在开始创建资源之前进行专门的架构审查。
如果你已经在运行 Amazon Quick： 根据本文中的最佳实践审计你的部署，尤其是代理式安全原则和已知限制列表。
如需架构指导，请联系你的 AWS Solutions Architect 或 AWS Healthcare and Life Sciences 团队。