AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
Healthcare organizations want the same thing from AI that every other business wants: faster answers, less manual work, and insights that reach decision-makers in time to act on them. However, what makes the healthcare industry different is that the data is uniquely complex, deeply contextual, and strictly regulated. So this post starts with a few definitions to set the foundation for everything that follows. Protected Health Information (PHI) is any information that identifies a person and relates to their health, care, or payment for care, such as a medical note, a claim, or a member ID. When software touches PHI, it falls under the Health Insurance Portability and Accountability Act (HIPAA), the federal law that governs how PHI data is accessed, secured, and audited. Agentic AI changes what it means for software to “touch PHI.” A traditional analytics tool reads data and returns a response. An agentic workspace like Amazon Quick might go further. For example, its chat agents work across both unstructured content, such as clinical notes and appeals letters, and structured data, such as claims and member records. Agents might retrieve data from both unstructured and structured sources, call other systems through connectors, and complete multi-step tasks on a user’s behalf. Connectors are pre-built integrations that let Amazon Quick securely read from and take action in your external systems, such as Slack, Microsoft Outlook, Salesforce, Atlassian Jira, and Microsoft SharePoint. You can also add your own custom tools through Model Context Protocol (MCP). Only connectors authorized within your organization are visible. When a chat agent can both read and act on PHI, you need sufficient governance: deterministic guardrails, a behavioral audit trail of what the agent did, and clear accountability for actions taken without a person in the loop. To support that governance, Amazon Quick exposes ACL-aware retrieval, chat and feedback logging, and controls over what each chat agent is allowed to do. Amazon Quick is a HIPAA-eligible service. This eligibility applies across the Amazon Quick web, desktop, and mobile clients, subject to the shared responsibility model and your configuration. This post, however, focuses on the capabilities of the Amazon Quick web version, which you access through your browser. In this post, we start with the foundations: who HIPAA applies to and the difference between HIPAA-eligible and HIPAA-compliant. We then introduce Amazon Quick as a platform and the two data flows for PHI (unstructured and structured). From there, we cover what Amazon Quick provides for regulated environments and what it doesn’t, walk through a fictional health plan (AnyCompany) deployment, and distill the best practices and irreversible decisions you should make up front. We close with a step-by-step implementation guide, a conclusion, and resources for deeper reading. Who does HIPAA apply to? HIPAA reaches further than hospitals and clinics. Under the law, two categories of organizations carry obligations, and most AI projects touch both. Covered entities (CEs) Health plans – Health insurance companies, HMOs, employer-sponsored plans, Medicare, and Medicaid. Healthcare clearinghouses – Organizations that process nonstandard health information into standard electronic formats. Healthcare providers – Doctors, clinics, hospitals, pharmacies, nursing homes, and any provider that transmits health information electronically. Business associates (BAs) A business associate is any person or entity, outside the covered entity’s workforce, that creates, receives, maintains, or transmits protected health information (PHI) on the covered entity’s behalf. Common examples include cloud service providers, IT vendors, billing companies, data analytics firms, claims processors, law firms, and consulting firms. Subcontractors who handle PHI on behalf of another business associate are themselves business associates. Covered entities and business associates must both sign a business associate addendum (BAA) before PHI changes hands. After you accept the AWS BAA through AWS Artifact, AWS acts as your business associate for that specific AWS account, and only when you use HIPAA-eligible services like Amazon Quick to process PHI within it. The addendum doesn’t extend to your other accounts, to PHI placed in services that are not HIPAA-eligible, or to how you configure the service. Those remain your responsibility. Always review and confirm the current AWS BAA terms and your obligations with your own legal and compliance teams. HIPAA eligible is not the same as HIPAA compliant While HIPAA eligible is an AWS designation, HIPAA compliant is a property of your entire environment. HIPAA eligible means AWS has assessed the service and permits you to use it to process, store, and transmit PHI under a signed AWS BAA. Amazon Quick is a HIPAA-eligible service, and third-party auditors assess it under AWS compliance programs including HIPAA, FedRAMP, PCI DSS, SOC, and ISO. No official HIPAA certification exists for AWS as a cloud service, and AWS itself is not “HIPAA eligible.” Amazon Quick eligibility serves only as a building block. That alone doesn’t make your application and environment HIPAA compliant. You still need to sign the BAA, classify your data, configure the controls correctly, and own the administrative and physical safeguards HIPAA requires, including workforce training, risk analysis, and breach procedures that AWS doesn’t perform for you. An eligible service such as Amazon Quick, a signed BAA, correct configuration, governance, and your own safeguards is what produces a HIPAA-compliant deployment. Amazon Quick being eligible means you can build a compliant workflow on it. It doesn’t mean that turning it on makes you automatically compliant. What is Amazon Quick Amazon Quick is often introduced through its chat agents, but HIPAA eligibility applies to the entire workspace, not to a single feature, so a platform-level view matters for compliance. All capabilities in Amazon Quick are assembled from the following building blocks: Chat is the primary interface. A user can pose a question or provide an instruction in natural language, and Amazon Quick decides how to respond. Chat agents process every request. This is what you see on the console, under the Chat agents menu. Each chat agent can be configured with instructions, grounded by knowledge sources, and given tools to take action. Amazon Quick ships a default chat agent (My Assistant), and you can create custom chat agents for specific domains. Spaces organize the resources a chat agent needs, such as documents, dashboards, datasets, knowledge bases, and action connectors. A space can be shared with a team. 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). On top of those building blocks sit the features. The What it draws on column matters for compliance, because it shows which building blocks, and therefore which data paths, each feature draws on. Feature What it does What it draws on Amazon Quick Sight Interactive dashboards and analytics (BI) Structured data connections, SPICE, datasets Amazon Quick Flows Task automation Action connectors, spaces, agent logic Amazon Quick Automate End-to-end process automation with human-in-the-loop Action connectors, agents, human review Amazon Quick Research In-depth, cited research reports Spaces, knowledge bases, web Apps in Quick Interactive web applications Structured data, connectors, Amazon Quick Sight visuals Note: SPICE is the in-memory query engine of Amazon Quick Sight. A SPICE dataset uses the account default customer managed key at creation, and to import an existing dataset onto a new default key you must perform a full refresh. If your data includes PHI, include SPICE in your encryption strategy (protect it with your customer managed AWS Key Management Service (KMS) key if you use one) and in your data-minimization decisions about what to import, such as querying live or loading a de-identified extract instead. The same eligibility, BAA, encryption, access control, and audit posture extend across every feature. But as noted at the start, PHI reaches Amazon Quick through two paths, and each is secured differently. The unstructured path runs through knowledge bases, where the documents are controlled by document-level ACLs and evaluated at query time. The structured path runs through Amazon Quick Sight reading your databases and data lakes, where row and column access is controlled by row-level and column-level security. These two data flows carry PHI differently and, as the following section shows, controls are enforced differently in each path. What Amazon Quick provides for regulated environments Amazon Quick is HIPAA eligible, and we outline what that means in practice. Managed infrastructure Amazon Quick is a fully managed service. AWS operates the underlying infrastructure and is responsible for security of the cloud, verified by third-party auditors as laid out in the AWS Shared Responsibility Model. Encryption Amazon Quick encrypts data at rest by default and supports encryption for data in transit. Encryption at rest is on by default using AWS owned or AWS managed keys. Registering a customer managed key is optional and is not a HIPAA requirement. If you require direct control over the encryption keys, you can register a customer managed AWS KMS key (requires an Enterprise subscription) for participating resource types, including SPICE datasets, data source credentials, OAuth tokens, and report artifacts. Where no customer managed key applies, AWS encrypts the data with an AWS owned or AWS managed key. One nuance to note: User feedback on chat responses, including optional free-text comments, isn’t encrypted with your customer managed key or the key that protects Amazon Quick’s AI-indexed data. User feedback should be treated as a potential PHI surface and governed accordingly. 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), in [truncated for AI cost control]