← Resources
USECASE · 2026-03-12
Private KI für das Gesundheitswesen: HIPAA-konforme Workspaces ohne Cloud-Lock-in
HIPAA-konforme KI erfordert nicht das Versenden von PHI an ein Drittanbieter-Modell. Ein On-Device-First-Workspace mit optionalem BYOK-Cloud-Fallback, Audit-Logs, RBAC und einem unterzeichneten BAA, wo immer Cloud berührt wird, kann die meisten Anforderungen von Covered Entities erfüllen.
Was HIPAA tatsächlich von einem KI-Assistenten verlangt
*Dieser Artikel ist allgemeine Orientierung und keine Rechts- oder Compliance-Beratung; der Privacy Officer Ihrer Covered Entity hat das letzte Wort.*
HIPAA wurde rund um die Daten geschrieben, nicht um das Tool, das sie liest, sodass ein KI-Assistent wie jedes andere Mitglied der Belegschaft oder Business Associate behandelt wird, das geschützte Gesundheitsdaten berührt. Die Privacy Rule regelt zulässige Nutzungen und Offenlegungen von PHI und den Minimum-Necessary-Standard. Die Security Rule verlangt administrative, physische und technische Schutzmaßnahmen, einschließlich Zugriffskontrolle, Audit-Kontrollen, Integrität, Übertragungssicherheit und einer dokumentierten Risikoanalyse. Die Breach Notification Rule legt die Pflicht fest, betroffene Personen, HHS und bei größeren Vorfällen die Medien zu benachrichtigen, wenn ungesicherte PHI ohne Autorisierung offengelegt werden.
Jüngste HHS-Regulierung hat signalisiert, dass KI-Systeme, die ePHI erstellen, empfangen, vorhalten oder übertragen, wie jedes andere Asset inventarisiert und risikoanalysiert werden müssen, mit Verschlüsselung während der Übertragung und im Ruhezustand, Multi-Faktor-Authentifizierung und zeitnaher Incident Response. Die Pflicht ändert sich nicht, weil die Entität, die die Akte liest, ein Modell ist.
Wo ChatGPT, Copilot und Gemini für PHI zu kurz greifen
Ab Werk sind die Consumer-Stufen von ChatGPT, Microsoft Copilot und Google Gemini nicht für PHI geeignet. Free- und Standard-Abos kommen ohne Business Associate Agreement, und Prompts können nach den Standardbedingungen vorgehalten oder zur Modellverbesserung verwendet werden.
Die Nuance ist wichtig: Jeder Anbieter bietet Enterprise-Konfigurationen, die unter ein BAA gestellt werden können. OpenAI unterschreibt BAAs für die API und für ChatGPT Enterprise oder Edu über vom Vertrieb verwaltete Konten. Microsoft bietet BAA-Abdeckung für Azure OpenAI Service und bestimmte Microsoft-365-Copilot-Tenants, obwohl GitHub Copilot und andere Consumer-Oberflächen ausgeschlossen sind. Google unterstützt ein BAA für Gemini innerhalb qualifizierender Workspace-Stufen, schließt aber NotebookLM und die Gemini-in-Chrome-Oberfläche ausdrücklich aus.
Das praktische Risiko ist Belegschafts-Drift. Eine Ärztin, die eine Entlassungszusammenfassung in einen kostenlosen Chatbot-Tab im Browser einfügt, ist standardmäßig eine Offenlegung außerhalb jedes BAA, unabhängig davon, was der Enterprise-Vertrag besagt.
Die On-Device-First-Architektur: lokales Modell + Opt-in-BYOK
Eine Architektur, die HIPAA-Exposition minimiert, kehrt das übliche SaaS-Muster um. Das Standardmodell läuft auf dem Gerät des Users, typischerweise ein quantisiertes Open-Weights-LLM, das lokal bereitgestellt wird, sodass Prompts und Generierungen den Endpunkt nie verlassen. Wenn eine Ärztin ein stärkeres Reasoning-Modell braucht, kann der Workspace auf einen Cloud-Anbieter mit dem eigenen API-Schlüssel der Organisation zurückfallen, unter dem BAA dieses Anbieters, mit einem expliziten Pro-Request- oder Pro-Workspace-Opt-in.
Das ist das Muster hinter osFoundry: Ein lokales llama.cpp-Runtime ist die First-Class-Voreinstellung, und jeder Cloud-Call ist Bring-your-own-key gegen einen Anbieter, den die Covered Entity unabhängig kontrahiert hat. Es gibt keinen geteilten Multi-Tenant-Inferenz-Pool zwischen Ärztin und Modell.
Der Compliance-Vorteil ist konkret. Workloads, die lokal bewältigt werden können, erzeugen nie ein Cloud-Offenlegungs-Ereignis. Workloads, die Cloud-Kapazität benötigen, werden verfolgt, sind zurechenbar und unterliegen dem BAA, das die Covered Entity bereits geprüft hat.
Audit, RBAC, DLP und Minimum-Necessary in der Praxis
Technische Schutzmaßnahmen sind dort, wo die meisten KI-Piloten ihr erstes internes Audit nicht bestehen. Vier Kontrollen leisten die Hauptarbeit.
Audit-Logs müssen erfassen, wer geprompted hat, welches Modell geantwortet hat, welche Datenquellen angehängt waren und was zurückkam, mit manipulationssicherer Speicherung und einem Aufbewahrungsfenster, das Ihrer Datensatzaufbewahrungsrichtlinie entspricht. RBAC sollte Modellzugang, Datensatzzugang und Tool-Zugang an die Jobrolle binden, sodass ein Empfangstresen-Konto kein Onkologie-Korpus abfragen kann und eine Abrechnungsrolle keinen Generator für klinische Notizen auslösen kann.
DLP gehört an die Prompt-Grenze. Muster- und klassifizierer-basierte Redaktion von Identifikatoren vor jedem Cloud-Call setzt den Minimum-Necessary-Standard programmatisch durch, statt nur durch Schulung. Pro-Workspace-Datenresidenz hält die Daten einer Praxis von denen einer anderen getrennt.
Keine davon sind KI-spezifische Erfindungen, aber zusammen sind sie das, was einen Privacy Officer dazu bringt, ein Modell, das eine Akte berührt, freizugeben.
Drei Workflows: Aufnahmenotizen, Vorautorisierung, Ops-Q&A
Aufnahme- und Besuchsnotizen sind der wertvollste lokale Workload. Eine Ärztin diktiert, ein lokales Modell entwirft eine strukturierte Notiz, und nichts verlässt das Gerät, bis die Ärztin unterschreibt und die EHR einen geposteten Datensatz über ihre bestehende Schnittstelle empfängt. Die Latenz ist auf einem modernen Laptop akzeptabel und die PHI-Angriffsfläche ist nur das Gerät.
Die Vorautorisierung profitiert von Retrieval. Das Modell stellt einen Briefentwurf aus der Patientenakte und den veröffentlichten medizinpolitischen Dokumenten des Kostenträgers zusammen, mit Zitationen. Wenn ein stärkeres Cloud-Modell zum Entwerfen aufgerufen wird, wird der Aktenauszug an der Prompt-Grenze de-identifiziert und nach der Rückgabe der Antwort auf dem Gerät re-identifiziert.
Operationelles Q&A über HR-Richtlinien, Abrechnungscodes und SOPs braucht selten überhaupt PHI und kann vollständig auf lokalen oder Cloud-Modellen mit PHI-blockierendem DLP laufen. Workloads so aufzuteilen, hält den höchstrisiko Traffic auf dem Gerät und den niedrigstrisiko Traffic in der Cloud.
BAA und Anbieterrisiko: was man jeden KI-Anbieter fragen sollte
Arbeiten Sie vor der Unterzeichnung eine kurze Liste durch. Wird der Anbieter ein BAA ausführen, das genau die Produktoberfläche abdeckt, die Sie nutzen werden, nicht ein verwandtes Produkt? Welche spezifischen Endpunkte, Modelle und Konsolen sind im Geltungsbereich, und welche sind schriftlich ausgeschlossen? Was ist die Datenaufbewahrungs-Voreinstellung für Prompts, Completions, Embeddings und Fine-Tuning-Artefakte, und kann sie auf null gesetzt werden?
Fragen Sie nach der Subprozessoren-Liste und dem Mechanismus für Benachrichtigung bei Änderungen. Bestätigen Sie Verschlüsselung während der Übertragung und im Ruhezustand, die Schlüsselverwaltungs-Haltung und ob kundenverwaltete Schlüssel verfügbar sind. Verlangen Sie Breach-Benachrichtigungszeiten, die es Ihnen erlauben, Ihre eigene 60-Tage-Patientenbenachrichtigungspflicht mit Spielraum zu erfüllen.
Fordern Sie das jüngste SOC 2 Type II und jede HITRUST-Attestierung an, die Penetrationstestkadenz und das Incident-Response-Runbook. Bestätigen Sie schließlich schriftlich, dass der Anbieter keine gemeinsamen Modelle auf den Daten Ihres Tenants trainieren wird.
Pilot-Rollout in 30 Tagen
Woche eins ist Scoping. Der Privacy Officer, ein klinischer Sponsor und IT wählen zwei oder drei Workflows aus, schreiben das Datenflussdiagramm und aktualisieren die Risikoanalyse. Identifizieren Sie, welche Schritte rein lokal sein können und welche Cloud erfordern, und bestätigen Sie die BAA-Abdeckung für jede Cloud-Oberfläche.
Woche zwei ist Provisionierung. Stellen Sie den Workspace mit RBAC-Rollen bereit, die auf Jobtitel gemappt sind, aktivieren Sie Audit-Logging an Ihr SIEM, konfigurieren Sie DLP-Redaktionsregeln an der Prompt-Grenze und laden Sie das lokale Modell auf Pilot-Geräte. Dokumentieren Sie den Rollback-Plan.
Woche drei ist ein beaufsichtigter Pilot mit fünf bis zehn Ärzten. Verfolgen Sie eingesparte Zeit, Fehlerrate gegen ein menschlich geprüftes Gold-Set und alle DLP-Auslöser. Halten Sie eine Mittwoch-Review mit dem Privacy Officer ab.
Woche vier ist das Go oder No-Go. Aktualisieren Sie Richtlinien- und Schulungsmaterialien, finalisieren Sie die KI-Nutzungsoffenlegung an Patienten, wo zutreffend, und entscheiden Sie über Expansionskriterien für die nächste Kohorte.
Frequently asked questions
- Vermeidet das Ausführen eines Modells auf dem Gerät die Notwendigkeit eines BAA vollständig?
- Für die lokale Inferenz selbst ja, weil keine PHI an einen Dritten offengelegt werden. Sie müssen weiterhin die Rolle des Softwareanbieters berücksichtigen. Wenn das lokale Runtime, die Workspace-Shell oder jede Management-Plane PHI über Telemetrie, Logs oder Support-Sessions empfangen könnte, agiert der Anbieter als Business Associate und ein BAA ist angemessen. Das sichere Muster ist, schriftlich zu bestätigen, dass der Anbieter standardmäßig keine PHI vom Gerät empfängt, und jede optionale Telemetrie zu deaktivieren, die Inhalte tragen könnte. Cloud-Fallbacks erfordern immer ein BAA mit dem Cloud-Modell-Anbieter.
- Können wir ChatGPT, Copilot oder Gemini überhaupt in einem HIPAA-Workflow verwenden?
- Ja, aber nur auf den spezifischen Enterprise-Konfigurationen, die der Anbieter unter einem BAA abzudecken vereinbart hat, und nur für die in dieser Vereinbarung ausdrücklich benannten Oberflächen. OpenAI deckt die API und bestimmte ChatGPT-Enterprise- oder Edu-Tenants ab. Microsoft deckt Azure OpenAI Service und qualifizierende Copilot-Tenants ab. Google deckt Gemini in qualifizierenden Workspace-Stufen ab, während NotebookLM und Gemini in Chrome ausgeschlossen sind. Free- und Standard-Consumer-Stufen sind nicht abgedeckt. Das härtere Problem ist Belegschaftsverhalten: Die Consumer-Oberflächen auf der Netzwerk- oder Browser-Schicht zu blockieren, zählt genauso viel wie der Vertrag.
- Wie unterscheiden sich Audit-Logs für KI gegenüber traditionellem EHR-Zugriff?
- Traditionelle EHR-Audit-Logs erfassen Datensatzzugriff nach User, Zeit und Aktion. KI-Audit-Logs müssen den Prompt, das Modell und die Version, den abgerufenen Kontext, die Antwort, den User, den Workspace und alle Tools, die das Modell aufgerufen hat, erfassen. Sie müssen auch Cloud-Routing-Entscheidungen erfassen, wenn ein BYOK-Fallback verwendet wird. Bewahren Sie diese neben EHR-Logs unter derselben Aufbewahrungsrichtlinie auf, speichern Sie sie in einem manipulationssicheren Speicher und führen Sie sie in dasselbe SIEM ein, das Ihr Sicherheitsteam bereits überwacht, damit KI-Aktivität Teil der normalen Incident Response ist und nicht ein paralleler Silo.
- Was ist mit den neuen Security-Rule-Änderungen für 2026?
- Jüngste HHS-Regulierung verschiebt mehrere zuvor adressierbare Schutzmaßnahmen in verpflichtende, mit stärkerem Fokus auf Verschlüsselung, Multi-Faktor-Authentifizierung, Asset-Inventar, das KI-Systeme einschließt, die ePHI verarbeiten, und engere Zeitfenster für Vorfallmeldungen. Behandeln Sie jeden KI-Assistenten als ein im Geltungsbereich liegendes Asset für die Risikoanalyse, dokumentieren Sie die Datenflüsse und bestätigen Sie, dass Ihr Incident-Response-Runbook die kürzeren Benachrichtigungsfenster einhalten kann. Stimmen Sie sich mit Ihrem Privacy Officer über die genauen Wirksamkeitsdaten und die Übergangserwartungen für Ihre Organisation ab, da sich die Durchsetzungshaltung und etwaige Verlängerungen nach der Veröffentlichung verschieben können.
Sources