如何使用 Amazon Quick 在 HIPAA eligible 環境部署 AI

醫療機構希望 AI 做到的，與其他企業的期望相同：更快取得答案、減少人手工作，並讓決策者及時取得洞察，以便採取行動。然而，醫療行業的不同之處在於，其資料複雜性獨特、高度依賴情境，而且受到嚴格規管。因此，本文先介紹幾個定義，為下文內容奠定基礎。

受保護健康資料（Protected Health Information，PHI）是指任何可識別個人身份，並與其健康狀況、醫療護理或醫療費用支付相關的資料，例如醫療紀錄、索償申請或會員編號。軟件一旦接觸 PHI，便受《健康保險流通與責任法案》（Health Insurance Portability and Accountability Act，HIPAA）規管；這項聯邦法例訂明如何存取、保護及稽核 PHI 資料。

Agentic AI 改變了軟件「接觸 PHI」的含義。傳統分析工具會讀取資料並提供回應。像 Amazon Quick 這樣的代理式工作空間，則可能做到更多。例如，它的聊天代理可處理非結構化內容（例如臨牀紀錄和申訴信），以及結構化資料（例如索償資料和會員紀錄）。代理可能會從非結構化及結構化來源擷取資料、透過連接器呼叫其他系統，並代表用戶完成多步驟工作。連接器是預先建立的整合功能，讓 Amazon Quick 能安全地從外部系統讀取資料並執行操作，例如 Slack、Microsoft Outlook、Salesforce、Atlassian Jira 和 Microsoft SharePoint。你也可以透過 Model Context Protocol (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。
• 醫療保健資料交換機構 – 將非標準健康資料轉換為標準電子格式的機構。
• 醫療服務提供者 – 醫生、診所、醫院、藥房、護理院，以及任何以電子方式傳送健康資訊的服務提供者。

業務夥伴（BAs）

• 業務夥伴是指受涵蓋實體員工隊伍以外，代表該實體建立、接收、保存或傳送受保護健康資訊（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 資格的服務，第三方審計人員會根據 AWS 的合規計劃評估該服務，計劃包括 HIPAA、FedRAMP、PCI DSS、SOC 及 ISO。AWS 作為雲端服務並沒有正式的 HIPAA 認證，而 AWS 本身也不「符合 HIPAA 資格」。

Amazon Quick 符合資格只是其中一項基礎。單憑這點，並不代表你的應用程式及環境符合 HIPAA 規範。你仍須簽署 BAA、為數據分類、正確設定控制措施，並負責 HIPAA 要求的行政及實體保障措施，包括 AWS 不會代你執行的員工培訓、風險分析及資料外洩處理程序。符合 HIPAA 資格的服務（例如 Amazon Quick）、已簽署的 BAA、正確的設定、管治措施，以及你自行實施的保障措施，合起來才能建立符合 HIPAA 規範的部署環境。Amazon Quick 符合資格，表示你可以在其上建立符合規範的工作流程；這不代表只要啟用服務，你便會自動符合規範。

甚麼是 Amazon Quick

介紹 Amazon Quick 時，通常會先提到它的聊天代理；但 HIPAA 資格適用於整個工作區，而非單一功能，因此從平台層面瞭解服務對合規至關重要。Amazon Quick 的所有功能均由以下基礎構件組成：

• 聊天是主要介面。用戶可以用自然語言提出問題或提供指示，而 Amazon Quick 會決定如何回應。
• 聊天代理會處理每項要求。你可以在主控台的「聊天代理」功能表中看到它。每個聊天代理都可以設定指示、以知識來源作為依據，並獲提供可用於執行操作的工具。Amazon Quick 隨附預設聊天代理（My Assistant），你也可以為特定領域建立自訂聊天代理。
• 空間會整理聊天代理所需的資源，例如文件、儀錶板、數據集、知識庫及動作連接器。空間可以與團隊共用。
• 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).

  這些基礎元件之上，是各項功能。「所使用的基礎」一欄與合規工作息息相關，因為它顯示每項功能使用哪些基礎元件，因而也顯示其使用哪些數據路徑。

注意：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 要求。如需直接控制加密金鑰，可為適用的資源類型註冊客戶管理的 AWS KMS 金鑰（需要 Enterprise 訂閲）；這些資源類型包括 SPICE 數據集、數據來源憑證、OAuth 權杖及報告成品。凡不適用客戶管理金鑰的數據，AWS 會使用 AWS 自有或 AWS 管理的金鑰加密。
• 有一點需要注意：用戶對聊天回應提供的意見，包括可選的自由文字評論，不會使用你的客戶管理金鑰或保護 Amazon Quick AI 索引數據的金鑰加密。用戶意見應視為潛在的 PHI 暴露面，並按此作出管理。
• 對於傳輸中的資料，Amazon Quick 使用 Transport Layer Security (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 和研究時數 (AGENT_HOURS_LOGS)、索引儲存空間用量 (INDEX_USAGE_LOGS)，以及知識庫檔案同步 (KB_FILE_SYNC_LOGS)。用戶提出的問題及 Amazon Quick 給出的回答會記錄在這裏，而不是 CloudTrail。
• CloudWatch 指標和警示亦提供近乎即時的操作監察。
• 分析儀錶板會向管理員顯示用量和採用情況。請注意，在審查負面意見時，儀錶板可能會顯示詳細的查詢文字及完整對話內容，因此只應向獲授權的管理員授予存取權。

由於聊天日誌和意見可能包含 PHI，請使用 CloudWatch Logs 的資料保護遮罩功能；在為合規用途依賴某項訊號前，亦請確認該訊號確實涵蓋你要追蹤的事件。

將功能對應至 HIPAA 控制措施

Amazon Quick 屬於 HIPAA 合資格服務，這點很有用，因為它會將各項功能對應至特定 HIPAA 防護措施，如下表所示：

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 決定誰可以向它提問，以及 Agent 可以如何使用這些數據。

AnyCompany Health Plan：示例使用案例

AnyCompany Health Plan 是虛構的健康計劃，用來説明一個使用案例及模式。AnyCompany Health Plan 是受 HIPAA 規管的實體，有兩項需求：讓護理管理團隊以自然語言查詢保單及會員申訴文件，並為營運主管提供自助式理賠數據儀錶板。兩者都涉及 PHI，因此 AnyCompany 需要確認方案符合 HIPAA 規定。AnyCompany 的環境有兩條數據路徑；在 Amazon Quick 存取數據前，每條路徑都會透過不同的方案進行架構設計及治理。

非結構化路徑（保單及醫療紀錄文件）

→ Amazon S3 儲存貯體（支援 ACL 的知識庫來源）

→ Amazon Quick Knowledge Base（文件層級 ACL；查詢時採用失敗即拒絕存取機制）

結構化路徑（理賠數據）

所有理賠數據目前都存放在數據湖（Amazon S3）。

→ Glue ETL（整理）→ Glue DataBrew（去識別化）

→ Lake Formation（列／欄位權限及 AWS Glue Data Catalog）

→ Amazon Quick Sight 數據集（Amazon Athena）（列層級及欄位層級安全性、執行角色）

上述結構化及非結構化數據流程都會匯入 Amazon Quick 聊天 Agent，並配備聯合式 SSO、最小權限空間、防護措施，以及 CloudWatch 提供的日誌。

以下説明 AnyCompany 的管理員如何實施此方案：

1. 簽署 BAA，並透過 AWS Management Console 配置服務。管理員在 AWS Artifact 中為 AWS 帳戶接受 AWS BAA，然後透過 AWS Management Console 使用 IAM Identity Center 配置 Amazon Quick。AnyCompany 會在其合規登記冊記錄協議 ID、時間戳記及帳戶。只有透過 AWS Management Console 配置的 Amazon Quick 網頁版，才能透過 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. 建立專用空間及自訂聊天 Agent。AnyCompany 會建立一個限制成員資格的 PHI 空間，並與一般工作效率空間分開。照護管理聊天 Agent 的範圍僅限於支援 ACL 的知識庫，並停用開放網絡搜尋及設定防護措施。所有與 PHI 相關的連接器均採用唯讀設定。
6. 以查詢時安全控制連接儀錶板。營運儀錶板會透過 Athena 讀取去識別化的 Amazon Quick Sight 數據集，並在 Lake Formation 授予的權限之上，加入 Amazon Quick Sight 列層級及欄層級安全控制，以及 run-as 角色。
7. 在用戶開始使用前啟用稽核記錄。管理員會建立 CloudTrail trail，並設定 CloudWatch vended log delivery（CHAT_LOGS、FEEDBACK_LOGS、KB_FILE_SYNC_LOGS 等），將記錄傳送至設有保留期限及遮罩的目的地。意見回饋會視為 PHI 接觸面。
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 負責執行身分控管、檢索、防護機制及稽核追蹤。不過，去識別化、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) 政策、文件層級存取控制清單、網絡邊界，以及由管理員設定的防護機制，都無法透過説服來繞過。應以這些措施作為主要的執行手段。代理程式指示是第二層防護，而不是唯一防線。

原則 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 是單一區域服務：它在單一區域內具備多可用區韌性，但不會在不同區域之間進行故障轉移。如果你支援需要跨區域韌性的業務關鍵工作流程，請在另一個區域佈建獨立的 Amazon Quick 部署環境，並配置相應的支援資料，例如將以 S3 為基礎的知識庫來源複製到不同區域。
• 服務供應情況。功能有時會在不同時間於不同區域推出。請確認 Agent 所需的一切功能，例如知識庫、連接器及 Amazon Quick Sight 功能，均可在計劃部署的區域使用。
• 多帳戶策略。請在 AWS Organizations 中的專用工作負載帳戶部署 Amazon Quick。使用服務控制政策（SCP）設定區域限制，並阻止意外在不符合範圍要求的區域佈建服務。

在網絡界線方面：Amazon Quick 是透過 HTTPS 存取的受管理服務。你不會將它部署到虛擬私有雲（VPC）內。不過，你的資料來源（S3 儲存貯體、數據庫、本地系統）可能位於 VPC 網絡界線之內。請在可用的情況下使用 VPC 端點和 AWS PrivateLink。確保 DNS 解析和防火牆規則允許 Amazon Quick 的連接器連線至已授權的資料來源，同時避免不必要地擴大網絡存取範圍。

縮小 Agent 的攻擊面

Amazon Quick 的官方文件將對抗性風險視為由兩個條件構成的問題：當 (1) Agent 可以讀取信任邊界以外的內容，而且 (2) 可以執行會造成重大影響的操作時，風險便會出現。縮小其中任何一項條件的範圍，都能降低風險暴露。

限制 Agent 可讀取的內容（Perceive 層）。瞭解所有會向 Agent 上下文提供資料的來源：知識庫、上載的檔案、網頁搜尋、第三方研究服務供應商、連接器回應、MCP 工具輸出，以及保留的對話記憶。對於 PHI 工作流程：

• 將 Agent 限定於可信且支援 ACL 控制的知識庫。
• 在不需要時，停用開放式網頁搜尋。
• 如果 Agent 不需要上載檔案，請停用檔案上載。
• 將對話記錄的保留時間限制在足以使用的最短時段。

限制 Agent 可執行的操作（Act 層）。盤點所有對外連線途徑：連接器、MCP 工具、網絡查詢、Quick Flows、Quick Automate 工作流程，以及排程執行的 Agent。對於涉及 PHI 的 Agent：

• 優先採用唯讀連接器存取權限。
• 審慎處理自動化及排程工作流程，因為這些流程執行時無人監察。
• 除非有明確理由並獲保安團隊批准，否則禁止寫入操作。
• 使用連接器層級的權限範圍設定，限制 Agent 可呼叫的操作。

瞭解操作以哪個身分執行。按需執行的操作會以發起用戶的身分驗證，並受該用戶的連接器權限限制。自動化工作流程執行時不會有互動式工作階段。操作的自主程度應配合其敏感程度，並記錄各 Agent 採用的身分模式。

實施最小權限原則及資料隔離

• 將包含 PHI 的知識庫和空間，與一般生產力用途的知識庫和空間分開。限制成員資格。
• 按知情需要授予空間及 Agent 存取權限。檢視分享權限（哪些用戶可使用知識庫）及來源文件 ACL（獲授權用戶實際可擷取哪些已建立索引的文件）。
• 知識庫的預設更新週期為 24 小時。當存取權限變更要求更快生效時，請縮短週期。重新指派或回收電郵地址前，先更新 ACL。
• 處理 PHI 的 Agent 不應與一般用途的生產力工具共用空間。因此，你需要在空間層級隔離不同用途。
• 定期檢視連接器權限。按照憑證管理政策所定的週期，輪換儲存在 AWS Secrets Manager 的憑證。

實踐資料最小化

AWS 建議不要在資源名稱或標籤中輸入機密資料，以免資料意外出現在帳單或診斷日誌中。

• 在用途許可的情況下，優先使用去識別化資料。
• 從資料庫或 API 擷取結構化資料時，應在來源端篩選欄和資料列，再建立索引。
• 設定 Agent 防護措施，在回應中遮蓋個人身份識別資料（PII），利用內置的 PII 偵測篩選器隱藏社會保障號碼（SSNs）、醫療紀錄號碼（MRNs）及出生日期。

設定審計日誌記錄及保留期限

Amazon Quick 提供多種不同的審計訊號。這些訊號預設都不會傳送，你可能需要啟用它們。

設定方法如下：

1. 為涵蓋範圍內的帳戶和區域建立 CloudTrail trail。
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. 將重要警示轉送至安全資訊與事件管理（SIEM）或事故應變平台。

擴大規模前先驗證

擴大範圍前，請檢查以下事項：

• 已在合規登記冊記錄 BAA 的接受情況。
• 已記錄資料分類：哪些知識庫和空間包含 PHI，以及哪些 Agent 可以存取這些資料。
• 已測試對抗式查詢和提示詞注入情境。
• 正在擷取日誌，而且遮蔽功能運作正常。
• 已完成資料外洩桌上演習。
• 資訊安全部門已批准。

已知限制

以下是 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）。
• 確認帳戶位於專用的工作負載組織單位 (OU) 中，並套用限制區域的 SCP。

步驟 3：建立具備 ACL 感知功能的知識庫（第 3–7 天）

• 將資料來源分類為 PHI、PHI 相鄰資料及非 PHI。
• 為 PHI 及 PHI 相鄰資料來源建立知識庫，並啟用 ACL 感知功能。
• 將身分儲存庫對應至來源權限，並使用多個測試用戶進行驗證。
• 確認同步日誌顯示資料已成功匯入。將 PHI 知識庫與一般內容分開。

步驟 4：建立空間（第 5–8 天）

• 將 PHI 相鄰資料空間與一般生產力空間分開。
• 連接知識庫、儀錶板及動作連接器，並限制成員資格。
• 確認未獲授權的用戶會被拒絕存取。

步驟 5：建立配備防護機制的自訂 Agent（第 7–12 天）

• 嚴格界定每個 Agent 的用途，只連接所需的知識來源。
• 設定 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 Management Console 建立的帳戶上簽訂 BAA。
3. 先設定不可逆的控制項：KMS 金鑰、身分模型，以及具備 ACL 感知能力的知識庫。
4. 盡量縮小 Agent 可讀取的資料範圍及可執行的操作範圍，落實最小權限原則，並遮蔽日誌中的 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：根據本文的最佳做法審核部署，尤其是代理式 AI 安全原則及已知限制清單。

如需架構指引，請聯絡你的 AWS 解決方案架構師或 AWS Healthcare and Life Sciences 團隊。

作者簡介

Meena Menon

Meena 是 AWS 的資深 客戶成功經理，擁有超過 20 年交付企業客戶成果及推動數碼轉型的經驗。在 AWS，她與安全、可觀測性及醫療保健領域的策略性 ISV 合作，協助他們在 AWS 上推出並擴展 AI 工作負載。她擁有豐富的跨行業經驗，曾與這些 ISV 合作推動雲端採用、平台現代化，並將新興技術轉化為可量度的業務效益。

Shailesh Doshi

Shailesh 是 AWS 的資深客戶解決方案經理，擁有超過 30 年跨多個行業領域的經驗，協助機構將雲端和 AI 投資轉化為可量化的業務價值。目前，他專注於醫療保健及生命科學領域，與醫療服務提供者、付款方及生命科學創新者合作，協助他們實現策略目標，並透過人工智能、機器學習和分析釋放企業價值，推動 GenAI 採用率倍數增長。Shailesh 與行政及技術團隊緊密合作，加快 GenAI 投資、推動採用，並將關鍵任務平台現代化。