人工智能

在符合 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 决定如何响应。
  • 聊天代理 处理每一个请求。这就是你在控制台中“聊天代理”菜单下看到的内容。每个聊天代理都可以配置指令、由知识源提供依据，并配备用于执行操作的工具。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 中的应用 交互式 Web 应用程序 结构化数据、连接器、Amazon Quick Sight 可视化

注意： 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 要求。如果您需要对加密密钥进行直接控制，可以为参与的资源类型（包括 SPICE 数据集、数据源凭证、OAuth 令牌和报告工件）注册客户托管的 AWS KMS 密钥（需要 Enterprise 订阅）。在客户托管密钥不适用的情况下，AWS 会使用 AWS 自有密钥或 AWS 托管密钥对数据进行加密。
  • 需要注意一个细节：用户对聊天回复的反馈（包括可选的自由文本评论）不会使用您的客户托管密钥或保护 Amazon Quick 的 AI 索引数据的密钥进行加密。用户反馈应被视为潜在的 PHI 暴露面，并据此进行治理。
  • For data in transit, Amazon Quick secures encrypted transfers with Transport Layer Security (TLS). For some database connections, you can choose whether the transfer is encrypted, so you should explicitly enable TLS/SSL on those data-source connections rather than assuming it is always on.

Your data does not train the models

Amazon Quick doesn’t use your customer data to train or improve the underlying large language models (LLMs).

Access control and identity federation

Amazon Quick supports role-based access control (RBAC) and single sign-on (SSO) through AWS IAM Identity Center, Microsoft Active Directory, and SAML 2.0 identity providers. For business intelligence (BI) workloads, you can supplement this with row-level and column-level security and run-as roles to limit data access at query time. With these capabilities, you can enforce unique user identification and least privilege.

Audit and monitoring signals

Amazon Quick emits several distinct signals. They aren’t interchangeable, and confusing them is a common audit gap.

  • AWS CloudTrail records supported API operations and a documented set of non-API events, such as dashboard views and user-management actions. It captures who did what and when, but not chat message bodies or response content.
  • Amazon CloudWatch vended logs deliver the AI-specific records to a destination you control (CloudWatch Logs, Amazon S3, or Firehose). There are five log types: chat conversations (CHAT_LOGS), user feedback (FEEDBACK_LOGS), agent and research hours (AGENT_HOURS_LOGS), index storage usage (INDEX_USAGE_LOGS), and knowledge base file sync (KB_FILE_SYNC_LOGS). This is where “what a user asked and what Amazon Quick answered” lives, not in CloudTrail.
  • CloudWatch metrics and alarms provide near-real-time operational monitoring as well.
  • The analytics dashboard surfaces usage and adoption for administrators. Note that it can expose detailed query text and full conversation context in the scope of negative-feedback review, so grant access only to authorized administrators.

Because chat logs and feedback can contain PHI, apply CloudWatch Logs data-protection masking, and confirm that a given signal actually covers the event you intend to track before you rely on it for compliance.

Translating features into HIPAA controls

That Amazon Quick is an eligible service is useful because it maps each feature to a specific HIPAA safeguard, as shown in the following table:

Amazon Quick capability How you use it HIPAA control it supports
Federated SSO + RBAC IAM Identity Center / AD, least-privilege roles 164.312(a)(1) access control. Unique user ID
Document-level ACLs on knowledge bases ACL-aware KBs. Fail-closed at query time 164.312(a)(1) access control. Minimum necessary
Encryption at rest and in transit On by default with AWS managed keys. Optionally a customer managed key for key ownership 164.312(a)(2)(iv) / (e)(2)(ii) encryption
CloudTrail + CloudWatch vended logs Capture API events and chat/feedback records 164.312(b) audit controls
Log retention + masking Retention policy, S3 Object Lock, PII masking 164.316(b) documentation retention
AI guardrails + built-in screening Blocked words/phrases, content safety checks Supports minimum-necessary and integrity goals

What Amazon Quick doesn’t do

While Amazon Quick offers the preceding controls, this section addresses what Amazon Quick doesn’t offer and how to bridge this gap. Amazon Quick governs access, retrieval, and interaction. It isn’t a data-engineering or data-lake governance platform. In a HIPAA context, several needs fall outside Amazon Quick and are met by other AWS services upstream of it.

  • De-identification and transformation. Amazon Quick doesn’t de-identify PHI or reshape source data. When your use case calls for a limited data set or a de-identified extract, prepare it before it reaches Amazon Quick using appropriate AWS services, for example, with AWS Glue DataBrew, a capability of AWS Glue, for visual data preparation and redaction, or AWS Glue for extract, transform, and load (ETL) pipelines.
  • Data lake governance and fine-grained table permissions. For structured data that Amazon Quick Sight queries through a data lake, column- and row-level governance on the lake itself is the role of AWS Lake Formation, not Amazon Quick. Amazon Quick Sight enforces its own row-level and column-level security at the analytics layer, but the authoritative lake-level grants live in Lake Formation and the AWS Glue Data Catalog.
  • The administrative and physical safeguards. Workforce training, risk analysis, and breach procedures remain yours regardless of tooling.

A general best practice is to delineate responsibilities and allow the upstream services to decide what data exists and who can query it at the source. Let Amazon Quick decide who can ask questions of it and what the agent may do with the data.

AnyCompany Health Plan: A sample use case

AnyCompany Health Plan, a fictional health plan, illustrates a use case and pattern. AnyCompany Health Plan is a covered entity that wants two things: let its care-management team ask questions of policy and member-appeals documents in natural language, and give operations leaders self-service dashboards over claims data. Both touch PHI, so AnyCompany needs to confirm the solution is HIPAA compliant. AnyCompany’s environment has two data paths, and each is architected and governed by distinct solutions before Amazon Quick can access the data.

Unstructured path (policy and medical records documents)

→ Amazon S3 bucket (ACL-aware KB source)

→ Amazon Quick Knowledge Base (document-level ACLs, fail-closed at query time)

Structured path (claims)

All claims data currently resides in a lake (Amazon S3).

→ Glue ETL (curate) → Glue DataBrew (de-identify)

→ Lake Formation (row/column grants and AWS Glue Data Catalog)

→ Amazon Quick Sight dataset (Amazon Athena) (row-level and column-level security, run-as role)

Both of the preceding data flows for structured and unstructured data converge into an Amazon Quick chat agent with federated SSO, least-privilege space, guardrails, and CloudWatch vended logs.

Here is how AnyCompany’s administrator implements the solution:

  1. Sign the BAA and provision through the AWS Management Console. The admin accepts the AWS BAA in AWS Artifact against the AWS account, then provisions Amazon Quick from the AWS Management Console with IAM Identity Center. AnyCompany records the agreement ID, timestamp, and account in its compliance register. Only the web version of Amazon Quick, provisioned through the AWS Management Console, can be brought under a signed BAA through AWS Artifact, which is a necessary component for customers building HIPAA-compliant workflows that touch PHI, subject to proper configuration and the customer’s own compliance responsibilities.
  2. Set the irreversible controls on day zero. Because AnyCompany’s security policy calls for control of its own encryption keys, the admin chooses to register a customer managed key as the account default before any Amazon Quick AI data is created. The data key is set once and can’t be changed later. (Default AWS managed encryption is also HIPAA-eligible. Using customer managed keys is not a prerequisite for the service to be HIPAA eligible.) The admin also settles the identity model on IAM Identity Center so that inactive-user detection applies. The Amazon Quick data key is set once on first data creation and can never be changed. If the key is deleted, the only recovery is to unsubscribe and resubscribe, which permanently removes all Amazon Quick data.
  3. Prepare the structured path outside Amazon Quick. Before Amazon Quick Sight touches claims, AnyCompany’s data team uses AWS Glue to build the curated claims tables and Glue DataBrew to produce a de-identified extract for the operations dashboards. AWS Lake Formation grants row- and column-level access on those tables through the AWS Glue Data Catalog. As a result, Amazon Quick never sees raw PHI that it does not need.
  4. Create an ACL-aware knowledge base for the documents. The admin connects the policy-and-appeals S3 bucket as a knowledge base with document-level ACLs enabled at creation. Because ACLs can’t be turned on later, this needs to be configured when you create the S3 bucket. Amazon Quick evaluates each user’s identity at query time and returns no documents when it can’t confirm access.
  5. Build a dedicated space and a custom chat agent. AnyCompany creates a PHI space with restricted membership, separate from general-productivity spaces. The care-management chat agent is scoped to only the ACL-aware knowledge base, with open web search disabled and guardrails configured. Read-only connectors are implemented for anything PHI-adjacent.
  6. Connect the dashboards with query-time security. The operations dashboards read the de-identified Amazon Quick Sight dataset over Athena, with Amazon Quick Sight row-level and column-level security and a run-as role layered on top of the Lake Formation grants.
  7. Turn on the audit signals before onboarding users. The admin creates a CloudTrail trail and configures CloudWatch vended log delivery (CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS, and the rest) to a retained, masked destination. Feedback is treated as a PHI surface.
  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 enforces identity, retrieval, guardrails, and the audit trail. But the de-identification, the ETL, and the lake-level grants happen upstream in Glue, Glue DataBrew, and Lake Formation. This division is the recommended pattern, and is the practical answer to augmenting Amazon Quick in a federated environment.

How to make it compliant: Best practices

Eligibility gives you a platform that can handle PHI. You still must configure it so that it does.

This section helps you understand the shared-responsibility decisions involved. Because a few of these decisions are irreversible, make them before you create resources or onboard users.

Start with the security model for agentic AI

Amazon Quick agents don’t wait for instructions at every step. They invoke tools, modify data, and interact with external systems on their own. That changes how you approach securing your environment. AWS published four security principles for agentic AI in April 2026, and they apply directly here.

Principle 1 — Layer agent safeguards onto your existing security framework. Don’t stand up a parallel security posture for Amazon Quick. Add agent-specific measures (guardrails, topic blocking, and PII redaction) on top of the IAM, network, and encryption policies you already enforce.

Principle 2 — Trust deterministic controls over prompt-based ones. A well-crafted adversarial input can circumvent a prompt instruction. AWS Identity and Access Management (IAM) policies, document-level ACLs, network boundaries, and admin-configured guardrails can’t be talked around. Use those as your primary enforcement. Agent instructions are your second layer, not your only one.

Principle 3 — Apply defense in depth across perceive, reason, and act. Map every agent capability to one of three layers:

  • Perceive: knowledge bases, uploaded files, web search, connector inputs, MCP tool outputs.
  • Reason: the LLM processing context, controlled by guardrails and topic controls.
  • Act: Connectors, Quick Flows, Quick Automate, scheduled tasks, MCP tool calls.

Apply controls at each layer independently. A gap in one shouldn’t cascade into the others.

Note that HIPAA BAA obligations extend to supporting services and solutions like MCP tools.

Principle 4 — Expand autonomy progressively. Start agents in read-only mode against non-PHI data. Add capabilities one at a time. Test for data leakage, prompt-injection resilience, and permission-boundary adherence at each step before moving to the next.

Decide before you deploy

Because these three choices are permanent, make these decisions before implementation.

Register your KMS key first. If your organization requires control of its own encryption keys, register a customer managed key as the account default before creating any Amazon Quick AI resources. The data key is set the first time Quick AI data is created in the account. After that, it can’t be changed. Customer managed key support requires an Enterprise subscription. Note that a customer managed key disables chat memory. Accounts configured with a customer managed key do not support this feature.

Choose your identity model deliberately. You have four options: IAM Identity Center, Active Directory, IAM federation, and Quick local users. They differ in provisioning, offboarding, and governance behavior. Inactive-user detection, for instance, works only with IAM Identity Center or Active Directory. Switching identity providers after deployment means reprovisioning every user’s permissions and space memberships. Pick once.

Make PHI knowledge bases ACL-aware at creation. For supported sources (Amazon S3, Google Drive, SharePoint, Confluence Cloud, and OneDrive), you decide at creation whether a knowledge base enforces document-level ACLs. That setting is permanent. You can’t enable ACLs on a knowledge base that was created without them. For anything PHI-adjacent, create it ACL-aware from the start.

Warning: Misconfigured user-store mappings can silently expose restricted documents to the wrong users, without errors or alerts. It’s critical to validate your identity-to-ACL mapping before you ingest PHI content.

AWS Region, network, and account boundaries

Plan your deployment Region based on the following factors:

  • Data residency: Amazon Quick processes and stores data in the Region where you provision it, and you need to confirm that Region satisfies your organization’s data-localization requirements. Note that Amazon Quick is a single-Region service: it benefits from multi-AZ resilience within a Region, but it doesn’t fail over across Regions. If you support business-critical workflows that require cross-Region resilience, provision a separate Amazon Quick deployment in a second Region, along with its supporting data, for example, replicating S3-based knowledge base sources across Regions.
  • Service availability. Features are at times launched in different Regions at different times. Verify that everything your agents need, such as knowledge bases, connectors, and Amazon Quick Sight capabilities, is available where you plan to deploy.
  • Multi-account strategy. Place Amazon Quick in a dedicated workload account in AWS Organizations. Use Service Control Policies (SCPs) to enforce Region restrictions and block accidental provisioning in out-of-scope Regions.

For network boundaries: Amazon Quick is a managed service accessed over HTTPS. You don’t deploy it into a virtual private cloud (VPC). But your data sources (S3 buckets, databases, on-premises systems) might sit behind VPC boundaries. Use VPC endpoints and AWS PrivateLink where available. Make sure DNS resolution and firewall rules let Amazon Quick’s connectors reach your authorized data sources without opening the network wider than necessary.

Minimize the agent’s attack surface

Amazon Quick’s own documentation frames adversarial risk as a two-condition problem: risk exists when (1) an agent can read content from outside your trust boundary, and (2) it can take a consequential action. Narrow either condition and you reduce exposure.

Constrain what agents can read (Perceive layer). Know every source that feeds an agent’s context: knowledge bases, uploaded files, web search, third-party research providers, connector responses, MCP tool outputs, and retained conversation memory. For PHI workflows:

  • Scope agents to trusted, ACL-aware knowledge bases.
  • Turn off open web search where it isn’t needed.
  • Turn off file upload if the agent doesn’t require it.
  • Limit conversation-history retention to the minimum useful window.

Constrain what agents can do (Act layer). Inventory every outbound path: connectors, MCP tools, web queries, Quick Flows, Quick Automate workflows, scheduled agent runs. For PHI-adjacent agents:

  • Prefer read-only connector access.
  • Be cautious with automated and scheduled workflows, because they run without anyone watching.
  • Block write actions unless explicitly justified and approved by your security team.
  • Use connector-level permission scoping to restrict which operations an agent can invoke.

Know the identity an action runs as. On-demand actions authenticate as the invoking user, bounded by that user’s connector permissions. Automated workflows run without an interactive session. Match the autonomy level to the sensitivity of the action, and document which agents operate in which identity mode.

Enforce least privilege and data segregation

  • Separate PHI-containing knowledge bases and spaces from general-productivity ones. Restrict membership.
  • Grant space and agent access on a need-to-know basis. Review both sharing permissions (who can use a knowledge base) and source-document ACLs (which indexed documents an authorized user can actually retrieve).
  • The default knowledge-base refresh cycle is 24 hours. Shorten it when your access-change requirements demand faster propagation. Refresh ACLs before reassigning or recycling email addresses.
  • A PHI agent shouldn’t share a space with general-purpose productivity tools. This means you need to isolate use cases at the space level.
  • Review connector permissions regularly. Rotate credentials stored in AWS Secrets Manager on a schedule that matches your credential-management policy.

Practice data minimization

AWS recommends against entering confidential data into resource names or tags, to avoid accidental mention in billing or diagnostic logs.

  • Prefer de-identified data wherever the use case allows it.
  • When ingesting structured data from databases or APIs, filter columns and rows at the source before indexing.
  • Configure agent guardrails to redact PII in responses, hiding Social Security numbers (SSNs), medical record numbers (MRNs), and dates of birth, using the built-in PII detection filters.

Configure audit logging and retention

Amazon Quick provides several distinct audit signals. None of them flow by default and you might need to turn them on.

Signal Source What it captures
API operations CloudTrail Admin actions, configuration changes
Chat interactions CloudWatch CHAT_LOGS — full conversation records
User feedback CloudWatch FEEDBACK_LOGS — thumbs up/down with context
KB sync events CloudWatch KB_FILE_SYNC_LOGS — ingestion status
Operational metrics CloudWatch Latency, error rates, invocation counts
Usage analytics Quick console Adoption, top queries, user activity

Here is how to set them up:

  1. Create a CloudTrail trail for the accounts and Regions in scope.
  2. Configure CloudWatch vended log delivery (CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS) shortly after you turn on Amazon Quick’s AI features.
  3. Apply CloudWatch Logs data-protection masking to chat logs so PHI isn’t stored in cleartext.
  4. Set a retention period of at least six years. Consider S3 Object Lock on the log archive.
  5. Add CloudWatch alarms for anomalous activity.
  6. Enable AWS Security Hub for continuous compliance checks.
  7. Route critical alerts to your security information and event management (SIEM) or incident-response platform.

Validate before you scale

Before expanding scope, check the following:

  • BAA acceptance is recorded in your compliance register.
  • Data classification is documented: Which knowledge bases and spaces contain PHI, which agents can reach them.
  • Adversarial queries and prompt-injection scenarios have been tested.
  • Logs are being captured and masking works correctly.
  • A tabletop breach exercise has been completed.
  • InfoSec has signed off.

Known limitations

Here are some known limitations of Amazon Quick.

  • No BAA on the Free or Plus path. You must use the path provisioned through the AWS Management Console to get BAA coverage.
  • No cross-Region replication. Disaster recovery (DR) is constrained to a single Region.
  • Guardrails are probabilistic, not deterministic. They reduce risk. They don’t eliminate it. Supplement with the infrastructure-level controls described earlier.
  • Third-party connectors extend your BAA obligations. When a connector sends data to an external system, your compliance responsibility follows the data.
  • Conversation memory might contain echoed PHI. Set retention policies and apply masking.

Implementation guide

The AnyCompany Health Plan example showed how to roll out Amazon Quick. This section turns that pattern into a step-by-step project plan you can hand to your platform team.

Step 1: Execute the BAA (Day 1)

  • Sign in with AWS Artifact permissions and accept the BAA.
  • Record the agreement ID, timestamp, principal ARN, and account ID.
  • Notify your legal and compliance team.

Step 2: Set foundational, irreversible controls (Days 1–2)

  • Register a customer managed key as the account default.
  • Verify the key policy grants the required permissions: Encrypt, Decrypt, GenerateDataKey, DescribeKey.
  • Configure your identity model (IAM Identity Center is recommended).
  • Confirm the account sits in a dedicated workload organizational unit (OU) with Region-restricting SCPs.

Step 3: Create ACL-aware knowledge bases (Days 3–7)

  • Classify your data sources: PHI, PHI-adjacent, and non-PHI.
  • Create knowledge bases with ACL awareness turned on for PHI and PHI-adjacent sources.
  • Map the identity store to source permissions and validate with multiple test users.
  • Verify sync logs confirm successful ingestion. Keep PHI knowledge bases separated from general content.

Step 4: Create spaces (Days 5–8)

  • Separate PHI-adjacent spaces from general-productivity spaces.
  • Attach knowledge bases, dashboards, and action connectors. Restrict membership.
  • Confirm that unauthorized users are blocked.

Step 5: Create custom agents with guardrails (Days 7–12)

  • Define each agent’s purpose narrowly. Attach only the knowledge sources it needs.
  • Configure PII redaction, blocked topics, content filters, and grounding controls.
  • Test with normal queries, boundary queries, and adversarial prompts.
  • Document results and remediation steps.

Step 6: Configure action connectors (Days 10–14)

  • Start with read-only mode for PHI-adjacent data. Scope each connector to specific resources.
  • Store credentials in AWS Secrets Manager with rotation turned on.
  • Document the justification for any write access. Get security sign-off before turning it on.
  • Test scope limits to confirm connectors can’t reach resources beyond their intended scope.

Step 7: Configure audit, retention, and monitoring (Days 12–16)

  • Enable CloudTrail and CloudWatch vended logs.
  • Apply data-protection masking. Set retention to at least six years. Enable S3 Object Lock.
  • Configure alarms, enable Security Hub, and integrate with your SIEM.

Step 8: Validate with InfoSec (Days 14–21)

  • Compile the evidence package: BAA confirmation, KMS configuration, identity setup, data classification, test results, and log samples.
  • Run a tabletop breach exercise.
  • Present to your InfoSec team. Remediate findings. Obtain sign-off.

Expansion phase (Weeks 4–8)

Start with non-PHI workflows: policy Q&A, document search, meeting prep, workflow automation. These let your team build confidence with the platform before PHI enters the picture.

Then expand to PHI-adjacent workflows: clinical documentation assistance, claims processing, prior authorization, regulatory Q&A, patient communication drafting with human review in the loop.

Monitor closely: review chat logs weekly, track guardrail trigger rates, and watch access patterns for 30 days after each new workflow goes live.

Conclusion

Amazon Quick gives regulated healthcare organizations, and the business associates who serve them, a managed AI workspace that is HIPAA-eligible across its full range of capabilities: agentic AI, knowledge retrieval, business intelligence, automation, and research.

The path to a compliant deployment follows a clear sequence:

  1. Understand the difference between eligible and compliant, and own your side of shared responsibility.
  2. Execute the BAA on an account provisioned through the AWS Management Console.
  3. Set the irreversible controls first: KMS keys, identity model, ACL-aware knowledge bases.
  4. Minimize the agent’s read and action surfaces, enforce least privilege, and mask PHI in logs.
  5. Validate with your InfoSec team, then scale from non-PHI to PHI-adjacent workflows.

The compliance expectations are moving as fast as the technology. AWS published its four security principles for agentic AI in April 2026 and the Well-Architected Agentic AI Lens in June 2026. Organizations that build on deterministic, infrastructure-level controls today will likely be well positioned as regulatory expectations catch up to what agentic AI can do.

What to do next

If you’re evaluating Amazon Quick: Request a compliance-focused briefing from your AWS account team. Ask about BAA scope, shared responsibility for agentic AI, and the latest HIPAA-eligible service additions.

If you’re ready to deploy: Use the implementation guide as your project plan. The irreversible decisions in Step 2 deserve a dedicated architecture review before you start creating resources.

If you’re already running Amazon Quick: Audit your deployment against the best practices in this post, especially the agentic security principles and the known limitations list.

For architecture guidance, reach out to your AWS Solutions Architect or the AWS Healthcare and Life Sciences team.

About the authors