Deploy AI in a HIPAA-eligible environment with Amazon Quick

在符合 HIPAA 的环境中使用 Amazon Quick 部署 AI | 人工智能

在符合 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 的网页、桌面和移动客户端，前提是遵循共享责任模型并进行适当配置。然而，本文重点介绍 Amazon Quick 的网页版本，您可以通过浏览器访问该版本。

在本文中，我们首先从基础开始：HIPAA 适用的范围以及 HIPAA 合格与 HIPAA 合规之间的区别。然后，我们将介绍 Amazon Quick 作为平台，以及 PHI 的两种数据流（非结构化和结构化）。从那里，我们将介绍 Amazon Quick 在受监管环境中提供的功能和不提供的功能，逐步演示一个虚构的健康计划（AnyCompany）的部署，并总结您在前期应制定的最佳实践和不可逆决策。最后，我们提供逐步实施指南、结论以及深入阅读的资源。

HIPAA 适用于谁？

HIPAA 的适用范围不仅限于医院和诊所。根据法律，两类组织需要承担义务，而大多数 AI 项目都会涉及这两类组织。

受监管实体（CEs）

• 健康计划 – 包括健康保险公司、HMO、雇主资助的计划、医疗保险和医疗补助。

• 医疗信息清算所 – 对非标准医疗信息进行处理，将其转换为标准电子格式的组织。

• 医疗服务提供者 – 医生、诊所、医院、药店、疗养院，以及任何通过电子方式传输医疗信息的提供者。

业务关联方（Business Associates，BAs）

• 业务关联方是指受监管实体工作团队以外的任何个人或实体，其代表受监管实体创建、接收、维护或传输受保护的健康信息（PHI）。

• 常见示例包括云服务提供商、IT供应商、账单公司、数据分析公司、理赔处理公司、律师事务所和咨询公司。

• 代表其他业务关联方处理PHI的分包商本身也属于业务关联方。

受监管实体和业务关联方在PHI交接前都必须签署业务关联方附录（BAA）。您通过AWS Artifact接受AWS BAA后，AWS将作为您的业务关联方，仅针对特定AWS账户，并且仅当您使用符合HIPAA资格的服务（如Amazon Quick）在该账户内处理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符合资格意味着您可以在其上构建合规的工作流程。但这并不意味着启用它后您会自动符合HIPAA合规。

什么是Amazon Quick

Amazon Quick通常通过其聊天代理引入，但HIPAA资格适用于整个工作区，而非某个单一功能，因此对于合规性而言，平台级视角至关重要。Amazon Quick中的所有功能均由以下构建模块组成：

• 聊天是主要界面。用户可以通过自然语言提出问题或提供指令，Amazon Quick决定如何响应。

• 聊天代理处理每个请求。您在控制台的“聊天代理”菜单下可以看到这些内容。每个聊天代理都可以配置指令、通过知识来源进行支撑，并获得执行操作的工具。Amazon Quick预装了一个默认聊天代理（My Assistant），您还可以为特定领域创建自定义聊天代理。

• 空间用于组织聊天代理所需的资源，如文档、仪表板、数据集、知识库和操作连接器。空间可以与团队共享。

• 集成将 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

深入且有引用的研究报告

空间、知识库、网络

Quick 中的应用

交互式网络应用

结构化数据、连接器、Amazon Quick Sight 可视化

注：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 的强制要求。如果您需要直接控制加密密钥，可以为参与资源类型（包括 SPICE 数据集、数据源凭证、OAuth 令牌和报告工件）注册客户管理的 AWS KMS 密钥（需要企业订阅）。在不适用客户管理密钥的情况下，AWS 会使用 AWS 拥有的或 AWS 管理的密钥对数据进行加密。

• 需要注意的一个细节：对聊天回复的用户反馈（包括可选的自由文本评论）不会使用您的客户管理密钥或保护 Amazon Quick 的 AI 索引数据的密钥进行加密。用户反馈应被视为潜在的 PHI（受保护健康信息）表面，并需相应治理。

• 对于传输中的数据，Amazon Quick 使用传输层安全协议（TLS）保护加密传输。对于某些数据库连接，您可以选择是否启用传输加密，因此应在这些数据源连接上显式启用 TLS/SSL，而不是假设其始终开启。

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

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

访问控制与身份联合

Amazon Quick 支持基于角色的访问控制（RBAC）和通过 AWS IAM Identity Center、Microsoft Active Directory 和 SAML 2.0 身份提供商实现的单点登录（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意识的知识库。查询时默认拒绝访问

164.312(a)(1) 访问控制。最小必要原则

静态数据和传输中数据的加密

默认启用AWS托管密钥。可选使用客户托管密钥实现密钥所有权

164.312(a)(2)(iv) / (e)(2)(ii) 加密要求

CloudTrail + CloudWatch 日志服务

捕获API事件和聊天/反馈记录

164.312(b) 审计控制

日志保留与脱敏

保留策略、S3对象锁定、PII数据脱敏

164.316(b) 文档保留要求

AI防护机制 + 内置筛查

阻止特定词汇/短语，内容安全检查

支持最小必要原则和数据完整性目标

Amazon Quick不提供的功能

虽然Amazon Quick提供上述控制措施，但本节将说明其不提供的功能以及如何弥补这些差距。Amazon Quick负责访问控制、数据检索和交互管理，但它不是数据工程或数据湖治理平台。在HIPAA合规场景中，多个需求超出Amazon Quick的范围，需要依赖其上游的其他AWS服务来满足。

• 去标识化和数据转换。Amazon Quick不会对PHI数据进行去标识化处理或重塑源数据。当使用场景需要有限数据集或去标识化提取时，应在数据到达Amazon Quick前通过适当AWS服务进行准备，例如使用AWS Glue DataBrew（AWS Glue的可视化数据准备和脱敏功能），或使用AWS Glue进行提取、转换和加载（ETL）流程。

• 数据湖治理与细粒度表权限。对于通过数据湖查询的结构化数据，数据湖本身的列级和行级治理由AWS Lake Formation负责，而非Amazon Quick。Amazon Quick在分析层实施自己的行级和列级安全策略，但数据湖层面的权限配置仍需通过Lake Formation和AWS Glue Data Catalog进行管理。

• 管理和物理安全措施。人员培训、风险分析和数据泄露处理等职责始终属于用户，与工具选择无关。

通用最佳实践是明确划分责任边界，允许上游服务决定数据的存在形式和可查询权限。让Amazon Quick决定谁可以向其提问，以及代理可以对数据执行哪些操作。

AnyCompany健康计划：示例用例

虚构的AnyCompany健康计划展示了典型用例和实现模式。作为受监管实体，AnyCompany健康计划希望实现两个目标：允许护理管理团队通过自然语言查询政策文件和成员申诉文档，同时为运营主管提供针对理赔数据的自助式仪表板。由于两者均涉及PHI数据，AnyCompany需要确认解决方案符合HIPAA合规要求。其环境包含两条数据路径，每条路径在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）（行级和列级安全策略，运行角色）

结构化和非结构化数据的两种数据流最终汇聚到一个带有联合SSO、最小权限空间、防护措施和CloudWatch托管日志的Amazon Quick聊天代理中。

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

• 签署BAA协议并通过AWS管理控制台进行部署。管理员在AWS Artifact中接受AWS BAA协议，针对AWS账户进行签署，然后通过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数据目录在这些表上授予行级和列级访问权限。因此，Amazon Quick永远不会看到其不需要的原始PHI数据。

• 为文档创建具备ACL意识的知识库。管理员将策略和申诉的S3存储桶连接为知识库，并在创建时启用文档级ACL。由于ACL无法在创建后启用，因此必须在创建S3存储桶时进行此配置。Amazon Quick在查询时评估每个用户的身份，当无法确认访问权限时不会返回任何文档。

• 创建专用空间和自定义聊天代理。AnyCompany创建了一个具有受限成员资格的PHI空间，该空间与通用生产力空间分开。护理管理聊天代理仅限于具备ACL意识的知识库，禁用开放网络搜索并配置防护措施。对于任何与PHI相关的数据，均实施只读连接器。

• 通过查询时安全机制连接仪表板。运营仪表板通过Athena读取去标识化的Amazon Quick Sight数据集，并叠加Amazon Quick Sight的行级和列级安全措施以及Lake Formation授权的运行角色。

• 在用户入职前启用审计信号。管理员创建CloudTrail跟踪，并将CloudWatch托管日志交付（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS等）配置到保留的脱敏目标。反馈被视为PHI表面，需特别处理。

• 验证后，从非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 IAM策略、文档级ACL、网络边界和管理员配置的防护机制无法被说服绕过。应将这些作为主要执行手段，代理指令仅作为第二层防护，而非唯一手段。

原则3 — 在感知、推理和行动三个层面实施纵深防御。将每个代理能力映射到以下三个层级之一：

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

在每个层级独立实施控制措施。某一层的漏洞不应扩散到其他层级。

注意HIPAA BAA义务适用于支持服务和解决方案（如MCP工具）。

原则4 — 逐步扩展代理自主性。首先以只读模式让代理处理非PHI数据。逐个添加功能。在每一步迁移前，测试数据泄露、提示注入防御能力和权限边界遵守情况。

部署前做出决策

由于这三个选择是永久性的，请在实施前完成这些决策。

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

慎重选择身份模型。您有四个选项：IAM Identity Center、Active Directory、IAM 联邦身份和快速本地用户。它们在配置、停用和治理行为方面存在差异。例如，非活跃用户检测功能仅适用于 IAM Identity Center 或 Active Directory。部署后切换身份提供商意味着需要重新配置每个用户的权限和空间成员资格。请一次性确定最终选择。

创建 PHI 知识库时需启用 ACL 识别功能。对于支持的数据源（Amazon S3、Google Drive、SharePoint、Confluence Cloud 和 OneDrive），您在创建时可决定知识库是否强制实施文档级 ACL。该设置为永久性配置。无法为未启用 ACL 的知识库事后添加该功能。对于所有涉及 PHI 的内容，应从创建之初就启用 ACL 识别功能。

警告：配置错误的用户存储映射可能导致受限文档在没有错误或警报的情况下静默暴露给错误用户。在摄入 PHI 内容前，必须验证身份到 ACL 的映射关系。

AWS 区域、网络和账户边界

根据以下因素规划部署区域：

• 数据驻留：Amazon Quick 在您配置的区域处理和存储数据，您需确认该区域满足组织的数据本地化要求。注意 Amazon Quick 是单区域服务：其在区域内受益于多可用区容灾能力，但不会跨区域故障转移。若需支持需要跨区域容灾的关键业务流程，请在第二个区域部署独立的 Amazon Quick 实例，并同步部署相关数据（例如跨区域复制基于 S3 的知识库源）。

• 服务可用性：某些功能可能在不同区域的上线时间存在差异。请确认您计划部署区域是否提供代理所需的所有功能，包括知识库、连接器和 Amazon Quick Sight 能力。

• 多账户策略：在 AWS Organizations 中的专用工作负载账户部署 Amazon Quick。使用服务控制策略（SCPs）强制实施区域限制，防止在非授权区域意外部署。

关于网络边界：Amazon Quick 是通过 HTTPS 访问的托管服务，您无需将其部署到虚拟私有云（VPC）。但您的数据源（S3 存储桶、数据库、本地系统）可能位于 VPC 后方。在支持的情况下使用 VPC 终端节点和 AWS PrivateLink。确保 DNS 解析和防火墙规则允许 Amazon Quick 的连接器访问授权数据源，且不扩大不必要的网络访问范围。

降低代理的攻击面

Amazon Quick 官方文档将对抗性风险描述为双条件问题：当（1）代理能够读取信任边界外的内容，且（2）能够执行具有后果的操作时，风险才会存在。缩小任一条件均可降低暴露风险。

限制代理的读取范围（感知层）：明确所有为代理提供上下文信息的数据源：知识库、上传文件、网络搜索、第三方研究提供商、连接器响应、MCP 工具输出和保留的对话记忆。针对 PHI 工作流：

• 仅允许代理访问受信任且启用 ACL 的知识库
• 在不需要时关闭开放网络搜索功能
• 代理无需文件上传功能时关闭该功能
• 将对话历史记录保留时间限制在最小必要窗口期内

限制代理的行为（行为层）。记录所有出站路径：连接器、MCP工具、网页查询、快速流程、快速自动化工作流、计划代理运行。对于与PHI相关的代理：

• 优先使用只读连接器访问。
• 对自动化和计划工作流保持谨慎，因为它们在无人监控的情况下运行。
• 除非获得安全团队的明确批准和正当理由，否则阻止写操作。
• 使用连接器级别的权限范围限制代理可调用的操作。

明确操作所使用的身份。按需操作以调用用户的身份进行身份验证，受该用户连接器权限的限制。自动化工作流在没有交互会话的情况下运行。将自主程度与操作的敏感性匹配，并记录代理在何种身份模式下运行。

实施最小权限和数据隔离

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

实践数据最小化

AWS建议避免将机密数据输入资源名称或标签，以防止意外出现在账单或诊断日志中。

• 在使用场景允许的情况下，优先使用去标识化数据。
• 从数据库或API摄取结构化数据时，在索引前在源端过滤列和行。
• 配置代理防护措施，在响应中隐藏PII，使用内置的PII检测过滤器隐藏社会保障号码（SSN）、医疗记录号码（MRN）和出生日期。

配置审计日志和保留策略

Amazon Quick提供多种独立的审计信号。默认情况下这些信号均未启用，可能需要手动开启。

信号 | 来源 | 捕获内容 --- | --- | --- API操作 | CloudTrail | 管理员操作、配置变更 聊天交互 | CloudWatch | CHAT_LOGS - 完整对话记录 用户反馈 | FEEDBACK_LOGS | 带上下文的点赞/点踩 知识库同步事件 | KB_FILE_SYNC_LOGS | 摄取状态 运营指标 | | 延迟、错误率、调用次数 使用分析 | Quick控制台 | 采用情况、热门查询、用户活动

配置方法如下：

• 为相关账户和区域创建CloudTrail追踪。
• 启用Amazon Quick AI功能后，立即配置CloudWatch日志交付（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS）。
• 对聊天日志应用CloudWatch Logs数据保护遮蔽，防止PHI以明文形式存储。
• 设置至少六年保留期。考虑对日志归档使用S3对象锁定。
• 为异常活动添加CloudWatch警报。
• 启用AWS Security Hub进行持续合规检查。
• 将关键警报路由到安全信息和事件管理（SIEM）或事件响应平台。

扩展前进行验证

在扩展范围之前，请检查以下内容：

• BAA接受情况已记录在您的合规登记册中。
• 数据分类已形成文档：哪些知识库和空间包含PHI，哪些代理可以访问它们。
• 已测试对抗性查询和提示注入场景。
• 日志正在捕获且遮蔽功能正常工作。
• 已完成桌面演练。
• 信息安全部已签署确认。

已知限制

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

• 免费版或Plus版路径没有BAA。您必须使用通过AWS管理控制台配置的路径才能获得BAA覆盖。
• 不支持跨区域复制。灾难恢复（DR）仅限于单一区域。
• 防护措施是概率性的，而非确定性的。它们降低风险，但不会消除风险。请补充之前提到的基础架构级控制措施。
• 第三方连接器会扩展您的BAA义务。当连接器将数据发送到外部系统时，您的合规责任会随数据延伸。
• 对话记忆可能包含重复的PHI。请设置保留策略并应用遮蔽处理。

实施指南

AnyCompany健康计划示例展示了如何部署Amazon Quick。本节将该模式转化为可提交给平台团队的逐步项目计划。

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

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

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

• 注册客户管理密钥作为账户默认密钥。
• 验证密钥策略已授予所需权限：加密、解密、生成数据密钥、描述密钥。
• 配置身份模型（推荐使用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对象锁定功能。

• 配置警报，启用Security Hub，并与您的SIEM系统集成。

第8步：与信息安全部门验证（第14-21天）

• 汇总证据包：BAA确认文件、KMS配置、身份设置、数据分类、测试结果和日志样本。

• 进行桌面式数据泄露演练。

• 向信息安全部团队展示。修复发现的问题。获得书面确认。

扩展阶段（第4-8周）

从非PHI工作流程开始：政策问答、文档搜索、会议准备、工作流程自动化。这些能让团队在PHI数据进入系统前建立对平台的信心。

随后扩展到与PHI相关的流程：临床文档辅助、理赔处理、预授权、法规问答、带有人工审核环节的患者沟通草稿编写。

密切监控：每周审查聊天日志，跟踪安全护栏触发率，每个新工作流程上线后30天内观察访问模式。

结论

Amazon Quick为受监管的医疗保健组织及其服务提供商提供了符合HIPAA合规的托管AI工作空间，其全部功能均符合HIPAA标准：自主AI、知识检索、商业智能、自动化和研究。

合规部署的路径遵循清晰的顺序：

• 理解符合资格与合规之间的区别，并承担共享责任中的自身职责。

• 通过AWS管理控制台创建的账户执行BAA协议。

• 首先设置不可逆的控制措施：KMS密钥、身份模型、ACL感知的知识库。

• 最小化代理的读取和操作范围，强制实施最小权限原则，并在日志中对PHI数据进行脱敏处理。

• 与信息安全部团队验证后，从非PHI流程扩展到与PHI相关的流程。

合规要求的发展速度与技术进步同步。AWS于2026年4月发布了自主AI的四项安全原则，并于2026年6月发布了Well-Architected自主AI架构镜像。如今采用确定性基础设施级控制措施的组织，很可能在监管期望追上自主AI能力时占据有利位置。

下一步行动

如果您正在评估Amazon Quick：请向AWS账户团队请求以合规为重点的简报。了解BAA范围、自主AI的共享责任以及最新的符合HIPAA合规的服务新增功能。

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

如果您已开始运行Amazon Quick：根据本文的最佳实践对部署进行审计，特别关注自主安全原则和已知限制列表。

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

作者简介

'"`