KI in einer HIPAA-fähigen Umgebung mit Amazon Quick bereitstellen

Organisationen im Gesundheitswesen wollen von KI dasselbe wie jedes andere Unternehmen: schnellere Antworten, weniger manuelle Arbeit und Erkenntnisse, die rechtzeitig bei den Entscheidungsträgern ankommen, damit diese handeln können. Was die Gesundheitsbranche jedoch unterscheidet, ist, dass die Daten einzigartig komplex, stark kontextabhängig und streng reguliert sind. Daher beginnt dieser Beitrag mit einigen Definitionen, um das Fundament für alles Folgende zu legen.

Geschützte Gesundheitsinformationen (Protected Health Information, PHI) sind alle Informationen, die eine Person identifizieren und in Bezug zu ihrer Gesundheit, ihrer Versorgung oder der Bezahlung von Versorgung stehen, z. B. eine medizinische Notiz, ein Anspruch oder eine Mitglieds-ID. Wenn Software PHI verarbeitet, fällt sie unter den Health Insurance Portability and Accountability Act (HIPAA), das Bundesgesetz, das regelt, wie auf PHI-Daten zugegriffen, wie sie gesichert und wie sie geprüft werden.

Agentic AI verändert, was es bedeutet, wenn Software „PHI verarbeitet“. Ein traditionelles Analyse-Tool liest Daten und gibt eine Antwort zurück. Ein agentischer Arbeitsbereich wie Amazon Quick kann weitergehen. Zum Beispiel arbeiten seine Chat-Agenten sowohl mit unstrukturierten Inhalten, wie klinischen Notizen und Widerspruchsschreiben, als auch mit strukturierten Daten, wie Ansprüchen und Mitgliedsdatensätzen. Agenten können Daten sowohl aus unstrukturierten als auch aus strukturierten Quellen abrufen, über Konnektoren andere Systeme aufrufen und mehrstufige Aufgaben im Auftrag eines Benutzers ausführen. Konnektoren sind vorgefertigte Integrationen, mit denen Amazon Quick sicher aus Ihren externen Systemen lesen und in ihnen Aktionen ausführen kann, z. B. Slack, Microsoft Outlook, Salesforce, Atlassian Jiraund Microsoft SharePoint. Sie können auch eigene benutzerdefinierte Tools über das Model Context Protocol (MCP) hinzufügen. Nur Konnektoren, die innerhalb Ihrer Organisation autorisiert sind, sind sichtbar. Wenn ein Chat-Agent sowohl PHI lesen als auch damit handeln kann, benötigen Sie ausreichende Governance: deterministische Schutzmaßnahmen, eine Verhaltensprüfprotokoll-Spur dessen, was der Agent getan hat, und klare Verantwortlichkeit für Aktionen, die ohne eine Person in der Schleife ausgeführt wurden. Um diese Governance zu unterstützen, bietet Amazon Quick ACL-bewussten Abruf, Chat- und Feedback-Protokollierung sowie Kontrollen darüber, was jeder Chat-Agent tun darf.

Amazon Quick ist ein HIPAA-fähiger Service. Diese Fähigkeit gilt für die Amazon Quick-Clients im Web, auf dem Desktop und auf mobilen Geräten, vorbehaltlich des gemeinsamen Verantwortlichkeitsmodells und Ihrer Konfiguration. Dieser Beitrag konzentriert sich jedoch auf die Funktionen der Amazon Quick-Webversion, auf die Sie über Ihren Browser zugreifen.

In diesem Beitrag beginnen wir mit den Grundlagen: für wen HIPAA gilt und der Unterschied zwischen HIPAA-fähig und HIPAA-konform. Anschließend stellen wir Amazon Quick als Plattform und die beiden Datenflüsse für PHI (unstrukturiert und strukturiert) vor. Danach behandeln wir, was Amazon Quick für regulierte Umgebungen bietet und was nicht, gehen eine fiktive Bereitstellung eines Gesundheitsplans (AnyCompany) durch und destillieren die Best Practices und irreversiblen Entscheidungen heraus, die Sie von vornherein treffen sollten. Wir schließen mit einer Schritt-für-Schritt-Implementierungsanleitung, einem Fazit und Ressourcen zur vertieften Lektüre.

Für wen gilt HIPAA?

HIPAA reicht weiter als Krankenhäuser und Kliniken. Nach dem Gesetz tragen zwei Kategorien von Organisationen Verpflichtungen, und die meisten KI-Projekte betreffen beide.

Unterstellte Einrichtungen (Covered Entities, CEs)

• Gesundheitspläne – Krankenversicherungen, HMOs, arbeitgeberfinanzierte Pläne, Medicare und Medicaid.
• Gesundheits-Clearingstellen – Organisationen, die nicht standardisierte Gesundheitsinformationen in standardisierte elektronische Formate verarbeiten.
• Gesundheitsdienstleister – Ärzte, Kliniken, Krankenhäuser, Apotheken, Pflegeheime und jeder Dienstleister, der Gesundheitsinformationen elektronisch überträgt.

Geschäftspartner (Business Associates, BAs)

• Ein Geschäftsassociates (Business Associate) ist jede Person oder Entität außerhalb der Belegschaft des Covered Entity, die geschützte Gesundheitsinformationen (PHI) im Auftrag des Covered Entity erstellt, empfängt, pflegt oder überträgt.
• Zu den häufigen Beispielen gehören Cloud-Dienstanbieter, IT-Dienstleister, Abrechnungsunternehmen, Datenanalysefirmen, Claims-Prozessoren, Kanzleien und Beratungsunternehmen.
• Subunternehmer, die PHI im Auftrag eines anderen Business Associate verarbeiten, sind selbst Business Associates.

Covered Entities und Business Associates müssen beide eine Business Associate Addendum (BAA) unterzeichnen, bevor PHI die Hände wechselt. Nachdem Sie die AWS BAA über AWS Artifact akzeptiert haben, fungiert AWS als Ihr Business Associate für dieses bestimmte AWS-Konto, und nur wenn Sie HIPAA-fähige Dienste wie Amazon Quick zur Verarbeitung von PHI innerhalb dieses Kontos nutzen. Das Addendum erstreckt sich nicht auf Ihre anderen Konten, nicht auf PHI, das in nicht HIPAA-fähige Dienste platziert wird, und nicht auf die Art und Weise, wie Sie den Dienst konfigurieren. Dies bleibt in Ihrer Verantwortung. Überprüfen und bestätigen Sie stets die aktuellen AWS-BAA-Bedingungen und Ihre Pflichten mit Ihren eigenen Rechts- und Compliance-Teams.

HIPAA-fähig ist nicht dasselbe wie HIPAA-konform

Während HIPAA-fähig eine AWS-Bezeichnung ist, ist HIPAA-konform eine Eigenschaft Ihrer gesamten Umgebung. HIPAA-fähig bedeutet, dass AWS den Dienst bewertet hat und Ihnen gestattet, ihn zur Verarbeitung, Speicherung und Übertragung von PHI unter einer unterzeichneten AWS BAA zu verwenden. Amazon Quick ist ein HIPAA-fähiger Dienst, und unabhängige Prüfer bewerten ihn im Rahmen der AWS-Compliance-Programme einschließlich HIPAA, FedRAMP, PCI DSS, SOC und ISO. Eine offizielle HIPAA-Zertifizierung für AWS als Cloud-Dienst existiert nicht, und AWS selbst ist nicht „HIPAA-fähig“.

Die Berechtigung von Amazon Quick dient lediglich als Baustein. Das allein macht Ihre Anwendung und Umgebung nicht HIPAA-konform. Sie müssen weiterhin die BAA unterzeichnen, Ihre Daten klassifizieren, die Kontrollen korrekt konfigurieren und die administrativen und physischen Schutzmaßnahmen übernehmen, die HIPAA verlangt, einschließlich Schulungen der Belegschaft, Risikoanalysen und Verfahren bei Datenschutzverletzungen, die AWS nicht für Sie durchführt. Ein berechtigter Dienst wie Amazon Quick, eine unterzeichnete BAA, korrekte Konfiguration, Governance und Ihre eigenen Schutzmaßnahmen together ergeben eine HIPAA-konforme Bereitstellung. Dass Amazon Quick berechtigt ist, bedeutet, dass Sie darauf einen konformen Workflow aufbauen können. Es bedeutet nicht, dass das Aktivieren Sie automatisch konform macht.

Was ist Amazon Quick

Amazon Quick wird oft über seine Chat-Agenten vorgestellt, aber die HIPAA-Berechtigung gilt für den gesamten Workspace, nicht für ein einzelnes Feature, daher ist eine Plattform-Perspektive für die Compliance entscheidend. Alle Funktionen in Amazon Quick setzen sich aus den folgenden Bausteinen zusammen:

• Chat ist die primäre Schnittstelle. Ein Nutzer kann eine Frage in natürlicher Sprache stellen oder eine Anweisung geben, und Amazon Quick entscheidet, wie geantwortet wird.
• Chat-Agenten verarbeiten jede Anfrage. Dies sehen Sie in der Konsole unter dem Menü Chat agents. Jeder Chat-Agent kann mit Anweisungen konfiguriert, durch Wissensquellen fundiert und mit Werkzeugen zum Ergreifen von Maßnahmen ausgestattet werden. Amazon Quick liefert einen Standard-Chat-Agenten (My Assistant) aus, und Sie können benutzerdefinierte Chat-Agenten für bestimmte Domänen erstellen.
• Spaces organisieren die Ressourcen, die ein Chat-Agent benötigt, wie Dokumente, Dashboards, Datensätze, Wissensbasen und Action-Konnektoren. Ein Space kann mit einem Team geteilt werden.
• Integrationen verbinden Amazon Quick mit Ihrer Umgebung: Wissensbasen für unstrukturierte Inhalte wie Amazon Simple Storage Service (Amazon S3), Microsoft SharePoint, sowie Atlassian Confluence; strukturierte Datenverbindungen, die Amazon Quick Sight mit Ihren strukturierten Datenbanken, Data Warehouses und Data Lakes verknüpfen; Action-Konnektoren (aufgebaut aus OpenAPI-Spezifikationen oder Model Context Protocol-Servern); und Erweiterungen (Chrome, Slack, Microsoft Teams und Microsoft 365).

  Auf diesen Bausteinen sitzen die Features. Die Spalte Worauf es zugreift ist für die Compliance wichtig, da sie zeigt, auf welche Bausteine und damit auf welche Datenpfade jedes Feature zugreift.

Hinweis: SPICE ist die In-Memory-Abfrage-Engine von Amazon Quick Sight. Ein SPICE-Datensatz verwendet bei der Erstellung den kontospezifischen Standard-Schlüssel (customer managed key), und um einen bestehenden Datensatz auf einen neuen Standardschlüssel zu importieren, müssen Sie eine vollständige Aktualisierungdurchführen. Wenn Ihre Daten PHI enthalten, beziehen Sie SPICE in Ihre Verschlüsselungsstrategie ein (schützen Sie es mit Ihrem customer managed AWS Key Management Service (KMS)-Schlüssel, falls Sie einen verwenden) und in Ihre Entscheidungen zur Datenminimierung darüber, was importiert wird, etwa indem Sie live abfragen oder stattdessen einen de-identifizierten Auszug laden.

Dieselben Voraussetzungen in Bezug auf Eignung, BAA, Verschlüsselung, Zugriffskontrolle und Audit-Postur erstrecken sich auf jede Funktion. Wie eingangs jedoch angemerkt, gelangt PHI über zwei Pfade zu Amazon Quick, und jeder davon ist unterschiedlich gesichert. Der unstrukturierte Pfad verläuft über Wissensbasen, wo die Dokumente durch ACLs auf Dokumentebene gesteuert und zur Abfragezeit ausgewertet werden. Der strukturierte Pfad verläuft über Amazon Quick Sight das Ihre Datenbanken und Data Lakes liest, wobei der Zeilen- und Spaltenzugriff durch Sicherheit auf Zeilen- und Spaltenebene gesteuert wird. Diese beiden Datenflüsse transportieren PHI unterschiedlich, und wie der folgende Abschnitt zeigt, werden die Kontrollen in jedem Pfad unterschiedlich durchgesetzt.

Was Amazon Quick für regulierte Umgebungen bietet

Amazon Quick ist HIPAA-berechtigt, und wir erläutern, was das in der Praxis bedeutet.

Verwaltete Infrastruktur

Amazon Quick ist ein vollständig verwalteter Service. AWS betreibt die zugrunde liegende Infrastruktur und ist für die Sicherheit der Cloud verantwortlich, was von unabhängigen Dritten geprüft wird, wie im AWS Shared Responsibility Model.

Verschlüsselung

Amazon Quick verschlüsselt ruhende Daten standardmäßig und unterstützt Verschlüsselung für Daten bei der Übertragung.

• Verschlüsselung ruhender Daten ist standardmäßig aktiviert und verwendet AWS owned- oder AWS managed-Keys. Das Registrieren eines customer managed keys ist optional und keine HIPAA-Anforderung. Wenn Sie die direkte Kontrolle über die Verschlüsselungsschlüssel benötigen, können Sie einen customer managed AWS KMS key registrieren (erfordert ein Enterprise-Abonnement) für teilnehmende Ressourcentypen, darunter SPICE-Datensätze, Datenquellen-Anmeldeinformationen, OAuth-Tokens und Berichtsartefakte. Wo kein customer managed key zur Anwendung kommt, verschlüsselt AWS die Daten mit einem AWS owned- oder AWS managed key.
• Eine Nuance ist zu beachten: Nutzerfeedback zu Chat-Antworten, einschließlich optionaler Freitextkommentare, wird nicht mit Ihrem customer managed key oder dem Schlüssel verschlüsselt, der die KI-indizierten Daten von Amazon Quick schützt. Nutzerfeedback sollte als potenzielle PHI-Fläche behandelt und entsprechend geregelt werden.
• Für Daten bei der Übertragung sichert Amazon Quick verschlüsselte Übertragungen mit Transport Layer Security (TLS). Bei einigen Datenbankverbindungen können Sie wählen, ob die Übertragung verschlüsselt ist, daher sollten Sie TLS/SSL auf diesen Datenquellenverbindungen ausdrücklich aktivieren, statt anzunehmen, dass es immer aktiviert ist.

Ihre Daten trainieren die Modelle nicht

Amazon Quick verwendet Ihre Kundendaten nicht, um die zugrunde liegenden großen Sprachmodelle (LLMs) zu trainieren oder zu verbessern.

Zugriffskontrolle und Identitätsföderation

Amazon Quick unterstützt rollenbasierte Zugriffskontrolle (RBAC) und Single Sign-On (SSO) über AWS IAM Identity Center, Microsoft Active Directory und SAML 2.0-Identitätsanbieter. Für Business-Intelligence-(BI)-Workloads können Sie dies ergänzen durch Sicherheit auf Zeilen- und Spaltenebene sowie Run-as-Rollen, um den Datenzugriff zur Abfragezeit einzuschränken. Mit diesen Funktionen können Sie eindeutige Benutzeridentifikation und das Prinzip der geringsten Privilegien durchsetzen.

Audit- und Monitoring-Signale

Amazon Quick liefert mehrere unterschiedliche Signale. Diese sind nicht austauschbar, und ihre Verwechslung ist eine häufige Audit-Lücke.

• AWS CloudTrail zeichnet unterstützte API-Operationen und eine dokumentierte Menge von Nicht-API-Ereignissen auf, wie Dashboard-Aufrufe und Benutzerverwaltungsaktionen. Es erfasst, wer was und wann getan hat, aber nicht Chat-Nachrichteninhalte oder Antwortinhalte.
• Amazon CloudWatch -vended logs liefern die KI-spezifischen Datensätze an ein Ziel Ihrer Wahl (CloudWatch Logs, Amazon S3 oder Firehose). Es gibt fünf Protokolltypen: Chat-Konversationen (CHAT_LOGS), Nutzerfeedback (FEEDBACK_LOGS), Agent- und Research-Stunden (AGENT_HOURS_LOGS), Indexspeichernutzung (INDEX_USAGE_LOGS) und Wissensbasis-Dateisynchronisierung (KB_FILE_SYNC_LOGS). Hier – und nicht in CloudTrail – liegt, was ein Nutzer gefragt hat und was Amazon Quick geantwortet hat.
• CloudWatch-Metriken und -Alarme bieten zudem eine Fast-Echtzeit-Betriebsüberwachung.
• Das Analytics-Dashboard zeigt Administratoren Nutzung und Adaption. Beachten Sie, dass es im Rahmen der Überprüfung negativen Feedbacks detaillierte Abfragetexte und den vollständigen Gesprächskontext offenlegen kann, daher gewähren Sie Zugriff nur autorisierten Administratoren.

Da Chatprotokolle und Feedback PHI enthalten können, wenden Sie CloudWatch Logs Data-Protection-Maskierung an, und bestätigen Sie, dass ein bestimmtes Signal tatsächlich das Ereignis abdeckt, das Sie verfolgen möchten, bevor Sie sich im Hinblick auf Compliance darauf verlassen.

Funktionen in HIPAA-Kontrollen übersetzen

Dass Amazon Quick ein zugelassener Service ist, ist nützlich, weil es jede Funktion einer bestimmten HIPAA-Sicherheitsmaßnahme zuordnet, wie die folgende Tabelle zeigt:

Was Amazon Quick nicht leistet

Während Amazon Quick die zuvor genannten Kontrollen bietet, behandelt dieser Abschnitt, was Amazon Quick nicht bietet und wie diese Lücke geschlossen werden kann. Amazon Quick steuert Zugriff, Abruf und Interaktion. Es ist keine Plattform für Data-Engineering- oder Data-Lake-Governance. In einem HIPAA-Kontext fallen mehrere Anforderungen außerhalb von Amazon Quick an und werden durch andere AWS-Services upstream erfüllt.

• De-Identifizierung und Transformation. Amazon Quick de-identifiziert keine PHI und formt Quelldaten nicht um. Wenn Ihr Anwendungsfall einen limited data set oder einen de-identifizierten Extrakt erfordert, bereiten Sie die Daten auf, bevor sie Amazon Quick erreichen, und zwar mit geeigneten AWS-Services, zum Beispiel mit AWS Glue DataBrew, einer Capability von AWS Glue, für visuelle Datenaufbereitung und Schwärzung, oder AWS Glue für Extract-, Transform- und Load-Pipelines (ETL).
• Data-Lake-Governance und feingranulare Tabellenberechtigungen. Bei strukturierten Daten, die Amazon Quick Sight über einen Data Lake abfragt, ist die Governance auf Spalten- und Zeilenebene des Lakes selbst Aufgabe von AWS Lake Formation, nicht von Amazon Quick. Amazon Quick Sight setzt seine eigene Sicherheit auf Zeilen- und Spaltenebene in der Analyseschicht durch, aber die maßgeblichen Berechtigungen auf Lake-Ebene liegen in Lake Formation und im AWS Glue Data Catalog.
• Die administrativen und physischen Schutzmaßnahmen. Schulungen der Belegschaft, Risikoanalysen und Verfahren bei Datenschutzverletzungen bleiben in Ihrer Verantwortung, unabhängig von den eingesetzten Tools.

Eine allgemeine bewährte Praxis besteht darin, Verantwortlichkeiten abzugrenzen und die Upstream-Services entscheiden zu lassen, welche Daten existieren und wer sie an der Quelle abfragen kann. Lassen Sie Amazon Quick entscheiden, wer ihm Fragen stellen darf und was der Agent mit den Daten tun darf.

AnyCompany Health Plan: Ein Beispielanwendungsfall

AnyCompany Health Plan, ein fiktiver Gesundheitsplan, veranschaulicht einen Anwendungsfall und ein Muster. AnyCompany Health Plan ist eine Covered Entity, die zwei Dinge möchte: ihrem Care-Management-Team ermöglichen, Fragen zu Richtlinien- und Mitgliedsbeschwerdedokumenten in natürlicher Sprache zu stellen, und Führungskräften im operativen Bereich Self-Service-Dashboards über Claims-Daten bereitstellen. Beides betrifft PHI, daher muss AnyCompany bestätigen, dass die Lösung HIPAA-konform ist. AnyCompanys Umgebung hat zwei Datenpfade, und jeder davon wird von eigenen Lösungen architected und geregelt, bevor Amazon Quick auf die Daten zugreifen kann.

Unstrukturierter Pfad (Richtlinien- und Krankenakten-Dokumente)

→ Amazon S3 Bucket (ACL-fähige KB-Quelle)

→ Amazon Quick Knowledge Base (Dokument-Level-ACLs, fail-closed zur Abfragezeit)

Strukturierter Pfad (Claims)

Alle Claims-Daten befinden sich derzeit in einem Lake (Amazon S3).

→ Glue ETL (Curate) → Glue DataBrew (De-Identifizierung)

→ Lake Formation (Zeilen-/Spaltenberechtigungen und AWS Glue Data Catalog)

→ Amazon Quick Sight Dataset (Amazon Athena) (Sicherheit auf Zeilen- und Spaltenebene, Run-as-Rolle)

Beide zuvor beschriebenen Datenflüsse für strukturierte und unstrukturierte Daten laufen in einem Amazon Quick Chat-Agenten mit föderiertem SSO, Least-Privilege-Space, Guardrails und von CloudWatch bereitgestellten Logs zusammen.

So implementiert der Administrator von AnyCompany die Lösung:

1. Unterschreiben Sie die BAA und provisionieren Sie über die AWS Management Console. Der Admin akzeptiert die AWS BAA in AWS Artifact für das AWS-Konto und provisioniert dann Amazon Quick über die AWS Management Console mit IAM Identity Center. AnyCompany erfasst die Vereinbarungs-ID, den Zeitstempel und das Konto in seinem Compliance-Register. Nur die Webversion von Amazon Quick, die über die AWS Management Console provisioniert wird, kann über AWS Artifact unter eine signierte BAA gebracht werden, was eine notwendige Komponente für Kunden ist, die HIPAA-konforme Workflows erstellen, die PHI berühren, vorbehaltlich einer ordnungsgemäßen Konfiguration und der eigenen Compliance-Verantwortung des Kunden.
2. Legen Sie die irreversiblen Kontrollen am Tag null fest. Da AnyComps Sicherheitsrichtlinie die Kontrolle über die eigenen Verschlüsselungsschlüssel vorschreibt, wählt der Admin, einen customer managed key als Kontostandard zu registrieren, bevor irgendwelche Amazon Quick AI-Daten erstellt werden. Der Datenschlüssel wird einmal festgelegt und kann später nicht geändert werden. (Die standardmäßige AWS-verwaltete Verschlüsselung ist ebenfalls HIPAA-geeignet. Die Verwendung von customer managed keys ist keine Voraussetzung dafür, dass der Dienst HIPAA-geeignet ist.) Der Admin legt außerdem das Identitätsmodell auf IAM Identity Center fest, sodass die Erkennung inaktiver Benutzer greift. Der Amazon Quick-Datenschlüssel wird bei der ersten Datenerstellung einmal festgelegt und kann nie geändert werden. Wenn der Schlüssel gelöscht wird, ist die einzige Wiederherstellung die Abmeldung und erneute Anmeldung, wodurch alle Amazon Quick-Daten dauerhaft entfernt werden.
3. Bereiten Sie den strukturierten Pfad außerhalb von Amazon Quick vor. Bevor Amazon Quick Sight die Ansprüche berührt, verwendet AnyComps Datenteam AWS Glue, um die kuratierten Claims-Tabellen zu erstellen, und Glue DataBrew, um einen de-identifizierten Extrakt für die Operations-Dashboards zu erzeugen. AWS Lake Formation gewährt zeilen- und spaltenbezogenen Zugriff auf diese Tabellen über den AWS Glue Data Catalog. Dadurch sieht Amazon Quick niemals rohe PHI, die es nicht benötigt.
4. Erstellen Sie eine ACL-bewusste Wissensbasis für die Dokumente. Der Admin verbindet den Policy-and-Appeals-S3-Bucket als Wissensbasis mit aktivierten document-level ACLs bei der Erstellung. Da ACLs später nicht mehr aktiviert werden können, muss dies beim Erstellen des S3-Buckets konfiguriert werden. Amazon Quick wertet die Identität jedes Benutzers zum Abfragezeitpunkt aus und gibt keine Dokumente zurück, wenn es den Zugriff nicht bestätigen kann.
5. Erstellen Sie einen dedizierten Space und einen benutzerdefinierten Chat-Agenten. AnyCompany erstellt einen PHI-Space mit eingeschränkter Mitgliedschaft, getrennt von Spaces für allgemeine Produktivität. Der Care-Management-Chat-Agent ist auf die ACL-bewusste Wissensbasis beschränkt, mit deaktivierter offener Websuche und konfigurierten Guardrails. Read-only-Konnektoren werden für alles implementiert, was PHI-nah ist.
6. Verbinden Sie die Dashboards mit Abfragesicherheit. Die Operations-Dashboards lesen den de-identifizierten Amazon Quick Sight-Datensatz über Athena, mit Amazon Quick Sight row-level und column-level security sowie einer Run-as-Rolle oberhalb der Lake Formation-Berechtigungen.
7. Aktivieren Sie die Audit-Signale, bevor Sie Benutzer onboarden. Der Admin erstellt einen CloudTrail-Trail und konfiguriert die CloudWatch vended log delivery (CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS und die übrigen) an einen dauerhaft gespeicherten, maskierten Zielort. Feedback wird als PHI-Oberfläche behandelt.
8. Validieren Sie, dann skalieren Sie von Non-PHI zu PHI. AnyCompany beginnt mit Non-PHI-Workflows, wie Policy Q&A und Dokumentensuche, um die Governance zu bestätigen, testet mit adversariellen Prompts, um das Fail-closed-ACL-Verhalten zu überprüfen, prüft die Protokolle, um zu bestätigen, dass die Ereignisse erfasst werden, und weitet die Arbeit des Care-Management-Teams erst dann auf PHI-nahe Aufgaben aus.

   Amazon Quick setzt Identität, Retrieval, Guardrails und den Audit-Trail durch. Aber die De-Identifizierung, das ETL und die Lake-Level-Berechtigungen erfolgen vorgelagert in Glue, Glue DataBrew und Lake Formation. Diese Aufteilung ist das empfohlene Muster und die praktische Antwort darauf, Amazon Quick in einer föderierten Umgebung zu erweitern.

So machen Sie es konform: Bewährte Methoden

Die Eignung verschafft Ihnen eine Plattform, die PHI verarbeiten kann . Sie müssen sie dennoch so konfigurieren, dass sie es tatsächlich tut.

Dieser Abschnitt hilft Ihnen, die Entscheidungen der geteilten Verantwortung zu verstehen. Da einige dieser Entscheidungen irreversibel sind, treffen Sie sie, bevor Sie Ressourcen erstellen oder Benutzer onboarden.

Beginnen Sie mit dem Sicherheitsmodell für agentenbasierte KI

Amazon Quick-Agenten warten nicht bei jedem Schritt auf Anweisungen. Sie rufen Tools auf, ändern Daten und interagieren eigenständig mit externen Systemen. Das verändert Ihren Ansatz zur Absicherung Ihrer Umgebung. AWS hat im April 2026 vier Sicherheitsprinzipien für agentenbasierte KI veröffentlicht vier Sicherheitsprinzipien für agentische KI im April 2026, und sie gelten hier unmittelbar.

Prinzip 1 — Legen Sie Agenten-Sicherheitsmaßnahmen über Ihr bestehendes Sicherheitsframework. Bauen Sie keine parallele Sicherheitsarchitektur für Amazon Quick auf. Fügen Sie agentenspezifische Maßnahmen (Guardrails, Topic Blocking und PII-Redaktion) über den IAM-, Netzwerk- und Verschlüsselungsrichtlinien hinzu, die Sie bereits durchsetzen.

Prinzip 2 — Verlassen Sie sich auf deterministische Kontrollen statt auf promptbasierte. Ein gut gearbeiteter adversarialer Input kann eine Prompt-Anweisung umgehen. AWS Identity and Access Management (IAM)-Policies, ACLs auf Dokumentebene, Netzwerkgrenzen und vom Administrator konfigurierte Guardrails lassen sich nicht durch Argumentation austricksen. Nutzen Sie diese als primäre Durchsetzungsmechanismen. Agenten-Anweisungen sind Ihre zweite Ebene, nicht Ihre einzige.

Prinzip 3 — Wenden Sie Defense in Depth über Wahrnehmung, Schlussfolgerung und Handlung an. Ordnen Sie jede Agenten-Fähigkeit einer von drei Ebenen zu:

• Wahrnehmen: Wissensbasen, hochgeladene Dateien, Websuche, Connector-Eingaben, MCP-Tool-Ausgaben.
• Grund: der LLM-Verarbeitungskontext, gesteuert durch Guardrails und Themenkontrollen.
• Aktion: Connectors, Quick Flows, Quick Automate, geplante Aufgaben, MCP-Toolaufrufe.

Wenden Sie Kontrollen auf jeder Ebene unabhängig an. Eine Lücke in einer Ebene sollte sich nicht auf die anderen übertragen.

Beachten Sie, dass sich HIPAA-BAA-Verpflichtungen auf unterstützende Dienste und Lösungen wie MCP-Tools erstrecken.

Prinzip 4 — Autonomie schrittweise ausweiten. Starten Sie Agents im Nur-Lese-Modus gegen Nicht-PHI-Daten. Fügen Sie Funktionen einzeln hinzu. Testen Sie bei jedem Schritt auf Datenlecks, Prompt-Injection-Resilienz und Einhaltung von Berechtigungsgrenzen, bevor Sie zum nächsten übergehen.

Entscheiden Sie, bevor Sie deployen

Da diese drei Entscheidungen dauerhaft sind, treffen Sie diese Entscheidungen vor der Implementierung.

Registrieren Sie zuerst Ihren KMS-Schlüssel. Wenn Ihre Organisation die Kontrolle über ihre eigenen Verschlüsselungsschlüssel benötigt, registrieren Sie einen customer managed key als Kontostandard, bevor Sie beliebige Amazon Quick AI-Ressourcen erstellen. Der Datenschlüssel wird festgelegt, wenn erstmals Quick AI-Daten im Konto erstellt werden. Danach kann er nicht mehr geändert werden. Die Unterstützung von customer managed keys erfordert ein Enterprise-Abonnement. Beachten Sie, dass ein customer managed key den Chat-Speicher deaktiviert. Konten, die mit einem customer managed key konfiguriert sind, unterstützen diese Funktion nicht.

Wählen Sie Ihr Identitätsmodell bewusst. Sie haben vier Optionen: IAM Identity Center, Active Directory, IAM-Föderation und Quick lokale Benutzer. Sie unterscheiden sich im Verhalten bei Provisionierung, Offboarding und Governance. Die Erkennung inaktiver Benutzer funktioniert beispielsweise nur mit IAM Identity Center oder Active Directory. Ein Wechsel des Identitätsanbieters nach dem Deployment bedeutet, dass die Berechtigungen und Space-Mitgliedschaften jedes Benutzers neu provisioniert werden müssen. Wählen Sie nur einmal.

Machen Sie PHI-Wissensbasen bei der Erstellung ACL-fähig. Für unterstützte Quellen (Amazon S3, Google Drive, SharePoint, Confluence Cloud und OneDrive) entscheiden Sie bei der Erstellung, ob eine Wissensbasis dokumentbezogene ACLs durchsetzt. Diese Einstellung ist dauerhaft. Sie können ACLs für eine Wissensbasis nicht aktivieren, die ohne sie erstellt wurde. Erstellen Sie für alles PHI-nahe die Wissensbasis von Anfang an ACL-fähig.

Warnung: Fehlkonfigurierte User-Store-Zuordnungen können eingeschränkte Dokumente stillschweigend den falschen Benutzern zugänglich machen, ohne Fehler oder Warnungen. Es ist entscheidend, Ihre Identitäts-zu-ACL-Zuordnung zu validieren, bevor Sie PHI-Inhalte aufnehmen.

AWS-Region, Netzwerk- und Kontogrenzen

Planen Sie Ihre Deployment-Region auf Grundlage der folgenden Faktoren:

• Datenresidenz: Amazon Quick verarbeitet und speichert Daten in der Region, in der Sie sie provisionieren, und Sie müssen bestätigen, dass diese Region die Anforderungen Ihrer Organisation an Datenlokalisierung erfüllt. Beachten Sie, dass Amazon Quick ein Single-Region-Service ist: Er profitiert von Multi-AZ-Resilienz innerhalb einer Region, aber es gibt kein Failover über Regionen hinweg. Wenn Sie geschäftskritische Workflows unterstützen, die regionsübergreifende Resilienz erfordern, provisionieren Sie ein separates Amazon Quick-Deployment in einer zweiten Region, zusammen mit den zugehörigen Daten, zum Beispiel durch Replikation von S3-basierten Wissensbasen-Quellen über Regionen hinweg.
• Serviceverfügbarkeit. Funktionen werden mitunter zu unterschiedlichen Zeiten in unterschiedlichen Regionen eingeführt. Stellen Sie sicher, dass alles, was Ihre Agents benötigen, wie Wissensbasen, Connectors und Amazon Quick Sight-Funktionen, dort verfügbar ist, wo Sie deployen möchten.
• Multi-Account-Strategie. Platzieren Sie Amazon Quick in einem dedizierten Workload-Konto in AWS Organizations. Verwenden Sie Service Control Policies (SCPs), um Regionsbeschränkungen durchzusetzen und versehentliche Provisionierung in außerhalb des Geltungsbereichs liegenden Regionen zu blockieren.

Zu Netzwerkgrenzen: Amazon Quick ist ein verwalteter Service, der über HTTPS zugänglich ist. Sie deployen ihn nicht in eine virtuelle private Cloud (VPC). Aber Ihre Datenquellen (S3-Buckets, Datenbanken, On-Premises-Systeme) könnten sich hinter VPC-Grenzen befinden. Verwenden Sie VPC-Endpunkte und AWS PrivateLink, wo verfügbar. Stellen Sie sicher, dass DNS-Auflösung und Firewall-Regeln es den Connectors von Amazon Quick ermöglichen, Ihre autorisierten Datenquellen zu erreichen, ohne das Netzwerk weiter als nötig zu öffnen.

Minimieren Sie die Angriffsfläche des Agents

Die eigene Dokumentation von Amazon Quick rahmt das adversariale Risiko als Problem mit zwei Bedingungen: Ein Risiko besteht, wenn (1) ein Agent Inhalte von außerhalb Ihrer Vertrauensgrenze lesen kann, und (2) eine konsequenzreiche Aktion ausführen kann. Schränken Sie eine der beiden Bedingungen ein, so verringern Sie die Exposition.

Einschränken, was Agenten lesen können (Perceive-Schicht). Kennen Sie jede Quelle, die in den Kontext eines Agenten einfließt: Wissensbasen, hochgeladene Dateien, Websuche, Drittanbieter-Research, Connector-Antworten, MCP-Tool-Ausgaben und gespeicherte Konversationserinnerung. Für PHI-Workflows:

• Beschränken Sie Agenten auf vertrauenswürdige, ACL-bewusste Wissensbasen.
• Deaktivieren Sie die offene Websuche, wo sie nicht benötigt wird.
• Deaktivieren Sie das Hochladen von Dateien, wenn der Agent sie nicht benötigt.
• Begrenzen Sie die Speicherung des Konversationsverlaufs auf das minimal nützliche Zeitfenster.

Einschränken, was Agenten tun können (Act-Schicht). Inventarisieren Sie jeden ausgehenden Pfad: Connectors, MCP-Tools, Webabfragen, Quick Flows, Quick Automate-Workflows, geplante Agentenläufe. Für PHA-nahe Agenten:

• Bevorzugen Sie schreibgeschützten Connector-Zugriff.
• Seien Sie vorsichtig mit automatisierten und geplanten Workflows, da sie ohne Aufsicht ausgeführt werden.
• Blockieren Sie Schreibaktionen, sofern sie nicht explizit begründet und von Ihrem Sicherheitsteam genehmigt sind.
• Verwenden Sie Berechtigungsabgrenzung auf Connector-Ebene, um einzuschränken, welche Operationen ein Agent aufrufen kann.

Kennen Sie die Identität, unter der eine Aktion ausgeführt wird. On-Demand-Aktionen authentifizieren sich als der aufrufende Benutzer, begrenzt durch die Connector-Berechtigungen dieses Benutzers. Automatisierte Workflows laufen ohne interaktive Sitzung. Passen Sie den Autonomiegrad an die Sensibilität der Aktion an, und dokumentieren Sie, welche Agenten in welchem Identitätsmodus arbeiten.

Durchsetzen Sie geringste Privilegien und Datentrennung

• Trennen Sie Wissensbasen und Bereiche mit PHI von solchen für allgemeine Produktivität. Schränken Sie die Mitgliedschaft ein.
• Gewähren Sie Space-Zugriff und Agent-Zugriff auf Basis des Need-to-know-Prinzips. Prüfen Sie sowohl die Freigabeberechtigungen (wer eine Knowledge Base nutzen kann) als auch die ACLs der Quelldokumente (welche indizierten Dokumente ein autorisierter Benutzer tatsächlich abrufen kann).
• Der Standard-Aktualisierungszyklus der Knowledge Base beträgt 24 Stunden. Verkürzen Sie ihn, wenn Ihre Anforderungen an Zugriffsänderungen eine schnellere Weitergabe erfordern. Aktualisieren Sie ACLs, bevor Sie E-Mail-Adressen neu zuweisen oder wiederverwenden.
• Ein PHI-Agent sollte einen Space nicht mit Allzweck-Produktivitätstools teilen. Das bedeutet, dass Sie Anwendungsfälle auf Space-Ebene isolieren müssen.
• Überprüfen Sie die Connector-Berechtigungen regelmäßig. Rotieren Sie die in AWS Secrets Manager gespeicherten Anmeldeinformationen nach einem Zeitplan, der Ihrer Richtlinie zum Verwaltung von Anmeldeinformationen entspricht.

Datenminimierung praktizieren

AWS rät davon ab, vertrauliche Daten in Ressourcennamen oder Tags einzugeben, um eine versehentliche Erwähnung in Abrechnungs- oder Diagnoseprotokollen zu vermeiden.

• Bevorzugen Sie anonymisierte Daten, wo immer der Anwendungsfall dies zulässt.
• Wenn Sie strukturierte Daten aus Datenbanken oder APIs aufnehmen, filtern Sie Spalten und Zeilen bereits an der Quelle vor der Indizierung.
• Konfigurieren Sie Agent-Guardrails so, dass PII in Antworten geschwärzt wird, und verbergen Sie Sozialversicherungsnummern (SSNs), Patientenaktennummern (MRNs) und Geburtsdaten mithilfe der integrierten PII-Erkennungsfilter.

Protokollierung und Aufbewahrung für Audits konfigurieren

Amazon Quick bietet mehrere unterschiedliche Audit-Signale. Keines davon wird standardmäßig ausgegeben, und Sie müssen sie möglicherweise erst aktivieren.

So richten Sie sie ein:

1. Erstellen Sie einen CloudTrail-Trail für die betroffenen Konten und Regionen.
2. Konfigurieren Sie die CloudWatch vended log delivery (CHAT_LOGS, FEEDBACK_LOGS, KB_FILE_SYNC_LOGS) kurz nach dem Aktivieren der AI-Funktionen von Amazon Quick.
3. Wenden Sie CloudWatch Logs data-protection masking auf die Chat-Protokolle an, damit PHI nicht im Klartext gespeichert wird.
4. Legen Sie eine Aufbewahrungsfrist von mindestens sechs Jahren fest. Ziehen Sie S3 Object Lock für das Protokollarchiv in Betracht.
5. Richten Sie CloudWatch-Alarme für anomale Aktivitäten ein.
6. Aktivieren Sie AWS Security Hub für kontinuierliche Compliance-Prüfungen.
7. Leiten Sie kritische Warnungen an Ihre Security Information and Event Management (SIEM)-Plattform oder Incident-Response-Plattform weiter.

Validierung vor der Skalierung

Bevor Sie den Umfang erweitern, prüfen Sie Folgendes:

• Die Annahme der BAA ist in Ihrem Compliance-Register dokumentiert.
• Die Datenklassifizierung ist dokumentiert: Welche Wissensbasen und Bereiche PHI enthalten und welche Agenten darauf zugreifen können.
• Adversarielle Abfragen und Prompt-Injection-Szenarien wurden getestet.
• Protokolle werden erfasst und das Maskieren funktioniert korrekt.
• Eine Tabletop-Breach-Übung wurde durchgeführt.
• InfoSec hat zugestimmt.

Bekannte Einschränkungen

Hier sind einige bekannte Einschränkungen von Amazon Quick.

• Keine BAA auf dem Free- oder Plus-Pfad. Sie müssen den Pfad verwenden, der über die AWS Management Console bereitgestellt wird, um eine BAA-Abdeckung zu erhalten.
• Keine regionsübergreifende Replikation. Disaster Recovery (DR) ist auf eine einzelne Region beschränkt.
• Guardrails sind probabilistisch, nicht deterministisch. Sie reduzieren das Risiko. Sie beseitigen es nicht. Ergänzen Sie dies durch die zuvor beschriebenen Kontrollen auf Infrastrukturebene.
• Connectors von Drittanbietern erweitern Ihre BAA-Verpflichtungen. Wenn ein Connector Daten an ein externes System sendet, folgt Ihre Compliance-Verantwortung den Daten.
• Der Unterhaltungsverlauf kann wiederholtes PHI enthalten. Legen Sie Aufbewahrungsrichtlinien fest und wenden Sie Maskierung an.

Implementierungsleitfaden

Das Beispiel AnyCompany Health Plan hat gezeigt, wie Amazon Quick ausgerollt wird. Dieser Abschnitt wandelt dieses Muster in einen schrittweisen Projektplan um, den Sie Ihrem Plattformteam übergeben können.

Schritt 1: Die BAA abschließen (Tag 1)

• Melden Sie sich mit AWS Artifact-Berechtigungen an und nehmen Sie die BAA an.
• Notieren Sie die Vereinbarungs-ID, den Zeitstempel, die Principal-ARN und die Account-ID.
• Benachrichtigen Sie Ihr Rechts- und Compliance-Team.

Schritt 2: Grundlegende, irreversible Kontrollen einrichten (Tage 1–2)

• Registrieren Sie einen customer managed key als Account-Standard.
• Überprüfen Sie, ob die Key-Policy die erforderlichen Berechtigungen gewährt: Encrypt, Decrypt, GenerateDataKey, DescribeKey.
• Konfigurieren Sie Ihr Identitätsmodell (IAM Identity Center wird empfohlen).
• Bestätigen Sie, dass sich das Konto in einer dedizierten Workload-Organisationseinheit (OU) mit Regionen-einschränkenden SCPs befindet.

Schritt 3: ACL-fähige Knowledge Bases erstellen (Tag 3–7)

• Klassifizieren Sie Ihre Datenquellen: PHI, PHI-nah und nicht-PHI.
• Erstellen Sie Knowledge Bases mit aktivierter ACL-Erkennung für PHI- und PHI-nahe Quellen.
• Ordnen Sie den Identitätsspeicher den Quellberechtigungen zu und validieren Sie dies mit mehreren Testbenutzern.
• Überprüfen Sie, ob die Sync-Protokolle eine erfolgreiche Ingestion bestätigen. Halten Sie PHI-Knowledge Bases von allgemeinen Inhalten getrennt.

Schritt 4: Spaces erstellen (Tag 5–8)

• Trennen Sie PHI-nahe Spaces von Spaces für allgemeine Produktivität.
• Fügen Sie Knowledge Bases, Dashboards und Action-Connectors hinzu. Beschränken Sie die Mitgliedschaft.
• Bestätigen Sie, dass unbefugte Benutzer blockiert werden.

Schritt 5: Benutzerdefinierte Agents mit Guardrails erstellen (Tag 7–12)

• Definieren Sie den Zweck jedes Agents eng. Fügen Sie nur die Wissensquellen hinzu, die er benötigt.
• Konfigurieren Sie PII-Schwärzung, blockierte Themen, Inhaltsfilter und Grounding-Kontrollen.
• Testen Sie mit normalen Abfragen, Grenzabfragen und adversariellen Prompts.
• Dokumentieren Sie Ergebnisse und Maßnahmen zur Behebung.

Schritt 6: Action-Connectors konfigurieren (Tag 10–14)

• Beginnen Sie im Nur-Lese-Modus für PHI-nahe Daten. Begrenzen Sie jeden Connector auf bestimmte Ressourcen.
• Speichern Sie Anmeldeinformationen in AWS Secrets Manager mit aktivierter Rotation.
• Dokumentieren Sie die Begründung für jeden Schreibzugriff. Holen Sie die Freigabe der Sicherheitabteilung ein, bevor Sie ihn aktivieren.
• Testen Sie die Bereichsgrenzen, um zu bestätigen, dass Connectors nicht auf Ressourcen außerhalb ihres vorgesehenen Bereichs zugreifen können.

Schritt 7: Audit, Aufbewahrung und Monitoring konfigurieren (Tag 12–16)

• Aktivieren Sie CloudTrail- und CloudWatch-vended Logs.
• Wenden Sie Datenschutz-Masking an. Legen Sie die Aufbewahrung auf mindestens sechs Jahre fest. Aktivieren Sie S3 Object Lock.
• Konfigurieren Sie Alarme, aktivieren Sie Security Hub und integrieren Sie Ihr SIEM.

Schritt 8: Validierung mit der InfoSec-Abteilung (Tag 14–21)

• Stellen Sie das Evidence-Paket zusammen: BAA-Bestätigung, KMS-Konfiguration, Identitätseinrichtung, Datenklassifizierung, Testergebnisse und Protokollbeispiele.
• Führen Sie eine Tabletop-Übung zu einem Datenschutzvorfall durch.
• Präsentieren Sie Ihrem InfoSec-Team. Beheben Sie die Feststellungen. Holen Sie die Freigabe ein.

Expansionsphase (Wochen 4–8)

Beginnen Sie mit nicht-PHI-Workflows: Policy-Fragen und Antworten, Dokumentensuche, Meeting-Vorbereitung, Workflow-Automatisierung. Diese ermöglichen es Ihrem Team, Vertrauen in die Plattform aufzubauen, bevor PHI ins Spiel kommt.

Erweitern Sie dann auf PHI-nahe Workflows: Unterstützung bei der klinischen Dokumentation, Claims-Verarbeitung, vorherige Genehmigung, regulatorische Fragen und Antworten, Erstellung der Patientenkommuinikation mit menschlicher Überprüfung im Prozess.

Genau überwachen: Chatprotokolle wöchentlich prüfen, Auslöseraten von Guardrails verfolgen und Zugriffsmuster 30 Tage nach Inbetriebnahme jedes neuen Workflows beobachten.

Fazit

Amazon Quick bietet regulierten Gesundheitsorganisationen und den Business Associates, die sie betreuen, einen verwalteten KI-Arbeitsbereich, der über seinen gesamten Funktionsumfang hinweg HIPAA-fähig ist: agentische KI, Wissensabruf, Business Intelligence, Automatisierung und Recherche.

Der Weg zu einer konformen Bereitstellung folgt einer klaren Abfolge:

1. Verstehen Sie den Unterschied zwischen fähig (eligible) und konform (compliant) und übernehmen Sie Verantwortung für Ihre Seite der geteilten Verantwortung.
2. Schließen Sie die BAA für ein Konto ab, das über die AWS Management Console bereitgestellt wurde.
3. Legen Sie zuerst die irreversiblen Kontrollen fest: KMS-Schlüssel, Identitätsmodell, ACL-fähige Wissensbasen.
4. Minimieren Sie die Lese- und Aktionsflächen des Agenten, setzen Sie Least Privilege durch und maskieren Sie PHI in Protokollen.
5. Validieren Sie mit Ihrem InfoSec-Team und skalieren Sie dann von Non-PHI- zu PHI-nahen Workflows.

Die Compliance-Anforderungen entwickeln sich so schnell wie die Technologie. AWS hat seine vier Sicherheitsprinzipien für agentische KI im April 2026 und die Well-Architected Agentic AI Lens im Juni 2026 veröffentlicht. Organisationen, die heute auf deterministischen, infrastrukturellen Kontrollen aufbauen, werden wahrscheinlich gut positioniert sein, wenn die regulatorischen Anforderungen mit dem aufholen, was agentische KI leisten kann.

Wie es weitergeht

Wenn Sie Amazon Quick evaluieren: Fordern Sie ein Compliance-orientiertes Briefing von Ihrem AWS-Kontoteam an. Fragen Sie nach dem Umfang der BAA, der geteilten Verantwortung für agentische KI und den neuesten HIPAA-fähigen Serviceergänzungen.

Wenn Sie bereit zur Bereitstellung sind: Verwenden Sie den Implementierungsleitfaden als Projektplan. Die irreversiblen Entscheidungen in Schritt 2 verdienen eine eigene Architekturprüfung, bevor Sie mit der Erstellung von Ressourcen beginnen.

Wenn Sie Amazon Quick bereits betreiben: Prüfen Sie Ihre Bereitstellung anhand der Best Practices in diesem Beitrag, insbesondere der agentischen Sicherheitsprinzipien und der Liste bekannter Einschränkungen.

Für Architekturberatung wenden Sie sich an Ihren AWS Solutions Architect oder das AWS Healthcare and Life Sciences Team.

Über die Autoren